Proposal to move Hudson to Eclipse

by Mik Kersten, May 4th, 2011

Some of the most successful open source projects have histories that transcend organizational boundaries. My first experience with this was AspectJ, which we launched as an independent open source portal out of Xerox PARC in 2000. In 2003 our DARPA funding dried up, but the user community was still growing. We moved the project to Eclipse, the leadership moved from PARC to IBM, then to SpringSource. Not one of the original committers remains. But Eclipse has allowed the project to thrive throughout these waves of change in commercial interests, community leadership and intellectual property (IP) ownership.

Today Oracle proposed to move Hudson to Eclipse. As a board member and long-time committer, I have an inherent bias towards Eclipse being a great place to grow frameworks and tools. But I also believe Eclipse’s track record is a strong indication of the foundation’s effectiveness at combining the interests of multiple vendors and community of plug-in builders and contributors, to the net benefit of all involved.

Oracle owns the Hudson IP which they acquired via Sun’s initial investment in the project. IP ownership is a key factor that drives companies to innovate, in open or source and otherwise. Open source projects additionally need governance that combines the interests of vendors and of the community. In moving the IP and governance of Hudson to Eclipse, Oracle has done the right thing for the long term success of this very popular Continuous Integration (CI) tool.

Jenkins exercised the very important open source community right to fork, but in the process split the community. I in no way want to diminish what Kohsuke Kawaguchi created, and I have a deep and personal appreciation for the labour of love that open source projects like this require. But FUD ensued around the state of CI, and today’s announcement of moving the project to a neutral body marks major progress.

Consider the alternatives. As we learned with the rapid exodus off CruiseControl to Hudson, CI tools are a well understood space and easy enough to migrate between. If the differences between Hudson and Jenkins had grown sufficiently large and there was overall confusion and friction among the developer and corporate communities, this would have increased the demand for a new CI solution.

At Tasktop we follow the Application Lifecycle Management (ALM) stack needs of our customers, integrating open source, legacy and enterprise ALM tools rather than pushing a single stack. Since the announcement of the fork, we have been witnessing our customers’ frustration from the lack of a clear path forward from the current fragmentation and from the fear of downstream incompatibilities, or of betting on the wrong horse. While we are happy seeing a heterogeneous and best-of-breed ALM ecosystem thrive, we are less happy about all of the duplicated effort this would involve, especially since there is so much work left to do on REST APIs of Hudson and its plug-ins, as well as in providing the IDE integration and ALM traceability needed to make Hudson a key component in modern ALM stacks. It would be counter-productive to split efforts in evolving the CI interoperability layer that we have been creating in Mylyn, which enables both IDE integration and traceability across builds, source code and tasks. Eclipse is a tried-and-true place to evolve this level of tool support around ALM tools such as Hudson, and we are looking forward to collaborating around the convergent evolution of Mylyn, Hudson and Git/EGit and other key ALM technologies.

While there may be many questions about this move, the proposal phase of the Eclipse Development Process makes the path forward clear. The next stage is soliciting input from the community-at-large. As I see Eclipse as a great home for this technology, I have agreed to mentor the project and look forward to the community discussions around this proposal and the increasingly central role of continuous integration in the ALM stack.

