When Kohsuke Kawaguchi received a Google-O’Reilly Open Source Award for his work on the continuous integration tool what was then known as Hudson, we all applauded but felt that the product needed a change of name.

The project, written in Java, finally had to change its name after a spat with Oracle, who said they owned the right to the Hudson name and the trademark. Oracle decided to continue with the development of Hudson and so now there are two competing forks of the same project under different names.

And so Kohsuke’s Hudson, named after an exemplary and loyal English butler, a stoical, fair, just and good-hearted man morphed into Jenkins, another stereotypical English butler.

A former senior engineer at Sun Microsystems, Kohsuke worked on Java to C++, .NET to x64 assembly, He also has system programming experience on different platforms including Windows, Linux and Solaris.

Apart from his work on Jenkins he was involved in JAXB, GlassFish v3 and other opensource projects including YouDebug.

When Kohsuke left Sun he started-up InfraDNA, which provided support and services for Jenkins. InfraDNA was later bought by CloudBees, where he still works.

RM:

How did Jenkins come into existence?

KK:

Jenkins, started life as Hudson but was forked after a dispute with Oracle which claims the right to trademark the Hudson name. The project began casually enough, as I enjoy writing programs and have been writing all sorts of things, games, utilities, and libraries, and so on. Jenkins was initially just one of them without any particular significance.

There were several motivations for writing it. One was that despite I was working in a group of Sun Microsystems that designed and developed JavaEE (the framework layer for server applications written in Java), I’ve never written apps on top of it. And that’s not a good thing. I’d been meaning to write one so effectively that idea became Jenkins; I thought this could be a good vehicle to make myself learn JavaEE.

Another motivation was that I’ve been known as a guy who breaks the build. I was working on a project with several developers, and often I forget to commit some files until my colleagues tell me so. So I thought it’d be nice if I can write a program that finds that out before they do, thereby making me look like a better programmer.

Unlike many of my other hobby projects, this one somehow “clicked” with the rest of the world, and it just kept growing and growing, and it is now quite a sizable project.

RM:

Was there a particular problem you were trying to solve?

KK:

In a way, I suppose you could say I was trying to solve these problems as I mentioned but as the project grew, the problem it tries to solve became clearer to me. That is, as the computing capacity becomes more abundant, we the software developers need to figure out new ways to use that to improve our productivity. And to me, that means more automation — letting computers do mundane things so that we humans can concentrate on more important things that actually require some intelligence. It’s a pretty broad problem, and there are a lot of things that can be done.

RM:

Did you face any hard decisions in Jenkins development?

KK:

There really weren’t any hard-to-swallow decisions, but I did try a few different things in what was Jenkins compared to my day-job projects that may be worth highlighting.

One is the lower barrier to entry for new contributors. In my own experience in trying to contribute to other open-source projects, I often got frustrated with the rituals that I have to go through, especially when my contributions are small pointed changes. By “rituals”, I mean things like hanging around in the project long enough before given the privilege of making changes, or making sure that a whitespace character is placed after every comma, or that there be only one return statement in a function call. So in Jenkins, I intentionally tried the opposite extreme. I give away the commit access privilege to anyone who asks, and relied on people’s common sense to play along.

Another choice I made was the release model of pushing a new release continuously every week. While it has its downsides, it creates incentive for people to keep the codebase functioning all the time, and discourage contributors from making incompatible changes.

So I’m happy with these decisions that I made.

RM:

I have read that Jenkins was developed while you were at Sun in your spare time. Can you tell me a little more about this?

KK:

I just really enjoy writing computer programs. It has always been my hobby. And from time to time I get motivated to write a new one. Sometimes, it’s the anger toward existing poorly written software, and the feeling that I can do so much better (there’s obviously a big difference in thinking that I can do better versus actually doing it, but hey.) Sometimes, I just come up with a nifty idea that solves some particular problem in an elegant way (I recently talked to a chef, and apparently this is very common in cooking — you come up with a creative way to put together this and that ingredient, and try it out.) Or sometimes it’s just me wanting to implement a clever algorithm.

Sun was very open to this kind of things, and I was lucky that my group was mostly doing open-source. So doing this kind of things wasn’t really a problem.

So Jenkins started as one of those, and then I started using it at my work. My colleagues liked that, and they gave me feedbacks, so I kept improving it. Then other teams started discovering what we were doing, and they started using it, and it kept going like that.

RM:

What do you think Jenkins future will be and what applications it will be put to?

KK:

When I think of Jenkins at high level, I think of it as a platform, rather than a CI tool. It has gotten enough low-level pieces and extensibility such that it can be a great foundation for all kinds of server-side tools for developers, and there are a lot of things that can be done on the server side. In a sense, my goal is to be like Eclipse for server-side. My ambition is that my new company InfraDNA can play a role here.

