Kohsuke Kawaguchi, founder 0f open source continuous integration tool Jenkins, was an early leader in DevOps, guiding the development of the Jenkins Project during his time at Sun (and later, Oracle) and plotting the course it would follow.
“This project started as a hobby while I was at Sun,” Kawaguchi says. “From the project’s inception, it was not popular. During those early days, my leadership was really just to keep the project going. It was easy for me because the project was so useful that I didn’t need any external encouragement.”
Once Jenkins steadily gained acceptance, Kawaguchi worked on polishing it and making it more user-friendly. “Writing software that works for you is much easier than writing software that works for other people, especially first-time users,” he says, noting he drew from his experiences supporting users to make Jenkins a better tool.
Kawaguchi applied his previous open source project experience to make Jenkins an application/project that others could join, invest in and enjoy using. “As the project grew even more popular, I expended more conscious effort into those initiatives, specifically into extensibility and incentivizing sharing,” says Kawaguchi.
Kawaguchi’s Vision for Extending Jenkins & Incentivizing Sharing
Kawaguchi decided to use a plugin model for extensibility to solve the potential bottleneck of using an increasing number of contributors while managing change. Sensible software development does not permit unbridled change; developers must propose changes or at least innovate in an environment where they can retract changes that create issues.
To attract more contributors into Jenkins, Kawaguchi decided to let people add whatever they wanted to it, through plugins. “Selling me on a software change need only happen when a change affects my use, so if we can split things up such that your change is in your plugin, I’m not affected by your change so long as I don’t use your plugin,” explains Kawaguchi. “This enables developers in the Jenkins Project to go from idea to implementation without getting blocked by someone, which reduces organizational overhead and encourages innovation.”
But while this approach solves the extensibility issue, it also can create a new one. Without any incentive to share plugins with other users, extensibility can lead to siloed development in which only the group that created the plugin benefits from it. It then becomes difficult for the open source community to locate, leverage and improve on others’ advances, leading to plugin abandonment should the developer of that extension relocate to another project.
Kawaguchi pressed for an update center and set a rule that plugins listed in the update center must be available to the entire community. “This created a positive feedback loop that encourages users to install plugins through the update center and developers to bring their plugins to the community,” says Kawaguchi.
Breaking Down the Walls
While extensibility and sharing accomplished much, the Jenkins Project faced another hurdle. Other projects such as the Apache Project use apprenticeships (the “committerships”), an approach designed to create a stable of tried-and-true contributors. But it also can be a hurdle, discouraging many developers.
The Jenkins Project, however, simply asks that contributors apply good judgment when considering whether a plugin/change is good for the larger open source project and its community. “This might sound scary to some, but it really strikes the right balance between the speed of progress and quality,” says Kawaguchi. “Besides, everything is version-controlled, so if we later find a problem, we can always roll things back.”
Stay tuned to staging-devopsy.kinsta.cloud for the rest of Kawaguchi’s DevOps journey with Jenkins.
