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?

Lukas Eder
  • 1,120

3 Answers3

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.

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.

Stephen C
  • 25,388
  • 6
  • 66
  • 89
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.

perdian
  • 2,106