7

We have been using Hudson for quite a while and we loved it. Now many Hudson-developers have "left the building" to create their own: Jenkins (which means the project has been forked). As Hudson/Jenkins users, we are now worried whether we should opt for the original "big and stable" producer Oracle, or the "small and dynamic" newcomer Jenkins.

EDIT: Our worries are mainly due to the fact that we did not really hear about this fork/split through any official ways. It looks like a guerilla action including the hijacking of logos and trademarks (after all, the copyright must be at Oracle, no? I'm not sure). So we're kinda missing professionalism here, as in well-organised course of action involving press relases, etc. Maybe we just missed that...

What are good objective reasons to decide for either project in the future? Can we postpone that decision until later, or is that too risky?

Here's one opinion about this: http://www.itworld.com/development/136173/more-concerns-surface-hudson-jenkins-split

Why did you choose either one?

Improve this question
12
  • I think this falls under the "What language should I learn next?" off topic clause in our FAQ
    – ChrisF ♦
    Feb 25, 2011 at 13:29
  • Hmm, I agree, it's similar even if responses are much more likely to be objective than with programming languages.
    – Lukas Eder
    Feb 25, 2011 at 13:35
  • 4
    I actually find this a good question. I didn't even know what was going on when I suddenly started seeing the term 'Jenkins' everywhere when looking up stuff for Hudson. It would be nice if someone can clear out what the exact deal is with this.
    – stijn
    Feb 25, 2011 at 13:37
  • 2
    @ChrisF: Not quite. This is a "which fork of a project has the brighter future?" question. It's more similar to "which technology is better", but as it's the same technology I don't think that applies either.
    – Ant
    Feb 25, 2011 at 13:38
  • @Ant - in that case the question needs to be reworded to reflect this. At first glance, to someone not familiar with the field, it's not clear that these are two flavours of the same thing.
    – ChrisF ♦
    Feb 25, 2011 at 13:40

3 Answers 3

Reset to default
10

To my understanding most if not all of the developers have gone to Jenkins. This will most likely mean that Oracle Hudson will stagnate around the current feature set (unless Oracle decides to either backport new packages or start developing Hudson-only plugins - which could be very likely to deal with their products).

Personally we will go with Jenkins as the Open Source development is more important to us than the Oracle-support available with Hudson.

Edit 2011-05: It appears that Oracle cleans up the plugin structure and makes it easier to write new things. Whether this will affect the above situation is hard to say yet.

Improve this answer
5
  • Hmm, OK. Personally I'd do the same for the same reason. But that's a rather subjective reason for a decision...
    – Lukas Eder
    Feb 25, 2011 at 13:52
  • @Lukas, well, it is still true. We do not need Oracle support, but we need the Open Source community.
    – user1249
    Feb 25, 2011 at 14:37
  • That was my understanding too. The team behind hudson created the fork and I think they'll continue their work.
    – Andreas Dolk
    Feb 25, 2011 at 15:01
  • Yes, but that's not a guarantee for quality in the future. I can understand that working for a large enterprise like Oracle may not always be rewarding. But now they have to find an entirely different means of funding and I'm not convinced that they did it well. Because if these things are well done, I would expect press releases and professionalism, not hijacking logos and "guerilla behaviour". I somehow don't see the motivation (yet). But maybe I missed the important press releases... I'll add this concern to my question phrasing
    – Lukas Eder
    Feb 25, 2011 at 15:26
  • @Lukas, as always you know your own needs best. It is just my understanding from what I've seen the last year, that Oracle makes products and we are consumers, not peers. That is important to me - it may or may not be important to you, but you should at least consider if it is.
    – user1249
    Feb 25, 2011 at 16:57
3

Can we postpone that decision until later, or is that too risky?

I think you can postpone it.

Right now, the differences between the two flavors of the Hudson/Jenkins codebase will be small. It will probably be some time before the differences are significant.

The linked article does mention that changes that break binary compatibility may be in the wings. But this shouldn't affect you if you are just using the software off-the-shelf, and there is likely to be push-back from people who develop plugins for disruptive changes. No noise is good news.

My parents had a humorous euphemism for not making up your mind. They called it "retaining the power of choice". I think it nicely sums up why putting off this particular decision ... for a bit ... is a good plan.

Improve this answer
2
  • That would mean, that we can't do anything wrong either way...
    – Lukas Eder
    Feb 25, 2011 at 13:53
  • @Lukas Elder - I'm not saying that exactly. What I'm saying that the risk of getting "stuck" if you make the wrong choice is small in the short term. The risk is not zero, and it increases over time.
    – Stephen C
    Feb 26, 2011 at 2:10
1

I think it depends on whether you're using Hudson/Jenkins from as a user or as an active developer/contributer. If you're mainly using Hudson/Jenkins as your CI system, and let him handle the build then I think the decision is not that important. Right now they're virtually identical. Even if they move apart in the future, the configuration of project X to run in CI system Y is relatively easy - once setup, there is not a lot to do for the rest of the project lifecycle. So even if you make the "wrong decision" by choosing system A and later think "Oh, we should've moved to system B" than you might need to update your build configuration but that's it - no big deal.

If you, however, are actually contributing to the Hudson/Jenkins community, by writing plugins it becomes more of an issue, since eventually these two are going to develop distinct APIs for a plugin. In this case I'd suggest retaining Jenkins, since most of the original developers have chosen this as their path and that's where I'd pldege my allegience to.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.