When reading the recent Jenkins survey results that just got published, my eyes got initially focused on the impressive numbers: 65% growth Y-to-Y to 53k active installations, 636 plugins available and growing by an average of one every two days, 83% of the respondents considering their Jenkins installation as being “mission critical,” etc. Yet, those numbers also serve as an illustration of some of the current major changes in the IT industry.
The first observation is that the good old world of packaged software is fading away. The cloud comes with a culture of “always on” codebases that are not published as binary blobs that will have to survive your most conservative customers, but, instead, as always “releasable” codebases provided -as-a-service. Instead of thinking of software as a growing number of very distinct and aging major releases, software developers now look at their application as an always-on release pipeline: current development branch, testing branch, staging branch, production branch, with some companies pushing value through that pipeline as frequently as multiple times a day! Focus is moving away from historical branch support towards next week’s new feature: code, test, publish, measure outcome, keep or rollback the feature and move on to the next iteration… While current on-line/cloud models enable such a shift, those shifts are only possible if the underlying tools are DNA-compatible with such a development process.
Continuous Integration, with its Continuous Deployment close cousin, is at the very core of such practice. In an environment where software gets released every 18 months, it is unlikely to see a CI environment considered as mission critical. However, in an always-on world, where new software gets pushed to testing, QA, staging and production continuously, there is hardly any debate that this core orchestration piece is mission critical. This is one of the most important stories that the Jenkins survey numbers tells. Now CI in itself is one critical piece that’s required to deliver on that always-on delivery model, but more pieces are required (such as delivering this experience as a … service, integrating this environment with third-party services such as load-testing, UI-testing, etc. and enabling transparent/no-cost/no-friction deployment to production). These services are what we are providing at CloudBees with DEV@cloud and RUN@cloud, under the “Continuous Cloud Deployment” tag line.
The second observation is that ecosystems remain critical to software and services offerings, be it with MSFT in the last 2 decades, or today in the mobile phone industry with Android and iOS or with AMZN in the cloud. It quickly becomes of war of ecosystems. On that front, Jenkins numbers are truly impressive: on average, more than one plugin gets released every other day! This obviously has architectural ramifications (Jenkins is built upon a highly pluggable architecture), but, also importantly, also boils down to trust: will a contributor trust the core entity that manages the project and make it evolve to provide a fair and balance environment that will serve your business interests in the long term? Establishing that relationship is essential in building a successful ecosystem. The Jenkins community has clearly succeeded in establishing that level of trust.
This nicely leads to my last observation: open source projects are more than a bunch of code, a license and a brand. Don’t get me wrong, successful projects are certainly about code, license and brands. But they are also about showing leadership, respect, and establishing trust for the long run. Two years ago, I remember writing another blog about the (re-)birth of Jenkins and journalists and analysts were wondering about the viability of the project against much more powerful industry forces. The jury was out. But my past experience in working in open source always made me keep faith in what would ultimately happen. Fast forward and two years after, the topic is just not mentioned anymore: it is boring. This has only been possible because of the excellent project’s stewardship by the amazing Kohsuke Kawaguchi, the Jenkins Governing Board, and the project community at large. Onward!
Sacha Labourey is the former CTO of JBoss, Inc. He was also co-general manager of middleware after the acquisition of JBoss by Red Hat. He ultimately left Red Hat in April 2009 and founded CloudBees in April 2010. Follow Sacha on Twitter.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.