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.
