How to succeed at commercializing open source

In 2015, our consulting company Percolate Studio was acquired by Meteor Development Group, maker of the popular open source Javascript framework Meteor. In 2017, we started Chroma, our new product company.

It’s tempting to dismiss open source software (OSS) as hobby projects built by engineers in their spare time. However, the world’s largest companies now rely on OSS to power their businesses. There are a growing number of successful open source commercial companies like MongoDB, Docker and of course Redhat whose business models build atop inherently free software. Let’s see how to commercialize and maintain momentum on open source projects.

The backstory

Matt Debergalis, Geoff Schmidt and Nick Martin founded Meteor Development Group (MDG) in 2011 with the mission to revolutionize app development by giving developers the tools to build the kind of advanced, realtime web apps only large, sophisticated companies could create at the time. This came packaged up as ‘Meteor’, an open source JavaScript web framework consisting of a build tool, reactive view layer, streaming database connector, package manager and more.

The technology was such a game changer it quickly grew popular with web developers and also some of the best VCs in the valley. Tools developers are now familiar with like React, Angular, and Redux either did not yet exist or were still in their nascency. At Percolate Studio, we adopted Meteor early to replace Rails as our framework of choice. Along the way we naturally became involved in the community, writing books and creating the Meteor package manager Atmosphere.

A Galaxy is Born

Fast forward to after our acquisition. Meteor’s plan was always to monetize the open source framework was by providing a scalable, simple to use hosting environment tailor-made for Meteor apps. Named ‘Galaxy’, this was the first product we helped build at Meteor after we were acquired.

Open source is a great marketing channel. If you build the right thing you’ll quickly gain the confidence of many targeted users. This creates a fertile market of potential buyers of your technology.

There are two common ways OSS is commercialized. The easiest (and most obvious) way to monetize is consulting or support. Since you created the tech, customers will assume you know it the best.

The ideal way to monetize open source is by building a commercial software extension to your free offering. Unlike consulting, selling software scales as opposed to selling time. The first challenge is coming up with something that isn’t contrived, and that your open source user base will find useful enough to want to buy. The open source and commercial offerings must complement and add value to each other.

Meteor’s approach with Galaxy assumes that app deployment and hosting is complicated or annoying enough that developers don’t want to do it themselves. Purists might argue that deployment is trivial these days and Galaxy doesn’t add much value on top of Heroku or AWS. For businesses however, this value proposition made a lot of sense. Hosting on a platform built by the makers of the framework that powers your application is good insurance that things up and down the stack are optimized and work well together. Peace of mind is well worth the modest markup on top of AWS.

Regardless of which monetization strategy you use, it’s important to realize the size of your addressable market will be bound by the size of your open source user base. In a sense, you’re creating a market in which you automatically become the leader and often the only player.

This sounds like a dream come true but unless your open source offering becomes incredibly popular the market may prove to be too small to sustain a business (especially one bounded by VCs expectation of a 10x exit).

Healthy Open Source

As the product manager of the Meteor framework, I needed to deeply understand the mechanics of the project. From why people open issues to how features are evaluated to what gets community pull requests merged. Although I’d built and maintained several open source libraries over the years, they paled in comparison to Meteor in scale both in terms of popularity and lines of code. Meteor is somewhat unique in that the project is fully funded by a commercial entity. However, the lessons apply equally to any open source project with an exclusive group of maintainers. One thing that had bugged me about Meteor for years was how hard it was to land a non-trivial or contentious PR (sometimes these would languish in a sort of PR purgatory forever). Now that I was on the inside, I set out to do my best to fix the problems I’d experienced as an outsider.

I began reading up on as much open source project management literature as I could get my hands on. Healthy Open Source by Mikeal Rogers really resonated. I recognized Meteor in Mikeal’s diagram of a project that’s in an early stage of disfunction. That is when the number of users heavily outweigh the number of contributors and maintainers. The symptoms of this were an ever growing issue list and open PRs. Core contributors, mostly MDG employees, were overwhelmed by the sheer volume of incoming Github issues and making forward progress on the framework became difficult. It was clear we needed help from the community.

This meant looking into what we could do to fix the poor ratio of users to contributors. We realized we needed better contribution guidelines to give folks clearly defined processes and ready made decisions. It was important to reduce the barrier to entry and provide an easy onramp for contributing to what is a complicated and daunting codebase. The easiest way to begin participating on the project is by helping to answer and triage incoming Github issues. Our first move was to document our issue triage process and recruit community members to help out. This successfully led to us re-gaining control of our growing issue & PR lists, now at 600 and 12, down from 1000+ and 100+ respectively.

Naturally, as people began to triage issues and fix documentation, they learnt the codebase and project goals. Soon they progressed to evaluating and merging PRs and beginning to participate in feature development. One such success story is exemplified by Jesse Rosenberger who began helping us triage issues in his spare time and is now employed by MDG to write Meteor code full time.

We learnt that it’s important to set up a clear project structure and to emphasize rewards for participation (in the form of recognition for work done and a clear progression of roles with increasing responsibility). It really helps if developers from outside the company sponsoring the project can reach the highest roles, effectively gaining equal footing with employees on the inside. This will encourage serious, high level contributions from skilled developers drawn to the appeal of becoming recognized as experts. In addition, the needs of the community will become better aligned with the goals of the company.

The holy grail for an open source project is to become a self sustainable entity that’s able to survive beyond when/if the original creators leave the project. In order for this to be possible there needs to exist a democratic governance structure that doesn’t rely on a benevolent dictatorship to maintain momentum and keep the project from falling apart. Although that’s a drastic scenario, having such a structure in place will just lead to a healthier project in general for all the reasons I talked about above. Defining systems for governance remains a work in progress at Meteor.

Part III

Meteor benefits from having raised several large rounds of funding from Silicon Valley superstar VC firms Andreessen Horowitz and Matrix Partners. In part III of this series, I’ll talk about the implications of raising VC money and explore whether bigger is always better.

To get part III and hear about more interesting, useful and funny stuff that happens to us here in Silicon Valley — subscribe to our mailing list! Members get first access to our latest products and experiments.