What Success Looks Like for Modern Open-Source Software Startups

• 

  Joseph RuscioGeneral Partner
  Heavybit

How Open-Source Startups Succeed

Estimates suggest that modern developers have built about 70%-90% of all modern software on top of open-source software projects. Not a surprising figure considering how many crucial aspects of modern software infrastructure depend on open-source software (OSS) for operating system (Linux), server (Apache), database (MySQL), web browser (Firefox), and even mobile (Android) functionality (among many others).

So for those looking to start a new technical project or startup, is open source just a straightforward, “better” path to success? Not necessarily. There are key differences between open-source vs. proprietary projects, and while there are specific benefits of open-source software for startups, there are increasingly important nuances that startup founders and investors need to consider.

Yes, startups must absolutely continue to uphold the basic tenets of OSS projects, including the foundational requirement of building a robust community and intelligently selecting the license that best suits their needs. Yes, they must also select a sensible business model with a go-to-market strategy that enables them to create a repeatable revenue engine while maintaining a vibrant core product. However, OSS startups differ from traditional proprietary software startups in the way they scale and “cross the chasm” into enterprise sales. And all OSS startups need to be aware of emerging issues around licensing defensibility, infrastructure dependencies, and liability.

We tapped Adam FitzGerald, HashiCorp's VP of developer relations, on how to build and scale a successful OSS startup and shared their insights below. Learn the latest insights directly from the leading voices in open-source software and tech VC by joining the DevGuild: Open Source event.

The Biggest Change in OSS?

Joseph Ruscio: What has been the biggest change in open-source software development over the years that startups need to be aware of today?

Adam FitzGerald: I think one of the biggest news items in the world of open source is all of the discussion around what it means to use an Elastic-like SSPL license. The background driver for nearly all of it is essentially, “If I build something in open source, how do I prevent a large cloud provider from just taking my open source code and making it run for them, and then selling it as a profitable service?”

Specifically, the actions from players such as Elastic and MongoDB in particular, are what have caused the shakeup. And then, you have the reaction to how those licenses aren't actually approved by the OSI–they’re “not actually open source.” How do end users who use and care about those products actually think about them?

There has been this big, seismic shift I've seen in open source for commercial business models in the last 15 years. Speaking not just from my role in developer relations (DevRel) at HashiCorp, but also from my personal opinion: I think people need to take a long, hard look at why they’re using an open-source license.

And if you're trying to use it to build a business, then you need to understand what you're trying to do with that open-source license and what sort of trade-offs you have once you pick one. In my opinion, picking an open-source license for a tool is a one-way door. When you go through it and you make that license choice, you're basically making the commitment to a huge number of people that are relying on you for that license.

In my opinion, picking an open-source license for a tool is a one-way door.

Any license change downstream is a huge trust-breaker for developers and technical end users. And nearly everything you do in DevRel/developer marketing comes down to trying to build trust with an audience that is very slow to give it. So you've got to have a very clear understanding about what your business model is going to be.

That’s not to say there aren’t options when it comes to creating a business model, with a permissive license, that is still open source. But you have to be really clear about what you're trying to do. And I think that in some cases, there’s probably too little thought applied at the early stages of an open-source project when people are just sort of starting to build developer tools...especially coming from a hobbyist background before looking to pivot to some kind of business model.

Managing OSS Infrastructure

JR: With so much modern software infrastructure built on OSS, what do startups need to know about managing liabilities and dependencies?

AF: It's all part of the software supply chain, in a general sense. If you’re working on an OSS project, you need to understand what your dependency model is. Where are your vulnerabilities?

I always think of that one great xkcd cartoon–the big pile of bricks supported by a tinier one, representing a bunch of libraries that one guy maintains on weekends. And this only becomes more true with increasingly complex systems, and as we build more OSS into our infrastructure.

Still, a very small number of maintainers can maintain a very important, critical piece of software for people. And so, we have to understand that this, in some cases, is the reality that we live in. We have to work out ways to encourage people to continue to contribute in that environment. And I'm not certain that the “open-core business model plus VC investing mechanism” is the right or only way to go about doing that.

