John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 117 posts at DZone. You can read more from them at their website. View Full User Profile

Jenkins and Hudson: Butler Wars!

02.17.2011
| 6687 views |
  • submit to reddit

"You fought in the Butler Wars?" "Yes, I was once a Hudson developer, the same as your father..."

Who, in our field, has not heard of Hudson? And who has not heard of the recent fork, which sent echos of seismic proportions through the Open Source community? Lots has been written, by both sides, about this fork, so I won't dwell on the causes and events here. Rather, I want to discuss the implications of the fork for developers, and the future paths of each product.

Hudson rose from a hobby project to becoming by far the most popular CI tool on the market in the space of just a few years, largely because of its intuitive interface, ease of use, fast development pace, and extensibility. Indeed, despite some (technically valid) criticism of the internal Hudson architecture, Hudson plugin development has proved easy enough to allow a host of community developers to have written over 330 plugins, which have greatly contributed to Hudson's success in the past.

Since the fork, we have two very similar products on the market. In the blue corner, we have Jenkins (née Hudson), lead by Kohsuke Kawaguchi (the original author of Hudson) and other members of the Open Source community, commercially backed by Cloudbees, and followed by, it would appear, the large majority of the current Hudson developer community. Jenkins is already showing signs of continuing the same tradition of a very fast development pace, innovative features and the broad support of the plugin developer community that the original Hudson enjoyed. And, in the red corner, we have Hudson the elder, backed by Oracle and supported by Sonatype, who are already undertaking some major under-the-hood changes.

It seems a large number of the developers who wrote these plugins (the same who voted overwhelmingly for a name change from "Hudson" to "Jenkins") are presently shifting their development focus to Jenkins. In theory, most plugins should continue to work on both versions of the product, and I have no doubt that this will remain a high priority for the development teams of both versions. What remains unclear is whether these new plugin releases will be published to both update sites, or only to one (presumably the Jenkins update center).

The big wildcard, however, is Sonatype, who have chosen to side with Oracle and support the Oracle-branded Hudson version. One of the principle reasons behind this decision is certainly because this path makes it easier to integrate the (fairly significant) infrastructural changes that the Sonatype team would like to introduce to Hudson, in order to facilitate Hudson's integration with other Sonatype products, and thus provide a more integrated product suite for their clients. Fair enough indeed.

Indeed, most of the development work currently being done on Hudson (as opposed to Jenkins) seems to be being carried out by, and at the initiative of, Sonatype developers. This work involves deep structural changes, in the same spirit as the work done to migrate Maven 2 to Maven 3. Knowing the Sonatype team, this work will no doubt be done with a strong emphasis on backward compatibility, regression tests and stability. However, these infrastructure changes run deep, and I suspect it will take them a while to bear their fruits.

Oracle, on the other hand, is proclaiming very loudly that they are the true representatives of "the community", perhaps a little too loudly to be truly convincing. However, community discussion, tweets, mailing lists, and a recent poll seems to indicate a strong community preference for Jenkins. Indeed, despite coming into official existence less then a month ago, Jenkins gains around 60% of overall votes, over three times as many votes as the longstanding Hudson name which came in a distant second with around 17% of the votes.

The big question is, however, how many Hudson users have been actively following the Hudson/Jenkins fork, and how many of them will take the decision to go with Jenkins rather than staying with Hudson. The Jenkins developer have gone out of their way to make upgrading from Hudson to Jenkins easy and painless, but no action is generally easier than any action - people need a reason to make a change. The Hudson developers and plugin developers who voted massively for the name change do indeed make up only a small proportion of the Hudson user community - how accurately do they represent the broader Hudson user base, who may not be following the blogs, tweets and mailing lists with such close attention, and who may not even be aware of the existence of Jenkins? This is the user base that Oracle, boldly (and some would say pretentiously) claims to represent.

Time will tell how founded this claim is. However, the Hudson user community does not seem to be made of the same material as many other user communities - the Hudson user is by definition very technical and close to the development community, more akin to a MySQL DBA than an Open Office user.

What proportion of the Hudson/Jenkins user base rely on the approval of managers who would only trust a product with a big name behind it, even for an internal development team? Any what proportion are free to choose the tool they feel is the most appropriate for their uses? My feeling is that a majority of Hudson users, like the developer community, will stay loyal to the principles that made Hudson so popular: ease of use, a fast development pace, and a broad and active developer community, and therefore follow Jenkins. And, if Oracle lets them have their way, Sonatype will continue to develop a high-quality more Maven-specific Hudson variation designed to integrate smoothly with the other Sonatype tools. Time will tell how accurate this picture is, of course.

In the light of these changes, the Continuous Integration with Hudson book, soon to be published by O'Reilly, will be renamed "Jenkins: The Definitive Guide", though most of the material will still apply equally well to both products.

Some other interesting discussions of the Hudson/Jenkins fork and in particular of Sonatype's role can be found here and and here.

 

From http://weblogs.java.net/blog/johnsmart/archive/2011/02/16/jenkins-and-hudson-butler-wars

Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Dave Co replied on Thu, 2011/02/17 - 12:18pm

I am one that followed the Jenkins fork closely and even supported the community in their move away from Oracle. The game changer for me though was Sonatype throwing their support behind Hudson. Nexus and Maven have been rock solid for our usage internally and reading about their plans for infrastructure changes to Hudson made the decision easy.

I've found that updating Hudson was a roll of the dice. It may have introduced a bug that affected our builds and the next version that fixes that bug would be released a day or two later as a point release. Why? It's hard to say but based on Sonatype's analysis of the poor unit tests (and in Mac's case, the complete failure of unit tests) I'd guess a lot of the problems could have been caught before the update is ever released through simple unit testing.

For me, I feel much more secure knowing that a release of Hudson won't be made until a robust suite of unit test ALL pass.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.