When vendors contribute less than the open source community, trademarks become weak control mechanisms -- especially when a project founder remains active

The current situation with Oracle, the Hudson community, and Hudson project founder Kohsuke Kawaguchi sheds new light on the relative value of a trademark as an open source project control mechanism. Understanding the balance of power in community-driven projects can help IT decision makers avoid vendor lock-in.

Oracle controls the Hudson trademark

Controlling an open source project's trademark has given the controlling entity -- often a vendor -- significant influence over the project itself. For instance, it can provide control over the project's future direction or even something as seemingly mundane as where the source code will be hosted.

I previously covered the unfolding story about Oracle preventing the open source Hudson project from making project infrastructure decisions that the Hudson community wanted. As owner of the Hudson trademark (through the Sun Microsystems acquisition), Oracle is well within its rights to act as it has.

The central issue was that we couldn't convince Oracle to put the trademark under a neutral party's custody (such as the Software Freedom Conservancy), to level the playing field. In a project where the community makes commits two orders of magnitude bigger than Oracle, we felt such an arrangement is necessary to ensure that meritocracy continues to function.

The response from the community, users, and interested readers has been overwhelmingly supportive. Sacha Labourey, CEO of CloudBees, where Kawaguchi now works, extended an offer for Oracle to join the newly branded Jenkins community:

What about Oracle now? It essentially has two choices. It can either keep working on its own project under the good old Hudson brand, or it can participate as an equal player in the newly branded community. Personally, I'd really like to see Oracle join forces with the rest of the community.

Sacha's offer is important because it presents Jenkins not as a fork, but simply a rebranding. A fork would imply that there are now at least two viable competing project destinations for community members to contribute to and decide among.