In parallel to this, there are a lot of enhancement requests and bug fixes filed in the project, and we need to work on those bit by bit. We the community has been traditionally very good at doing this.

RM:

Can you describe the benefits of continuous integration?

KK:

Tools like Jenkins bring several benefits.

One is that it enhances automation, and automation is good. If it’s your computers that are doing builds and tests, you can do them far more often than any human being can do, and that’ll improve your confidence in the code. When computers do some of the work that you used to do by yourself, you can use that time for doing other things, which is good, too.

Another benefit is the reduced human dependency. Several years ago, it was common situation that only a few people know how to run a test, or how to perform a build. It was also very common that only the development team knew which branch is actively worked on, or where the up-to-date test reports are available. The problem becomes obvious when those “critical” people go to a vacation, or if people outside the team want to pitch in to get a few issues resolved — the productivity of the team gets hampered badly. Tools like Jenkins reduce this issue, as Jenkins knows about and publicizes all these things, and Jenkins doesn’t take a vacation. Another way to put this is that it improves the transparency of the project.

And then what we are discovering now is that once you have sufficient degree of automation in place, it opens up a whole different level of productivity. For example, you can now “compartmentalize” your development team, so that a mistake one developer makes won’t affect others in the team. You just keep on making changes and let Jenkins verify that your changes look good and make them available to others. Another example is that you can very easily utilize a much bigger pool of computing resources, for example to run a large number of tests in a short amount of time.

RM:

How practical is it to integrate Jenkins with existing version/release management systems?

KK:

One of the big selling points of Jenkins is its extensibility, and version control system support is an area where the extensibility worked quite beautifully. People from all over the world came to the Jenkins project to develop plugins that integrate Jenkins with their favorite version control systems.

On top of that, some companies even have in-house version control systems (which is a crazy thing to do, but it happens often), and I’ve also seen them develop plugins for those, too. So whatever source code management system you are using, chances are good that Jenkins has a plug-in for it.

RM:

Are there other continuous integration systems for Java, and how do they compare?

KK:

Yes, there are many. But I don’t really spend too much time looking into other implementations – Jenkins users are already pretty loud and clear about what they want to see in Jenkins, so I don’t need to turn to my competitions to understand what the users want. With that said, I think Jenkins has done a few things very well.

One is its extensibility. While everyone claims that their CI server is extensible, I think the degree of extensibility in Jenkins is unparalleled, and it shows in its number of plugins and contributors, and the kind of things those plugins can do. Extensibility works very well with open-source, as it makes contributions easier.

Another thing it did well is that it made everything configurable via web browser. It creates a much richer user experience, compared to more traditional configuration-file based approach.

Yet another thing is its support for distributed computing. It is really critical that a CI server can manage a large number of computers as a single build farm, in a way that doesn’t cost too much in terms of the maintenance overhead.

Lastly, Jenkins has a lot more focus on the operational side of things, such as the upgrade experience, installation.

Trying to achieve these goals simultaneously, without sacrificing the ease of use, is actually very tricky, and I think Jenkins has gotten those right.

RM:

What are the tools you use to program with?

KK:

I write Jenkins on IntelliJ IDEA on Linux, and of course with a help of Jenkins. I’ve been so attached to this combo, plus a whole bunch of customizations at different layers. It’s so much so that I cannot really work productively on anyone else’s computers, it’s just too frustrating.

RM:

Do you feel that there are times in your life where your passion for programming and Jenkins in particular has been to run to the detriment of other parts of your life?

KK:

My wife certainly wouldn’t mind my spending more time with the real world than the virtual world of programming!

But more seriously, I think programming is such an integral part of me that I can’t really think of it the way you phrased it. It’s one of the facets that make me who I am, and while I’m sure every such facet has various implications, I can’t quite picture what it would be like without it.

Perhaps what that means is that I’m so brain-damaged already that it’s hopeless.

RM:

What do you enjoy most about programming? Is there something about it – the intellectual fun of defining a process that can be enacted for you by the machines you work with – that’s the same weather you’re operating very close to the hardware at a very abstract level?

KK:

I think a part of what I like about it is the sense of building something. The act of turning an idea into a reality (OK, programs aren’t all the real nor tangible, but you get the idea.) There are other similar activities that have this aspect (like the chef I mentioned earlier, LEGO building, or wood working), but programming is unique in that one can build a pretty big program, and only your imagination and capability are the constraint.

I enjoy programming at all kinds of levels. Being close to the hardware is fun, because I get really excited about the elaborate abstraction that is CPU, modern CPUs are very abstract things. I also enjoy working in higher-level languages, as I can get more work done quickly.

I also like that I am making a positive change to the world by doing this. Programs I write are used by a lot of people, and it does make their lives better, if only just a little. Still, it’s a very satisfying feeling.