That's why I say when you're building a library or a tool or a product, you have to understand what your plan is for that product. Maybe you’re just working on a passion project, and you figure that as long as you can make a living from it, you’re fine with it. Very different from trying to go out and conquer the world, get startup funding, and create a large-scale business. We’re talking about very different choices, and you’ll need to look ahead further than just the next 18 months–which is harder to do than it was 10 years ago.

There are also decisions that affect multiple factors. For example, there's a huge amount of value in the infrastructure underpinning a lot of these different systems. As we look at connectivity across a large number of things, open source might be the only real way.

You’ll need to look ahead further than just the next 18 months–which is harder to do than it was 10 years ago.

Look at old enterprise service buses or integration systems, and how it was all about the multitude of connectors between different systems. MuleSoft basically nailed that in the enterprise space by having a really good system that let lots of different people contribute to the same model. If you look at Terraform from HashiCorp, it's the same sort of idea. There are something like 3,000 providers and modules in the Terraform ecosystem that let you connect almost any system you want into your common language for orchestration and provisioning.

So in a sense, you need an open-source model for working in those spaces if you're going to go do anything that's an aggregate or ecosystem-like play. So, open source is going to continue to be super-important for everybody. I think the layering of technology is going to continue to grow. Open source is where you will see tons of innovation, but there'll be plenty of innovation inside private enterprises and non-open-source projects as well. So, I don't think any of that stuff is going to stop or slow down.

Also, a quick aside about maintaining existing projects: In the open-source world, the existential worry is always long-term sustainability, and that is especially true if you plan to host your project as part of an open source foundation (CNCF, ASF, LF, etc). Such organizations have models of engagement to push projects into particular contributor models. For example, if more than half of your maintainers work for a specific company, and that company goes away, it’s likely your project won’t survive.

There’s some value to that dichotomy–having to balance sustainability vs. being able to create and maintain something that provides substantial value. Most coders will be making their contributions as part of their job, not out of charity. So it’s important to figure out how to manage the intersection of supporting a business model versus the capabilities demanded by a foundation to maintain a community. I think the foundation model has its own interesting challenges, in part because open source as a whole tends to lack uniformity across the board.

Community Building for Open-Source Startups

JR: OSS projects live and die by their communities. In your opinion, what’s the key to success for building and maintaining a vibrant community for a commercial OSS project?

AF: I think there are two keys here.

First, you've got to make the use case of your project abundantly clear, from the beginning: “We are doing Project X to solve Problem Y.” And Problem Y has to be a real problem that people in your community actually have.

Now, what you're doing could be similar to what everybody else is doing, but maybe you're doing it ten times faster, or in a really valuable way that no one has ever done before. Or, there’s a problem people are trying to solve in many ways and you’re trying to provide a standardized solution. In any case, you’ve got to be very clear about what your project is actually solving for.

So, an important component is messaging about what your product is. Which is something that really excellent technical developers can sometimes miss. Think about it this way: For technical end users and practitioners, the first thing they do when trying to solve a problem is do an Internet search and compare what they find to things they already know about. So, if you can't articulate what your project is solving for, it will never show up in any of those searches, and will never be successful because it doesn’t have the visibility you need in order to get the adoption.

Second, you need to build some kind of mechanism that encourages engagement, to bring in either people that want to improve your project (and might even contribute code), or they might be willing to talk to you about the direction your project is going. But you also want people who are willing to be the champions of your project–who will talk about how using your project successfully provided value for them.

The fact is, an external user has more credibility to an audience of practitioners or developers than you do. If you're out there writing webpages or on the conference circuit talking about how great your technology is, everybody will immediately assume you’re selling something. But testimonials from outside your company, from people who say, “I use Project X to solve my problem, and you should too, because it’s great”–that’s incredibly important.

You'll notice most open source projects that have become successful did so because somebody else, somewhere, was talking about how great it was. (This is, of course, true for just about any product, not just OSS).

