If you have ever looked at my blog, you know that I’m a huge advocate of Continuous Integration and have been pushing Hudson for several years now. The end of SUN unfortunately had a significant impact on many open-source projects, including Hudson. Support for Hudson continued to work pretty smooth from a user perspective until last December. I don’t think the quality of Hudson changed, but the quality of the releases seemed to change. The Hudson team had been extremely consistent with their weekly releases; the release notes were always updated, the download links always worked, life was good. As 2010 came to an end, something seemed to change; links pointed to the wrong versions, releases seems inconsistent, release notes were out of date or lagged days after. The most obvious indicator was that the community was very quiet… something was happening behind the scenes.
Fast forward to last week, an important vote was taken by the existing Hudson community. It overwhelming decided to break away from ORACLE, essentially forking Hudson into a new product called Jenkins. ORACLE apparently holds the rights to the Hudson name and has already revamped the Hudson website. It will be very interesting to see what happens next. I don’t think I’m a fan of forking. I lived through the remnants of the emacs/XEmacs split; where did that really get us? In the end, I think it is mostly about ego and control; as users, we ultimately end up being split into two camps, typically incompatible with lots of petty sniping. You can read this recent announcement from ORACLE and the follow up responses, it is pretty obvious that this was not a friendly breakup!
Question of the Day – Which side are you picking? |
I’m going with Jenkins.
|
Alternate Question of the Day – Which butler image will change first? |
They can’t be the same, right? I think Jenkins should get a new mascot, after all, it is a brand new world! And one small favor, please don’t make it Chuck Norris! |
I recently had the opportunity to create a couple Hudson plug-ins, this was a very educational experience! There is a lot of information available on the process, but unfortunately, I found it more valuable to walk through the code of existing plug-in implementations. I believe that one of the major advantages of the Hudson/Jenkins architecture is the plug-in infrastructure. With just a little bit of vision and support, teams (and organizations) could extend Hudson into so much more than basic CI server. All things take time…
I already have my Jenkin’s server up and running and hope to get it integrated with my GitHub account in the near future… I want to finish documenting my experience creating a custom plug-in, which I will hopefully share out with my sample implementation.