BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Jenkins, Hudson and Eclipse

Jenkins, Hudson and Eclipse

This item in japanese

Bookmarks

With the recent proposal to move Hudson to the Eclipse Foundation, there has been speculation as to whether this will lead to a coming together of Jenkins and Hudson, or even whether the code can be relicensed under the EPL.

There has been a lot of anger from the Jenkins community (as seen on the comments threads) that they were not involved or included in the announcement to move to Hudson. And whilst several companies have put their approval to the move, CloudBees has not yet done so.

In fact, the proposal to move to the Eclipse foundation was on the cards before the fork occurred and rejected as too heavyweight a process. Whilst Jenkins has always been developed in a fast, iterative manner, Oracle and Sonatype wanted to bring regular releases and predictability to the process (something which has subsequently happened in the Jenkins community in any case).

InfoQ reached out to CloudBees for their view on the situation, and received responses from Hudson/Jenkins creator Kohsuke Kawaguchi and CloudBees CEO Sacha Labourey.

InfoQ: What are your thoughts on the proposed move to the Eclipse foundation, along with the domain and trademark?

Kohsuke Kawaguchi: We were very surprised. In a way, I see this as a validation of success of the Jenkins project, as I mentioned in my blog. When the divorce was happening, this was indeed one of the more contentious issues, and they were very firm that they cannot transfer the trademark to someone else - since this was actually the leverage they were using to get what they wanted from the community. I wish they chose to do this when we were talking, but as you say I suppose our efforts were needed to make Oracle feel that this transition is necessary. I think Eclipse foundation is a very reputable foundation that is known for vendor neutrality.

InfoQ: Existing code is copyright by both individuals and companies under the MIT license. Whilst this doesn't preclude the software being relicensed by the copyright holders, the (non-Oracle/Sonatype) Jenkins community owns a fair proportion of the recent code changes that were merged into Hudson. Does this match your understanding?

Kohsuke Kawaguchi: Yes, this matches my understanding.

 

InfoQ: If the Eclipse Foundation reached out to CloudBees with a request for relicensing under EPL in order to move the Hudson codebase to the Eclipse Foundation, would that be something you would be willing to assist or be actively uninterested in participating?

Sacha Labourey: CloudBees participates in the Jenkins community, and we have been pretty open about supporting whichever direction the Jenkins community wants to take. The MIT license is a more open license and less corporate-driven than Eclipse and we like that. We view it as more inclusive and open, but have no real objections to any open source license.

InfoQ: The proposal is, as it currently stands, a starting point only. It is open for others to join and participate. It has been noted this is vendor-heavy and community-light at this stage. Is there any interest in either CloudBees or other members joining as interested parties?

Kohsuke Kawaguchi: The Jenkins community is going to have a meeting on May 11th at 18:00 UTC on the Jenkins IRC Chat channel, and hopefully after that we'll know where the community stands on this issue. We are naturally considering all options, and CloudBees would stand behind how the Jenkins community decides.

 

For me personally, the "divorce" experience is still vivid in memory and wounds are still fresh that I'm feeling bit cautious. A lot of things get done in an open-source project via human relationships and trusts, and it's hard thing to rebuild.

InfoQ: How does the Eclipse model compare with the model that Jenkins is operating under at the moment? Are there any specific differences (or objections) to the way that Eclipse projects are run generally?

Kohsuke Kawaguchi: Eclipse projects have project leads, PMC, and committers. Jenkins project has a governance board and committers. There are some technical difference but I don't think there's a whole lot of difference in the way the project operates and the voting structure goes.

I think one key difference is the very low bar to a committer-ship in the Jenkins project. Historically, we didn't require people to hang around and prove themselves before we make them committers, and that helped us recruit more developers and get smaller changes into the codebase. We also kept plugin developers close to us, which acted as a funnel to bring in fresh blood to the community. This agility is in our DNA and helped make Hudson successful in the first place. That's why the Jenkins community is organized this way, to perpetuate what made us successful while allowing for balanced governance.

The last point is likely to be one of the contentious points for the Jenkins community. The Eclipse foundation has legal guidelines on when to become a committer, and there's signed paperwork which must happen prior to any commit access being granted, which can take a couple of weeks to complete. However, the proposal is to host the Hudson core at Eclipse, and leave plugins to be hosted elsewhere (for example, at GitHub) so the agility only affects the core runtime instead of the plugin contributors.

Another key point is one of project leadership. Many in the Jenkins community would not support a move unless Kohsuke was the project lead; but since no-one is discussing the issue on the project forums, the possibility hasn't arisen. However, the Eclipse process ensures that committers have equal voting in committer rights; something which wasn't felt in the pre-fork issues.

Ultimately, the Jenkins community will decide whether Jenkins will be part of the Eclipse Foundation, either as a coming together of projects or as an independent entity. Whilst Kohsuke and CloudBees are likely to heavily influence that decision, and most of the original blocking points have been resolved, the level of mistrust and process impedance mismatch may still be too big a divide to bring together.

Finally, if the Jenkins community decides to continue as a separate project under their own process, it is not clear whether Hudson will be able to move over to the EPL without consenting rights of the copyright holders that were not employed by an EPL organisation at the time. Certainly the current codebase has merged some of the post-fork code back into the Hudson codebase, so unless those copyright holders consent to use relicense under the EPL then it may not be possible to use those contributions as is.

Whether the Jenkins community is interested in combining with the Eclipse proposal or not, the end users (and plugin developers) would be better served by not having two forks to choose from.

Update: the Jenkins user meeting concluded today with a proposal to create a wiki with a list of conditions that would need to be met in order to come back together. Several users voted -1 on principle of moving to the Eclipse Foundation but there was some progress in discussions about what it would mean if Jenkins were to move to Eclipse or Apache. However, there was doubt whether the Jenkins community would want to work with the Hudson community. A decision will be made on the next meeting, on the 24th May.

Rate this Article

Adoption
Style

BT