Why Jenkins is better off as an independent organization

One thing that has definitely moved me this year is the development around Jenkins / Hudson. I never even used either (although I am quite sure that I will during the 20 years of my remaining professional live), so I cannot even tell why it was moving me, but I definitely followed with real concern. May be, that it was due to the well known persons that are involved, including Kohsuke Kawaguchi (the guy who drove JAXB 2) as well as the founders of Sonatypehttp://www.blogger.com/img/blank.gif, Tasktop, and Cloudbees. May be that it was caused by the front built between the opponents, consisting of an open source community and Oracle, a corporation that nowadays enjoys much more weight than it requires. Whatever.

One point that definitely interested me has been whether the respective projects would join a larger organization or not. As it currently looks, Jenkins has decided to stay independently and not join, for example, Apache. OTOH, Hudson will be moved to Eclipse. My expectation is that Jenkins will be better off with it's decision.

It's not that I'd vote against big organizations in general. For example, I believe that Subversion's move to Apache has been
a good choice. In that case, the benefits of having a big daddy will outweigh the disadvantages like the need to following certain policies that are largely driven by a bigger community and close-to-corporate culture. I haven't got any personal experiences with Eclipse, but I'd expect that both the benefits and the weak points will be comparable for Hudson.

From my point of view, the power of Hudson/Jenkins is the unusual multitude of plugins. Name any source control or build system, programming language, repository or CMS: Chances are excellent that you'll find one or even more plugins that support it. This is most likely due to the architecture, most likely borrowed from Eclipse, which has had a phenomenal success in this regard. Consequently, the more attractive Hudson or Jenkins can be for plugin developers, the more successful they will be.

But fine grained access rights, tight control over legal aspects of code that enters and well defined policies aren't exactly what a bunch of completely different plugin developers requires. In contrary, the lower the hurdles are for adding a new plugin or publishing a new plugin release, the more attractive.

I can very well imagine that Sonatype, in particular, will do an excellent Job in driving Hudson at Eclipse. They have demonstrated their exceptional abilities with Maven, Tycho, or Nexus. In the medium term, I'd expect Hudson to be more visually attractive, perhaps easier to use and possibly will have a cleaner and mroe agile core. (That's some things they are doing really well.) But they won't be able to create and maintain plugins for just everything. My guess is that Jenkins will take the lead in terms of extension points (that's the part of the core that's driven by plugin developers), number of plugins and hence applicability in different situations. May very well be that Hudson can be the bigger commercial success, but Jenkin's big enough to counter.

Whatever the outcome, it will be interesting to follow. :-)