Not knowing what I was getting myself into, about eleven years ago I started contributing to what became known as the Jenkins project. What followed has been nothing short of incredible; hundreds of new contributors, tens of thousands of new users, and millions of executed pipelines. Growth is challenging. Growth means new problems which demand new solutions. Two and a half years ago I stood in front of a large group of contributors at the 2017 Jenkins World Contributor Summit and made a pitch for what I called a “Jenkins Software Foundation”, never shy to pilfer ideas from the Python community. With help from my pal Chris Aniszczyk and the Linux Foundation, the concept morphed into something far more comprehensive the Continuous Delivery Foundation (CDF), for which my colleague Tracy Miranda has been leading the charge, helping drive the founding of the CDF.
Kohsuke wrote up a good overview post for the jenkinsci-dev@ mailing list which spells out the reasons why the Jenkins project should join the Continuous Delivery Foundation once it has been established. For those interested in the Jenkins project, I encourage you to take the time to read Kohsuke’s mail if you have not already. In this post, I wanted to share some of the reasons that I am excited to help establish the Continuous Delivery Foundation (CDF).
Continuous Delivery (CD) has been an integral part of my career, something which I learned early and became passionate about, even before it was so clearly characterized by Jez Humble. I view it to be so fundamental to the practice of software development, that I have started to react like a puzzled puppy when somebody says they don’t practice CI or CD. Imagine if somebody said “eh, we’ve got a project to adopt Source Control here, but the executives aren’t really convinced yet.” Your eye would twitch and your jaw would drop. “How can any organization not use Source Control in this day and age?!” I believe CD is that fundamental to modern software development.
Continuous Delivery is also not the domain a single tool like Jenkins, but rather relies on many tools working together in concert. While I might put Jenkins at the center of it all, it is by no means the only pretty face in the picture. Unfortunately, many open source communities like Jenkins tend to have a necessarily narrower view of their world. They focus on their thing, which makes sense, but this can result in missed opportunities for incredibly valuable cross-over episodes.
Many of the tools we rely on for CD are supported wholly, or in part by different vendors as well. Jenkins receives substantial investment from CloudBees, as well as Microsoft and Red Hat to name a few. In the last five years, I have come to understand how and why foundations such as the CDF, can act as neutral territory for these different companies. By providing corporate contributors a set of guidelines, rules, and expectations, open source projects stand a much greater chance of eliciting support from them. Whether it’s advocacy, code, or cash, helping bring corporate contributors under the same neutral tent as the rest of us helps ensure the longevity of open source efforts. The added benefit of the rules set forth by the foundation is that corporate actors cannot overrun one another or individual contributors, intentionally or otherwise.
In the earlier days of free and open source projects, we deluded ourselves into thinking that everybody would read our licenses, subscribe to our “open source ethos”, file and fix issues, and contribute code back upstream. The reality is that it takes a lot more to operate large open source communities. It takes people, it takes infrastructure, and it takes money. Foundations like the CDF provide a means for organizations which depend on, or are otherwise invested in projects, to participate in a meaningful way. The Jenkins project runs on a shoe-string budget. We spend no more than $10-15k annually. If we were to tabulate the value of our donated assets, free services, or any of the other things I have managed to beg for over the past eleven years, that number would be closer to 60-80k annually. Kohsuke can attest to my ability to beg for free stuff for the Jenkins project, but free stuff is not guaranteed year to year. In order to grow, Jenkins needs a stable budget which we can invest in services and people, similar to larger foundations like the FreeBSD Foundation.
If you find yourself worried about the sustainability of open source, looking at different community homes, crowd-funding, or other ideological tools such as licensing changes, let me help you out. What makes large open source projects sustainable is a consistent budget. Because underneath it all, what makes open source projects “go” is people. Ensuring talented writers, developers, marketers, testers, and designers continue to contribute means that their employers have to invest time on their behalf, or they need to be paid through other means. I strongly believe that open source foundations provide a path for larger free and open source projects to solve that fundamental problem of budget.
The Continuous Delivery Foundation is not yet launched, but I’m already excited for its potential. Not only for the Jenkins project, but for the entire domain of continuous delivery.
It’s about time.