Twitter github

My Thoughts on Hudson and Jenkins

The Jenkins community had a meeting yesterday, here are the minutes. As part of the meeting, there was discussion to see if there could be any reconciliation with the Hudson proposal at eclipse.org, they started a wiki page with their requirements.

I was mostly at the meeting to dismiss any false knowledge with how we operate at the Eclipse Foundation. There seems to be a lot of confusion that Eclipse is controlled by IBM and whatever evil companies you want to name, but that’s so almost a decade ago when Eclipse wasn’t a Foundation but a Consortium. If you take a peak at this year’s commit information so far, you see that individuals make up the most commits at eclipse.org so far (with IBM as a close second). Eclipse.org is a very professionally run open source organization that understands the line between commercial and open source offerings well, you won’t find many freetards here. You’ll find people who care deeply about developing quality open source software for companies and individuals alike. Just take a look at the eclipse.org membership rolls and you’ll see the amount of diversity. There’s an established development process called the Eclipse Development Process which gets refined every year or so and helps guide projects in the right direction to releasing quality software. In the end, each eclipse.org project is individually run by the committers and project leadership.

I have a selfish reason to have a great CI system at eclipse.org… we already are fanatical users of an older Hudson version for a lot of our eclipse.org projects (http://hudson.eclipse.org/) and having a project within the eclipse.org walls would allow for some nice dogfooding. On top of that, we have a great set of Mylyn Builds tools (see Mik Kersten’s blog entry) that allow developers to interact with their Hudson/Jenkins instances from within the Eclipse IDE. On top of that, the Eclipse community also has a lot of advice to share when creating a plug-in based ecosystem, from technology (e.g., OSGi) decisions to infrastructure to licensing.

In the end, it’s pretty comical that the Java ecosystem is large enough to damage itself like this. A prolonging fork of Hudson/Jenkins is a not an ideal solution for the future and having the projects reunited would be better in my humble opinion. Regardless of the decision, I hope people from both sides can put the politics and hard feelings aside and do what is right for your adopters, because at the end, you need to keep them happy, whether they are individuals or companies.

  • Slewis

    Chris: From reading the transcript of the meeting, I don’t see that there was a lot of ‘IBM control’ or ‘corporate evil’ comments during the meeting…but there were a lot of comments of the kind that ‘Eclipse’s process is too heavyweight’, ‘EF is good for companies but not communities/developers’…in addition to lots of concerns about whether the Hudson and Jenkins teams could work together at this point…and etc.

    I think the Eclipse Foundation (and the Board…especially committer reps) would do well to pay attention to those comments…as some of us have been trying to say for some time. As a project lead that knows the EF…these comments certainly have a point.

  • http://twitter.com/simach Simon Chemouil

    Hi Chris,

    Reading the wiki, it seems that some requirements the Jenkins community has for rejoining with the Hudson devs at Eclipse are incompatible with being an Eclipse project (e.g: not using the EPL, I’m guessing leaving the Hudson name won’t be OK with Oracle and Sonatype either, etc). It’s a waste not to have Hudson & Jenkins merge back, but right now the problem is with egos. It’s about acknowledging that the community that left Jenkins is the one that contributed most and had very valid reasons to fork. It’s also about them agreeing that Hudson has architectural problems and that Sonatype is actually doing something interesting about it.
    Also, I don’t think calling people freetards is going to help anything, but it might offend some developers, including within the current Eclipse community. 

    In any case, I hope something good will come out of this.

  • http://aniszczyk.org Chris Aniszczyk

    Even though 99% of projects at eclipse.org use EPL, it’s not a requirement. There are certain projects like JGit (which is EDL only) and others that are dual licensed under EPL/EDL. Sorry Simon, I didn’t mean to call anyone in particular a freetard, my point was that within eclipse.org’s walls, it’s a very professionally run organization. We have people coming from all walks of life, private sector, public sector and universities. Heck, we even people working on the same open source project from competing companies, which is awesome. I think we have a very pragmatic attitude towards open source at Eclipse and I want to be sure people are aware of that.

  • http://aniszczyk.org Chris Aniszczyk

    Well, I would like to know exactly what is heavyweight. If you complain without details, we can’t fix things. I am paying special attention to a lot of comments and have been doing a lot of work trying to build a bridge between the two communities. 

  • Slewis

    Heavyweight:  IP process (even with parallel IP).  Indigo participation requirement.  Eclipse Development Process.  New committer membership process (especially for independents).   Major and minor release process.  Enough details?

    RE: doing a lot of work to ‘build a bridge’…that’s great…but I would suggest that EF heal thyself…if it actually wants to be attractive to new projects that aren’t corporate member owned/controlled.