+1. I had the same question "What would be a good reason to use Hudson over Jenkins"
We used to use Hudson and have now moved over to Jenkins and as a user I don't see much difference .... pretty similar looking UI. Why use one over the other?
I'm obviously partial to Hudson, but I will try a balanced answer. Much of the usage of Hudson and Jenkins are very similar, so switching between the two should not be very challenging. A benefit of using Hudson is that it is an eclipse project, so there is an established open source organization behind it. Much (all?) of the eclipse projects are using Hudson for their CI needs. There have been some interesting new features added to Hudson since the fork with Jenkins such as the team concept feature. Benefits of Jenkins are that it has more frequent releases than Hudson (so it will evolve more quickly) and many of the original developers work on it.
I think using either Hudson or Jenkins, even for hobby projects, can be beneficial. When you are working on a project by yourself, it is easy for the project to become dependent on your IDE or computer. If you decide to work on your project on another computer or operating system or if other developers join you on the project, there may unexpected difficulties getting the new development environment configured correctly. By using Hudson, you can ensure that the build is not tied to your specific configuration. You can also use Hudson to automate any tasks that you find yourself doing over and over again (test reports, builds, deployments).
For any programmer working on any project, for your employer or a hobby project, using CI can automate repeatable mundane tasks and implement a repeatable build process. This can be a real time saver, especially when working on a hobby project when there is not much spare time.
Joined: Dec 22, 2013
As I replied to Stephan and as you noted yourself, there are many similarities between Hudson and Jenkins. I think one of the biggest differentiators is the new Team Concept feature that was added to Hudson. Previously, access control was only on a user level. With the Team Concept feature, access control can be defined based on teams (or groups) of users. So you could have a team of developers of Project A being members of Team A and developers of Project B being members of Team B. Then Team A could have full access to Job A and Team B could have full access to Job B and read-only access to Job A (or whatever scenario makes sense). This level of control wasn't possible before without a very complex security configuration.