If you run builds while you sleep, you felt the tremor when Hudson split.
Today the question is simple: stay on Hudson or move to Jenkins for your CI server.
From a seat on the build floor, the story of Hudson vs Jenkins is a story about people more than code. Hudson carried many of us from the Sun days into nightly builds and green balls, and then the handoff to Oracle brought a new set of rules and a push on naming rights. The community wanted a vote and a path forward, and that path turned into Jenkins, led by Kohsuke Kawaguchi and a very active set of plugin authors. You can read threads all day, but the short version is this: energy and commits moved fast toward Jenkins, the plugin update center sits busy, and release cadence feels quick and alive. Oracle kept Hudson on its rails with corporate infra, and that promises a steadier gate and process, though the vibe on the public lists feels quieter. For a team that just wants reliable CI, the fork raises a practical choice, and it comes down to momentum, governance, and where your plugins are getting love.
Let’s talk migration, because that is the bump in the road most of us care about. Moving from Hudson to Jenkins is not a rewrite of your world; jobs, build history, and common plugins carry over cleanly for a large chunk of teams. The Jenkins core reads the same job structure and the same workspace layout, and most of the popular plugins trace their roots to the same authors who now push releases on the Jenkins side. If your shop runs Git or Subversion, you will find the Jenkins plugins are current and under active care, with faster fixes landing and new features like smarter polling, tighter changelog parsing, and better credential handling. Maven support is still first class, Ant is solid, and those big matrix jobs with lots of axes keep working, while the Build Pipeline view and promotion plugins help you tell a clean story about stages. Plan the move like any other production change: take backups, line up plugin versions, test on a separate controller with a copy of your jobs, and scan for any custom extensions that tie you to Hudson only features. Teams that need a calmer cadence can pick the Jenkins long term support line, which gives you a slower and more predictable release base, while the weekly train suits shops that want the newest fixes on their CI server.
There is also the business lens, which no one should ignore. Oracle wants Hudson as a steady option with a vendor behind it, and that will appeal to orgs that favor vendor backed tools and slower change. On the other side, Jenkins rides forward on community drive and a flood of plugins, with companies like CloudBees already circling with hosted builds and commercial support if you want a phone number to call. The network effect is real: more contributors, more plugins, more examples, and that loop feeds itself, which matters when you hit a weird bug on a Friday and you need a fix or at least a workaround. Search trends, job posts, and chatter in user groups point to Jenkins as the center of gravity right now, while Hudson finds its shape with Oracle tools and a path that may appeal to teams who like things neat and slow. Both sides talk about security, governance, and stability, and both ship fixes; the difference most folks will feel is the speed of change and the reach of the plugin world wrapped around each server. If you depend on a specific Hudson only extension or a workflow that your ops group blessed years ago, staying put can be fine; if you want the wider street of community and faster plugin cycles, Jenkins is where the traffic is going.
Pick the CI that keeps your people shipping, because in the end tools are code but communities decide the pace.