Wednesday, May 4, 2011

Hudson, Jenkins and Eclipse

Wow. Am I the only one who is hugely ambivalent about the Eclipse Hudson announcement? If William Safire were still with us he would point out here that Ambivalence does not mean "unsure", "undecided" or even "conflicted"; rather, it means that one holds two opposing -- often strongly opposing -- views at the same time. I have strong views, but I don't have a dog in the hunt at all, except that like many of you I rely on Jenkins and Hudson to actually build my software. And as there is big money and big corporate ego involved here, I should probably keep those views to myself. But naturally, I won't.

While the news isn't completely surprising -- there were some odd hints here and there -- it still raises a number of interesting and even challenging questions for our community. My guess is that this is in a way a harbinger of deeper changes in the overall role and mission of Eclipse and so I think it is worth talking about all of that openly.

I [Valence +] am thrilled because this is a huge win for the Eclipse Community. Transparency, good governance, common communication and tool infrastructure -- above all, a trusted community and process -- that's what Eclipse has to offer to open source projects everywhere. The fact that Oracle has chosen Eclipse as in effect the trusted repository for all of their CI related IP, community, branding and other assets speaks really well of Mike and the community as a whole. Basically, Oracle fucked up big time. Now they're making an attempt to do the right thing. Does it matter why, as long as everyone knows the emperor isn't actually wearing any clothes? And it is also yet more evidence that companies are going to be forced to move to a truly shared open governance model. The days when companies could get away with open sourcing in name only are numbered. All of this is great news for the open source movement. Oh, and speaking as an Eclipse project lead, the prospect of having an Eclipse project devoted to builds and integration makes me happy indeed.

I [valence -] am worried because it feels like a big loss for the Eclipse Community. The Jenkins / Hudson split was probably the most dramatic open source news of the year, and personally I loved every minute of it. If the Hudson move to Eclipse demonstrates the power of open source, Jenkins embodies its spirit. The name change was spectacular judo and -- to mix martial arts -- better than watching Kung Fu Panda. Deeper still, the name change puts out a real challenge to the corporate mindset, one that hasn't been really appreciated. That's for another post, but I believe the next big wave for open source is the triumph of community over branding, and substance over labels. Now, to me the deepest Eclipse principle is that actual contributors lead the project. If you didn't write the code, you don't get to make the decisions, unless you're actually my boss. Fundamentally, the Jenkins folks left Hudson because Oracle was violating that principle. I'm also concerned because the Hudson proposal puts all of us -- including independent committers like me -- in the uncomfortable position of being on a "side" of a battle that we didn't choose. And we wouldn't even be talking about this if the Jenkins folks -- i.e. the people who actually wrote most of the code -- hadn't had the courage of their convictions.

There is the smaller issue of how Hudson fits in to the Eclipse project ecosystem. Every other project that I can think of has some connection to the same basic OSGi architecture. Is this the beginning of a redefinition of what Eclipse itself is? I think Orion is pointing that way as well, and I don't think that that is necessarily a bad thing, but it is worth discussing.

So where does this leave us? I don't know. Even if I fell down on the [Valence -] side more, I still wouldn't actually oppose the Eclipse project, and it wouldn't matter a bit if I did. Ultimately projects need to sink or swim on their own merits, and the fact that Hudson will be subject to the same rules as everyone else makes me feel ok about that. But the process should not be pro forma either and should genuinely involve the whole community, especially the Jenkins folks if they chose to get involved. For me the best outcome would be for the Jenkins team to be invited in as co-equals. I wouldn't be a bit ambivalent about that.

7 comments:

  1. I have pretty much the same feelings and I could not have stated in a better way !

    ReplyDelete
  2. Just a point of fact.
    Jetty had no OSGi bits and pieces when it came into eclipse.
    Jetty also continues to break new ground in the Eclipse ecosystem with the way it consumes maven dependencies (poor IP/CQ folks had to define new language to deal with us) and produces releases (we have standalone distributions, no osgi) not part of an eclipse release train as well.

    ReplyDelete
  3. I hadn't thought of that, interesting. Thanks for the note!

    ReplyDelete
  4. Miles, not sure I follow 'valence -1', I don't see how Hudson at Eclipse is a loss for Eclipse. At the point of the fork, only a few short months ago, Hudson == Jenkins in all things except community. Could the code base changed so significantly over those short months that Hudson is no longer a technical success? I don't think it could have. Do you?

    Perhaps you would say there is bad karma on Hudson and that carries over into eclipse? Not sure if that is a rational idea. Perhaps you would say that Hudson is now an infamous brand, shunned forever? I see that point, if that is what you mean. Time will tell though.

    This is a complicated situation. There are many factors which are hidden from me. Jenkins and Hudson have the same heritage and should not be competitors. Kawaguchi (and Jenkins community) could explore the terms of open source governance that eclipse offers (and Oracle didn't). Perhaps there is a possibility of a merge?

    ReplyDelete
  5. Miles, The project proposal makes it clear that Hudson will be moving to Equinox as its core runtime. See http://www.eclipse.org/proposals/technology.hudson/

    "A standard OSGi runtime model based on Eclipse Equinox, a standard component model using JSR330, and standard web services using JAXRS are high on the priority list. Compatibility is also of utmost importance while all these improvements are being made. "

    So I think this is all goodness on the OSGi front.

    ReplyDelete
  6. John, rationality is overvalued. ;-) I'm really referring to the community in the larger sense -- our shared understanding of what's decent and proper and what's not -- as opposed to simply say the market or mind share of the Eclipse platform.

    Mike, thx. Stuart mentioned the efforts made on OSGi on Twitter as well and that sounds really cool, especially as it means that some of these bits could be used elsewhere.

    ReplyDelete
  7. I'm right there with you Miles, great article! Project managers can download Jenkins, together with enterprise support, from the new WANdisco uberApps Store.

    Check out the video for info: http://www.ubersvn.com/videos/introducing-uberapps

    ReplyDelete

Popular Posts

Recent Tweets

    follow me on Twitter