Sunday, January 30, 2011

The Hudson rename/fork. Part 1 - a question of fears and mis-communications

(Disclaimer: I am a registered Hudson developer, although I haven't commited much on the project. I use Hudson on site at most clients. I have always been interested in CI and am a former external contributor to the cruisecontrol project. I also voted yes to the fork/rename, for reasons I may explain in a further post)

For those who don't know, the renaming/forking of Hudson into Jenkins was decided a few hours ago, 214 votes against 14.
Although a lot will happen around those projects in the next future, I think it is important to have a look at this event right now.
To me, this renaming/fork symbolizes the big culture gap between open source and corporate driven projects, and I could add, between Sun (RIP) and Oracle.

The information I gathered here come from the different public documents found on the web and a few private conversations/communications with some of the main actors of Hudson's community.

I'll cut this post in 4 sections


The first 2 sections will be addressed in this document, the 2 later ones in a later post.



Note: This article contains mostly facts and a few personal opinions. I've tried to keep the facts in this document. There might some innaccuracies. If you find any, please accept my apologies if any and feel free to point them out.

I - The historical perspective



If you know all about Hudson's history, you might want to skip this section.

The key moments

  • Kohsuke Kawaguchi started Hudson end of 2004 as a hobby project. Kohsuke was working at Sun on various Java related projects (e.g. Jaxb)

  • the first public release that I know of was release 1.04, released on the 9th of February 2005, and weigthed 2.32M (!) [LINK]

  • Hudson has irregular releases up to early 2006, but from Februar of that year, hudson was released almost at least once a week, except maybe in June and early July 2006. I guess Kohsuke took some holidays !

  • Hudson quickly became one of the top community projects on java.net and was itself heavily used at Sun (over 15 servers in Sep 2007). I'll come back to that part later on.

  • in Mai 2008, Sun allowed Kohsuke to work on hudson full time. This was great news and probably not unexpected as Sun was at the time a full open source company and was seen this as a nice opportunity

  • April 20th 2009 Oracle announced it bought Sun. The acquisition was completed on January 27th 2010

  • Kohsuke announced it was leaving Oracle in the following early April, and registered hudson-labs.org a few days later (14-Apr-2010 05:05:13 UTC according to whois.net)

  • then in the past few months, things accelerated. The community took some decisions, Oracle others, and the clash grew. This article is a good summary, I'll let you read it's "The facts" section

  • I'll just note that on 2010.10.29 Oracle Oracle filled for the Hudson Trademark in Europe (application nb: 009482902) and on 2010.12.08 in USA.



II - analysing the problem



Rewind the few last weeks and watch the dominoes fall. The last moves are crucial.

At some point, Oracle registers the trademark (without notifying the community).
At about the same time they ask for co-ownership of the project on java.net. The community agrees "as a nice gesture". Then the java.net migration indicent is the straw that broke the camel's back. The community finally took the decision to move the mailing lists to google groups and the code hosting to github, because they needed a working solution.
From then on, the gap is there, and even if the 2 parties still exchange ideas, there's a communication gap, and that leads to the rename/fork.

Note that I keep talking about rename/fork. That's because the 2 parties don't agree on how to name the act. The developers, thinking the project is theirs, are simpling renaming the project to solve some legal issues, and move the infrastructure elsewhere. Oracle who intend to keep the name Hudson for their own version, considers this move a fork.

It's all a question of perspective. And to further understand the root of the problem, let's try to place ourselves from both perspectives.

I am a big fan of Non Violent Communication, and I will try to list here the actions each party took, and how these affected the feelings of the other party

  • once Oracle purchased Sun, they needed whether or not to keep the project running. Hudson was clearly a strategic asset to Oracle. I am not sure, but they probably increased the number of resources on the project. "We are here, trying to work in a community we have been part of for almost a year, trying to make it better for everyone and promote it's growth and potential." source

  • java.net is also strategic to Oracle. Understandably Oracle wants to federate the projects resolving around Java on this development platform.
    To me and many in the community this is irrelevant. Java.net is notorious for its instability, and for many the only reason we go there, is named "Hudson"... The rest of the world holds the most interesting java projects (Apache, Codehaus, github, Google code...).

  • keep in mind that a lot of people in the open source community fear what Oracle might do to the Open Source projects formerly owned by Sun. This summary (by Kohsuke's former boss) seems to indicate that some of these fears have some substance.

  • the Oracle Hudson trademark registration happening behind the back of the community, effectively 'breaking Sun's promise' doesn't help keeping trust between the parties. This happens a few days before Oracle asked to co-own the Hudson project on java.net. This combined with the java.net infrastructure upgrade incident, a move uniteraly decided by Oracle for the benefits of all, and the community feels that Oracle is asserting ownership of the hudson project.

  • by then, Oracle comes with many interesting issues regarding hudson: core licensing issues (over 10 OSS licenses gravitate over the core), quality/stability issues, reasons for enforcing the branding of the project, size of the community much bigger than what the mailing lists are seeing ("tip of the iceberg"), etc

  • but Oracle is feared and not trusted. The community reacts by making demands that Oracle can't accept. Transferring the trademark to a third party entity isn't accepted. Replacing the Oracle contributor agreement to something more balanced aren't things Oracle can't let happen that fast. This is Oracle, one of the biggest software corporation of the world. It purchased Sun right ?

  • then it is clear from Kohsuke's latest blog entry that the clash has now grown very emotional. According to him, Oracle asked him to "find something else to work on"(source). Hudson being his pet project to start with, and having used lots of free time on it, I understand he feels threatened in his rights, and a bit of lack of respect, from a company who's probably earning some money from that project.

  • you don't want the main reason behind a project to want to publicly ask for a fork/rename. Game over.



What I find interesting is that most arguments raised by Oracle are valid to me. Alone these could have been let aside for the moment. But the chain of events make this impossible.
And all arguments raised by the community are also valid! And those combined arguments can probably be solved in a manner satisfying by all. Yet the divorce is innevitable. The 2 parties can't listen to each other. Or at least the community cannot trust Oracle, and Oracle isn't clearing their fears.

Let me guess what happened here. Oracle probably assessed Hudson's status internally. And they asked their customers.
I can guess their sales department giving a few phone calls to big businesses. "You aren't using Hudson ? Why ?" And feeding the answers up to Oracle project managers and engineers who come up with a "Plan" to fix it all. Here are the issues to address: solve licensing, make the product more stable, etc... How is this solved ? By adding more control...
java.net sucks ? Oh yeah, let's move to Kenai. As for the risk of brand dillution ? Let's make sure Hudson means Hudson, trademark the thing to make sure we can control how the external people name hudson. And the Oracle machine moves on, implementing the decisions. For the good of the community.

Yet without talking with the community.

And when they talk, and show their plan, or try to keep the community on java.net, saying they're working in the project's best interest, it's already too late. They bring arguments that the community can't grasp. Oracle feels that their decisions are right: they are indeed proxying the voice of many of their users/potential customers! And they have probably done a bit of work to find this information and try to solve the issues.
Yet in an open source world, users are taken into account if they raise their voice. They should interact, or even better act!

The developer community, who feels they are properly answering to the community of users (the one they see), cannot accept this from a (currently) minor contributor. There's a culture gap. Oracle tries to manage Hudson as a product, the community is only interested in the project. The cathedral meets the bazaar.

Yet if you go back to each parties motives, you can see that most would benefit the project!


  • The community's motives


    • better infrastructure (DVCS vs svn, better lists, more control of their own tools)

    • independence of the community


  • Oracle's motives


    • provide compatibility and stability across instances of things calling themselves Hudson.

    • represent the voice of their many users

    • enforce quality through development process (commit reviews, developer agreement)

    • strong branding




Yet the means to resolve those motives aren't shared. Because of a lack of early communication and mistrust. Too bad.

What now ? I am hopeful that things will move forward in a positive manner and issues will settle. Whether engineers will work to make one or 2 very differing projects, I don't know yet.

One thing I know? People will shut up and code will talk. Long live Hudson, Long live Jenkins !

In a later post I will address the 2 next sections, i.e. previsions and learnings from this very interesting incident.

No comments:

Post a Comment