When vendors contribute less than the open source community, trademarks become weak control mechanisms -- especially when a project founder remains active Credit: Dragos Asaftei / Shutterstock 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. Hudson community sides with founder This week, the Hudson community is being asked by project founder Kohsuke Kawaguchi and other project leaders to support their proposal of renaming the project Jenkins, thereby freeing them from Oracle’s control through the Hudson trademark. Kawaguchi writes: 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. Project contributions and founder brand outweigh trademark ownership Positioning Jenkins as a rebranding, not a fork, hinges on two important factors: The trademark controlling vendor’s contributions being outweighed by the community’s contributions to the project. The project’s brand remaining tightly linked to the founder’s personal brand. Both aspects hold for the Hudson project. Labourey states: The difference here is that Hudson has an “asymmetry” in its community: one of its community members, Oracle, claims it “owns” the brand and that every contributor has to sign a contributor agreement granting it a copyright license. This asymmetry is frequent in many projects (JBoss, Glassfish, etc.). Yet, what is less frequent is when the “owner” of such asymmetry contributes very very little intellectual property to the project (but receives a lot of free intellectual property from the contributors through the contributor license agreement). Although several key leaders exist for the Hudson project, few would argue that Kawaguchi’s personal brand is not intimately linked to that of Hudson and, soon, to Jenkins. This is especially true because Kawaguchi is involved in the day-to-day technical work and decisions of the project. In other projects, the founder becomes less and less involved in the day-to-day technical direction of a project to focus on other work items, such as the business surrounding the project. In these cases, even when the founder leaves or tries to start a competing project, the original project remains sufficiently viable despite the founder’s absence. Advice for IT decision makers I encourage IT decision makers to identify the control that a vendor has over an open source project, before making vendor-selection decisions. Project contributions and the use of contributions from valued community members should be given more importance in your decision than ownership of project trademarks. Even a vendor as large and established as Oracle is not immune to losing control over a community project. In this case, the fight over control is putting customers in an unenviable position of deciding between the vendor and the 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.” JavaSoftware Development