72 Responses to “Proposal to move Hudson to Eclipse”

  1. Bob Bickel Says:

    You write “If the differences between Hudson and Jenkins had grown sufficiently large and there was overall confusion and friction among the developer and corporate communities, this would have increased the demand for a new CI solution.”

    I am wondering how this proposal solves the problem when it was done in a vacuum from the Jenkins community. I am not sure there was outreach to KK, in spite of your reverence for him. Time will see if Hudson becomes an Eclipse Project and what the Jenkins community decides to do. Just saying it is a bit a shocking proposal and supposition.

    Another take it or leave it moment from Oracle to the community, although a better step than previous moments…

    Bob Bickel
    Yes, Ted, I am on the board at CloudBees, where KK works and is a major contributor to the Jenkins project.

  2. Mike Milinkovich Says:


    I can certainly appreciate that this is comes as a surprise. As I am sure you can imagine, a great deal of work went into today’s announcement.

    Although the announcement is an event, the creation of a new project and community at Eclipse is a process. I think that we can all agree that hosting Hudson at Eclipse is an improvement over the status quo. I want to assure you, and everyone else involved in Jenkins, that Eclipse is an open and respectful community. None of us can say with certainty whether the Hudson/Jenkins rift can be healed. But we would all certainly welcome the conversation.

  3. Mik Kersten Says:

    Bob, as Mike points out, the proposal is a first step in this process. In the past it has often happened that only a subset of the community knows about a particular proposal, which is why the next stage is for the proposal to gather community feedback.

    I am guessing that the length of the full Eclipse Development Process (EDP) will have you responding that this process is overly onerous to be friendly to developers. But balancing the interests of vendors, users, and the contributor community is not simple, and as far as I know the EDP has put in place just in enough process to strike this balance and then get out of developers’ way.

  4. Geoff Says:

    Oracle continues to prove they have no idea what they are doing when it comes to open source and cultivating an open community…

  5. Mike Milinkovich Says:


    Thank you for your thoughtful and informed opinion.

    Others, of course, may respectfully disagree. And there are many paths to success, even for communities.

  6. steve Says:

    Yet another if-the-community-doesn’t-like-what-we-are-doing-we-will-throw-away-the-project-after-everyone-has-left-move like Oracle did with LibreOffice?

    Judging from the plugin maintenance status Oracle’s Hudson fork was already dead in the water the day after the community renamed the project. Why should the Eclipse foundation (except from playing the useful idiot for its leader IBM again) invest time and energy trying to resurrect a proprietary dead project, if the real one just lives on?

    This sounds much like some PR move after Oracle saw that there wasn’t much reason investing money into it after they alienated the whole community around it.

  7. Geoff Says:


    Thanks for your condescending response. My opinion is, in fact, informed, so save the disparaging remarks.

    Obviously, Oracle is hoping that there are many paths for success; they have already tried one with Hudson and failed, so they have no choice but to keep looking… However, dismissing the original community that was built around Hudson, is not likely to help them attain that goal.

  8. Mik Kersten Says:

    Steve: I think that Mylyn is one existance proof of the fact that Eclipse today is way beyond what you characterize as a “useful idiot for its leader IBM”. In the same way that Mylyn grew independently of IBM within Eclipse, so can other projects. Even using your argument of this being just a PR move were true, which I think is unlikely, there would still be major and very positive implications implied by this proposal as compared to any other outcome that I can think of.

    Geoff: I think we have to be careful in characterizing needs of “the original community”. The bulk of any large community tends to be pragmatists that just want things to work, and for better or worse, don’t care about the details and open source drama. On the other end you have the contributors and plug-in creators, who are much closer to home and critical to success. I’m not sure whether Oracle tried and failed as you say, as this seems like the first big move since the fork. But I agree with you that engaging and supporting the community of contributors and plug-in vendors is key to any efforts around Hudson. Eclipse is one of the most mature dev tool plug-in ecosystems, which is why I see this move as positive in the long run.

  9. Geoff Says:


    Thats the problem…I keep hearing Oracle, and now you, trying to redefine who the Hudson community is. It is pretty obvious that the community at large migrated over to Jenkins, leaving Oracle with little option but to make a move like this.

    Obviously, Oracle’s original plan failed, since one the main reason for the fork was that Oracle wanted to retain the infrastructure for Hudson on, yet now they completely reverse direction and drop it on the eclipse foundation. Here is Ted Farrell’s quote:

    “We believe it is important for hudson to stay connected with the rest of the the java community, as well as take advantage of some of the cool changes we will have coming to”

    Sounds like they changed direction to me…

    And you say that engaging and supporting the community of contributors is key, yet the actions of Oracle are saying just the opposite. I don’t see CloudBees listed as an “Interested Party” on the Eclipse Proposal at

  10. Ted Farrell Says:


    > Here is Ted Farrell’s quote:

    You are quoting something out of the rest of the context, and something that was clarified and elaborated on multiple times after that. More on that below.

    > I don’t see CloudBees listed as an “Interested Party” on the Eclipse Proposal

    There is still time for that. You need a proposal before you can talk about a proposal. We now have something real we can discuss. An Eclipse committer from SAP chimed in this morning asking to be added to the list. Anyone can during this review period. The idea is this is the start of the conversation.

    I don’t see how this move is reversing directions for the Hudson project, nor how it is in response to its performance. We were looking to define some formal governance for Hudson. We promised to do that after the fork. The lack of goverance and structure was our concern from the very beginning. We liked what Eclipse had to offer. As part of being an Eclipse project there are things you have to do. One of them is to move the project onto their infrastructure. If given the choice, I would have just stayed on, but the inconvenience of moving infrastructures seems worth it for the gain we get w.r.t. the process, structure, quality and predictability that comes with being an Eclipse project. That was the driving factor.

  11. andrew Says:

    From the more learned on the list I would like to understand the implications to Hudson from being required to use Eclipse’s rather restrictive EPL licensing regime? Today Hudson is under the most permissive MIT license but would have to convert to the EPL.

  12. Mik Kersten Says:

    Geoff: I get the frustration underlying the sentiments of the parts of the community that sided with Jenkins. In my original post I discussed that a fork of this magnitude would cause damage, which leads to bad feelings, speculation and divisions on both the vendor and the community boundaries. The current state is very much unfortunate and I would not wish it on any open source community. While I am sure that countless articles will attempt to dissect what happened in this fork, if the forcing function is the success of this particular CI technology in the hands of the user community, I think it is more important to focus on the path ahead.

    First, everyone should understand that this is an Eclipse project *proposal*, not a project that has been created. Having proposals happen behind closed doors is both reasonable and expected, since organizations need to determine how they align with each other’s efforts. That’s not a bad thing, and I think it is one step more community-oriented single-vendor dominated “corporate open source”, which has a track record of being productive (eg, JBoss, SpringSource, MySQL). What’s key in the Eclipse Development Process (EDP) is what comes next. The proposal is opened up to the community. So instead of the project getting provisioned behind closed doors, the process of meritocracy is kicked off and the discussions and expansion of scope or interested parties can continue. Meritocracy is the key principle used by the EDP to combine community and commercial interests. And what I would like to assure everyone of is that if you have a multi-vendor open source project without a process like the EDP in place, once the project becomes interesting to the industry-at-large, there will be a mismatch between commercial and community interests, causing damage to both, as we have seen with the Hudson/Jenkins split.

    I am sure that people will continue to dissect the positioning here and come up with plenty of ideas and conspiracy theories. What I am going to focus on is how we move forward from the damaged state that this great CI technology is in, and towards an IP-clean, inviting, API-robust and long-lived de facto standard CI tool. What I am sure of is that Eclipse has some of the key components needed to make that happen. It is now up to the Hudson/Jenkins plug-in developer, vendor, and most importantly the user community, to determine how we move forward in a productive way.

  13. Björn Sveinbjörnsson Says:

    Mik: When you write “IP-clean, inviting, API-robust and long-lived” do you mean by that Jenkins is not IP-clean, not inviting, not API-robust and short lived?

    You also write about meritocracy. Did you see the number of commits in the project and who made them?
    This is not an open source drama. It is about companies, or organizations (acting for companies) trying to gain ownership of something which is not theirs.

    I would suggest that if Jenkins should go under some umbrella organization that a better option would be “The Apache Foundation”. They know and live by the true meaning of meritocracy and are not controlled by any company. And finally, they are coders and not MBAs acting as programmers .

    Best Regards from a grumpy old programmer.

  14. Mike Milinkovich Says:

    @Andrew, You are correct in pointing out that the EPL is more restrictive than the MIT license. Specifically, the EPL is a copyleft license that requires changes to be contributed back under the EPL. However, the EPL does allow plug-ins to be under difference open source and commercial licenses. As you can see from the flourishing ecosystem of Eclipse plug-ins, the EPL does well as a license for a platform which is expected to be extended by plug-in developers.

    So as a practical matter, I am not aware of any changes required by the Hudson ecosystem as a result of using the EPL. If anyone can point out a concrete example of where the EPL could cause a problem, I would ask that you discuss it on the proposal forum at These are exactly the types of issues that the community needs to work through before the project is created.

  15. Mike Milinkovich Says:


    We have nothing but respect for the Apache Software Foundation and its community. However, your comment could be interpreted as implying that the Eclipse Foundation does not follow the rules of meritocracy, is in the control of some company, or both. Those are false. The Eclipse Development Process has been modeled in many ways after Apache’s and we firmly follow the rules of meritocracy, as those who have earned Eclipse committer status can attest to.

    The Eclipse Foundation is scrupulously vendor-neutral. How else do you think we can get so many individuals and companies, large and small, to work together here at Eclipse?

    Eclipse is a very vibrant and active community, where there are lots of developers building great software. I am sure that you can express your preference for Apache in ways that do not require you to make incorrect and negative statements about Eclipse and the people who make the Eclipse community so great.

  16. Mik Kersten Says:

    Björn: There are some incorrect statements being made about the Eclipse Foundation, some of which Mike has addressed. I understand that the details of how Eclipse functions as a vendor-neutral open source ecosystem are not familiar to everyone. That’s fine. But please at least take a moment to do some digging before assuming that Eclipse gets in the way of growing great open source software. If the “MBAs acting as programmers” statement was directed at me, I’m happy to argue the important role of MBAs in the success of open source software. Or to point out that I don’t have an MBA, and but that my code contributions are still the highest-ranked on Mylyn. Though I do admit that my focus has shifted from day-to-day coding to making open source ALM efforts successful.

    My point about “IP-clean, inviting, API-robust and long-lived” all had to do with governance model. To move into its next phase of enterprise adoption, I believe that the winning CI tool needs to have a solid governance model, n round of IP diligence that afaik Hudson and Jenkins have not seen yet, and the commercial/community governance that will ultimately determine whether it becomes the de facto standard or whether it gets replaced by the next open source CI effort. I understand that you and others may unhappy about how all of this transpired and in needing to figure out what this Eclipse thing is and whether it makes sense for helping build the technology that you care deeply about. That is frustrating and there is no way around that frustration given that the fork happened. It is just as frustrating to me given that I’m closely involved with integrations efforts around this technology. What’s important here is that the EDP empowers you, me and the other interested parties to drive the discussion around where Hudson should go. Given that we cannot rewind the fork, and that the majority of Hudson/Jenkins users had nothing to do with it and were not well-served by it, could you please point out your concerns about what it would take to make the forward-looking evolution of this CI tool successful?

  17. Thomas Says:

    As a semi-process manager, who had his share of complex project over takings/buyouts,
    its all about message – and sticking to it. Be assertive, be fair or not, but at least be predictable.

    From the owner change of Hudson to the Jenkins fork, some people say, it was a “heavy communication misfire” on both sides. I can’t see that. Oracle clearly played hardball on the Trademark and what will go where and when. It backfired, and when lots of customers and devs left, there is was a ‘Plan B’: the move to Eclipse.

    I don’t care much about what will go on Eclipse or anywhere. But people read. Important people. They watch the HudsonJenkins drama, the OpenOfficeLibreOffice drama…and make up their own minds.

    Now everybody will watch the next move with the next project out of Oracle and guess “Lets see: they will first play hardball, and the drop it to the next bucket the find. That’s their method now”.

  18. Björn Sveinbjörnsson Says:

    I’m sorry if I sounded harsh. I have nothing but the deepest respect for the Eclipse project. Use it any time I need to write something in Java.

    For me as an outsider the Hudson/Jenkins project is the baby of KK. I know a lot of other people have been involved in the project(s) but at the end of day it is KK and his incredible skills that drive the whole thing. What would Linux be without Linus or Python without Guido?

    If Oracle (and Eclipse) would invite the Jenkins people into the project and let KK have a governing role I would listen.

    Whatever will happen I will follow Jenkins and KK. It is not because of some irrational worship. It is about trust. I trust KK as I trust PJ of Groklaw, Linus Torvalds and many other in the opens source world. But I do not trust Oracle.

    Best Regards,

  19. Daniel K Says:

    Interesting development.

    Our team decided a month ago to switch to Jenkins as it was clear that Jenkins had more energy and support, and it was unclear where Hudson would end up.

    I don’t see this announcement changing anything yet, but if the Jenkins folks decide to reunite the two systems I would be behind that.

    Personally what bothers me, a simple user of these tools, is the constant bickering between the two sides, particularly in blog post threads on the matter. A lot of egos and too little reasonable discussions.

    That said, competition, and dare I say, a little antagonism driving the feverish pace of updates and bug fixes at Jenkins, can’t be such a bad thing. Innovation comes more from competition than it does from uniformity. If Jenkins continues as it has in recent months, I’m happy to stick with it – unless Hudson adds something I just can’t live without.

  20. Mike Milinkovich Says:

    @Björn – I expect that there will be many who feel the same way you do. FWIW, the goal is that once Hudson is completely moved to Eclipse it will not be a matter of “trust Oracle”. Instead Hudson will be a community project with a diverse group of contributors. The “Hudson” name will become community owned, rather than the property of Oracle.

    But the bottom line is that trust must be earned. It is certainly our goal to see Hudson earn the trust of the community.

    @Daniel – I completely agree that bickering helps no one, and competition drives innovation. It would be wonderful if we could get Hudson and Jenkins back together again. The Eclipse Foundation is certainly willing to do what it can to achieve a reconciliation.

  21. Hamid Sauh Says:

    Mike, you said “The Hudson name will become community owned, rather than the property of Oracle.”

    Which community?
    Hudson community already ‘owned’ the Hudson name until Oracle decided to trademark the name.

    Mike, do you know how many of the current Oracle and Sonatype committers had been part of the original Hudson community before Oracle created havoc?
    If you’re talking about meritocracy re Hudson project, you should know who are those people in the original Hudson community. I don’t recall Oracle employees name and most of Sonatype’s being part of that community.

    I’m just a Hudson and Jenkins user, but I did get the impression that Oracle did a hostile takeover from the original Hudson community. It left a negative impression.
    I must admit that this move on Eclipse Foundation’s behalf put EF in a negative light.

    Btw, I’m interested to know. If, say, tomorrow Jenkins community is proposing a separate move to Eclipse Foundation, what will you do?

  22. Hamid Sauh Says:

    “The goal is that once Hudson is completely moved to Eclipse it will not be a matter of “trust Oracle”. Instead Hudson will be a community project with a diverse group of contributors.”

    Mike, if you follow Hudson mailing list, you should know that that’s already the mantra that Oracle used. Oracle kept talking about their moves representing the community, but seriously, what community?

    It looks like Oracle is building a new community, and they knew that their initial idea of a community already failed, so now they’re adding the “eclipse foundation” label.

  23. Hamid Sauh Says:

    Also, let’s not forget that Oracle trademarked the name without consulting the then Hudson community. Does that sound an honest and open action there?

    It would’ve been different if Oracle said “hey, we’re going to trademark the Hudson brand, what do you guys think?”

    Instead, they trademarked the name, and told the community that they own the name Hudson.

    An awesome community leadership right there.

  24. Mike Milinkovich Says:


    The community I referred to is Eclipse. The Hudson trademark will be owned by the Eclipse Foundation.

    I respect your point of view, but there is not much I can say in response without pulling all of the controversies of the past months which frankly do not have anything to do with Eclipse.

    Let me say this: I totally respect everyone who has strong feelings that they like Jenkins and want to continue to support that community. But I also feel that moving Hudson to Eclipse is a far better solution for the development community and users of Hudson than the status quo. So I firmly believe that this proposal is a very positive move.

    Your comment about “this move on Eclipse Foundation befalf…” has me confused. What was announced was that Oracle was _proposing_ to move a project to Eclipse. This is a process and I would encourage everyone to provide feedback on the proposal.

    If Jenkins proposed to move to Eclipse we would certainly talk to them about how that would work. Of course, our recommendation would be to see if we could put Hudson and Jenkins back together again. But we will happily talk to anyone who wants to bring a project to Eclipse. We think it’s a pretty good place to build great software.

  25. Björn Sveinbjörnsson Says:

    Here is one reason why I do not trust Oracle.

    They have an agenda.

    Oracle subpoenas Apache:

    From the blog “… As an open development group the majority of our documents are already publicly available…”

    So much for understanding and respecting the community!

    Best Regards

  26. Karsten F Says:

    Mike, Mik, et al.

    Is this proposal basically about the trademark and not so much about the code or the community?

    I don’t understand what Eclipse Foundation is getting.
    Wouldn’t it be the similar to, say for example, any large company forking Jenkins, apply for Jenkins trademark, screw the rest of Jenkins community, then put some employees working on it, then propose to donate the project to Eclipse Foundation?

    If there’s such a thing as donating Hudson, surely it has to involve the original Hudson community.
    To add what Bjorn said, and I’m behind this 100%, if there’s any person who can propose Hudson brand or project to Eclipse Foundation, it should be Kohsuke.
    Let meritocracy speaks for itself. How old is Hudson codebase? How many percent of the codebase came from Oracle?

    It’s ironic Oracle can propose to donate something that’s 90%+ coded by somoene else, just because Oracle has the trademark.

  27. Mik Kersten Says:

    Where we have come to in this discussion should serve as an important reminder of the need for both open source software users and contributors to understand the commercial interests and governance models that determine how projects evolve.

    Consider the successful open source projects that you use. If you look beneath the covers, most of these have become successful by combining commercial and community interests. There are the exceptional non-profit and volunteer-based open source projects like, XBMC. But what we are talking about here is not a volunteer project. Projects like Hudson often start as labors of love, consuming the evenings and weekends of their creators. The passion of those leaders fuels the growth of the ecosystem, and the reactions to supporting KK are justified. But it is important to recognize that Hudson/Jenkins has a been commercial open source project from the start. Unlike some Linux contributors, KK was not serving ice cream as his day job and creating Hudson in his spare time. He was a Sun employee, Hudson had access to a marketing budget, and the IP generated was owned by Sun.

    Consider the origins of Mylyn. I created the project while a PhD student at the University of British Columbia. During the first user study I realized the value that it could bring to developers, so I wanted to make sure that the project was open and easy for others to contribute to and build on. I also knew that the only way I could get enough resources on it was to build a company around it. Because I was a student of UBC, and not selling ice cream, UBC had rights to the IP. Once the project got traction we negotiated with UBC to get rights to it and gave up a small piece of the company in the process. Eclipse and the EPL ensured that ongoing governance could combine this IP, Tasktop’s interests, the growing number of other companies contributing to Mylyn, and the volunteer style contributions that now make up 1/7th of the work that has gone into Mylyn.

    For this Hudson/Jenkins to reach its potential as the opens source de facto standard for CI, it needs this level of governance. In maturing developer-centric open source projects dismissing the importance of commercial interests can be as harmful as dismissing the needs of the community. Commercial open source works best when organizations act with enlightened self-interest, which can yield a much needed level of support and contributors needed to scale popular projects to the growing demands of their user base. The only way to marry those corporate interests with those of the community is with a robust governance model.

    It is not my place to tell the Jenkins community what they should do or where they should go. But do not go there blindly if you are contributing to or building on an open source projects, because more problems of this sort will result. For example, contributors to Hudson were assigning the IP rights of their contributions to Sun. That’s fine for corporate open source where the vast majority of contributions come from a single vendor. Less so for multi-vendor and community open source. For this reason, it has always been important to me that contributors to Mylyn owned the IP of their contributions when contributing to Eclipse because this makes the contributor and committer communities a first-class citizen in the development process.

  28. steve Says:

    Having read a bit further, I think it is just a shame how the Eclipse Foundations lets itself drag into Oracle’s conflict with Jenkins. Now we have one open-source community fighting against another one. Great job!

    If the Eclipse Foundation would be really independent it had told Oracle to first sort out the mess with Hudson/Jenkins they created and apologize to the people they alienated in that process.
    But it seems if the corporate sponsors tell the EF what they want EF screams “Yes Sir” and does it without thinking how much damage and harm they create to the whole open-source ecosystem.

  29. Karsten F Says:

    Mik, I’m not questioning the need for the project to evolve.
    Jenkins itself is evolving in terms of governance and process ever since the split.

    What I’m questioning is what is Eclipse getting out of this?
    If the need is on an enterprise level CI, why don’t you just fork Jenkins/Hudson/CruiseControl and put it as an Eclipse Foundation top level project?
    What is it that Oracle has that no one else has? Trademark?

    You’re correct that Kohsuke was a Sun employee. But don’t forget that Hudson codebase dated from 2004. Sun allowed Kohsuke to work on Hudson during work hours only starting 2008. Even then, check his commit logs, tons of them were clearly out of work hours.
    Even if we assume all of 2.5 years worth of them were Oracle’s IP, it’s still way less than a half of what Kohsuke put in to Hudson at his own time.

    Tell me, do you think that the people who proposed the project adoption really represent Hudson codebase? Or are they there just because they own the trademark?

  30. Björn Sveinbjörnsson Says:

    The following text is from Brian Proffit’s on ITWorld

    “Governance of Hudson, should the proposal be approved, will be managed by the EF, with Oracle still maintaining their status as the project lead, with companies like TaskTop, VMware, Sonatype, and Intuit all having representatives as initial contributors.”

    I see no mention of KK or his employer, CloudBees.
    So. Oracle decides to hand over ownership/governance of Hudson that was conceived by KK while at Sun. It is KK’s baby and anybody trying to make it look otherwise is dishonest.

    It would be great if CloudBees would be on the list among the other companies and KK would be the “project lead”.

    What I see is a political maneuver.

    This is very clear and very sad indeed to see EF being used like that.

    Best Regards,

  31. Karsten F Says:

    It’s also ironic that Oracle had the time to round up TaskTop, VMWare, Intuit, but couldn’t spare few minutes to contact Jenkins community as the original Hudson community.

  32. Mik Kersten Says:


    > It would be great if CloudBees would be on the list among the other companies and KK would
    > be the “project lead”.

    Ian Skerrett of the Eclipse Foundation blogged a good summary of this.


    > It’s also ironic that Oracle had the time to round up TaskTop, VMWare, Intuit, but couldn’t spare
    > few minutes to contact Jenkins community as the original Hudson community.

    There are two commercial parties here, Oracle and CloudBees, that did not agree on the future of Hudson. Jenkins was forked, and in KK’s words this constituded a divorce from Oracle. So I don’t think that it’s ironic, just an obvious and very unfortunate outcome given that the fork happened. And again, thanks to this being a *proposal* from one side of that split, there is still a chance for a real dialog to ensue. As I posted on KK’s blog, given what the broader community been put through, this seems like the last chance.

  33. Mik Kersten Says:


    > If the Eclipse Foundation would be really independent it had told Oracle to first sort out the mess
    > with Hudson/Jenkins they created and apologize to the people they alienated in that process.

    Resolving open source disputes is not the role of the Eclipse Foundation. Providing a good home for projects with commercial and community interest is. Consider what happened with SVN clients on Eclipse. There were two competing proposals (Subclipse vs. Subversive) and the Foundation clearly communicated that it was up to the community to determine the outcome or a path to to reconcile them, and said it was happy to host both. In the end only Subversive was hosted on Eclipse, as CollabNet, the vendor behind Subclipse, chose the corporate open source route. In many scenarios competing interests of this sort can be a healthy thing. This kind of freedom, competition and options are good thing for open source communities if properly governed. Eclipse can’t undo the past, it just provides a possible path for moving forward.

  34. steve Says:

    > Resolving open source disputes is not the role of the Eclipse Foundation.

    But actively participating in one is? I honestly wonder what the EF wants to do with basically a trademark, without community, plugins or real development going on.
    There is no way how the EF can stay “neutral” in the current situation.

    It would be in EF’s own interest to not have too much bias towards to the side which started the aggression, stole the projects trademark and forked, while giving those people who actually did the hard work the finger.

  35. Daniel K Says:

    …and the bickering continues.

    The complete and utter inability for people to constructively discuss the merits of one future over another, but instead fall into accusations, point scoring and plain old whinging is astounding.

  36. Mark Phippard Says:


    Ironically, I was also going to cite Subclipse vs. Subversive but for opposite reasons. I decided not to because there is enough heated talk here without dragging this even more off track. I think there is also one significant difference, namely that Subclipse and Subversive did not come from the same code base. So joining the two projects together always basically meant that one of the two projects had to just abandon the work they had done and force their users to move to a different product. That is not really the case with Hudson and Jenkins as they are a fork of the same source code and bringing them back together is an obvious goal that a lot of us share.

    Since you brought this up, I might as well make the point I was going to make. But first let me just state that Subclipse was not a commercial backed project. It was open-source and totally driven by independent volunteer contributions. I did not join CollabNet until after all of this went down and I only originally joined Subclipse as an interested developer that wanted to see SVN support in Eclipse.

    Anyway, my feeling at the time was that Subversive was developed as a commercial product, obviously backed by a single vendor, that ultimately realized they were not going to be successful when there was a viable free alternative that had already captured the community. Rather than support the existing open-source project, they used the Eclipse Foundation to give them an air of legitimacy that they would not have had on their own. Subversive is coming up on the 5-year anniversary of their proposal and they are still in Incubation.

    It feels like there is the potential for the same thing here with Hudson. The developer community has already left Hudson and moved on to Jenkins and it seems like the user community is following. The proposal to move the project to the Eclipse Foundation feels like another instance where the EF is being used to bring legitimacy and relevance to a project that otherwise does not have it. The vendors that are supporting the Eclipse proposal could also simply support Jenkins and help define and improve its process going forward. Hudson would just become a footnote in the history of Jenkins.

    That said, I do realize that Oracle’s desire to improve the process under which Hudson was being developed was real and moving to the EDP is one legitimate way to improve that process. The Eclipse process is proven and I think would meet the objectives of most parties that wanted to see improvements in this area. I also recall that this was proposed before the split happened, so I am not saying that Oracle does not have real intentions to continue the project at the EF. If KK and the Jenkins community get on board with this, then I think that will be great. However, I do not think they will get on board and it feels like there is an attempt here to shame them into doing so.

    Coming from a purely open-source perspective, the Eclipse process is heavyweight and mainly benefits the commercial companies in the ecosystem. When the software is initially sponsored by one of those entities, as was the case with Eclipse itself I think this is fine. But if I were KK or another Jenkins developer, I would probably prefer to improve the process I had then adopt something as formal as the EDP. That is basically the route we chose for Subclipse.

    Finally, I will also state that I am skeptical about Hudson moving through the IP process at Eclipse successfully. What is the plan for plugins? Just to host everything outside the Eclipse infrastructure? As an example, if the EF will not allow Subversive to use SVNKit they are not going to allow Hudson either. So that means something as essential to Hudson as the SVN plugin has to live somewhere else? I assume that means users that infrastructure to host and install plugins will also need to live outside the EF ecosystem for similar reasons?

  37. Karsten F Says:

    Mik, thanks for your answers, but you missed out some of my questions

    Tell me, do you think that the people who proposed the project adoption really represent Hudson codebase? Or are they there just because they own the trademark?

    what is Eclipse getting out of this?
    If the need is on an enterprise level CI, why don’t you just fork Jenkins/Hudson/CruiseControl and put it as an Eclipse Foundation top level project?
    What is it that Oracle has that no one else has? Trademark?

  38. Ted Farrell Says:


    > It’s also ironic that Oracle had the time to round up TaskTop, VMWare, Intuit, but
    > couldn’t spare few minutes to contact Jenkins community as the original Hudson
    > community.

    The reason we focused on the companies we did in the initial proposal is that they were open to the discussion. We know the Jenkins people and know the relationship we have with them. I don’t believe they would consider joining Oracle in anything. Their position is that we join Jenkins. Period. It is currently being discussed on the Jenkins emails. Their position is stated as “I personally see *zero* benefit from Hudson and Jenkins merging in the future”. That sounds pretty clear to me. The companies we did talk to do see a benefit in a more diverse Hudson as well as working with Oracle to do that. Obviously anyone else who wants to can join too.

    This proposal is intended to help define some governance around Hudson as well as alleviate some concerns around it from being an Oracle-owned project. It is intended to help start more conversations around growth of the code and community. It is not a statement about Jenkins in any way. We didn’t *need* to do this. We did it to help the project grow and get more people using it.

    Today, we have thousands of Hudson users who rely on us to support them and improve the software. We turned back on usage tracking for Hudson after the fork and in the 3 months since then we are currently tracking over 15,000 unique machines running Hudson. As you know, if you just try to update the pre-fork Hudson it will take you to Jenkins. So this is 15K instances where users explicitly downloaded and installed Hudson. We also know that many of our users haven’t upgraded yet, and we expect this number to grow substantially. This proposal is about trying to improve Hudson for the Hudson users and community.


    This proposal only covers the core. Plug-ins can do as they like. Mike M. covers that earlier in this thread. As far as the IP, I am not sure why people are concerned about that. We would not have submitted this proposal without first ensuring that we were capable of contributing the code. It took us a lot of work to get us to this point. As Mike mentions, Eclipse will verify the IP as part of the acceptance process.

  39. Mark Phippard Says:


    > Their position is that we join Jenkins. Period.

    Have you considered that option? It seems like a valid solution to all of this.

    > As you know, if you just try to update the pre-fork Hudson it will take you to Jenkins.

    That is now what we saw on our server. It gave a choice with a link that explained the options.

    > This proposal only covers the core. Plug-ins can do as they like.

    I understand that each plug-in is essentially its own project and can host where it likes. But what about all of the online infrastructure to discover and install plugins. Where will that be hosted? Would the Eclipse Foundation allow it to host non-EF plugins?

    > As far as the IP, I am not sure why people are concerned about that.

    I was not trying to raise the issue of your right to the IP. I know that the Eclipse IP process is very thorough and will find the issues if they exist. I was speaking more to the 3rd party components used by Hudson and its plugins, and whether the EF will allow those to live on its infrastructure.

    FWIW, I think Oracle proposing to hand over the IP and trademarks is good. I also hope that the projects can find a way to come back together. Unfortunately, I do not get the sense that there is any real desire for this to happen. If that was the goal, then I think the offer to hand over the IP and trademarks would have been made privately to the Jenkins developers rather than make a big public splash. This feels like it is more about #winning

  40. Mik Kersten Says:


    I’m glad that you point out that Subclipse was born out of volunteer contributions, as I think that it is a good open source success story and an example of good project leadership. I agree that having vendors using Eclipse to do nothing more than gain positioning is an anti-pattern, and thankfully there is enough Darwinism in the Eclipse Development Process to let meritocracy prevail. I don’t think that’s happening here, and if it did, that Eclipse-based effort would fail and the effort external to Eclipse prevail. This is why I have considered efforts like Mylyn Connector Discovery and MPC so key, since they level the playing field (eg, for more the “The economics of extension listings” section of my blog post on growing open source ecosystems). Going back to your example, I believe that these efforts, and the plug-in discovery infrastructure already in place on Eclipse, were instrumental in leveling the playing field between Subversive and Subclipse, and on my CI Panel at JAX with KK yesterday, an audience member argued that a similar mechanism would be helpful for Hudson/Jenkins.

  41. Mik Kersten Says:


    > do you think that the people who proposed the project adoption really represent
    > Hudson codebase? Or are they there just because they own the trademark?

    Given that key folks like KK and Andrew Bayer went with Jenkins, clearly more of the original codebase’s contributors went with Jenkins. Some key recent contributions, like Sonatype’s, have been to Hudson. So looing to the past, yes the merit leans to the original community. It is also important to look to the future. For example, there is constant interest in better support for Maven in Hudson, since those technologies are so intertwined in the land of Java. And this is where I think the governance issue gets interesting and determines whether its Hudson/Jenkins that becomes the de facto CI server, or whether something less encumbered by commercial and community divisions takes its place. My view is that the de facto open source CI platform needs to support a healthy innovation network that includes build tools, quality tools, IDEs, enterprise support and the like. Note that creating a forge that supports these innovation networks, like Eclipse, Apache, and Mozilla, takes years.

  42. Ted Farrell Says:


    >> Their position is that we join Jenkins. Period.

    > Have you considered that option? It seems like a valid solution to all of this.

    I am doing my best not to rehash the past but, yes we did consider the equivalent of that during the pre-fork talks. The issue we always had was the lack of a more formal and stringent process and infrastructure. I appreciate that some people don’t like or believe they need something as formal as the Eclipse development process, but we do in order to feel comfortable about giving away IP.

    >> As you know, if you just try to update the pre-fork Hudson it will take you to Jenkins.

    > That is now what we saw on our server. It gave a choice with a link that explained
    > the options.

    Yes, that is the case for non-native packages. My thanks to Andrew for that. My point was the users made a conscious decision to go with Hudson post-fork. The stats we are seeing are not people who were automatically updated to the post-fork Hudson without deciding.

    > I understand that each plug-in is essentially its own project and can host where it likes.
    > But what about all of the online infrastructure to discover and install plugins. Where
    > will that be hosted? Would the Eclipse Foundation allow it to host non-EF plugins?

    The update center will be hosted at Eclipse and will be capable of including plug-ins that are hosted in different places, like Maven Central, Jenkins or something else. We will be working that out with Eclipse in the coming weeks, but there shouldn’t be any issues there. Above, Mike references the Eclipse IDE as an example of that.

    > If that was the goal, then I think the offer to hand over the IP and trademarks would
    > have been made privately to the Jenkins developers rather than make a big public
    > splash. This feels like it is more about #winning

    I think this is about winning. Not winning against Jenkins, but winning by making Hudson stronger for our users. The stronger Hudson is, the more our users are happy. This proposal isn’t about Jenkins or handing over the IP to Jenkins. This is about Hudson. Previously, it was demanded of Oracle to give away the IP without the assurances of a more formal, stringent structure and process. That was not acceptable. The Eclipse Foundation provides that structure so we are contributing the IP to the Hudson community as part of this proposal under Eclipse.

  43. Christian Trutz Says:


    > do you think that the people who proposed the project adoption really represent
    > Hudson codebase? Or are they there just because they own the trademark?

    Can Oracle fill this Eclipse Foundation IP questionnaire?

    1] Did you agree to contribute the code to the XXX project:

    a) to be licensed as open source under the YYY license; and now
    b) to be licensed as open source under the EPL license?

    2] Did you [yourself] write the code you contributed to the XXX project?

    3] Does anyone else have rights to the code you contributed? [For example, did you have an agreement with an employer giving the employer rights to all code you wrote during that time?]

    4] Can you estimate how much code you contributed to the XXX project?

    Is the 2] answer “yes”? How about 3]? Exists an agreement between Oracle/SUN and KK?


  44. Miles Parker Says:


    Just a technicality, but you’re really looking at the wrong document. IIRC, that’s for an individual making a single contribution to a project. The below is a pretty straightforward ;-) view of the different paths that IP can take into the Eclipse project. I think if you ask any committer in the Eclipse universe, the one thing that you don’t have to worry about is that great diligence will be taken.



  45. Christian Trutz Says:


    OK am not a lawyer, but a enthusiastic Eclipse developer ;-) The point / question is:

    Own Oracle really the IP on Hudson code? As a Hudson user (not a lawyer) I would say: not 100% …

  46. Johannes Jacop Says:

    I think Mik actually pointed out one or two very important things:
    1. No matter what happened in the past, a prolonging fork of Hudson/Jenkins is a sub-ideal solution for the future. In other words, reunited both projects could evolve better.
    2. The Eclipse Foundation is a very good place to host and manage – not only Hudson, but also Jenkins in a project. To some point, this is also a matter of trust. (No offense, Ted, but it seems pretty obvious that Oracle could have done better in obtaining and deserving the trust of the open-source developer community.)
    However, the proposal seems to be a good first step to me. I am sure it was not easy within the Oracle ecosystem to carry this through. I am glad you did it, Ted. So, what might come next? Well, I do understand that next to those points there are personal interests (and feelings) involved making a solution not easy. However, in the very best interest of the whole community and other stakeholders (e.g. Hudson/Jenkins users), we should think it through. How do we get the best solution? It seems pretty obvious to me that KK is key to that point. I do understand the legal issues regarding IP. However, “Hudson” was and still is KK’s baby. He won’t dump it easily. I think Ted knows this as well.
    @Ted: How would you like to involve KK in the future development and project lead of Hudson/Jenkins?
    So, what could a second step look like? And last but not least… Due to the deepest respect for KK and some other major players, let’s give those guys some time to think it through. We shouldn’t make a possible reunion even more difficult than the fork surely was.
    At the end, we all (users, vendors, developers) should think about what kind of Jenkins/Hudson future we would like to have. Two bickering community projects focusing on bashing each other? Or one cool kick-ass CI project under the umbrella of EF involving the smartest brains (including KK) and balancing all interests.
    Regarding some EF bashing mentioned above… Being founder and CEO of an independent start-up, I’d like to add: Yes, I do trust those guys! That is mainly why Yatta Solutions became an Eclipse Solutions member.

  47. Hamid Sauh Says:

    After re-reading the Hudson/Jenkins mailing list right before the split, I think the ‘bad blood’ between the two sides was overblown.
    There are only two really hostile individuals, Ted from Oracle’s side, and Tyler from Jenkins side. Everyone else was basically polite. It could’ve been a simple disagreement instead of a drama.

    Ted, you got to admit that your grand entrance to the mailing list was pretty bad. You sounded commanding and arrogant. And you were never apologetic, it would’ve been a lot difference if you said “I’m sorry if I said…, what I meant was…” Ted, have you read the new book title Rework by 37signals? There’s a chapter on fixing things after making a mistake.
    Do you even acknowledge that your choice of words were often open for interpretation? You had to clarify things so many times on the mailing list, that means you’re often misunderstood.
    You also often like to take things offline, off the mailing list, the lack of openness caused more misunderstanding. Like, your offer to move the project to Ecilpse prior to the split, now you say it was offered, but the rest of the community never saw the conversation because it was not done on the mailing list.
    No wonder the community turned against you, it’s not a good thing for Oracle.

    From Jenkins side, Tyler reacted quite immaturely and that damaged the Jenkins community. He’s a valuable contributor, but perhaps not the best spokeperson.

    Let’s not let the hostility coming out of these two individuals to reflect the rest of Hudson and Jenkins community.

    From the media side. Most coverage was ok, but Brian Proffit’s article on ITWorld tend to contain lots of falacies and he never tried to rectified them even after people corrected him in the comments.

  48. Hamid Sauh Says:

    “we are currently tracking over 15,000 unique machines running Hudson”

    Ah, what a coincidence, we’re actually going to move 50 of our machines to Jenkins today :).
    So make that 14,950.

  49. zeitgeber Says:

    > I’ll certainly get involved with patches etc if that can occur.
    > If I’m completely honest, the selfish part of me doesn’t want
    > to have to fix issues in what is currently two places!
    > I guess I simply would’ve liked to seen it handled a little
    > differently…

    This is why Eclipse should should just donate Hudson to Cloudbees.

  50. steve Says:

    @Ted: Considering that the value of Hudson basically hit the bottom (I guess this is what you mean with “IP”) and no one cares about it anymore, why not just scrap your fork? You wouldn’t even need to “donate” “your” IP to Jenkins.

  51. SteveJJ Says:

    I keep hearing the same comment KK owns the IP or his contributions were done during off hours, but as far as I know every big corporation (Oracle, IBM, MS,etc…) _own_ any IP created by their employees while they’re working from them _even_ if done during you off time. That’s why Oracle can contribute the code to EF without asking nobody they acquired the IP when they bought SUN.

  52. Mik Kersten Says:

    SteveJJ brings up a point here that I think is worth thinking through. Outside of volunteer-based projects, the contributor community needs to understand what they are contributing to, what the IP implications are, and what can change.
    Back when Hudson was Hudson and Tasktop was building on it, the CLA that we needed to sign, which have assigned over all of our rights, meant that we instead chose to build separate extensions of the tool that were not encumbered. We knew that without additional governance in place we could not get assurance of what would be done with the IP. Our concerns were confirmed when the project was forked in a way that split the community, and no suitable governance materialized.

    In the world of software, acquisitions are commonplace. Things changed when Oracle acquired Sun. Things could change just as dramatically if a company acquired CloudBees. The good thing is that large organizations are learning both the value of community and the importance of open source, and we are seeing more enlightened self-interest working for communities than we did before. Foundations like Eclipse have formed to support such open source efforts, and to allow community of individual contributors and smaller vendors to retain rights to the IP of their contributions.

    Looking at the big picture, the question now is how this technology moves forward in a constructive way. I am not now and have never been against Jenkins. But to assume that Jenkins has won because of the strong contributor community support behind it will only cement the permanence of this fork. For early adopters, that might be fine. But for the bulk of the potential that this key open source CI technology is relevant to, who are by definition pragmatists and risk-averse, the choice of CI tool will have just as much to do with IP assurances and commercial ecosystem around the tool. In other words, some of the line of reasoning above will only serve to drive a deeper and more permanent split between an enterprise-friendly and community-centric versions of the technology. In the long-run, my view is that marrying those two sets of interests is the only way to make this category of open source projects thrive. Failing to do that results in situations like this one. The question now is how we move forward. Oracle has proposed one path, and while I don’t think the responses should be rushed in this phase where opinions are being gathered, to move forward in a productive way there needs to a be a dialog not only about fallout from the past, but about what’s needed in a governance model for Hudson/Jenkins going forward. Then hopefully we can get back to thinking about what we enjoy, which is using and innovating on this great technology.

  53. Mik Kersten Says:

    In relation to my last comment, KK has posted about Hudson IP:

  54. Christian Trutz Says:

    OK let us assume Hudson IP is 100% owned by Oracle, Hudson become a Eclipse top level project and 2012 “the world” will have 2 main CI systems Jenkins and Eclipse Hudson.
    Whats sooo wrong about this? We have also:

    - JBoss and Geronimo
    - Subversive and Subclipse
    - Eclipse and NetBeans
    - IE and Firefox and Chrome
    - Windows and Linux and BSD and OSX

    And perhaps is a good think that we have not only one OS, Browser, IDE …

    Another thing is the Hudson IP (not the Hudson License): Assume a poor cs student works every night on a cool new OS, 2-3 years of nightly cool hacks. He creates the new Linux the world is happy … but wait he also works daily for XYZ cs company, remember he is very poor => oh nooo XYZ has the IP of the new OS. My stomach tells me: not my world!

    Time for Outrage!!


  55. chukked Says:

    well, an open source project belongs to the community and community has moved the porject to jenkins so hudson is a dead piece of code.

    if eclipse has any respect and human feeling to open source community and right ownership justice then when oracle proposed them to offer hudson they shoud have refused and rather have asked first to jenkins community to join eclipse.

    here i see first culprit was oracle and now second culprit is eclipse who is joining now to oracle to kill jenkins by biasing hudson.

    backoff eclipse

  56. Mik Kersten Says:


    > well, an open source project belongs to the community

    If only it were that simple. Corporate open source projects do not belong to the community. Volunteer-driven and community-centric ones do, but those are not being discussed here. Eclipse-projects are different in that they support a mix of corporate and individual community members and interests. For example, the Eclipse Board of Directors has both individual committer and corporate member representatives. That helps strike a balance.

    I personally have a lot of respect and feeling for community contributions. I tried to get involved in this mess before the fork happened, as the fork was the last thing that I wanted to see. I don’t like it and others don’t like it. Much of the sentiment out there is outside of the parties who are closely involved is the desire for a merge.
    Bickering about culprits and community vs. commercial interests may help you vent, but it won’t increase the chances of the codebase that you love thriving. While Eclipse is not the only possible route, there needs to be a way forward that combines corporate interests of multiple vendors wanting to build on Hudson/Jenkins with those of the community.

  57. Ian Skerrett Says:

    @chukked seems how you are leaving the same comment on a number of blogs, I will add my similar response here.

    I don’t think anyone is going to kill anyone. I expect Jenkins to continue to be a thriving, successful open source project. I also hope Hudson will have the same success at Eclipse.

    FWIW, I expect a lot of Eclipse users will continue to use Jenkins.

  58. Karsten F Says:

    I know it’s just a one man opinion, but really this proposal is borderline unethical.
    We’re purely talking about the Hudson trademark here, and not so much respect to the product code and the community behind the code.

    I also don’t buy the argument that Oracle is entitled to Hudson since Oracle acquired Sun.
    Well, Sun didn’t secretly registered the Hudson trademark without talking to the community, Oracle did.

    Mik, out of curiousity, let’s say Jenkins community hasn’t registered the Jenkins trademark.
    Then Microsoft register Jenkins trademark, fork Jenkins, make a few improvements to the codebase, then donate the project to Eclipse Foundation. What will you do?

    What if, let’s say, both Microsoft and Google fork Jenkins, register trademarks for respective forks, then both of them donate to Eclipse Foundation. What will you do?

  59. Ted Farrell Says:


    I’m not sure you’re being fair here. Sun/Oracle didn’t come out of the blue in this. They funded KK for 4.5 of the 5 years he was creating Hudson. That included salary as well as infrastructure, support, etc. and then continued with the infrastructure and support until the fork. I think if you ask KK, he would tell you that Eduardo P. was also a key component in helping Hudson grow and flourish with the support he provided. Sun/Oracle funded Eduardo as well.

    Nobody has ever said that KK doesn’t deserve the credit for getting Hudson to where it is today. In fact we have stated multiple times that he deserves that credit. The part I don’t understand is how you can claim that Sun/Oracle has no right whatsoever in this project. KK was Sun/Oracle until recently. They were the same thing. Him leaving created an interesting dilemma which (along with a lot of other external factors), ended us up here.

    I have been a developer for 25 years. I have personally created patents and programs that I consider mine, but are owned by companies who either I worked for or who acquired them. I respect that. That is the deal that each of us makes.

    It is unfortunate that we are where we are with Hudson/Jenkins. There are a lot of things I wish happened differently on both sides. But I don’t think it is fair to ask Oracle to walk away from Hudson at this point. We have a lot of people who are relying on us to support it, and in doing so, we are going to work to improve it. I don’t view improving Hudson as an attack on Jenkins. It seems by reading some of these replies, others do. As I stated earlier, this proposal isn’t about Jenkins. It is about Hudson and helping our thousands of users who are using it.

  60. Karsten F Says:

    Ted, did you get the number right?

    I’m happy to be corrected, thanks in advance for that.
    Kohsuke started working on Hudson as his day job from May 2008 , Hudson codebase started from 2004 (check the commit logs).
    If Sun provided support prior to 2008, is there a legal binding to it?

    I never undermine Ed’s involvement in Hudson’s success. But you should also remember that Ed himself was the person who said that he gave Kohsuke’s freedom to run Hudson without the heavyweight process because Hudson was by far the most successful open source project related to Sun after May 2008.

    Sure you never said that Kohsuke didn’t deserve credit, but by registering the trademark without the Hudson community consent, you spat in Kohsuke’s face and the original Hudson community’s face.
    You didn’t discredit, but you simply disrespected them.

    Thanks for sharing your 25 years of experience and your patents.
    I understand such deal, but the situation is different. Your situation didn’t involve a hostile takeover, while in Hudson’s case, it did.

    The fact that Oracle had to resort to trademark to take control of Hudson was a great example of your lack of ability in communicating with the community, and that clearly reflects in Oracle’s failure in dealing with the other open source communities (think LibreOffice).

    I never asked Oracle to walk away from Hudson. You wish things happened differently, it could’ve happened by having different strategy the moment you entered Hudson community, starting with your absolutely-bad-for-pr first email on the mailing list.

  61. Ted Farrell Says:


    Sorry if I missed the numbers, but if it was longer, that only strenghtens my point that Sun/Oracle paid for Hudson’s development and should have some rights to it.

    w.r.t. the Hudson trademark, there is a normal IP cleanup/sanity process that goes along with any acquisition. The Hudson trademark was started as part of that, months before any conflict with the community arose.

  62. Karsten F Says:


    Are you saying that Kohsuke’s work on Hudson from 2004 and 2008 are owned by Sun?
    What’s the legal binding?

    Several people in my organisation work on their own respective (and successful) open source projects at their own time, my organisation has never claimed ownership of those projects.
    Yes, we do support them with hosting and a few things, but only to support them, not to claim ownership of their work.

    If the process was started months before, why didn’t you be courteous and notify the community back then to clarify any misunderstanding?

  63. Henrik Says:

    This is certainly a interesting move by Oracle. In general I am positive of the idea, but I do have my concerns.

    I have written a more extensive comment on the thing at (Not going to repeat the entire thing in a comment field)

  64. Hamid Sauh Says:

    Mik, I have a question

    In this eweek article
    “Moreover, in a blog post about the move, Kersten said:
    “The Hudson/Jenkins fork has generated FUD around this very popular Continuous Integration (CI) tool. Oracle has ownership of the Hudson IP that they acquired via Sun’s initial investment in the project. ”

    I’ve been a hudson user since 2006. When Sun allowed Kohsuke to work full time on Hudson in 2008, all I saw was Sun becoming a member of the community, not the owner of the product or the community.
    The product belonged to the community, not to Kohsuke alone, definitely not to Sun.

    Could you please explain why Sun had ownership over Hudson?

  65. Ted Farrell Says:

    Hamid, Sun invested over $1 million dollars funding the creation and support of Hudson over the 5 years. Why would you think that they don’t have some ownership over it?

  66. Christian Trutz Says:

    @Ted “some ownership” yes, but not the complete ownership. A very important point.

  67. Ted Farrell Says:

    Christian, I agree. My wording was intentional. It is being implied in certain posts that Sun/Oracle has no rights over Hudson, which I disagree with.

  68. Hamid Sauh Says:

    If Sun/Oracle had some ownership, wouldn’t that mean there are other parties in the community who have some other ownership rights?

    If that’s the case, why did Oracle register the trademark without consulting the other parties who have the collective ownership rights?

    Oracle certainly didn’t act like it had some ownership, by registering the trademark without consulting the community, Oracle acted as if it claims 100% ownership over Hudson.
    That didn’t sound like something a respected member of community would do, and certainly not a great example of community leadership.

  69. Mik Kersten Says:

    > If Sun/Oracle had some ownership, wouldn’t that mean there are other parties in the
    > community who have some other ownership rights?

    @Hamid This is exactly where the question of project governance comes in. As I discussed in my comment above, in a corporate open source project the ownership in the IP sense is usually not given to the community. That’s why everyone contributing to Hudson everyone had to sign a CLA, and in the process handed over their rights. Too often the community does not realize that, which is why I think this discussion is so important both for the future of Hudson/Jenkins and for the sanity of those contributing to open source projects. The community rightfully feels that it has ownership, but this ownership is not official unless it is expressed in a governance model.

    For a technology this important to both developers and corporations, this story teaches us that a community-friendly governance model needs to provide ownership that goes beyond a single organization. This is very important to individual contributors who want to have a say in the future of a project. That say needs to be more than vocal complaints or opinions on a mailing list. It needs to be represented in the governance of the project. This is equally important for corporations wanting to contribute their best developers to improving open source projects that are important to them and their customers. If the ownership of the IP is not retained by the company contributing, and assurances of the cleanliness of the overall IP of the project are not met, companies instead choose to contribute to their own projects, and we lose the benefits of multi-vendor collaboration.

    What I am proposing is that to move forward on the path to its potential, Hudson/Jenkins needs to provide a multi-vendor and community friendly governance model. Apache is close, but requires contributors to assign the IP to the foundation. Eclipse allows the contributors to retain the IP, and has both community contributors and multi-vendor collaboration as an explicit part of its governance model. For example, voting on committers and release reviews are an explicit and streamlined part of the Eclipse Development Process. There could be other options, but the reason that I have been positive on Eclipse as the place for this technology is that it has a proven track record of multi-vendor and the community friendly governance needed to keep such problems from arising as this technology continues its growth.

  70. Hamid Sauh Says:

    Mik, so are you saying that Sun/Oracle had 100% ownership of Hudson?

  71. Christian Trutz Says:

    OK Ted said, that Oracle have not 100% IP ownership of Hudson, only some IP ownership. But what is “some”? tells us, that Hudson is ca. 2.3 million dollars worth

    and has 128k lines of code. The contribution of KK is and he contribute ca. 400k lines of code. So he write Hudson 4 times ;-) Oh this is very complicated ;-)

    But Oracle said, they spend 1 million dollar and Hudson is 2.3 million worth => Oracle own 40% of Hudson?

    @Ted, has Oracle from every Hudson contributor a signed CLA?


  72. Karsten F Says:

    That’s interesting. It’s now even questionable whether Oracle had the right to register trademark of something they do not fully owned.

Leave a Reply