Evolving Mission of Jenkins

Lately, perhaps subtle but exciting changes are starting to happen in the Jenkins project.

The past few weeks have seen the birth of two new initiatives in Jenkins: Jenkins Essentials and Jenkins X. Each is exciting in its own right, and I encourage interested parties to take a look at their goals and missions and participate in them. But in this post, I want to discuss why together these two dots form an important arc, which actually started in the introduction of Jenkins 2 and continued with Blue Ocean.

In Jenkins 2, we changed Jenkins so that it starts with richer functionality and more sensible security setup, among other things. This was the first step in a new direction for Jenkins. We changed our focus from “we’ll write plugins and you figure out the rest” to “we’ll write plugins, we’ll assemble them, and we’ll help you be more productive.”

Blue Ocean was another step on this journey. We focused on important continuous delivery use cases in Jenkins, and aimed to provide a great user-experience for those use cases. Aside from obvious productivity boost for users, it also decidedly blended together feature areas that are internally provided by a whole bunch of different plugins, but users see much less seam between them.

Jenkins Essentials, which R Tyler Croy proposed in recent weeks, is another step forward. That project aims to take an even bigger responsibility in keeping people’s Jenkins instances up and running. Like Blue Ocean, Jenkins Essentials focuses on delivering a comprehensive Jenkins user experience rather than a collection of unrelated plugins which users have to figure out how to wire together. It also creates an exciting vehicle for contributors, in which we can develop and deliver features quite differently, and more rapidly, than how we deliver them today.

Jenkins X, which was proposed by James Strachan a few weeks after Jenkins Essentials, is the latest point on this same arc. Jenkins X brings a different aspect to building a solution — it focuses on a specific vertical area, namely Kubernetes application development, and drastically simplifies the software development in that domain by bringing together Jenkins, a whole bunch of plugins, and an opinionated best practice of how one should use Kubernetes.

Collectively, the arc that these efforts form aims to solve the most important and consistent concerns for Jenkins users — ease of use, plugin complexity, fear of upgrade, etc.

In the early days of Jenkins, it was up to each and every Jenkins admin to find the right way to assemble pieces into a solution for their organizations, but this hard work remained largely private. Now, these newer projects are bringing this back into the community. They are making Jenkins more valuable to existing users, and more approachable and useful to a whole new set of users who are not currently using Jenkins.

From that perspective, I hope more projects like them will follow, pushing us beyond “just writing plugins”, taking even bigger steps to make users productive. This is a little bit like how I watched Eclipse evolve from just a Java IDE to an umbrella of projects.

Exciting times!