You have 1 article left to read this month before you need to register a free LeadDev.com account.
When Kevin Stewart worked at Heptio, open source offerings were part of their business model. Here he shares how they created successful open source projects for their community.
Many people are passionate about the topic of open source. Some have strong opinions about what should or shouldn’t be considered open source, while others debate its merits compared to free software (free as in freedom, not free as in free beer).
There’s also a lot of confusion around open source, especially when you start positioning open source offerings as part of a company’s business model, and terms like ‘open core’ and ‘commercial open software’ are thrown into the mix.
I’m not a purist, and I have worked for companies whose business models were based on the fact that their products were open source. Not every product or company succeeded, but I learned several valuable lessons along the way. In the spirit of openness, I’m going to share some of these stories, walking you through a few different open source projects and highlighting what worked and what didn’t so that you can start pushing more successful open source offerings to your community.
Different approaches to open source projects
A few years ago, I was working at a startup called Heptio (acquired by VMware in 2018). Heptio was founded by two of the creators of Kubernetes and was created to support enterprise adoption of their technology. During my time there, we released several open source projects intended to fill in perceived gaps in the Kubernetes experience for enterprises.
One of our first offerings was ksonnet, a framework for configuring and deploying applications on Kubernetes. From the beginning, the goal was to have ksonnet be developed in the open with contributions from multiple sources. We collaborated with people from Bitnami, Box and Microsoft in an attempt to provide a solution that the community would adopt. Unfortunately, the early enterprise contributors were all trying to solve different problems using the same approach. As a result, ksonnet did not end up solving any particular problem well enough, and so a rush of other projects jumped in to fill the void. Tools like Pulumi have picked up where ksonnet left off and are experiencing good adoption.
We also worked on two other projects aimed at solving enterprise adoption issues: Sonobuoy and Velero. Customers were most likely getting their Kubernetes installation as part of an offering from their cloud provider but they could also self-host and install Kubernetes on bare metal. Sonobuoy provided a clean and simple way to run the official Kubernetes conformance tests with a plugin model to allow the execution of custom tests. Velero started out as a tool to backup EBS volumes on AWS and evolved into a complete solution for backing up and migrating Kubernetes resources and persistent volumes. These capabilities were critical for an enterprise’s disaster recovery solution.
We took a different approach with the development, release, and ongoing evolution of Sonobuoy and Velero than we did with ksonnet. First, both projects bore the Heptio brand, as the capabilities each project delivered were core to the company mission. Second, we developed the projects internally at first before cleaning the repositories and making them public. We created channels in the Kubernetes slack, which eventually became our only discussion forum for the projects. Both Sonobuoy and Velero were developed in public from that point onwards.
What worked and what didn’t
Our approach with Sonobuoy and Velero was much more successful than how we handled ksonnet. We discovered that as a company engaging with open source contributors, we couldn’t just wish into existence an open source project with an active and engaged community. We also realized that although we wanted to have open projects and outside contributions, we also wanted to steer the roadmap. With new projects in active development, we needed to determine our open source strategy.
The effective approach we used for Sonobuoy and Velero was essentially the BDFL (benevolent dictator for life) model. The ‘dictator’ does not need to be a single person like Guido van Rossum in the Python world; many open source projects, such as the Go programming language, have a core team mostly composed of members from a corporate sponsor. Later, once a project has achieved a certain critical mass, it may be donated to a foundation. Heptio’s next project, Contour, followed Sonobuoy and Velero in using this model.
That’s not to say the BDFL model was appropriate for all our open source projects. In some cases, our developers simply wanted to host and share their code with others, for example when working on smaller projects. They wanted the tools they created to be available but didn’t need to build communities around them. To address this need, we created Heptio Labs, a separate GitHub organization where our engineers could publish their open source projects without all the overhead of our BDFL projects. We also developed a set of heuristics that made it easier for people to determine whether their project should be a Heptio BDFL project or something that should go under Labs.
Reflections
Open source is not a panacea. Making a repository public on GitHub does not guarantee that your project will be discovered, much less adopted. Significant work needs to be put in to demonstrate the value of your project and help people use it, and while many want to reap the benefits, few are willing to put in the work. A key factor for success is managing expectations; there’s nothing wrong with just throwing code out there for people to use, but you should set those expectations upfront (lately, GitHub has been offering more tools to help maintainers communicate those expectations). By having specific goals in mind when making your project open source, setting clear expectations around the level of ongoing investment that your company will make throughout the project, and cultivating the right kind of relationship with the larger community, you can make sure your commercial open source projects are successful for the long term.
