Go to any open source community forum and its busiest subforum is usually the one where people are desperately looking for help getting started. That’s as true for Kubernetes today as it was for the Apache web server back when I began working in open source. And it’s an insight that has driven my career in software.
While programming came pretty naturally to me, I couldn’t help noticing how many people with great ideas for using open source software in new and creative ways were giving up almost as soon as they started, simply because they found it too hard to get anything working. That drove my early contributions as a member of the Apache Software Foundation and author of several books and “how to” guides on Linux and other topics. And in 2004 it inspired my co-founder Erica Brescia (now GitHub’s COO) and me to create Bitnami, a service that packages popular open source software in ways that make them super-easy to get up and running.
Bitnami started out as a side project that we simply wanted to exist and knew how to build. It was our way of contributing back while we worked on our day jobs. The idea was to package the latest version of several pieces of open source software, along with the proper documentation and a decent set of configuration options, in a way that would work right out of the box. We didn’t offer the customization you’d get by hiring an expert to put everything together for you. But that wasn’t the point. This was about making it super easy to get going – and keeping it free.
We first focused on software that was powering the growing trend for creating and maintaining blogs, like the publishing platform WordPress, and content management systems like Drupal and Joomla. Instead of needing to know a lot about file systems or how to set up PHP or databases, our users could download a Bitnami package and start running a fully functional blog with just a few clicks.
What we didn’t foresee was the demand that existed for this kind of service, and the impact it could have on software use. Just by making these packages easier to use, demand for them — and thus for Bitnami — grew exponentially.
Five years later, cloud computing started changing how people deployed software. They could now access servers on demand and run web applications from those servers. That was attractive for all kinds of reasons, but, again, setting up these servers was far from easy. So we started creating pre-built virtual machines, or cloud images, for the application services we had been offering. If you wanted, say, to run WordPress on AWS, you could now use Bitnami to launch it with a single click.
As the cloud grew, so did we. Before long, millions of developers were coming to our website, and Bitnami was generating a significant percentage of user adoption for clouds run by AWS, Google, Microsoft, and others. At that point we decided to focus on Bitnami and create a business around what we were doing. It was important to us, however, that our software always remained open source and free to the end user, which it does to this day.
Then around 2016-2017, Kubernetes and containers began attracting a lot of attention. This was another exciting new development that an enormous number of people were interested in, but that many found hard to get up and running. Once again, we looked for ways to take away some of that complexity and created Helm Charts and other Kubernetes Projects, which you can use to build and run reliable and performant applications on Kubernetes environments.
This and our cloud-related work proved interesting to VMware, which acquired Bitnami in 2019 and now offers a supported enterprise version of Bitnami in the form of the Tanzu Application Catalog, designed for companies looking to use open source software in production across multiple platforms. Nothing changed, however, for developers looking to use Bitnami. If anything, we’re releasing more products for more platforms faster than ever and all of them continue to be free.
Bitnami also remains incredibly popular. Tens of millions of developers are using it to run a wide variety of packages and services (we’re up to 180 different applications, servers, and language runtimes). That variety is important to us, because it meets developers where they are and lets them decide what might be useful. A single developer, after all, could be running Kubernetes at work, a virtual machine in their own time on which they’re testing an idea they might take to their employer or build out on their own, and a WordPress site they maintain pro bono for their kids’ soccer team.
We continue adding new applications and platforms whenever we see community interest in them grow. As more developers, including our own, are working on laptops powered by ARM processors, for example, that’s fueling interest in using Bitnami to support this platform.
While we don’t write the software we compile, we still get a lot of feedback and suggestions for improvements. If people want us to configure an installation template in a way that would allow them to do something we hadn’t thought of, we’ll try and make that possible if we can do it safely and in a way that other community members would find useful.
Like a lot of popular open source projects, a relatively small group of developers produce the vast majority of Bitnami’s code. But hundreds of people comment on and submit fixes to each of our packages and we welcome everything from tiny one off suggestions, to bug notifications, to people wanting to help fix them or help build the next package.
It may sound hokey, but over the last 15 years the philosophy driving Bitnami hasn’t changed: it’s still about giving back to the community by making open source software as easy as possible to use — and thereby enlarging the pool of developers able to build whatever they find interesting or useful as easily as possible. People are still getting excited about an idea, spending too many hours failing to get it working, and then just giving up. But if they can work with Bitnami, see some early success, grow more excited, and then spend the next few weeks productively tweaking, trying plugins, reading guides, and building out from where they started – that’s all the motivation we need to keep going.
