WatersWorks

Blog archive

Reaction to Oracle's Move to Eclipsify Hudson, and What About Jenkins?

When I heard that Oracle would be proposing the Hudson project to the Eclipse Foundation, a few things struck me: 1) Oracle is getting better at dancing back from stepped-on toes in lively open source communities; 2) This is the very move IBM made when it created the Eclipse Foundation; and, 3) What will this move mean for the Jenkins fork?

During the first few years of the Foundation's existence, virtually all of my conversations with executive director Mike Milinkovich included a question about "demonstrating its independence" from IBM. I asked him if he thought Oracle's move would effectively satisfy concerns about Oracle's stewardship and perceived control of the Hudson project.

"Absolutely," he told me in an e-mail. "By the time the project is officially created, the 'Hudson' trademark will be the legal property of the Eclipse Foundation. The Hudson project will be a diverse, community-led project running under the Eclipse community’s development and IP processes and rules. Actions speak louder than words, and those are some pretty tangible actions."

Several companies are going to be providing development resources for an Eclipse-based Hudson project, including Sonatype, Tasktop and VMware. VMware's participation in particular will be a boost to the project, says Jason van Zyl, founder and CTO of Sonatype, because of the SpringSource connection. (VMware owns SpringSource.)

"Many users of Hudson work in the enterprise Java space so an endorsement and provisioning of resources for the Hudson project by SpringSource is a huge vote of confidence," he said.

As for the Jenkins fork, "If this move had happened some months ago, it may have prevented [it]," Milinkovich said. "But at this point it's safe to assume that the split will remain. I am as interested as anyone to see how this will all play out."

Oracle's announcement likely came as a surprise to the Jenkins community. Oracle kept an unusually tight lid on this announcement. (I had to pinky swear to keep it under my hat until this morning to get an early briefing.) The Eclipse Foundation's director of marketing, Ian Skerrett, even tweeted an apology to @jenkinsci: "If anyone in the Jenkins community has questions about Eclipse feel free to contact me; sorry for your morning surprise."

IDC analyst Al Hilwa noted that the Jenkins community seemed to have been operating under the assumption that Oracle "was going to do some bad things with the code," and overreacted when they created the fork. "It may be time to come together again under one code base, now that it's under the Eclipse foundation," he said.

UPDATE: Hudson creator Kohsuke Kawaguchi just posted his reaction to the news today on his blog. He said the news was "quite a surprise," and added:

"[On the] one hand, I think this definitely shows the great success of the Jenkins project post divorce…. Were it not for the success of Jenkins, they wouldn’t be giving up the project…. But at the same time, I just wish Oracle saw that coming a few months earlier, while we were still seeking the middle ground. We were very interested in having the trademark moved under the custody of a neutral third party, but they were very clear that that’s not acceptable to them. And it also disappoints me that they decided not to reach out to the Jenkins community about this move, but I guess they are never really interested in working with us."

I asked Mik Kersten, CEO of Tasktop and founder of Eclipse Mylyn, what he thought this move would do for users of the popular CI tool and the growing population of plugin makers.

"For users the answer is straightforward," he said, "as Eclipse is a clear go-to place for enterprise-ready open source tools. For plug-in makers… Eclipse has very clear and hardened guidelines on APIs, which provide a significant benefit to any growing plug-in ecosystem. However, a key reason for the success of Hudson was a rapid pace of innovation in the plug-in ecosystem, which has, in part, come from Hudson’s permissive approach to committer rights." "

"The rate of innovation that comes from this kind of freedom of evolution will need to be combined with the API hardening needed by enterprise consumers," he continued. "Eclipse’s endorsement of GitHub as an extension of the Eclipse contribution ecosystem is one mechanism that could help combine the best of both worlds."

Posted by John K. Waters on May 4, 2011