So yes–start by being really succinct and clear about what you’re solving, then build a collection of fans, champions, heroes, and ambassadors (or whatever you want to call them) who will advocate for the value of what you've created.

If you can't articulate what your project is solving for, it will never be successful because it doesn’t have the visibility you need in order to get the adoption.

Now, regarding community building: You have to realize a community has strata. There’s a number of people who are potential users who come in through your landing page or peruse your documentation, but haven’t tried the project. Then there’s a collection of people who actually kick the tires, but maybe your project didn’t fit their use case.

And then, there’s a different subset of people that tried your project and were successful. Of those people, there might be a subsection who are experts, and if you’re lucky, maybe they answer questions in your community about how to be successful. And from there, maybe there’s an even smaller subset of people who will actually tell you how to make your product better–people who want to be deeply engaged, contribute to it, or tell you, “I’d use your product so much more if it also did XYZ.”

You have to understand all those different layers in your community and how to manage them. Keep in mind also that more is not always better. Sometimes a very, very small contributor pool, as long as it's tightly focused around the area you want to improve, can make a bigger difference than having 100 contributors add one pull request apiece.

So having a small handful of heroes or ambassadors, if they're the right people, is much better than having a thousand people talking about it. Having a handful of experts regularly answer questions on your forum or Discord is better than hoping that one of 1,000 people is going to chime in. And so the real question comes down to: What are you really trying to achieve with your project? And then, understanding all the different layers of possible interaction in the community, how can you reinforce those good habits, or find good people in all those different areas who are worth engaging? Some of the most successful open-source projects I've seen had remarkably small code-contribution groups in comparison to the much larger group of people just using the project. I've seen contributor pools of fewer than five people for projects that millions of practitioners use.

Scaling an OSS Startup to the Enterprise

JR: What’s the key difference-maker that ensures an OSS startup can scale to the enterprise?

AF: Well, figuring out who is going to actually pay will probably help! Too often, I see people thinking that they're going to make a lot of money by having “lots and lots of small accounts.” That there's going to be a million developers paying five dollars every month. Well, maybe. But quite often, it's a really hard audience to satisfy, and it's really hard to maintain support channels for that volume of people.

That's why the enterprise model is so much more popular. Instead of a million people, there are 1,000 companies on the Fortune 1,000 List that could be using your technology, and they'll be paying a lot more than five bucks a month!

So you need to ask: Who is the actual buying audience for your product as opposed to the user audience? Understanding that, most commonly in the developer tool space, the price for developer tools winds up going to zero in the end, anyway...even if you're an IDE.

So from a business model perspective, you've got to understand: If I'm going to make things as popular and as easy to use as possible for practitioners, and I'm going to make it open source with high trust, how am I going to fund all the other pieces that need to happen? At that point, you need to make sure you have the things that matter for enterprise buyers: Governance, compliance, audit controls, observability, cross-platform connectivity, and so on.

This is where defensibility becomes important. If you know who your buyer is and what features they are willing to pay for, you make sure those are the features that are hard for cloud service providers to replicate.

You've got to understand the difference between a user and a buyer. Working that out ahead of time gives you a really big head start on people that may be approaching things a bit more naively. Realistically, there's a lot of continual self-reflection you need to do over time to figure out where that line sits for your business model and your project.

Getting back to our first topic, this is also the point where you need to think about these large cloud providers that might just take your open-source project and run it as a service. This is where defensibility becomes important. If you know who your buyer is and what features they are willing to pay for, you make sure those are the features that are hard for cloud service providers to replicate. So, you may want to make sure your product or tool works across cloud providers seamlessly. Or that your product has compliance in a particular region where other cloud providers find it difficult to operate. Things like making sure your tool has the type of observability and integrated metrics that are really hard for a cloud provider to issue from their own system. There's a collection of different things to immediately consider to build a defensive business model against being raided by some of these huge cloud providers and vendors.

Conclusion

Open-source software is becoming increasingly central to every development team’s daily operations and fundamental software infrastructure. Learn how to position your teams for success by joining the DevGuild: Open Source event.