CloudBees and Jenkins: An Update

Hi Jenkins community. For those of you who don’t know me yet, I have been chief product officer here at CloudBees since last March - so I’m just now no longer a NewBee! I’m responsible for all of CloudBees’ engineering, product management, product marketing, design, and documentation - hundreds of busy Bees working from 15 countries. Which means I’m responsible for our strategy of how we invest those resources, including all of our CloudBees funded contributions to Jenkins.

In the last few months, as we’ve moved to align our product development with the direction described by our CTO and Jenkins creator Kohsuke Kawaguchi in his Shifting Gears post, we’ve learned some things, some things have changed, and we’ve made some changes in direction and priorities as a result, and we haven’t yet communicated that to the community. You’ve also probably noticed the announcement of our CloudBees Jenkins Distribution and may have perceived some differences in how CloudBees participates in the community and may have wondered what’s going on. I also haven’t put our Jenkins stewardship in the context of our larger product strategy. So this post is intended to begin to remedy that.

If you are reading this and have more questions or feedback on these or other topics, I encourage you to drop me an email at cfrln@cloudbees.com - I’ll be sure to reply and will post followups based on our email conversations. I’m also pretty active on Twitter as @cfrln . (And if you’d like to know a little bit more about me and how I think about software, take a look at my previous posts on my own journey and thinking around #continuouseverything .)

First off, I want to reaffirm CloudBees’ intent to remain Jenkins’ foremost corporate contributor and continue to do our part to ensure that Jenkins remains the most powerful, flexible and widely used general purpose CI/CD and DevOps automation framework. Thanks to CloudBees’ continued business growth, we have the good fortune to be able to significantly scale our product development organization to do more of many things we consider very important, including our Jenkins and related open source investments. While in earlier, leaner years, we had teams that worked on both our commercially licensed CloudBees Jenkins Platform/ CloudBees Jenkins Enterprise *and* our open source contributions to Jenkins, as of late last year we created and staffed dedicated teams for Jenkins and for its sibling project Jenkins X .

Also, in those earlier years, when our commercial products were what I call “Jenkins ++” and architecturally delivered primarily as Jenkins plugins, there was more tension around “should we put this in open source or make it proprietary and premium to make money?” Since June of last year we embarked on an updated product strategy that replaced CloudBees Jenkins Platform and CloudBees Jenkins Enterprise with a single product we now call CloudBees Core . We now see CloudBees Core and our commercial products as helping manage Jenkins-based CI/CD controllers that customers run themselves (and eventually also jobs running in the CodeShip CI/CD-aaS we acquired last year), rather than being “versions” or “flavors” of Jenkins. The next major release version of CloudBees Core will have a new architecture that is not built on Jenkins, but will be able to manage controllers across every deployment model and platform on which Jenkins runs. And it will be a smooth in place upgrade with no loss of capability (in fact lots of new capability!) for customers using any older CloudBees Core, CloudBees Jenkins Platform/Team/Enterprise, just Jenkins, or Jenkins X.

That allows us to re-affirm that any feature that is necessary for a developer to choose Jenkins or Jenkins X over non-Jenkins open source CI/CD alternatives should be open source - so no more zero sum game between open source and commercial.

So how do we make money then? (If we don’t make money we won’t have development capacity to do anything!) Well, two ways. Support for Jenkins and Jenkins X, and our commercial products.

What do we make premium? Like many open core companies serving developers, our commercial products get the features that developers care about only when they are working in the context of a larger organization and having to collaborate and coordinate across teams, deal with policies or standards, or wanting to share and learn with other developers across the organization. This is true of what is exclusive to CloudBees Core today in its v2, as well as DevOptics, and there will be much more in this vein in the upcoming Core v3. But if you don’t have those concerns yet, you can happily use Jenkins or Jenkins X, and we are happy to keep making them both better.

We just released CloudBees Jenkins Distribution a couple of weeks ago and it’s a first for us - free, with proprietary features added to a rock solid release version of Jenkins. We’ll be doing similar for Jenkins X shortly. Why are we doing these?

Well, a few reasons.

For both Jenkins and Jenkins X, we wanted to have stable distributions to base our support offerings on. In Jenkins, that means including previously premium features of CloudBees Core, CloudBees Jenkins Platform, CloudBees Jenkins Enterprise, and CloudBees Jenkins Team for free - CloudBees Jenkins Advisor that helps diagnose issues in your Jenkins, CloudBees Customer Assurance Program (CAP ) that certifies plugins and versions of those plugins that we test to be sure are stable and compatible with one another, and BeeKeeper Upgrade Assistant that makes for happy “boring” upgrades. So while we’re not making these open source, we are giving these away. We’d love you to have a support contract of course, but you don’t need one to download, install and use our distributions for free forever.

Then, with the launch of the new Continuous Delivery Foundation (CDF) (which we’re super excited about) we are moving into a slightly different relationship to the community with much more involvement of other large players in CDF projects including Jenkins and Jenkins X . That is one reason we felt it important to have a place to land non-premium enhancements asked for by our user base independently.

We also feel that some things that Jenkins users would want or need are significant pieces of IP, sometimes backed by actual services (like CloudBees Jenkins Advisor) that we do not feel should be available to other software vendors who have not contributed much to them, or in many cases much to Jenkins at all, as part of any of their Jenkins-based offerings. We felt a clean split between proprietary and open source was more straightforward than some of the new “open source” licenses with restrictions that are beginning to be out there.

Finally, we do frankly want to earn the right to have a direct relationship with developers running Jenkins - there is free registration needed to install and run our free distributions. That means there needs to be value that is worth a developer creating a CloudBees account. CloudBees Jenkins Advisor, CAP and Upgrade Assistant are only the beginning of this value. We have lots of ideas for delivering value to developer users within the distributions’ in product experience, as well as new products and services integrated with them that we are starting to design and prototype. We do have an ambition to create a thriving CloudBees community overlapping with the thriving Jenkins community.

We’ve created this flow chart to help clarify our decision process.

Ultimately, we’ll put anything in open source necessary to ensure Jenkins remains the best open source CI/CD and DevOps automation server for any developer on any development team, but may keep some things proprietary that go beyond that, especially if they link to services costing us money to operate. Whether it’s free or premium boils down to a business analysis of whether the community building impact of making it free justifies the hard costs it might involve or the opportunity cost of what we could make by selling it. We’ll continually monitor all the outcomes of our choices and will often move things across boundaries as conditions change. Our business strategy continues to depend on a thriving Jenkins community, and we won’t make choices that threaten that for more short term returns.

Close observers out there may have noticed that some of the work CloudBees has been contributing to open source since the Shifting Gears blog seems to be following a different behavior pattern. We believe these changes are ultimately good for both CloudBees and the community as a whole (or we wouldn’t do them!) But it is on us to be transparent about that change.

With the CDF, we are sharing more of the responsibility and the benefit of Jenkins and Jenkins X contribution with other community members - from tech giants to individuals. As an example, in collaboration with Google, Tekton is becoming a new pipeline execution option within Jenkins X. With CloudBees Core and our other commercial products’ direction, we are moving to selling something that works with / depends on Jenkins rather than being a “flavor of” Jenkins. That means we are actually ready to do a lot more in both free and open source.

With Jenkins X, we’ve initiated an open source project with a very different early community dynamic than has been present in the Jenkins community. It’s more “Elasticsearch style” if you will, where we have really driven a lot of the early development. We’d actually like to take this into a more collaborative direction and nurture more contributors. I sincerely apologize to those to whom we haven’t been responsive enough in the chaos of the early days of this project. We hope that many of you in the Jenkins community find happy places in the new Jenkins X community if you’re moving to Kubernetes. The Jenkins X app framework should become an exciting place to contribute, just as the Jenkins plugin framework has been for many years.

But on the Jenkins side we may do more “leading with code” by building things fast without a long proposal process and include them in our free version while waiting for community approval to get them into the open source projects. Kohsuke likens this approach more to that of Chef than how we have done things in the past. We also won’t propose things in the community anymore which we find important for our product strategy, but that the community might not care as much about independently.

We believe that, done right, this change actually makes for a healthier community with less of an agenda driven by one vendor. We acknowledge that this change in approach, and the pressure to create value in our free distributions, carry the risk of creating a vacuum in project leadership. Time will tell - and please do let us know if we’re getting it wrong.

Now onto what we’re doing in Jenkins and Jenkins X and how it has evolved since Kohsuke’s Shifting Gears post.

The biggest change since Kohsuke’s post has to do with the respective missions of Jenkins and Jenkins X. Instead of building Jenkins X to run on Kubernetes exclusively for the use case of continuous deployment *to* Kubernetes, while at the same time investing in the Cloud Native SIG and all of its associated initiatives in the original Jenkins project, it actually made more sense to make Jenkins X into a general purpose CI/CD and DevOps automation server that could run most of the same workloads, even the same pipelines, as Jenkins alone but natively *on* Kubernetes.

So the scope of Jenkins X use cases becomes essentially the same as Jenkins use cases in time, with Jenkins X being what you’d use to take advantage of Kubernetes for execution, and Jenkins what you’d use if you don’t want to do that or can’t do that. If you’re already running just Jenkins in Kubernetes, you may end up moving to Jenkins X at some point. But if you stay with Jenkins, we’re committed to it continuing to stay best in class for running CI/CD yourself outside of Kubernetes.

To do this we are doing a subset of the work that had been under that Cloud Native SIG umbrella - most notably making Jenkins run “serverless” or “ephemeral” - so that Jenkins itself running existing Jenkins pipelines could execute on Kubernetes *within* Jenkins X. The first version of this shipped in the Jenkins X project already. But we’re choosing not to fund development of work in the Cloud Native SIG that we judge to only be of benefit running Jenkins on Kubernetes outside of Jenkins X because it would be duplicative and inefficient to do so. Some of the work outlined in the Cloud Native SIG is clearly already present or in progress in Jenkins X - particularly the cloud native extensibility mechanism of its app framework. Some makes sense in the context of keeping Jenkins healthy even outside Kubernetes - Config as code - and we still have it in our backlog but have not yet started. Some we are not currently intending to do now - but will keep an open mind if conditions change - such as data on cloud managed data services.

Our investment in making Jenkins X the cloud native general purpose CI/CD framework does not in any way lessen our commitment to keeping Jenkins healthy for those running it outside of Kubernetes, nor lessen our obligation to ensure that paying CloudBees Core customers who run Jenkins controllers today on Kubernetes outside of Jenkins X have a smooth path forward. Keeping Jenkins healthy does not mean just basic maintenance and life support - it means new features and improvements that emerge as users’ use cases and technology options evolve. We have a dedicated team on Jenkins, separate from Jenkins X, and they’re not just doing bugfixes. No one knows how fast or how widely Kubernetes will spread, and we want Jenkins to continue to be the favorite choice for running CI/CD yourself outside of Kubernetes, while ensuring that Jenkins X becomes the favorite for doing so in Kubernetes, regardless of workload.

OK. So what is the status of the rest of the work outlined in Shifting Gears beyond Jenkins X and Cloud Native?

Security. We’ve delivered many security fixes in the December, January and February releases and have more resources devoted to addressing them than ever before.

Java 11. We invested significant resources in the Java 11 support project. CloudBees engineers did a significant part of the work around Jenkins JEP-211, and CloudBees also contributes engineering resources to the Java 11 Support Team, which maintains Java 11 support in the community.

“Continued evolution of Jenkins pipeline.” We are working on a significant expansion of use cases covered by declarative syntax which should land in the middle of this year. We did shelve ideas for a new pipeline execution engine to make scripted pipeline execution more stable since we feel that it is better to help users migrate scripted to declarative, OR migrate to Jenkins X at such time as its wrapping of Jenkins execution provides more stability to scripted. The new declarative pipeline will include many of the features that made scripted attractive, such as libraries.

Config as code . Discussed above. Still likely, not started as official CloudBees Product Organization funded work yet due to resource tradeoffs, although we appreciate and don’t intend to waste the independent community efforts so far that involved both some of our own Bees and our friends at Praqma .

Developer experience. We are focusing our CloudBees efforts to build a better developer user experience on work that will start in our free distributions. This includes the “batteries included onboarding experience,” a “modern lovable UX,” and “developer experience improvements.”

This new experience demands we do what Kohsuke described as “plugin spring cleaning” and “table stakes service integration.” But we absolutely do not want to fork community plugins, duplicate them, or deprive the community of them, so this work we will do in open source, contributing to existing plugins where need be, and reaching out to and collaborating with their original developers and maintainers. We want to ensure that every critical plugin is healthy in open source. This is a very significant amount of CloudBees funded work going into open source.

We have not materially shifted from Kohsuke’s Shifting Gears stance on Blue Ocean, though we know that the community has some concerns here.

“Given that, CloudBees will reconsider where to spend its effort in Blue Ocean. The current work where parts of Blue Ocean are made reusable as NPM modules is one example that aligns well with this new vision.” - Kohsuke Kawaguchi, Shifting Gears

We believe the right UI path forward is to start with a new architecture that leads to the “modern lovable UX” promised above. We have a significantly expanded design team in the last few months with some really solid design thinking going into this new UX. They are definitely building on some of the ideas developed in Blue Ocean and we are certainly happy to contribute components back and leverage some existing independent components as noted above.

Now, onto the last few loose ends. Jolt in Jenkins, Evergreen and posting to cloud marketplaces.

We believe in all the great reasons to do something like Evergreen - continuous delivery and deployment of a streamlined package of Jenkins and plugins - that Kohsuke outlines. Evergreen provides the ability to get immediate feedback on changes and thereby get benefits of continuous practices for the Jenkins project itself. We are not currently investing in this area due to a combination of sheer volume of projects we are undertaking, and because we are not certain if the right place to do this is open source or free. Part of the motivation - ability to run faster and do experiments - we feel we have a better vehicle for in our free distributions. And the features we are making free that used to be premium - CloudBees Jenkins Advisor, CAP, BeeKeeper Upgrade Assistant - have some mission overlap with Evergreen. So, this remains in the wings but we are not currently doing active work to ship it.

Regarding Jolt - people took away from Kohsuke’s memo that this was a thing in and of itself. I’d like to correct this view a bit. It’s more of an umbrella of various initiatives outlined above to keep Jenkins healthy and an approach where we would be a bit more comfortable “breaking things” to make those initiatives happen. We never intended to ship something called “Jolt.” And as noted above, we’re enthusiastically contributing to or leading a healthy number of those initiatives.

On cloud marketplaces, that work is taking place and we’ll have a full complement of Jenkins, Jenkins X and our commercial products in all the major marketplaces over the next few months.

So that concludes my update on the evolution of both the “how” and the “what” the CloudBees product org is doing vis-a-vis Jenkins over the last few months. I know it was a long post. I’ll conclude with two things.

1. Yes, we have made changes. We will continue to do so as we learn. That is the spirit of the #continuouseverything movement to which both CloudBees and Jenkins are instrumental. We do need to continuously communicate these changes better and I promise that we will.

2. You can influence these changes! We welcome requests for CloudBees developed enhancements in open source, free, and our commercial products. Nothing is off limits! Everyone is welcome to file a ticket for any request for enhancement (RFE) whether or not you are a paying customer. Just email support@cloudbees.com . If you aren’t a paying customer, SLAs don’t apply on response but we will be building out automated status updating for RFEs on CloudBees.com very soon. Another reason to have a free CloudBees account! (Sure you can keep filing tickets in the Jenkins public Jira but this is the way to specifically ask CloudBees PMs to consider prioritizing the work as CloudBees. And it’s easier to send a quick email. ;)

Thanks to everyone in the Jenkins community for your participation over the years and your continuous, honest feedback to us at CloudBees. And again, you can always reach me personally at cfrln@cloudbees.com .

As Sacha says, onward!

- cfrln