I came across this couple of times before and I always wanted to blog about it. In my daily work life I see many developers which just don’t get Open Source. For example, some discover issues in libraries they use. But they don’t fix them. They don’t even inform the maintainers of a library. Yet others have a great new use-case to address. Again, the library doesn’t support it. Thus, they write a great deal of new code to address their issue and eventually run into new ones (for example, see this thread).

But it’s that darn simple!

1. Checkout the library from source. You can use a well known tag/branch for this.
2. Get in touch with the maintainers and implement your modifications.
3. Build and release your modified version until a new official release is available.

I opened my RSS reader this morning and found a few more interestings posts from Bjorn, Doug and Micheal ind the Planet Eclipse feed. I really have to thank Bjorn for starting this  discussion. He raised some very good points. The posts I read also made me think more about it.

I do not agree with all the ideas. Well, I don’t have to. Especially I don’t like to see the Eclipse Foundation hiring Eclipse developers. But I have another idea. It’s not that of a big deal, i.e. we could tackle it today with the process we have in place. But it’s not a low hanging fruit either.

Think along the lines of the Runtime project. It’s a great project with a diverse committer community. I think we should archive the Eclipse project. Equinox already moved out. The desktop bits could move to the RT project as well. RAP is already there so SWT, JFace and parts of the workbench would be a good fit too. The IDE stuff, JDT, Help and Resources bits could move to the Tool project. e4 clearly is a Technology project. Why didn’t it start as such in the beginning? Is it all driven by the fear of one contributor?

I think you get the point. It’s not so important what we move where. I think it’s more important that we refactor the Eclipse project. It’s too large, too complex and too difficult for adopters to understand it and to get involved. We should listen to ourselves. It’s written in the Equinox whitepaper. I’d like to see more smaller components, which are developed and evolved independent from each other. That’s easier to handle and to develop than one large code base.

Don’t believe me? Checkout this. But seriously, I share some of the  concerns Doug raised. You know what, I really wonder how that works out with the processes we currently have in place. Let’s take for example the Eclipse IP policy. It requires that stuff is maintained on Eclipse.org infrastructure. Do our webmasters need to install and maintain their own cloud?

I’m in Frankfurt already. My plane will leave tomorrow at 10am Frankfurt time. Thus, I should be in the Hyatt in the afternoon.

Update, March 21, 5:30pm local time … I’m there.

There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.

There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work  in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.

The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.