Sunday, 8 May 2011

My thought on the Eclipse proposal

It has been a very interesting week in Hudson/Jenkins land with the announcement of the Eclipse proposal. The responses have been very varied ranging from the thoughtful and constructive to lets-start-another-mudslinging match. Luckily the mudslinging part is much less this time, and seem to have died down quickly.

Before I get into the details, let me just say that nothing in the proposal changes my overall perception, I  remain fork neutral and any plug-in I develop will work on both if at all technically possible.

From my point of view I am mostly positive towards the proposal,

  • I think this is a good move, bringing it to eclipse can hopefully reduce some of the bad blood and knee-jerk reactions when people mention Hudson/Oracle, and in time this will hopefully manifest as better corporation between the two projects.
  • I am very pleased that this has made sonatype contribute even more to the open source version instead of hudson pro. :-)
  • It is nice to see that more companies are investing in Hudson, for people like me that tries to remain fork neutral it is good to see that the effort is not "wasted". 

but it does leave me with some concerns and questions:
  • One of mentioned reasons for going with Eclipse is the better governance model, but I haven't seen any explanation on how this governance will be performed except that 2 people are listed as project lead. Maybe it is just following a standard eclipse governance ? (which I haven't found the link for yet). Some basic clarification would be nice, like: Will it be the comiters  who are in control, or will there be some sort of governance board ? if a board how is the election process?
  • I can see why Oracle want to move to a neutral 3. party, but I haven't understood why eclipse and not something like Apache ? 
  • How will the re-licensing affect the possibility to port fixes between the forks ? my initial understanding is that since MIT code can be re-licensed as EPL but not the other way, fixes can be ported only from Jenkins to Hudson. Am I correct  ? 
  • One of my major concerns with this move is the requirement to use eclipse infrastructure. I haven't been a comitter to eclipse based projects so I am not overly familiar with it, but looking at it does appear somewhat dated compared to + github. I am especially concerned about loosing the easy fork and pull workflow. Are we really loosing that functionality entirely, and if so what  is the replacement?
  • Another of my concerns is that contributing to the core seems more geared towards company sponsored development, leaving less room for individual free-time contributors like me to help out or get a say in the development. Maybe it is just caused by my own lack of knowledge, but perhaps someone can clarify ?
  • I haven't seen any discussion on the developer mailing list or JIRA on how to replace the LGPL components. This discussion should be started.

So in summary: Good move, but more details should be posted

1 comment:

  1. Henrik,

    Thanks for the post. Those are good questions that I will try to answer briefly.

    With regard to governance, Eclipse is an independent, vendor-neutral organization that hosts 200+ projects. Individual projects are self-governing meritocracies managed under a project management committee (PMC). There is much documentation related to governance on our website. I would suggest starting here:

    As for why Eclipse rather than Apache, I cannot speak for Oracle. However, given that Oracle has a number of projects already at Eclipse (Dali, Gemini, EclipseLink,...), I can hypothesize that they are comfortable with our community and processes.

    The licensing question is a good one. I haven't considered that issue before and need to think about it.

    I don't know, so I can't really compare. Eclipse certainly does not aspire to be a generic forge, which is clear design goal difference. However, one thing I can say is that the Eclipse infrastructure is reliable - we've had better than 99.95% uptime for the last two years.

    The workflow will definitely change at least a little bit as a result of being at Eclipse. This is a logical conclusion from the fact that Eclipse has its own development and IP management processes that Hudson will need to conform with. That said, there are a wide variety of projects at Eclipse with a wide variety of release cycles, development conventions and the like. It will be interesting to watch how Hudson settles into Eclipse.

    As for "corporate development", there is absolutely nothing preventing individual contributors from getting involved at Eclipse and I would encourage you to do so.

    I hope this helps!