Investing in open source cybersecurity products: a field guide for VCs and a useful source for founders
A deep dive into investing in open source companies, characteristics of open source startups that can succeed in cybersecurity, metrics that can be used to evaluate OSS, and more
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
To paraphrase the tagline of the OSS Capital, if the software is eating the world, then open source is eating software. Over the past decade, we have witnessed an impressive rise in the number of open source projects, accelerated by the growth of platforms like GitHub, as well as the number of software developers actively looking for ways to contribute. Moreover, open source is no longer a stand-alone part of the ecosystem as it has evolved from a way for people to share their work with the community, to a unique business model lucrative to tech investors. More and more VC firms - Decibel, Unusual Ventures, eCAPITAL, and many others are placing bets on open source tools, while others such as Open Core Ventures run by Sid Sijbrandij and OSS Capital run by Joseph Jacks choose to specialize entirely in open source.
Cybersecurity has not stayed on the sidelines of the open source evolution. On the contrary, a lot of what we know today as security has emerged in communities of hackers sharing their knowledge for free, without any agenda or expectations of a payoff. I have previously written a comprehensive deep dive into the complex world of open source in cybersecurity, looking at open source as a way to build security products, not just an attack vector. In this deep dive, I will instead focus on the business side of open source cybersecurity projects, looking at ways they are structured and monetized, factors that attract VCs to open source, metrics they should be paying attention to, and segments of security where open source is more likely to succeed and result in the formation of venture-scale businesses.
Basics of the open source as a business model
Common origins of open source projects
There are several ways in which open source projects typically originate.
A spinout from a large company
It is common to see open source projects originate at big companies and then branch out into their own venture. Say, a team has built an open source product to solve a problem, and then realized that other companies need this solution too. An example of a startup that falls under that category is Confluent which originated around the open source project Apache Kafka at LinkedIn. In cases like this, people who have solved the problem take the solution and build a company.
Solving the same problem for the open market
Another common approach is when people who have already solved a given problem internally at their company, realize that more businesses experience the same problem, and choose to start their own venture and build it as open source. This approach is similar to the spinout but the founders are not taking anything from the parent company and building the solution from scratch.
Starting an open source project from scratch
This describes the most common path when founders identify a problem on the market, develop a conviction they can solve it, and get started on building the solution. The vast majority of open source projects in cybersecurity fall under this category where experienced industry practitioners feel the urge to tackle a pain point they have been experiencing for a long time.
Building a commercial version of somebody else’s open source projects
Some products get started when people see an opportunity in commercializing an open source project built by someone else. Typically, those looking to build a paid version would get the “blessing” of the creators of the original project.
Those who have built an open source project while working at an enterprise have a great community around them and a deep understanding of their customers, which makes them good candidates for VC funding, assuming the parent company can provide them with the invention assignment and give its blessing for them to go out and strike on their own. The same is true for people who have built a proprietary solution to an internal problem and then decided to bring an open source version to other organizations. On the other hand, building a commercial version of somebody else’s open source project rarely works. This is because there a) is no community buy-in, and b) the underlying open source project can change in ways founders of the commercial tool don’t have control over, thus messing up their product.
Monetizing open source
There are several ways to monetize open source. Before we look at them, it is worth noting that while some people assume that open source is synonymous to free (provided at no cost), the other way to understand freedom is to see it as the freedom to explore the source code and use it the way one wants. Here are common ways open source founders can generate revenue from their work.
Offering services to help companies implement software
It is common for open source founders to make money by providing services and helping companies run and implement the software. As open source tools are getting more and more complex, security teams new to open source software (OSS) require a lot of time and effort to fine-tune it for their internal use cases. This is where open source founders come in who can charge either hourly or project-based rates to help organizations get the most out of the tooling. After the initial spike, income from this stream typically decreases, which makes sense as most enthusiastic and ready-to-pay customers get up and running and no longer require the same levels of support.
Offering services can help companies get to revenue quicker but if they don’t build a product on top, they will end up creating a services company. This isn't always compelling to VCs due to different (much lower) profit margins and growth rates. I have previously written a separate deep dive about investing in security services.
Charging for support
Another way to generate revenue from open source is to charge for a premium level of support. Unlike commercial products, open source projects do not typically have a customer success function, so answering questions and assisting members of the community in resolving their challenges is done by the community itself. While this approach has proven to work, the quality of responses varies, and some asks may remain unanswered for weeks.
Charging for premium support is a win-win as it enables founders of the OSS to generate some revenue while allowing paying customers to get help when they need it. Similar to offering services, this isn’t typically a way to build a company fit for venture investment. Additionally, this channel is not scalable long-term as the more customers the project has, the more people it will need to hire to answer support tickets.
Open core approach
The open core model is seen whenever there is a commercial (proprietary) offering built on top of the freely available, open source core. This strategy requires founders to understand the dynamics of the space, how users want to interact with the product, and what they would accept as a commercial use case. Defining a line between free and proprietary features in such a way that does not diminish the value of the open source core while encouraging conversion to paid is not easy. When done well, it can unlock growth potential and make the project a good fit for the VC model. A great example of the open core model related to security is Elastic, which offers both free and premium (enterprise) versions of the product.
An interesting approach to monetizing open core products is a model called "buyer-based open core" used by Open Core Ventures. Under this model, decisions on what should stay free and what should be a paid feature are based on who cares most about the particular functionality. As the founder of the OCC explains, “If it’s an individual contributor that cares most about the feature, typically, you make it open source. If it’s an executive, you make it proprietary — you charge for it.” Interestingly, the first company founded by Open Core Ventures is Fleet - the lightweight, programmable telemetry platform for servers and workstations.
Not treating monetization carefully can sometimes backfire. An example would be InfluxDB which started as open source and then decided to charge for some features. That made people unhappy and many stopped using the project. This is why understanding how users of open source (in this particular case - developers) think about commercialization is incredibly important, and that comes with experience. One can succeed in building an open source project, and see everything fall apart when he or she tries to monetize it.
Charging for the cloud-based version of the product
Many buyers, particularly those in cybersecurity, do not like having to maintain more infrastructure on their own. The complexity of an organization’s environment and the need to rely on multiple tools makes it hard to justify hosting any software unless there is a business reason to do so. Charging for a cloud-based SaaS version of the product is a popular way to monetize open source tools, and the one that if done well, can enable the company to meet the investor’s expectations for growth (if VC funding is something they want to pursue). Wazuh, a security platform, hosts the open source software in the cloud and charges a fee for hosting and supporting it.
The SaaS model is easier to implement as it doesn’t require complex decision-making about what goes in the open source version and what is a paid feature. Company charges for the value add of maintaining the infrastructure for the customer - something that is generally seen as valuable and is not expected to be free.
Donations, sponsorships, and content creation
Collecting donations via Github sponsors, OpenCollective, Patreon, or another platform, and offering sponsorships can generate a stream of revenue sufficient to support the founders. The same is true for community leadership and content creation - writing books, creating courses, and speaking at conferences. It does not, however, make the project attractive for investors unless there is another plan for monetization in place.
Not all open source projects can be monetized
Some founders fail to build a successful (from the VC standpoint) business on top of their open source project because there is little to offer on top of the great but free project. A case in point is GatsbyJS, an open-source static site generator. The company raised $47M and is one of the most popular projects out there. The problem is that once a developer generates a website using Gatsby, there is not much else to charge for so long as the website is working well. Even though the company has a large base of free users, it appears to be struggling to grow as there aren’t many ways to capture value after website creation.
Another example of projects that cannot be successfully monetized is package managers such as npm. While they are incredibly popular, there is no obvious way to charge for their usage. Microsoft ended up buying npm in 2020 for an undisclosed amount, but rumors are the acquisition wasn’t massive.
I will discuss monetizing cybersecurity projects in depth later in the article.
Factors that attract investors to open source
Lower technical risk compared to early-stage closed source products
For an early-stage investor, the technical risks of investing in open source are much lower because founders already spent time building the product, and someone has paid their expenses while they were doing it. Many popular open source projects started when their founders worked at large organizations such as Google, Netflix, Amazon, and Facebook. Cybersecurity isn’t an exception: Maxime Lamothe-Brassard started LimaCharlie as an open source project while working at Google, while Panther was founded while Jack Naglieri, its CEO, worked at Airbnb (note that both startups are no longer open source). Most employers are okay seeing developers work on open source on the side, which enables technical founders to bootstrap their ideas, and only start thinking about raising capital from investors if and when they are ready to grow and commercialize their creations.
The same is true when open source projects originate from research. A case in point is Apache Spark which started as a research project at UC Berkeley in 2009 and was open sourced in early 2010. When founders figured out it is really good for the ML workloads, they built a company on top of it - DataBricks - which as of 2021 was valued at $38 billion.
When VCs are investing in a seed round of an open source project, the project would typically already have thousands of free users. An investor can either fund some proprietary system that nobody is using, and that still needs to be built, or they can invest in the open source project used by thousands of people, some of whom, it is reasonable to assume, may eventually be willing to pay. At the time when a VC is deciding to invest in an early-stage open source project, there is already some customer validation: they know there is a problem, they know the founders have a solution that is being used, they know that the cost of customer support will be lower because of the power of the community, and so on. All this changes the equation of risk and makes open source an attractive area for VCs.
Engineering-first product-led growth
Open source projects allow for bottom-up adoption, therefore enabling companies to do a proof of concept (POC) and proof of value (POV) before engaging in the enterprise sales process. This is especially important in security where more and more tools get adopted by being first tried and tested in the home labs of security practitioners. While CISOs are focusing more on strategic, company-wide tasks such as building relationships with other departments, working with boards, and attracting the best talent, members of security teams are looking for new approaches, trying new tooling, and seeing what can address their company’s problems. Granted, not all security professionals are equally equipped and interested in doing this work, but the number of technically proficient practitioners capable of using open source has been growing.
While developers and engineers are a great fit for the adoption of OSS, they do not control purchasing budgets, therefore founders of open source projects should keep their monetization plans in mind.
Low customer acquisition costs
Compared to traditional proprietary tools, the customer acquisition cost of open source projects is typically as close to zero as it can reasonably be. Since open source is available to everybody, it can effectively grow via word of mouth, referrals, and the so-called “engineering as marketing” when every time someone shares a link to the solution, it drives other people to give it a try.
Open source projects are able to scale usage quickly without the need to invest in marketing and customer support. While people can play the role of marketing, the inherent transparency of the open source supercharged with a passionate user base also reduces the need for investment in customer support: instead of hiring someone who can help understand how to use the product, founders can simply design a way for users to collaborate and help one another.
Open source is an incredibly important strategy for product distribution. As Jocelyn Goldfein of Zetta Venture Partners noted at The Linux Foundation’s Open Source Leadership Summit (OSLS) in 2018, “…startups are in a race with big companies. Startups have innovation. Big companies have distribution. You’re in a race to get distribution before the big company can get innovation.”
Ability to find product-market fit (PMF) quicker
With continuous feedback from the community and the benefits of building in public, open source founders can observe how their product is being used, ask questions, and identify problems and use cases they could not have thought of on their own. Having continuous feedback from the community can enable open source projects to rapidly validate the product-market fit for the initial free version, which can be a precursor to the PMF expansion and the introduction of revenue-generating offerings.
Large total addressable market
This is especially the case for open source projects targeting tens of millions of software developers who, not accidentally, are the main consumers of open source tooling today. The total addressable market for open source cybersecurity tooling is smaller, especially for those targeting security professionals - engineers, analysts, architects, and the like. The security industry is maturing and becoming more technical, but the size of TAM for projects that solve security challenges for developers is going to be much larger for the years to come, compared to those that are to be used by security practitioners.
Connectivity and the flywheel effect
Connectivity and the flywheel effect are big advantages of open source.
A traditional company, to support interoperability, needs to hire engineers so that they can build more connectors and integrations with other tools. In the case of open source, users of the project can contribute different integrations and extensions themselves, making it possible to grow the product functionality and the number of connectors much quicker. This is especially important for cybersecurity where every organization’s needs for connectivity are different, and most customers have 30-50+ products in their environment that must talk to one another. A great example of an open source cybersecurity project that leverages this as a superpower is Shuffle (I have described how they do it in my previous deep dive).
The flywheel effect is one of the outcomes of the connectivity: as more developers contribute connectors and extensions, more people can start using the product out of the box, which then encourages them to contribute to addressing their unique use cases, and so on.
Most open source security projects are not a fit for the VC model
Most open source founders are not looking to monetize their projects (and that’s great)
Most open source projects will never raise venture capital. First and foremost, the vast majority are not designed to be monetized to begin with, as their founders are pursuing new ideas on the side and giving back to the community. Out of those that are already, or will gradually evolve into businesses, most won’t be a fit for the VC model (capable of generating outsized returns). More often than not, founders trying to make money from their open source projects are not looking to build large companies, but rather to support themselves and to gain the ability to focus on what they care about without having to also work full-time.
I think that the fact that most open source founders are not looking to monetize their projects is fantastic, especially for cybersecurity where it is so important that we keep sharing the best practices, learnings, and tools that work for the betterment of the community.
Most open source cybersecurity projects cannot be monetized (as of today)
The job of a software developer is to glue together existing tools, frameworks, approaches, and techniques in such a way that solves a business problem. Software developers are builders who spend their days in code. The job of security professionals, on the other hand, is to ensure visibility into their organization’s security posture, as well as prevent and recover from cyber breaches. The vast majority of security professionals operate in the presentation layer, not the code layer.
Traditionally companies looking to buy security tooling are seeking solutions to their specific problems. The vast majority of cybersecurity solutions today are black-box magic tools that do something to “keep organizations safe” (I call them promise-based security providers). By its nature, “magic” conflicts with transparency, hence it is not typically possible to have an open source product in this space.
The second category of security solutions - tools for security practitioners to do their job, are the ones we typically think about when we think of open source in cybersecurity. Automation and orchestration tooling, data lakes, detection and response rulesets, vulnerability scanners, and many other components of security infrastructure that require configuration, and someone to configure them, are good examples. The reason these kinds of tools are hard to monetize at a venture scale is that they are first and foremost tools - standalone components that typically provide so much value for free, that it is hard to build a commercial offering on top.
When I say “monetize at venture scale”, I mean that it is hard to build a company generating $100-300 million of revenue on top of the open source security project. This does not mean that founders cannot find a way to make a few hundred thousand dollars to support themselves, or even $10-50 million ARR, and build a larger dedicated team.
It’s hard to build security tools that do not solve a problem but still open room for founders to charge for the solution. Think this way: when we build an open source database, we can monetize the way it can be distributed, as well as backups, access controls, and the like. If we were to open source a network scanner, it will either work, in which case users will get the value for free, or it won’t and nobody will want to pay for the commercial version of something that isn’t functioning. In other words, if one is open sourcing a security tool that works - they have to open source the whole thing, which doesn’t leave a lot of room to build on top.
Another factor that impacts the ability of open source security companies to monetize, is that when buying security tooling, companies will always go through a thorough buying process, looking for assurances and guarantees around supply chain security, compliance, and the like. A cherry on top is that CISOs don’t want to self-host anything, knowing that their environments are already complex.
There are many great open source projects which make a huge difference for the community, but will never become billion-dollar companies, and frankly, I think the industry immensely benefits from this fact. These projects equip practitioners with the tools to do their jobs, without spoiling them with aggressive marketing and sales. Many companies use open source as a growth channel and do not look for ways to make money from them, which is also great for the community.
As the industry matures and embraces the engineering approach, I anticipate that more and more security professionals will be working in the code layer, but that evolution will naturally take time.
The three types of open source security projects that can be a good fit for VCs
There are three types of open source security projects that, despite all the challenges discussed above, can be a good fit for VCs:
Security platforms
Security tooling for developers
Rare categories of point solutions that leverage openness & connectivity as their competitive advantages
First are the security platforms - products that offer a broad range of capabilities in one place. Unlike point solutions the commercial potential of which in OSS is very limited, platforms give more freedom to founders to choose how to monetize them. A good example of an open source security platform is San Jose California-based Wazuh which has been growing at about a 40% pace year-over-year in revenue, notably without any VC support. While platforms are a good fit for VC funding, they are also incredibly hard to build, in a large part because they rely on the data gravity effect. Data lakes such as Matano, and security data platforms such as Tenzir, also fall under this bucket.
The second category of VC-ready open source security projects are those where the buyer may still be the security team, but the end user is a developer. A good example is software supply chain security. The security team cares the most that the supply chain is secure, but developers under the CTO are the ones who need to integrate tooling with their CI/CD pipeline and remediate the vulnerabilities as they are discovered. If open source projects win the hearts & minds of developers who will have to use them, it can translate into security teams going ahead with purchasing. When we hear about “open source security products” receiving funding, in most cases, this is the type of project discussed. Unlike security professionals, software developers operate in code, have a much higher level of trust in open source, and are used to using open source tools. The engineering leadership is naturally more inclined to pay for open source products than security leadership, and because developers are much more active on platforms like StackOverflow and GitHub, companies looking to execute bottom-up go-to-market strategies such as PLG, are better off targeting developers.
Open source offers security teams several advantages:
Visibility into the code
Less of a sense of vendor lock-in
Understanding that all software is vulnerable, but with open source, vulnerabilities will be discovered and fixed much quicker
The main risk which prevents companies from adopting open source is the fact that malicious actors can inject bad code - an issue that is less likely with proprietary software.
The last segment of open source products that can sometimes be a good fit for VCs is rare categories of point solutions that leverage the characteristics of open source as their competitive advantages.
Products where connectivity and interoperability are the main (or a part of the main) value proposition. The abovementioned security orchestration, automation and response fits into this bucket with Shuffle being a prime example of how it’s done: instead of hiring a large development team, the founder is encouraging the community to contribute connectors, and even created a monetization strategy for contributors.
Products that use full transparency or control as the core differentiator. The two examples are Passbolt and Bitwarden - open source password managers which give people the ability to inspect the codebase, thus increasing the level of confidence and trust about using the tools.
Evaluating open source companies
Understanding the founder’s motivation to go open source
The most important question to ask founders when evaluating an open source project is “Why have you decided to build your product as open source?”.
Founders need to have a compelling story to justify their decision. This may be because they see that incumbents lack a lot of integrations and interoperability which inhibits their ability to capture the market, coupled with a strong conviction that being open source is a way to win in this market. Or, it can be that competitive products lack transparency, and customers don’t trust their solutions so by giving them the ability to inspect the code, the founders can get ahead and earn trust. Whatever it is, it has to be rooted in deep research or a hypothesis that can be tested and challenged.
Many founders start open source projects thinking that it would be cool if “people can use it for free and build it together” - that is not a good enough reason for a VC-funded project. The depth of the founder's thinking is important.
Keeping in mind the wrong reasons to go open source
Many people choose to go open source for the wrong reasons, one of which is thinking that being open source can help them get to the market quicker “because the community will get excited and help build it from day one”. The opposite is typically true as open source projects have an additional constraint: the quality of code. When one is building a proprietary product, only the internal team has access to the source code so they make a lot of trade-offs in terms of readability, ease of understanding, and quality of the code. In open source, on the other hand, everyone will be able to see the source code, so the level of code cleanliness has to be much higher; someone new to the codebase should be able to contribute to it.
Open source founders need to make sure the product is easy to understand and easy to use even for those who have never seen it before. This is not an easy task, especially at the early stage, as a lot of times new products are rough around the edges, require a manual setup, and so on. When a closed source product is hard to understand and hard to get started with, it is typically fine as the team would internally apply the necessary configurations, offer a demo, provide training before the customer can get started, and even do some magic behind the scenes. With open source, users need to be able to succeed on their own, and that can be a challenge.
Gauging the strength of the community
One of the most important things to look at when evaluating open source companies is the strength of the community. Are the maintainers doing most of the work, or are they coordinating the broader community that is helping the project grow? How many developers contribute to the project, and more important - what is the nature of their contribution - is it a one-time bug fix, or regular additions of new features, integrations, etc?
If the founders do everything themselves and there are few contributions from others, being open source doesn’t help to do anything. However, if the community is actively helping one another, if people ask questions and contribute to the repository, it’s a sign of a healthy project with a much stronger competitive advantage and the ability to stand against existing and future competitors.
Picking the right metrics and focusing on qualitative research
While it is not possible to implement product analytics and see how self-hosted open source projects are being used, open source arguably offers more transparency to investors than closed source, proprietary tooling. First of all, the project's GitHub star count, engagement, contribution history, and alike are all public. While signals such as stars are vanity metrics, they can still be useful: the presence of many stars doesn’t mean that the project is awesome, but if there are none - it is a strong indicator that there is little traction. If a startup has raised a seed round and there is no slope in engagement and no growth - it is much easier to gauge it from the outside than it would be with closed-source tools.
For understanding the state of the open source project, qualitative research is much more important. Seeing that people are engaging and contributing is not enough to gauge if the project solves an important pain point, and to whom. Founders and investors must understand who is using the project and how - are they running it in production in their companies, or at home? Are they relying on it to tackle important issues, or just playing around? Investors should be looking to understand how the founders think about user research, how often (if at all) they reach out to their community members, and how they stay in check about priorities and the realities of their venture.
Founders should talk to their users, reach out and ask questions, reflect, and get deeply involved in the community.
Verifying if there are any design partners founders work with
Building based on anonymous feedback is hard and is more often than not outright dangerous as different types of users have different needs. Without knowing who the contributors are and what problems they are trying to solve, it is easy to let the loud minority take the project in a direction that is dramatically different from where the founders wanted to go.
It is important to see if founders have design partners that help them shape the direction of the project, instead of building in twenty different directions on anonymous feedback. For those that do work with design partners, it is helpful to understand the nature of the relationship. Almost every founder has a few friends they can get to help, but a year later when a design partner will be asked to start paying, those not truly committed and who do not have the actual pain points are likely to churn.
Understanding the founder’s plan around monetization
Some founders think “I can just build an open source project and then it will grow and I can charge people”, but monetization of the open source doesn’t work that way. Charging for training and collecting donations doesn’t translate into a VC-investable project.
Most open source startups make money by targeting enterprise adoption. The founder should have a vision for what enterprise implementation could look like, and also be smart about what goes into the open source version of their tool VS what they should reserve for the SaaS platform or whatever will later be built on top (assuming the open core model). It is important to start thinking about monetization early as decisions founders make as they build the product will inform what will or won’t be possible later. If they adopt the “we’ll figure out in the future” approach, it is likely that by the time they will be ready to start charging, they would have made decisions that cannot be undone.
In some segments, there are clear precedents on how something can be monetized, even if founders don’t know exactly how they can implement it. For instance, those building an open source database might not know how they will monetize it, but there are repeatable patterns for doing it based on the amount of data the customers are storing, data transfers, access control, and so on. While there are no necessarily right and wrong answers, it’s important to verify that founders have thought of these problems and have a plan about how they will tackle them.
Monetization is a complex topic, and one many VCs without experience investing in open source often get tripped over. The fact that people love using a great open source project for free does not at all mean that given the opportunity, they will start paying. You do need a strong, passionate community for monetization to be successful, but that is only one piece of the puzzle.
Understanding the drivers of the project’s growth
It is not enough to see that the project is growing; open source investors need to understand the drivers of its growth. A great example is Stable Diffusion - “a latent text-to-image diffusion model capable of generating photo-realistic images given any text input, cultivates autonomous freedom to produce incredible imagery, empowers billions of people to create stunning art within seconds”. Stable Diffusion, a competitor of OpenAI’s DALL-E, has been growing a lot in recent months as unlike DALL-E, it’s entirely free. The challenge is this: if free usage is the only driver for growth, and people leave OpenAI for Stable Diffusion because it doesn't cost anything, what will enable Stable Diffusion to build a business out of their free version? If there is already a business the average person doesn't want to pay for (OpenAI), then Stable Diffusion seems to be only collecting the users who don’t want to pay.
Seeing traction of an open source project is not enough; one needs to understand the drivers of that traction, and the context of the broader tech ecosystem in which it is seen.
Understanding the conversion rate and the context surrounding it
For later-stage open source projects, there are two components of growth: growth of free users and growth of users and organizations that pay. First, it’s important to understand the conversion rate (how many of the paid closed source customers started as open source users). Sometimes there can be thousands of free users and a few paid customers, but the paid customers never used the open source version of the product. There could also be cases when most users are paid and only a few are using the open source tool, begging the question if it would be wiser to double down on the commercial side. For these companies, open source acts as a free trial, great for POCs (proof of concepts) and upsell.
VC funding rounds in open source
The way funding rounds look in the context of open source is a bit different. While all VC firms would have their own logic and expectations for the round, here is an example of what it could be:
At the seed stage, VC is investing in an open source project used by ~1,000 people. The goal is to provide capital to continue building the free product and to get the number of free users to 20,000. Additionally, build the alpha version of the commercial offering.
At the Series A stage, the open source project got 20,000 people using it, and is now looking to build a GA, fully-featured version of the cloud-hosted product, and get 10 customers on it.
At the Series B stage, the project has 50,000 free users and 10 paying customers on the platform version. The Series B raise would provide a startup with funding to get their go-to-market figured out, sell to enterprise customers, and convert their free users.
The actual numbers will vary, but this is an actual example of how funding open source could look like.
Benefits of getting VC funding for open source companies
Ability to grow the team faster and hire the best talent
Building an open source project is not an easy task. Being able to gather a rockstar team of experienced and talented people can help open source founders supercharge growth and start with a tremendous advantage over the competition. Sure, it is also possible to bootstrap the product while working full-time somewhere else, or by relying on help from early adopters. However, a new project is unlikely to have enough supporters to make this viable, and having the maintainer’s attention split between multiple initiatives while trying to start a new venture will slow down the progress.
Providing confidence and assurance to early customers
Open source projects require a lot of time and attention from their maintainers. If the income stream they are able to generate from the project cannot justify their full focus, one of two things happens: either the founders will be able to do it on the side with their full-time job, or the project will get abandoned.
Companies interested in adopting open source tools, tend to do their due diligence to understand if the project will be around a year later. This is especially the case in cybersecurity where the cost of introducing a new component to the company’s security infrastructure is very high. Having a backing of a VC firm can help maintainers show that they are serious about their venture and that they have enough money to keep it running. Additionally, it enables founders to hire more people and provide more value, faster.
Getting support and valuable introductions
While the actual execution and value will heavily depend on the VC firm in question, most investors promise support to their portfolio companies. This can be a game changer to open source founders as many of whom have not built a company before and aren’t familiar with the nuances of running recruitment, operations, finance, legal, marketing, and other areas of business. An experienced VC can help close the gaps in the founder’s knowledge, make introductions to experienced entrepreneurs, and even connect open source maintainers with potential customers.
The recipe for success: the case for venture-backed open source security
Product adoption in cybersecurity moves with the speed of trust. In order to make buying decisions, companies have to trust the technology and the people building it and have confidence that the company will be around a few years later.
Early-stage startups are most affected by this reliance on trust, and rightfully so: a few organizations are comfortable bringing a one-year-old tool into their environment that has not been tried and tested by others over a long period of time. Companies know that startups take shortcuts, make sacrifices to get stuff out of the door quickly, and can sometimes be trying to sell something that doesn’t exist at all. Open sourcing the product helps to accelerate the trust-building as security teams can evaluate the ins and outs of the product, see how it’s built, and identify any gaps and blockers to adoption.
On the other hand, being open source creates a risk that the maintainers will lose interest or have to shut down the project due to the lack of funding. As I’ve explained, being funded by VCs can help provide reassurance to potential customers that these problems are much less likely. In combination, building a venture-backed open source security company may be a solution to the biggest problem impacting adoption in cybersecurity - the lack of trust.
Challenges surrounding open source VC-funded companies
The need to master enterprise sales
Open source companies looking to scale to over $100 million in ARR, have little choice but to build the enterprise sales motion. Because it feels almost contrary to the bottom-up, freemium-like approach of the open source, and most cybersecurity founders struggle with the need to change their mindset about go-to-market, few startups can do it well. HashiCorp is one of the few good examples of a company that was able to figure out enterprise sales.
The enterprise sales motion is especially critical in cybersecurity, where the buying process is still very traditional, involving demos, formal POCs, compliance and SOC II documentation review, and so on. Whether the company is open or closed source, it is forced to satisfy roughly the same requirements and expectations. Security startups, open source or not, cannot avoid hiring sales teams and mastering the enterprise sales motion. For products targeting developers, the sales process might be easier as the open source nature would appeal to developers and make it easier to adopt the tool, but even then sles enablement and execution are equally important.
Different hiring needs & the importance of community
Because few founders of open source startups have experience being employed by OSS, they may not know that open source companies need to make slightly different hiring decisions compared to their closed source counterparts. This is especially the case at the early stages when roles such as community and developer relations are critical for the company's growth.
Paying attention to the community is incredibly important. Open source founders should track and continually work on improving metrics that measure the health of the community, such as the average time of response to a GitHub issue, how many days on average it takes to get PRs merged, and the like.
Hard to preserve focus
Having the ability to preserve focus is critical for early-stage startups as their resources are limited, while the amount of work is insurmountable. When building an open source company, it is very likely that a big chunk of the founder’s time will be spent answering questions, reviewing contributions, and providing support to users who may be trying to solve very niche problems and will likely never become paying customers. Building a proprietary product, on the other hand, makes it possible to focus on solving a specific problem for a few design partners, and then scaling it to others.
Risks surrounding intellectual property and competition
Choosing to open source a security product has its risks. Building in public means that someone else can see what the tool does and how it works, and quickly build a much better solution.
Before open sourcing a product, founders need to have a good idea of what open source will enable them to do, and what risks they would be exposing themselves to. If entrepreneurs are building a product that needs a longer period of stealth, or has some proprietary algorithms or technology that should be kept secret, they will need to be smart about what they open source and how.
Another important dimension is the presence of an adversary in the cybersecurity world. If the source code of all the detection methods and instrumentation self-protection mechanisms employed by defensive tooling were open sourced, adversaries would be easily able to build their offensive suites to bypass them. As Peter Holditch of SenseOn points out in comments to the original piece, this makes OSS particularly challenging in cybersecurity compared to other areas of the tech industry.
Lack of investors who understand open source
There is a solid body of knowledge for VCs focused on B2B SaaS and enterprise; with open source investing, the situation is different. Every time an investor approaches an early-stage open source founder and starts the conversation by asking about their ARR, it becomes clear that they do not understand how OSS works.
VCs investing in open source need to understand the nuances of developer psychology and developer economics, open source licensing models, as well as product-led growth and community-led growth strategies, and have experience seeing the good and bad of monetizing open source tooling. Those investing in open source in cybersecurity, also need a strong understanding of the security industry, as some types of security products are more likely to be bought despite (or because) their open source nature than others.
Closing Thoughts
Open source can be a strong differentiator for cybersecurity startups and an important tool to build trust and get early adopters, but it isn’t by any means a Holy Grail. For the open source project to be a fit for VCs, it needs to have a well-thought-out business model, which cannot emerge on its own, without careful planning and execution.
In cybersecurity as in most other industries, many great open source projects won't ever have any commercial angle - they are hobbyist tools, point solutions, and ways for people to give back to the community. As with any startup, for the open source project to fit the VC model, it has to solve a painful problem or address an unmet need, have a large total addressable market, and typically have a path to be used by the enterprise customers. It's a good practice for early-stage founders to grow the community first and focus on the revenue later. However, it is very important to have a plan for monetization in place and to work with design partners that match the company’s ideal customer profile. Without design partners, it is easy to start building “stuff for the community” and lose sight of the fact that founders who raised capital from VCs need to build the product enterprises will eventually spend money on. Having a vision about who could use it, and making sure they are attracting those companies, is important for sustainable growth.
When it comes to cybersecurity, there are additional layers of complexity such as the fact that few CISOs are open to self-hosting open source tools, and most security professionals do not live in code. Platforms such as Wazuh, data lakes like Matano, and developer-centric security providers are much more likely to succeed in open source than tools targeting security analysts and CISOs. As we go into the future, and security becomes more and more technical, the number of areas where open source can produce companies fit for the VC model will likely grow.
As cybersecurity moves away from the “magic” and more towards measurable capabilities, we will see more open source projects raise VC funds. The trend has already started, with CrowdSec, Matano, Tenzir, Ockam, ThatDot, Project Discovery, Tailscale, Ory, Pomerium, Styra, Kusari, Codenotary, Infisical, Firezone being some of the many examples of either open source tools, or commercial products with open source components. A few months ago, Andrew Smyth of Atlantic Bridge and Chenxi Wang of Rain Capital launched the Open Source Security Index - the list of the most popular & fastest-growing open source security projects on GitHub. Investors are paying attention to open source in cybersecurity, and I am excited to follow the growth of this space in the coming years.
Investing in open source is hard, and given the number of unique constraints such as community, legal, and commercialization challenges, it is not something that can be approached with a generic recipe. Deep expertise and understanding of the developer ecosystem are highly beneficial to properly evaluating open source tools, hence why not many VC firms have been successful in this area. Similarly, not every open source project should try to raise capital from VCs. Companies that are successful from the VC standpoint can generate $100 or $200 million of revenue every year, but the bar for success for founders doesn’t have to be that high. That is what is so great about open source: we can have many founders working on solving important problems, and being rewarded for this work without having to scale and meet growth objectives imposed or expected by VCs.
Gratitude
This piece would not have been possible without the generous help from Alessio Fanelli, Partner at Decibel, Allison Averill, Vice President at Unusual Ventures, and Dirk Seewald, Partner at eCAPITAL.
Another important dimension you could add to the "Risks surrounding intellectual property and competition" section is the presence of an adversary in the cyber world...
Especially for detection tooling, if the source code of all the detection methods and instrumentation self-protection mechanisms employed by tooling were OSS, adversaries would be easily able to build their offensive suites to bypass them.
I think this makes OSS particularly challenging in the cyber space vs other areas of the tech industry, particularly in the Detection subspace.