Prediction #6: Continuous integration becomes central to deployment, Jenkins attacks Hudson with a chicken

How does a continuous integration (CI) tool named after a butler or two grab such a large market share when much more feature-rich and polished commercial counterparts exist? The naive answer is that it’s free. If you dig a bit deeper, the success of Hudson can be seen as part of a larger trend in developer-centric application lifecycle tools.

A growing number of open source tools have hit the mark in capturing developer collaboration and Agile lifecycle management practices. What has caused these tools to snowball in popularity is the rich ecosystems of extensions that they support. That combination has become lucrative to larger organizations wishing to increase the productivity of their developers. When an open source community starts smelling of money-making potential, a different breed of dog moves in. This can be a very good thing, as it is often the catalyst needed to move the project across the chasm to broad industry adoption.

The challenge for popular open source projects is to create a governance model that marries the interests of the project’s community with those of vendors supporting the project. The most successful open source projects are ones that manage this dichotomy without alienating either party. Spring, JBoss and MySQL won by having a single dedicated vendor managing commercial and community interests. Eclipse and Apache have created governance models that support the overlapping interests of multiple vendors. In the case of Hudson, with Kohsuke’s departure from Oracle, a split formed. In recent blog posts we’ve seen Kohsuke Kawaguchi, creator of Hudson, highlighting the community and the ecosystem of extensions that have made Hudson successful to date.

On the public forums, Oracle’s Ted Farrell has emphasized the importance of versioning, consistency and stability, which are relevant for taking Hudson to the next level of enterprise adoption. Both of these concerns need to be addressed. Over the coming year, extensible continuous integration is going to play a key role in both on-premise ALM stack modernizations and cloud-hosted ALM solutions. If you have a few grey hairs on your head, this may not sound new or noteworthy. A decade ago, we set up a CI build for AspectJ.org with CruiseControl and Ant and it is still running today.

More modern Mylyn CI builds are very similar, but running Hudson and Tycho. What’s interesting is that over the past decade the continuous integration loop has become the underpinning of build automation in the Agile development process. Easy extensibility has made CI servers a convenient hub for plugging a variety of ALM tools into the Agile build loop. We are moving away from a world where realses, code metrics, testing tools and deployment destinations are being configured by each developer within his or her IDE. Instead, the CI server is becoming the hub that holds the authoritative build specs, with developers attaching to the portion of the ALM artefacts that they need to work on for the current release.

Testing, quality, and metrics tools will increasingly use the CI server as the place to hook into the development process. In an upcoming prediction, I’ll discuss how combining task-focused workflow with continuous integration will prove to be a convenient abstraction for tool support that facilitates knowledge capture and sharing between Planning, Dev, Ops and QA.

All of this potential means that Hudson is a hot topic, and that Hudson’s consumers are scratching their heads on what to do about the Jenkins fork. Hudson’s success to date comes from the typical mix of passionate community leadership, open source extensibility and a vendor-sponsored marketing investment that helped create that community. The latter is often omitted from developers’ discussions, but now that we are in the later stages of open source maturity, a project’s access to marketing resources has become a key component to success. A case in point is the significant marketing budget of successful open source foundations, or that of the Mozilla Foundation’s, which is in the millions. In open source, community-centric passions drive projects to their initial critical. Then comes the point at which enterprise support, stability, and the ability for other vendors to invest in a project become relevant. These help a project to graduate from an early adopter community to the pragmatists who can establish an open source project as a de facto standard. For that to happen, a project must be bigger than the cult of personality around its founder, just as any organization must be bigger than its leader to thrive. But with the heart of the contributor community in his hands, and his brain more wired to the technical vision of the project than any other person’s on the planet, the founder is often required to drive major downstream innovations. In the year ahead, the existing consumers of Hudson will vote with their feet whether to go with the forked Jenkins codebase or with Hudson. The question will largely boil down to how stable the core of Hudson is, and whether upcoming changes to the core of Hudson that happen within Jenkins, and its key extensions, warrant a migration.

In the closer-knit community there will be a tendency to Jenkins, as represented two hundred community votes, the majority of which were in favour of the fork. But in the much larger end-user community the default will be resistance to change in the absence of major and clear value add to making the move. We’ve seen this on Eclipse with the overly slow migration of many plug-ins to e4, which brings incremental value add and only benefit. The large and more conservative consumers of Hudson will look to which corporate sponsor, Oracle for Hudson and the CloudBees startup for Jenkins, is providing better long-term assurance for their build infrastructure investment. There will be questions about Jenkins’ promise of neutrality. In the past, genuine open source project neutrality has only been achieved by large open source foundations with sufficiently diverse funding sources, and even then with mixed success. As such, while Jenkins is likely to see activity, Oracle’s Hudson is unlikely to go away and I predict that it will continue to be a major target of CI deployments through the year.

In the interim, as with the Emacs vs. XEmacs fork of the 90s, there will be some confusion and annoyance from those less interested in the drama. Thankfully John Ferguson Smart wrote his Continuous Integration with Hudson book in open source fashion, making it easier to refactor. If the divergence between the two projects is sufficient to fragment and fracture the community, there could be a large enough gap for a new open source CI system to join the scene, but it would take time for it to build up momentum. In the meantime, the usual API-level federation layer is likely to form so that plug-ins can support both tools, and we’re invariably going to be asked to create one in Mylyn. Most of the internet associates the name Jenkins with a certain Leeroy who went into a World of Warcraft battle wielding little more than an attitude and a chicken. I hope that in this battle less damage is done to the consumers of this otherwise winning CI technology.