As seen on Forbes.com
The enterprise software industry is in the midst of a revolution, moving from a world where many of the biggest blockbuster products are created for developers and other technical workers rather than end-users. I recently wrote about the emergence of this new trillion-dollar market for developer-focused software, discussing why developers are now in the driver’s seat and what this means for enterprise software giants and startups alike. In a developer-focused world, companies that sell flexible, collaborative products and platforms to help power software development will create significant market value in the years to come. But just how are companies supposed to generate millions in revenue selling to developers? After all, developers rarely hold the corporate purse strings and they almost always favor freely available software. How can a company generate revenue when the target “buyers” aren’t accustomed to buying anything at all?
The answer starts with winning the hearts and minds of developers before trying to sell them anything. Developers want to tinker with products, influence what features are offered and how products evolve, and contribute to their development via open source collaboration. Building developer-focused software isn’t easy. It takes time. In the world of fast-moving startups, the patience required to win over developers en masse is often lacking. But, winning over developers, which can take months or even years, will be critical for the creation of a multibillion-dollar enterprise software company in the next decade.
Once developers adopt products, there are three business models that have emerged to successfully commercialize this developer love: freemium, API-based services, and commercial open source. I’ll give an overview of each, including specific examples of companies that have already succeeded with each of these models.
Freemium
In this model, a lightweight version of a product is made available for free usage (or in a try-before-you-buy mode) to help encourage adoption. The goal is to delight people so they become loyal users. If developers become reliant on a freemium product, then converting them to paying customers by offering valuable features behind a paywall is the next challenge. Like any business model, there are pros and cons to freemium. The biggest advantage is that if developers flock to the free version of your product, the opportunity arises to build a large, engaged customer base. The biggest disadvantage is that it is sometimes difficult to convince development teams to upgrade to a paid model, and competitors can copy freemium software but offer more features for free, undercutting a well thought-out revenue model.
One company that has seen amazing success with the freemium model is Slack. While its product is now widely used by knowledge workers of all types, Slack was originally built by developers for developers as a collaboration platform for software development projects. The commercial product launched in 2014, and since then, the basic app has always been free. Even today, most companies start using Slack for free and then later upgrade to a paid plan that offers certain features such as unlimited archival of messages and integrations with third-party apps.
The brilliance of the freemium model is that once a lot of developers start trying a product, if they like it, they tell their colleagues, accelerating the flywheel. Of course, getting the flywheel spinning in the first place is not easy; developers can’t be expected to just flock to free product; first they have to know about it. This involves boots-on-the-ground marketing tactics such as trying to get an article about a product trending on Hacker News, getting good reviews on Product Hunt, and hosting or attending events for developers. Additionally, just because a product is free, doesn’t mean target users don’t have high expectations. The bar to get developers to use and tell colleagues about a product is extremely high.
If a free product is both good enough and viral enough to build a large user base, then getting the monetization mechanics right is the next big challenge. The trick to the freemium model is to think from day one about monetization, not waiting until a product has millions of users to decide which features to commercialize. Instead, building a product roadmap from the beginning that clearly delineates which features will be free and which will be premium is paramount, especially if developers are the target users. Recall that developers rarely make purchase decisions, so devising a strategy up front to bridge the gap between rabid developer users and budget holders is a must. And, remember, just because developers convert to paying customers doesn’t mean they will stay customers forever. Continuing to work closely with them, incorporating all of their feedback into future versions of the product is key. Competitors are always lurking that will likely offer a similar product with more free features, and developers will leave if they find something better and cheaper. Look no further than what Microsoft Teams has tried to do to compete with Slack.
APIs
The API monetization model is prized by developers because APIs are nimble, flexible building blocks. APIs allow developers to add functionality, such as payment processing or messaging, to any product they’re building by simply inserting a few lines of code. Most API revenue models are service-based, with users paying either a subscription, a consumption level, or transaction-based fee to incorporate APIs into their products.
Why are APIs so popular with developers? Everyone knows that developers are stretched thin. They work long hours to release products on time and on spec. With so much pressure on them, developers are always looking for safe, reliable shortcuts, and APIs are just that. Two great examples of software companies that have succeeded with the API model are Twilio, which offers a messaging API, and Stripe, which offers a payments processing API.
API-driven software companies charge service fees for their products and the three most popular nuances to this revenue model are: subscription fees (users pay a monthly fee), consumption fees (users pay a fee each time the API is called), and transaction fees (users pay a percentage of each purchase completed via the API). All of these are very solid, continual revenue streams, so with the right API model, companies can feasibly create many millions in recurring value. However, the trick to the API model is to develop an API that developers want to use above all others. To do this requires all the same groundwork as any developer-focused business model: listening closely to what they need and taking the time to educate them on the virtues of an API and its roadmap in online forums, at conferences, and in other developer relations efforts.
While winning developer loyalty enables an API to get the “design win,” becoming integral to a solution, one of the potential risks with the API model is that some developers may eventually decide to jettison a third party API to build the same functionality directly into their own products. This doesn’t happen often, but it’s more likely to occur when API fees skyrocket, risking that the value of the service doesn’t match its cost. Obviously, constantly iterating and improving an API is critical to the long-term success of any API model.
Commercial Open Source
I’ve saved the most promising, and most complex, developer-driven software model for last, and I’ll write an entire post exploring the intricacies of this model next time. But the base assumption for most commercial open source is similar to freemium: first make a free version of the software available and then later charge for premium features or services. However, the biggest difference with open source is that the source code is made available for all to see and work with. Many developer users may also seek to contribute to an open source product or adjacent products, making the core product more useful and valuable. More and more software today is being built open source, so nailing the dynamics of usage and contribution among a community is very important.
The biggest advantage of the commercial open source model is that, because open source is very popular among software developers, products built in open source confront the lowest friction to developer adoption. However, the biggest disadvantage is that open source software development can take years. Adoption typically relies on word of mouth, not conventional marketing, so gaining a user base sizable enough from which to gather important feedback about how to keep iterating the product takes time. If open source products are governed by larger consortiums, roadmaps can also lose alacrity and become difficult to control.
As mentioned, rarely do open source projects gain rapid user adoption on their own. “Build it and they will come” is not a strategy. In addition to hosting the project on GitHub, good ways to get the word out about an open source project include writing technical blogs, presenting papers at technical conferences, hosting meetups, attending developer conferences and responding to feedback on social media channels.
Two companies that have done a great job of commercializing open source software are MongoDB and HashiCorp. The road was long for both of these companies and their founders spent many years working closely with developers to get their projects out of the “tinkering” phase and into real product development cycles. I invested in HashiCorp in 2014 and remember the founders flying 250,000 miles a year back then just to visit developers at conferences, and spending thousands of hours working with them to gain insights from users about HashiCorp’s early products.
The gulf between an open source user and a paying account is very wide—even wider than the classic freemium model. That’s because commercial open source companies walk a very fine line between being both a free, collaborative project open to everyone, and a commercial product available only to those who pay. It’s possible to build incredible value among the developer community, with millions of developers using and talking about an open source product. But as soon as an attempt is made to commercialize some aspect of the product, these same developers can feel cheated and tricked. The best way to succeed with a commercial open source model is total transparency. Plan far in advance for the features that will one day be commercialized and communicate that plan clearly with the developer community. Ask for their input about which features and/or services would be worth paying for. Bridging the gap between the developer users in an organization and the budget holders who will consider paying for commercial features is another treacherous task. We’ll focus on this in our next post, where we’ll go deeper into the commercial open source business model.
In conclusion, there is more than one revenue model that works to build a viable developer-focused software company. But there is only one way to really win in this space: be a true partner with developers and work closely with them to deliver products that help them do their jobs more efficiently, quickly, and collaboratively.
Note: My firm, GGV Capital, is invested in and I am a board member for HashiCorp. GGV is also a venture investor and shareholder in Slack.