Building Sustainable Companies - A Guide for Open Source Startups

Recently, MinIO achieved a major milestone, passing the one billion docker downloads mark. Almost simultaneously, MinIO notched its 20,000th member of its public Slack community and its 35,000th GitHub Stargazers - putting the company in the top 250 repositories on the site (out of 28 million repositories).

There are some that will say that those are vanity metrics, but at that size, the metrics transcend arguments otherwise. More importantly, the metrics are coupled with commercial success, with hundreds of customers, a cash flow positive business, a unicorn valuation and more than $100M in the bank from our recent Series B.

There is a larger question at play, however, and that involves how open source companies are increasingly outperforming proprietary software companies and how that is likely to accelerate in the coming years. MinIO is one reference architecture. There are others, but this post shares our thinking on the subject and what lessons other open source companies can learn from.

While there is no “one” universal open source playbook, there is the traditional model of a project with purist open source licensing, and a company built adjacent to that product using features (security, user management, proprietary extensions), professional services and support as the revenue engine.  Examples abound but Databricks, Redis, Confluent, Elastic and MongoDB represent this model. You can likely think of countless more.

MinIO differs from the traditional open source business models in fairly material ways:

• While MinIO is 100% open source, MinIO is both the company and the project. MinIO determines the license (GNU AGPL v3). MinIO owns the copyright to the GNU AGPL’ed code. MinIO is the primary contributor to MinIO and is not dependent on any other party for maintainability.
  
• With MinIO, the “community” edition is the same as the commercial editions. There are no differences between the upstream and what a paying customer downloads. There are differences in how a customer maintains that environment, and, along with license compliance, that supportability (in the form of more MinIO software) is what motivates the commercial decision.
  
• MinIO doesn’t believe in the traditional support model. Every inquiry and issue is direct-to-engineer. There are no “support” teams at MinIO.
  
• MinIO does not employ any commissioned salespeople. There are no SDRs. There are business folks, but they are engineers by trade. To date, 100% of MinIO’s business came inbound. We will expand on this shortly, but it fundamentally changes the model.
  

This model has enabled MinIO to build an exceptionally efficient machine - one that doesn’t require expensive sales teams, expensive marketing teams or offices around the globe. It allowed us to go five years on our Series A round of just $23M.

It is predicated on a fundamentally superior product, a relentless content machine, a sophisticated listening infrastructure and transparent, simple economics.

There are limits to what we can talk about on the product front given that object storage is different from observability and service mesh, but the key takeaway is that the product must be simple, powerful and feature complete. If it is superior, everything we will discuss next comes into play. If it is not, your machine will be less efficient.

As an open source company there is no need for a free trial of the software. It is freely available. There is no friction between the download button and the user (person or machine). No form to fill, no email to provide. This is one of the reasons that open source companies can be so much more efficient (provided they don’t build a proprietary moat around their products).

With a frictionless model, there is no need to track trial terms, build customer success teams, invest in conversion software. In a frictionless model, your product and content do the work of those teams. Again, product superiority cannot be understated. You cannot achieve efficiency with a “good” offering, it has to be great.

Keeping with that philosophy, there is no friction between our content and our audience. All content is ungated. Without a sales team, SDRs and marketing folks, what would we do with the names anyway? Having said that, we think about content consumption patterns all of the time and have invested in some great software to drive incremental views of posts, papers and videos.

This requires us to be relentless in our content cadence. We believe developers are the engine of value creation in the enterprise and we write for them - documentation, blogs, web copy. We produce videos and how to’s. They are spare, light on marketing, long on technical depth. We publish multiple times a week and promote accordingly. We build content that educates while we sleep. We don’t have rules around content length. If the piece merits sixteen pages - make it sixteen pages. Developers want technical depth - we will not short that.

We are opinionated. We want people to learn the “MinIO Way” not the legacy way. We need them to understand, unequivocally, the value that comes from software-defined, cloud-native, performant object storage. We don’t just position MinIO against other object stores (AWS primarily) but against other storage approaches.

Open source companies need to build the community with the same resources they use to build the product. There are different perspectives here, and multiple ways to achieve success, but in our experience, the best communities are built through service. We serve our community. We make them accessible, we avoid monetization, we celebrate their success. If engineering is supporting those communities it builds user empathy and eliminates the challenges associated with “that's not my role, that is the community manager’s.” Also, when you approach it this way you don’t need a team of community managers/dev relationship folks (some of whom are awesome and would be welcome content creators at MinIO).

There are also choices to be made with regard to the .org and .com side of things. Both are important but have very different implications. Think along the lines of fundraising vs. soliciting donations. Benevolent dictator vs. consortium building (and managing). We obviously opted for the .com version. MinIO liked the idea that we would have full control over our roadmap and our R&D investments. This is not to suggest that the .org model doesn’t also have its benefits - there is an acceleration element that often comes with alignment there. Either way - there is a choice to be made.

Understanding Patience and Taking the Long View

This is how we built MinIO. It is going well on the community adoption side and the commercial side. We are really proud of that. This post reflects our learnings and we share them with you, not prescriptively, but as a template.

We picked the open source path because we believed as much in the philosophy as we did in the business model. That will not sound strange to the readers of this site, but it will to others. What is the business model in free software?

The answer lies in achieving adoption. A great product, a frictionless adoption model and a relentless content machine drives the type of adoption that proprietary software simply cannot achieve. Markets are increasingly favoring the winner-take-all dynamic. MinIO recognized that while the traditional object storage market was crowded, the modern object storage market was not, and that was where the future lay. Creating a competitive wall in the form of adoption was critical to our success.

In our early days, traditional storage players ignored us or viewed us with mild amusement. By the time they realized how big we had become it was too late. They didn’t realize that developers were in charge, that IT had become diminished. There is little chance they will recover. There are likely more exabytes stored on MinIO than the rest of the object storage industry combined (excluding the big three public clouds).  

Open source has a myriad of other advantages - the strength of the code, the security, the freedom to inspect and the freedom from lock-in - but these are things readers of this post know already.

It is true that open source requires a longer runway. It is said that there will not be another Warren Buffett because people don’t want to get rich slowly. That truth translates to choosing the open source path. Open source companies must build their following through adoption, often over years. It takes patient investors. It takes patient leadership. It takes patient employees.

There are no “shortcuts” to open source success. It is a longer path, it requires patience and discipline. The payoff, however, comes as the competitors start to leave the ring, one at a time until there are none left. The commercial leverage equation changes considerably at that point.

We are entering an economic period where austerity, not largess will be the governing principle for startups and large enterprises alike. The efficiency of the open source model will get significantly more attention given its ability to produce cashflow positive results and competitive moat characteristics.