Some of the most successful open source projects have histories that transcend organizational boundaries. My first experience with this was AspectJ, which we launched as an independent open source portal out of Xerox PARC in 2000. In 2003 our DARPA funding dried up, but the user community was still growing. We moved the project to Eclipse, the leadership moved from PARC to IBM, then to SpringSource. Not one of the original committers remains. But Eclipse has allowed the project to thrive throughout these waves of change in commercial interests, community leadership and intellectual property (IP) ownership.
Today Oracle proposed to move Hudson to Eclipse. As a board member and long-time committer, I have an inherent bias towards Eclipse being a great place to grow frameworks and tools. But I also believe Eclipses track record is a strong indication of the foundations effectiveness at combining the interests of multiple vendors and community of plug-in builders and contributors, to the net benefit of all involved. Oracle owns the Hudson IP which they acquired via Suns initial investment in the project. IP ownership is a key factor that drives companies to innovate, in open or source and otherwise.
Open source projects additionally need governance that combines the interests of vendors and of the community. In moving the IP and governance of Hudson to Eclipse, Oracle has done the right thing for the long term success of this very popular Continuous Integration (CI) tool. Jenkins exercised the very important open source community right to fork, but in the process split the community. I in no way want to diminish what Kohsuke Kawaguchi created, and I have a deep and personal appreciation for the labour of love that open source projects like this require. But FUD ensued around the state of CI, and todays announcement of moving the project to a neutral body marks major progress. Consider the alternatives. As we learned with the rapid exodus off CruiseControl to Hudson, CI tools are a well understood space and easy enough to migrate between. If the differences between Hudson and Jenkins had grown sufficiently large and there was overall confusion and friction among the developer and corporate communities, this would have increased the demand for a new CI solution.
At Tasktop we follow the Application Lifecycle Management (ALM) stack needs of our customers, integrating open source, legacy and enterprise ALM tools rather than pushing a single stack. Since the announcement of the fork, we have been witnessing our customers frustration from the lack of a clear path forward from the current fragmentation and from the fear of downstream incompatibilities, or of betting on the wrong horse.
While we are happy seeing a heterogeneous and best-of-breed ALM ecosystem thrive, we are less happy about all of the duplicated effort this would involve, especially since there is so much work left to do on REST APIs of Hudson and its plug-ins, as well as in providing the IDE integration and ALM traceability needed to make Hudson a key component in modern ALM stacks. It would be counter-productive to split efforts in evolving the CI interoperability layer that we have been creating in Mylyn, which enables both IDE integration and traceability across builds, source code and tasks. Eclipse is a tried-and-true place to evolve this level of tool support around ALM tools such as Hudson, and we are looking forward to collaborating around the convergent evolution of Mylyn, Hudson and Git/EGit and other key ALM technologies.
While there may be many questions about this move, the proposal phase of the Eclipse Development Process makes the path forward clear. The next stage is soliciting input from the community-at-large. As I see Eclipse as a great home for this technology, I have agreed to mentor the project and look forward to the community discussions around this proposal and the increasingly central role of continuous integration in the ALM stack.
