The Hudson-ci.org Website has been closed down on Jan 31 2020, the update center is no longer available. Hudson, the ancestor of Jenkins, retires.
In this occasion, let’s go through the story of the first butler of the software industry.
- In the beginning was the Shell.
- From DamageControl descended Hudson.
- Enters Jenkins.
- Hudson goes to the Eclipse Foundation.
- A butler is retiring.
1. In the beginning was the Shell.
At the time Kohsuke Kawaguchi released on java.net Hudson’s first version, he was staff Engineer at Sun Microsystems.
Talking about the reasons, which brought him to write Hudson, Kawaguchi told some years later later:
“I was busy implementing the JAXB RI, I must have broken one too many builds… Wouldn’t it be nice if I can have a program make sure that the workspace always build?”
The first solution he found was very pragmatic:
# build.sh#!/bin/sh -ex
exec 2> $1
build.sh > build.log || mail
2. From DamageControl descended Hudson.
The breakthrough came after some time, as Kawaguchi discovered DamageControl, an automated integration server written in Ruby by Aslak Hellesøy, better known as the creator of Cucumber.
Similarly to the more popular Cruise Control , DamageControl was intended to automate the integration process by monitoring the team’s source code repository directly, giving the possibility to follow the software development practices of the continuous integration, as described by Kent Beck in his Extreme Programming manifesto some years before (s. Martin Fowler, continuous integration). DamageControl can be still found on GitHub.
Unfortunately, this software was very far away to represent the best fit solution.
In his book titled The Rails Way. The expert guide to building Ruby on Rails applications (Pearson Education, 2007), Obie Fernandez writes:
“In late 2004, I was consulting at one of the big American auto makers, alongside a good friend of mine, Aslak Hellesøy.[…] In a moment of questionable judgment, the team agreed to base our continuous integration system on a pet project of Aslak’s named DamageControl.
It was a Ruby-based version of the venerable CruiseControl server produced by our employer, ThoughtWorks. The problem was that DamageControl wasn’t quite what you’d call a finished product.”
Fernandez was not the only one, who experienced the limits of this software: also Kawaguchi had some problems with DamageControl. He told later: “UI was nice but as soon as I accumulated a few 100 builds it ground to a halt”.
“The way Stapler works is some what like Expression Language; it takes an object and URL, then evaluate the URL against the object. It repeats this process until it hits either a static resource, a view (such as JSP, Jelly, Groovy, etc.), or an action method.
This process can be best understood as a recursively defined mathematical function evaluate(node,url). For example, the hypothetical application depicted in the “getting started” document could have an evaluation process like the following:”
Scenario: browser sends "POST /project/jaxb/docsAndFiles/upload HTTP/1.1" -> evaluate(<root object>, "/project/jaxb/docsAndFiles/upload")
-> evaluate(<root object>.getProject("jaxb"), "/docsAndFiles/upload")
-> evaluate(<jaxb project object>, "/docsAndFiles/upload")
-> evaluate(<jaxb project object>.getDocsAndFiles(), "/upload")
-> evaluate(<docs-and-files-section-object for jaxb>, "/upload")
-> <docs-and-files-section-object for jaxb>.doUpload(...)
A that point, Kawaguchi had a simple idea: why not reimplement DamageControl, integrating it with Stapler and introducing a master/ slave architecture?
At October 3rd, 2004 the programmer made the first CVS commit: Hudson was born.
By the way, it is still possible to find traces of DamageControl in the Jenkins’ source code, for instance here.
At Februar 7th, 2005, Hudson 1.0 was released on java.net and a year later, the Tango icon set was adopted. In 2006 Hudson 1.15 looked like this:
In the late 2000s Hudson experienced increasing interest and was more and more supported from a large community of developers, aimed to improve its core and to extend its functionalities with a multitude of plugins.
At JavaOne conference in May 2008, Hudson won the Duke’s Choice Award in the Developer Solutions category.
3. Enters Jenkins.
At April 20th, 2009 Oracle announced the purchase of Sun Microsystems in a $7.4 billion dollar deal. The agreement was finalized on January 27th 2010.
Worried about the future of Hudson as an open source project, Kohsuke and many key Hudson developers demanded that Oracle leave them control of Hudson, including naming rights. Oracle declined it: the software giant had already filed a trademark in December 2010 to gain exclusive rights to the Hudson brand and start monetizing it with a commercial version.
This was the straw that broke the camel’s back and initiated the split.
Hudson was renamed Jenkins on January 29, 2011 with 214 votes to 14, and got out of control of Oracle. This triggered a mass exodus of key developers who distanced themselves from Oracle and adopted the Jenkins project, leaving Hudson.
4. Hudson goes to the Eclipse Foundation.
At May 3rd, 2011, in collaboration with major Hudson providers like Oracle and Sonatype, Eclipse made a formal proposal for the transfer of the Hudson project, including the core code and problematic brands, to the Eclipse Foundation. Hudson’s founder Kohsuke Kawaguchi saw in this a confirmation for Jenkins:
“When we were talking with Oracle to find a middle ground, they made it very clear that they have no intention of giving up the trademark control. But with this move, they clearly acknowledge that Oracle couldn’t keep up with the Jenkins project.”
At January 23rd, 2013 Eclipse announced the release of Hudson 3 and its inclusion in the Eclipse Foundation.
5. A butler is retiring.
During the last years, Hudson tried to survive, competing with Jenkins, without success. Taking a look to the google trends is self explanatory.
Since May 2016 there is no trace of active development on its repository org.eclipse.hudson.core.git.
So, it came to the 30th January 2020. Going on the website hudson-ci.org you could read the announce:
“You should configure your Hudson instances with the environment options hudson.model.DownloadService.never and hudson.model.UpdateCenter.never both set to true to stop the instance from trying to phone home for updates.
Your Hudson instances will of course continue to run, but there will be no further updates to Hudson itself or its plugins.
Thank you for your loyalty over the years…”