Oracle hasn’t won many friends in open source communities since its acquisition of Sun Microsystems and Sun’s array of open source assets including MySQL, Java and OpenOffice. Oracle seems bent on continuing this trend with the growing Hudson open source project.

Oracle controls the Hudson project trademark
The Hudson open source project delivers a leading continuous integration server along with over 300 plugins to support building and testing a wide variety of software projects.

Then Sun employee Kohsuke Kawaguchi, and now a key member of CloudBees, which aims to bring Hudson to the cloud, founded the Hudson project. Kawaguchi worked on Hudson as part of his Sun duties. As such, Sun, and now Oracle, retained ownership of the Hudson trademark and intellectual property.

Kawaguchi remains co-owner of the project, along with Winston Prakash, an Oracle engineer assigned to replace Kawaguchi after his departure from Oracle.

The tension between community and company over project decision making
The Hudson project hosted its developer and user mailing lists and source code on Java.net. However, downtime and reliability issues at Java.net encouraged the Hudson developer community to propose moving the mailing lists to Google Groups. In parallel, Oracle, also unhappy with reliability issues with Java.net, decided to upgrade the Java.net infrastructure and migrate the Hudson project to the new Java.net infrastructure.

Unfortunately, an Oracle email notifying Hudson users and developers of this migration was not received as the sender was not subscribed to the mailing lists in question, and hence the emails were not delivered. As a result, Hudson developers have been locked out of the mailing lists and unable to access or update the source code for over a week.

Frustrated by the inability to access the Hudson source code, Kawaguchi proposed moving the source code to GitHub. Others supported the proposal on the developer mailing list, with no major objections raised for nearly a week. Then, Oracle’s Senior VP of Tools and Middleware, Ted Farrell, wrote the Hudson mailing list to express Oracle’s concerns:

For now, however, we are going to stay on the java.net infrastructure. We believe it is important for Hudson to stay connected with the rest of the java community, as well as take advantage of some of the cool changes we will have coming to java.net. Moving to GIT can be done while staying on java.net. It is not a requirement to move to GitHub.

Because it is open source, we can’t stop anybody from forking it. We do however own the trademark to the name so you cannot use the name outside of the core community. We acquired that as part of Sun. We hope that everyone working on Hudson today will do as they claim to want, and work with us to make Hudson stronger.

When Hudson developers questioned whether the Hudson community had the right to make decisions about where the source code would be hosted, Oracle’s Farrell clarified:

…what I am saying is that I believe the *final* decision of what to do with respect to infrastructure belongs to Oracle and that decision should be made according to the will of the community as it makes sense…We are not prohibiting the developer community from making decisions. In fact we are encouraging that they help form the decisions being made. The decisions just need to be checked with the realities of hosting the community and what is best for the growth of the Hudson ecosystem (eg. syncing with other projects, etc.)

Benefiting from the GitHub community
Oracle, as the owner of the Hudson trademark, is well within its rights to decide where the Hudson project source code and community interactions are hosted. This point, however is lost on the vast majority of Hudson users commenting that the development community should fork the source code under a new, non-trademark encumbered name.

The larger issue is Oracle insisting that simply using Git on the new Java.net is enough to meet the project’s needs; something that the Hudson developer community disagrees with.

Git is based on the notion of being able to fork code and later merge the forked code, along with any changes, back into the mainline code base. Kawaguchi had previously written in support of Git’s fork and merge later approach:

For example, many contributors in the Japanese community hesitate to ask for a commit access, for one reason or another, but they can fork and push changes and send me e-mail all right.

GitHub has become a gathering place for developers, as Hudson project contributor R. Tyler Cory tries to explain to Farrell:

…one of the primary reasons for selecting GitHub instead of one of the many Git hosts such as Gitorious (including Kenai) is the very low barrier to entry for a lot of developers these days. We had considered “self-hosting” the Git service but pooh-poohed that idea in favor of GitHub since having a GitHub account is almost as common as having a twitter handle or Gmail address.

Hosing on GitHub would give the Hudson project exposure to a much larger developer base from which to attract future contributions.

Judging by comments from Hudson project developers, there is little desire to fork the code and found a new project under a different name. However, Oracle’s insistence of keeping the source code on Java.net and not wishing to leverage the larger audience and collaboration found at GitHub leaves the Hudson developer community in a difficult position.

For the sake of the Hudson community, and Oracle’s open source credibility, let’s hope cooler heads prevail and Oracle executives see the benefit of accessing the larger GitHub community.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”