Over the past month my team and I have been working with some other members of the Hudson community to get resolution on some issues different members had. Oracle and some of our partners/customer's primary concern was around the licenses associated with some of the core technologies, and the lack of process w.r.t. software development, feature information/auditing, infrastructure decisions, etc. Cloudbees (Sacha Labourey & KK) and Andrew Bayer had issues around Oracle's ownership of the Hudson trademark. Below is my summary of those talks and some of the outcomes. I tried to keep this as brief as possible while attempting to leave nothing unclear, but there is a lot to cover.
Let's start with the process concerns. We have been discussing these issues with Andrew, Cloudbees, Dean Yu and Romain Seguy. This proposal outlines what came from those discussions. While there are some other issues we still need to work through, I think this represents the things we were in most agreement on and things many of us believed would help the Hudson developer and user communities. We would like to collect some additional feedback and plan on how to roll out some of this process in the next month or two. We believe it will add clarity, equality and openness to the community. With regards to the licensing of the core components, we talked about adding hook points to the core to allow some of the current technology to be substituted with different technology options. This would allow the community to address some of the Hudson core licensing concerns, and would also allow users to have the flexibility to use more standard technologies with the Hudson core.
The second topic we covered was around the naming rights of Hudson. I think there has been a lot of confusion around this topic so I would like to first try and clarify some of that here by listing some facts:
So with that in mind, here is a link to the naming proposal we have come up with. After reviewing about a dozen examples of how to do this, what we came up with is pretty simple. In a nutshell the proposal is, if you take a copy of the hudson-ci.war file from hudson-ci.org and don't modify it, you can add as many extensions and plugins as you like and package it all up and call it Hudson something (or a variant). If you write a plugin that works with the unmodified hudson-ci.war file you can publically call your plugin a Hudson plugin. The extensions and plugins that you write don't need to be contributed back to the community if you or your company decides you want to try to make money off of them. The reason we stayed away from the source code itself is that would introduce the need for a TCK to certify implementations. We thought that was too heavy-weight in this situation. Companies or users could also request specific trademark licenses for cases with changes to the Hudson core. We would just want to make sure those changes didn't cause plugin compatibility issues. This proposal is pretty straightforward and ensures that everything calling itself Hudson is the same to the end users and plugin writers.
Finally, I want to make two comments on Cloudbees & Andrew's proposal for a "re-branding" of Hudson. First, I don't believe there is any such thing as re-branding a community while part of that community still exists. We are talking about a fork, so IMO we should call it what it is. The only difference is whether or not you take the assets like mailing list and source repository away from the Hudson community when you start the fork. Secondly, the proposal is based on leaving Hudson how it has been, but only with regards to who gets to make the decisions and who controls it. The same proposal wants to change Hudson from how it has always been by dropping the OCA requirement and having us give up the naming rights. To me, that sounds like a contradiction and an unfair deal for Oracle.
As many of you have pointed out, there can be a fork at any time. If Oracle ever did anything that the community disagreed with, whether it was enforcing new rights on the Hudson name, or trying to muscle the community, the community could always fork at that point in time. That is one of the assurances against a corporation doing things like that.
Regardless of what happens with the fork/no-fork decision, Winston and the rest of my team along with many of our partners, customers and other members of the current Hudson community will continue to work on, support and improve Hudson for years to come. There are many ways to run an open source project. I think in order for Hudson to grow and reach more people the core community needs to grow and become more open and equal. I can appreciate that some people want to keep things the same as they have been up until now, with a very small group of people making all of the final decisions on things. That is their choice and they have the right to fork and do that.
I concede that my initial posting could have been handled better. I don't believe it was a indication of lack of understanding about OSS as much as it was that I was doing too many things at once and had tried to reach out to individuals beforehand without reply. I would really like to put all of the politics and drama behind us and focus on building software. That's what my team and I love to do.
Ted Farrell - Jan 2011
