BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Jenkins, Hudson and Eclipse

by Alex Blewitt on May 11, 2011 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Kohsuke Kawaguchi seems to being a bit disingenuous by William H

The fact that Oracle has put the Eclipse proposal on the table *before* the fork puts a very different spin on his and CloudBess' behaviour. I wonder how many people who voted in favour of the fork were aware of this.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by Stuart McCulloch

Speaking personally (I work on Hudson) I just hope both sides can start looking forward and not back...

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by Sacha Labourey

William,

I think you are being slightly misled here.

ORCL had shared with us at some point a write-up that contained a set of rules very much Eclipse-like (but *outside* of the EF). I mentioned to ORCL that I thought their proposal was very heavy compared to what the Hudson community had been doing to date (successfully), for no obvious gain and that a bunch of problems were NOT solved in the proposal, including IP ownership, trademark and CA - none of them being lightweight topics. Also, ORCL mentioned to us that the following licenses had issues and either rarely or never get approval at ORCL: GPL, LGPL, CPL, CDDL, MPL, EPL & NPL. (can you see the EPL in there?)

As you can see, this was not as simple as "an Eclipse proposal is on the table", it was an "Eclipse-like" proposal but with lots of the other problems unsolved.

I've seen the same pattern happen quite a few times, where the story tends to be bended "just a bit" in order to accommodate a smoother history flow. But since ORCL has the e-mails, they should just publish them next time they make such a claim, that way anybody can judge.

Cheers,


sacha

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by William H

Maybe. Obviously I have no way of knowing who is putting the spin on here - but Ted's comment is
"I have the emails stating our proposal, which was both Eclipse or an Eclipse-like process"

I wish InfoQ would clarify on this point.

In any event it doesn't seem to make any difference. You rejected it not for not being eclipse, but for being too heavyweight.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by Charles Humble

I wish InfoQ would clarify on this point.


Just so you know we have tried, but we've not been able to get sufficiently strong evidence one way or the other to date.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by Sacha Labourey

...

In any event it doesn't seem to make any difference. You rejected it not for not being eclipse, but for being too heavyweight.


It actually makes a big difference since it made you state: "Kohsuke Kawaguchi seems to being a bit disingenuous".

Eclipse and Licensing Decisions by Chris Aniszczyk

Although probably 99% of the projects at eclipse.org use a form of the EPL, some projects like JGit are under the EDL (www.eclipse.org/org/documents/edl-v10.php) only. The EDL is simply a BSD variant. In terms of what license to choose, that's a bit more complicated. If you're building an ecosystem, a weak copyleft license like EPL can protect your core code and force people to contribute back.

Hudson has not taken code from Jenkins by Duncan Mills

The statement "Certainly the current codebase has merged some of the post-fork code back into the Hudson codebase" is incorrect. No post-fork code has been merged in to Hudson core from the Jenkins codebase. Hudson has a strict policy about who can contribute code and where it comes from, with committers having to sign a contributor agreement and having ownership of the code that they contribute. To blindly merge code in from another project where there is no knowledge of the code quality or where the original contribution came from, would go against this entire process. It is simply not allowed.
Now in this respect I'm talking about the Hudson core. This may not be true for individual plug-in writers who merge their own code between the Hudson and Jenkins versions of the plugins, but that is less material as non-core plugins are not part of this proposed contribution to the Eclipse Foundation.

Re: Hudson has not taken code from Jenkins by Sacha Labourey

Duncan,

Do you realize that all code contributed by Kohsuke Kawaguchi to Hudson Core since he left ORCL - which represents the majority of his contributions to core during about 8 months - doesn't fit that requirement?

Cheers,


Sacha

Re: Hudson has not taken code from Jenkins by Duncan Mills

So you are saying that the actual Jenkins Fork took place at the moment in time that Kohsuke left Oracle? That does not jive with the established and well known facts. I repeat no post-fork code has been merged from Jenkins to Hudson which was the (incorrect) statement made in the article.
Any discussion about the IP of Kohsuke's contributions to the Hudson project is separate, and one for the lawyers.
Needless to say any contributor to Hudson (pre or post fork), where they can be identified, would need to be correctly credited in the codebase, this is part of the Eclipse process.

Re: Eclipse and Licensing Decisions by Stuart McCulloch

Thanks for the link Chris, I hadn't heard of the EDL before.

Re: Hudson has not taken code from Jenkins by Andrew Bayer

Hi Duncan -

Is the CA signatory list at sca.java.net/CA_signatories.htm actually up to date? Because there seem to be people contributing to Hudson core who haven't submitted it, so far as I can tell.

A.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by eduardo pelegri-llopart

My recollection was that the main reason that proposal didn't move forward is because it did not address the copyright/IP issues.

Re: Hudson has not taken code from Jenkins by Stuart McCulloch

I don't think that page is up-to-date, since I signed the OCA several months ago but my name isn't listed there.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by William H

It actually makes a big difference since it made you state: "Kohsuke Kawaguchi seems to being a bit disingenuous".

Ok I agree with this point. It certainly makes a difference to how I *perceive* Kawaguchi/Cloudbees behaviour, but I don't think it makes any difference in terms of how you would have behaved since you rejected the Eclipse process outright (at least the first time around).

As you rightly say, unless Oracle publishes its private emails (which is unlikely) no-one other than you and they can know the truth.

But for what it is worth I hope the Jenkins community makes a serious effort to re-join the Hudson project, because I don't think anyone wins with this madness.

Re: Hudson has not taken code from Jenkins by Alex Blewitt

Please see:

github.com/hudson/hudson/commit/dc7e05a4c33f709...

This change, by kohsuke on the 30th January, updated the Hudson logo to Jenkins.

Here is the reversion of that commit, on the 9th February by wjprakash:

github.com/hudson/hudson/commit/00b909928823a58...

So the Hudson history most definitely has code taken from Jenkins.

Re: Hudson has not taken code from Jenkins by eduardo pelegri-llopart

Would be useful to update the page; last time I fell behind on it, Jason had plenty to say about it :)

Re: Hudson has not taken code from Jenkins by Stuart McCulloch

FWIW, the change that added the Jenkins labels was committed by kk@kohsuke.org (at least according to java.net):

java.net/projects/hudson/sources/git/revision/d...

IIRC there was an automatic push/sync that someone had put in place before the fork, and maybe it wasn't switched off immediately. (People were still catching up with the various infra changes). So I assume Winston was just rolling back these commits - I can't remember any major code changes during that period, but the repository history will no doubt be double/tripled-checked as part of the Eclipse process.

Re: Kohsuke Kawaguchi seems to being a bit disingenuous by Sacha Labourey

...but I don't think it makes any difference in terms of how you would have behaved since you rejected the Eclipse process outright (at least the first time around).


Again, just to be accurate, the Eclipse-way was never proposed to us: just a rip-off of the process without any IP/CA/TM counterpart. Would people have reacted differently if their proposal also offered the IP/CA/TM? Most probably. The problem with that proposal is that there was no advantage, only disadvantages: not only was the DNA of the project deeply modified by the new process, but none of the hard problems were solved.


But for what it is worth I hope the Jenkins community makes a serious effort to re-join the Hudson project, because I don't think anyone wins with this madness


The problem is that this is not just about the "community" in an abstract way. This is about contributors, about specific individuals and their personal feelings are important.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

19 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT