Oracle responds to Hudson/Jenkins fork

Kohsuke Kawaguchi created the continuous-integration tool Hudson in order to simplify agile Java development processes. Kawaguchi ran the project as he saw fit, moving forward quickly and pushing out quick, new releases. This helped to propel Hudson to an over 80% share of the continuous integration market for Java, according to a survey by Sonatype released earlier this year.

But while Kawaguchi moved forward without looking back, Oracle was growing more and more concerned about how the project was led.

Ted Farrell, Oracle senior vice president and chief architect, wrote in a statement to SD Times that “Oracle had an issue with how decisions about Hudson (code changes, committers, etc.) were being made. We were working those through the community with [Kawaguchi]. More recently, there were also concerns around how changes to the Hudson infrastructure were being made. As an example, on Nov. 22, Kawaguchi moved both the mailing lists and source repository to new infrastructure without consulting anyone, including Winston Prakash of Oracle, who was co-owner of the Hudson project.”

The real issue, wrote Farrell, was that Kawaguchi moved the project without input from the community, highlighting Hudson’s capricious nature.

“After several unanswered e-mails to [Kawaguchi] to discuss these changes, I posted to the community mailing list asking for the moves to stop until we could discuss the best way to implement the changes,” wrote Farrell. “We had heard multiple complaints from users and developers about the unpredictability of the Hudson project. We were trying to address those concerns. A slanted blog post misrepresented a lot of these points and incited a lot of confusion around the event. We never forbid moving to GitHub. In fact, I stated we were in favor of doing that, but wanted some time to think through the ramifications to everyone.”

Oracle decided it would exert its ownership of the Hudson name and try to force some more structure into the project. Kawaguchi did not take Oracle’s pressure lightly. At the end of January, he officially forked Hudson, calling the fork “Jenkins” (in keeping with the project’s butler theme). But that was not the end of the drama.

“First, I wanted to apologize for not being able to resolve the dispute with a more happy ending,” Kawaguchi said. “We’ve really tried hard, but in the end we just weren’t getting anywhere. While there are different ideas in OSS about how many people should contribute (cathedral vs. bazaar), I think it’s more widely agreeable that an open-source project needs to be a meritocracy, where one is valued by his contribution. So in the end, we concluded that the only way to get back to a productive structure is to avoid the only thing that Oracle owns, which is the name.”

Kawaguchi postulated that Oracle was so hostile to him because, as he put it, “I’m not working for Oracle? Seriously, it’s not entirely clear to me what was their problem with me. But from the tone of the e-mail, it was very clear that they don’t intend to have me lead the project in the same capacity. I think they wanted to feel in control of the project by making sure that they understand changes that go in. Using trademark to push for that is a wrong approach, in my opinion, but I really don’t know what made them so upset.”

To that, Farrell responded that Kawaguchi was a self-proclaimed dictator, and that this was unhealthy for Hudson.

“[Kawaguchi] called himself the ‘Benevolent Dictator of Hudson.’ We don’t think a healthy open-source community needs a dictator. [Kawaguchi] started the Hudson project. He is the reason it is what it is today. We are not disputing that,” said Farrell.

“We strongly believe, however, that for the community to grow and become a viable choice for enterprise-wide adoption, the community needs to be more open with how changes are made, as well as have a more formal structure around it regarding governance, release process, testing certification, etc.”

The break
So where does Jenkins go now? “Some of the technical problems raised by various people during the saga are valid, and I’d like to address those,” said Kawaguchi. “This includes things like the release process, so that we can also provide more stable, less frequently updated line of releases.

“Another effort that I’m deeply interested in is the effort to enable Jenkins’ plug-ins to be developed by other languages like Ruby and Python. The Ruby and Python communities have started adopting Jenkins a lot lately, and if we can let them write plug-ins in their own favorite languages, I think we’ll see a substantial boost in the plug-in community. I think that’s really great.”

So while Oracle pushes forward with its own version of the project, Kawaguchi and the former Hudson team are already well on their way to settling into the new fork. Kawaguchi said this fork will also give him and the team time to focus on issues Hudson has had for some time.

“I also want to focus on fixing the issues in the backlog. The tool has been very popular and we have a lot of [issues] to go through. The good news is that I’m already seeing a surge of new developers joining the project, partly thanks to [its inclusion on] GitHub. So I want to encourage more people to join us,” said Kawaguchi.

For now, the Jenkins project is moving along independently, but the development team has been considering a move to the Apache Foundation. So far, the Apache Foundation has been amenable to the idea of bringing Jenkins on board. Such a move would give the project both a foundation to watch over its legal and organizational issues, and would help to formalize the project as an independent open-source entity with no more fear of corporate takeover.

Oracle, on the other hand, has plenty of plans for the Hudson project. “I think the appeal of Hudson is its flexibility,” said Farrell. “Unlike many other continuous integration servers, Hudson is very pluggable, which makes it easier to adapt to the very different development environments that are found in companies today.

“There are things that our customers also don’t like about Hudson and have asked us to help resolve for them. These include its lack of predictable releases. A new version was posted almost every week. There was no issue tracking or detailed notes that would allow for users to see what changed (bug vs. feature), or get an idea of the impact to them. Also, there was no test suite run against any of these releases so quality was in question, and often an issue for users picking up a new release.

“The other big area is the licensing. Oracle, along with some of the other members of the Hudson community, would like to ship a version of Hudson, but currently the core has over seven open-source licenses associated with it, many of which are unfriendly to corporations. We have had multiple requests to clean up the code to have fewer, more friendly (e.g. MIT or ASL) licenses.”

So it would seem the drama has matured into a tale of two Hudsons: one that will be reliable and dependable, and another that will race toward the future at a breakneck pace. In the end, the biggest winners will be agile Java development efforts.