In part one of this two-part series, we covered the early work of Kohsuke Kawaguchi, founder of Jenkins while he was at Sun (now Oracle) and also how he addressed the project’s challenges to growth by applying extensibility/plugins, incentivizing sharing in the community, and removing barriers that can result from apprenticeships. Now let’s continue as Kawaguchi shares the rest of his story.
Explosive Community & Tooling Growth
Today the Jenkins Project and its open source community boast more than 120,000 members and 1,000 plugins. It was by design that Kawaguchi spurred that growth. Here are the challenges he faced, his solutions and his good fortune.
Though continuous integration (CI) and continuous delivery (CD) have sprouted an immense amount of automation in DevOps, it was necessary to have diversity in the software development environment/toolkit to ensure that each developer and team have the tools best-suited to their goals and uses.
“This is where our extensibility features came in handy—by letting people reuse what they could and build the missing pieces. As developers, we prefer flexible building blocks over rigid software that does things in just one way,” says Kawaguchi. This diversity encouraged community growth by removing a tooling stumbling block and brought even more plugins to life.
Jenkins emerged at a time when IT began embracing open source projects and, as a result, benefited from that momentum. “Companies recognize that it’s better in a lot of ways to rely on open source software than proprietary tools. It gives them more control,” he says.
Jenkins as a Key Component for Build Orchestration
The DevOps movement has helped Jenkins become a key component of helping teams orchestrate their builds. From its roots of using time-based activity triggers and requiring a developer complete “this task, then that one” in a cascading, triggering fashion, Jenkins has moved on to model what people do and then pull that work into Jenkins as automated functions.
The automation capabilities of Jenkins kept expanding and Jenkins entered what Kawaguchi calls the “orchestration-idioms-as-plugins” era, with different people in the community developing different patterns for orchestrating/automating activities. “I created one such plugin called the Promoted Builds plugin, which basically was a generalization of how different teams collaborated within Sun to release software,” says Kawaguchi. By creating these idioms within the model of executable plugins that others can adopt, the Jenkins Project fostered even more efficiency in sharing, adopting and reusing proven orchestrations.
As automation spread from builds to tests, deployments and releases, these orchestrations gained new importance but presented still another challenge, which a plugin also solved. “Idioms were useful but different idioms created by different people weren’t really composable,” Kawaguchi said. “In recognizing that, we’ve built the Workflow plugin, which creates a single framework to describe any orchestration, whether simple or complex. We can share and compose these fragments.”
Kawaguchi’s Leadership Accelerates DevOps Acceptance
As both a leader of the Jenkins open source community and the CTO of CloudBees, Kawaguchi has helped the open source community and enterprise teams alike wade in to DevOps. The open source Jenkins ecosystem helped to move automation ahead. It gave developers a fast track to useful, functional software that would please ops and enter production quickly. At the same time, it enabled developers to innovate swiftly and improve on that same software to see more utility and recurring rewards.
“Now with CloudBees, we have allowed the project to have a number of full-time engineers, which increased its velocity. It also brought commercial support, an enterprise version of Jenkins, professional services and training,” Kawaguchi notes. “It made Jenkins more viable in the mind of large-scale conservative enterprise users who value those things and allowed Jenkins to be deployed at scale in those organizations.”
