KK at Jenkins UC

Kohsuke Kawaguchi, normally known as KK, is an interesting guy. He founded the Open Source Software (OSS) project Jenkins, which orchestrates continuous software integration and delivery (as a coded rather than as a manual process). He still  runs the Jenkins Community as well as being CTO of CloudBees (which produces a commercial packaging of Jenkins). I had an opportunity to chat to him at the 2015 Jenkins User Conference in London.

Jenkins started as a hobby project for KK (who was a Sun employee back then). He wrote, in Java, a continuous integration tool called Hudson, which was extremely successful around 2008. When Oracle bought Sun it was thinking about a commercial implementation of Hudson. In 2011, the community – including KK, who didn’t think Oracle would take Hudson anywhere – decided to continue OSS development under the Jenkins name (as Oracle had rights to the Hudson name) and interest largely moved to the Jenkins OSS project (Oracle donated Hudson to Eclipse in 2012). KK is obviously protective of Jenkins as an OSS project and Andre Pino (VP marketing at Cloudbees) confirms that he still stands up for the community – and that CloudBees is very supportive whenever (as KK puts it), he “raises the red flag”.

This sounds like the epitome of the OSS model – KK says that, quite apart from the commercial and professional implications of the Jenkins project, he needs some recreational programming in order to stay sane (which is an interesting discussion topic for KK and his wife and children). But he’s a good programmer and probably the best decision he made was the Jenkins plug-in architecture, which allows both the community and Cloudbees to extend the tool without getting in each other’s way. 

KK now has two roles in Jenkins – in his own words, he wears two different and very separate hats – he mentors the Jenkins community and he is CTO of Cloudbees, the commercial packaging of Jenkins for organisations that want to concentrate on their core business rather than on OSS development.

We talked about the rather “code geeky” look and feel of Jenkins. Basically, he says that it’s what he’s happy with and what the Community is happy with. With OSS, how could it be otherwise? I suggested that there were two sorts of developers, those that like code and those that like dragging pictorial objects into place; KK countered with the idea that sometimes only code will cope. He says that there is a demand for visualisation, but more as a visualisation of what happened, so you can understand and fix it, rather than for a visual development process (where you’d orchestrate a continuous delivery process by dragging and dropping objects into place in a visual model). But he did make the shrewd observation that this might change, if the “citizen developer” got interested in continuous delivery and the DevOps disciplines. DevoOps is all about automation; but if sufficient “citizen developers” joined the Jenkins community, it might start to support visual automation – although KK is emphatic that this would be in addition to the current Jenkins code-based approach (which I think is a good thing).

As an aside, although the OSS culture itself may be – currently – very code-centric (which works well), as OSS becomes increasingly accepted as a valid alternative to commercial software (with some real advantages), I wonder if the OSS culture will change? I don’t see why one shouldn’t build OSS by visually orchestrating cloud-sourced OSS components with well-defined APIs. The source-code for the components is available for inspection; but the higher-level orchestration model would be open for inspection too.

We also talked about the new workflow capabilities in Jenkins. These could help with the choreography of complex activities but KK sees them mainly as accommodating the manual checkpoints or control gates that are an essential part of understanding an automated process in context. They might also help with parallelisation of complex processes – the best way to speed up continuous delivery is to do more work in parallel. On parallelisation, a workflow needs to be designed for parallel processing, with independent units of work – KK thought that a Jenkins plugin to aid parallelisation might be feasible (it could highlight possible dependencies that prevent parallelisation, for example).

Thinking “blue sky”, about where Jenkins is going, we talked about the huge amount of information on an automated system that is currently held in Jenkins, and the further information that could be captured. In future, predictive analytics (applied to development information rather than business information) might be able to exploit this in interesting new ways: patterns of build failure or low velocity could, for example, highlight areas of unexpected complexity or areas where more training is needed; possibly, areas that will become troublesome can be identified in advance, in time to do something about them; and particularly active build pipelines could identify areas of the business increasing in importance and bring this to management attention. I see the possibility of deep analytics applied to repositories such as that in Jenkins, providing “actionable insights” into the development process, leading to better development governance.