Jenkins and Hudson: Butler Wars!
Jenkins and Hudson: Butler Wars!
Join the DZone community and get the full member experience.Join For Free
"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.
Opinions expressed by DZone contributors are their own.