Inside Open Source #7
All things Open Source: Interesting reads, startup news, trivia and views from Europe and beyond
Welcome to issue #7 of the Inside Open Source Newsletter
Every month I write about interesting developments in the Open Source ecosystem and related topics that I come across. Check out this month’s issue below and subscribe if you like what you read :)
This month’s topics:
🔎Framework for evaluating Commercial Open Source Startups from Bessemer Ventures
⏲How developers spend their time
🔎The Open Source Six: Good, Better, Best Framework
Just recently I came across a framework to evaluate Open Source companies from Bessemer Ventures, one of the most successful venture capital funds out there. As you can imagine, they did a pretty good job on that one.
“After meeting with hundreds of open-source project creators, analyzing the top 10,000 public GitHub repos, and aggregating data across the most successful OSS companies of all time, today we’re excited to share Bessemer’s Open Source Six, a Good, Better, Best Framework for open-source investing.”
Here’s the framework and my key takeaways from their research:
Team
When looking at the top 50 open source companies, it's the project creators who formed the company over 75% of the time!
Bessemer’s hypothesis of the drivers of this data point come down to 2 main factors:
Superior access to talent through the fame of the project creators in the dev community
Head start in thinking about long-term strategic aspects of the technology because of the intimate familiarity of the creators with the project
Origin
Most successful open-source stories are created through individual developers that dedicate their time to solving a specific existing challenge they face in their professional life. The resulting technology is then usually not poured into a business until much later.
“In fact, of the top 50 successful open source companies, more than half the time the project was launched long before a dedicated company was formed.”
The second big narrative in the open-source world is the tools that emerge from big tech. However, Bessemer argues that the tools released by these “tech giants” rarely result in commercially successful standalone businesses. They use Kubernetes as a prominent example for a technology that has a massive impact on the transformation of cloud infrastructure yet hasn’t had large commercial successes from a company perspective. Bessemer wonders: “Perhaps it is the instant, widespread popularity that prevents any single player from building a business atop of these corporate-released projects?”
Early adopters
Bessemer found out that early usage by the most cutting-edge tech companies increases the likelihood of wide adoption later on.
Especially “big tech” has a tremendous signaling effect that generates a validation around the business potential of a project. Additionally, these companies frequently face the “build or buy” question and mostly have the resources and know-how to build great tools in-house. So if these companies choose an external party to cooperate with on key IT infrastructure components, there is obviously a lot of validation for investors and big budgets to conquer.
Project ownership
The best-case scenario for an OSS company is when the team has full authority over the open-source project’s roadmap. They can prioritize features, approve commits, are closest to the project for talent and knowledge acquisition etc.
Additionally, the best market dynamic for founders occurs when they are the primary vendor for the specific open-source technology, and as mentioned before, if they are also the original project creator and maintainer.
But history has also shown that some categories are not “winner takes most” markets and that there can be enough space for multiple winners that build their business on top of an open-source project. As an example, Bessemer refers to Cloudera, Hortonworks and MapR which all serve Hadoop (open-source framework for large-scale data processing).
Monetization
Bessemer argues that the best companies only monetize a very small percentage of their user base (often less than 5%) and leave as much functionality as possible in the open-source version. This enables broader adoption in the dev community and fuels top-of-the-funnel lead generation for the paid product.
The biggest challenge in the monetization of open-source technology is figuring out the minimum set of features for a paid enterprise version while maximizing the value in the open-source version for the broad community.
From an investor’s perspective, Bessemer is most excited about companies that tap existing technology budgets and replace another service in production.
However, they also acknowledge that companies increasingly provide a budget for reducing the amount of time an internal engineering team will need to spend maintaining and managing a product.
Another interesting learning from Bessemer is that once open-source companies figure out a working business model, they can even grow faster than some cloud leaders.
Community
According to Bessemer, achieving large-scale community engagement is extremely rare.
“Out of the 37+ million public repos on GitHub, we have analyzed the top 10,000 (ranked by contributor activity), and we have identified less than 500 projects that we would consider to have ‘large scale’ community engagement. So about one in 80,000 projects reach this type of scale.”
Also, out of the top 500 open source projects, fewer than 100 are associated with venture-backed companies commercializing the project.
For a detailed explanation of the framework, you can check out their piece here.
⏲How developers spend their time
I came across a super interesting article from thenewstack.io about how developers spend their time.
Here is an overview of what they found out including a break-down by job description:
Key take-aways:
Not surprisingly, people who manage software developers spend twice as much time in meetings as do the people they supervise
Software developers spend 22% of their time just doing code maintenance
DevOps engineers spend even more of their time in meetings (34%), partly because they are facilitating communication between different teams
They also asked respondents to share the percentage of the time they spend on code maintenance related to their open source dependencies:
Obviously, the 25% time spent on open-source maintenance time emphasizes the importance of open-source technology. What really surprised me is the jump to 32% in larger organizations. One explanation for this stark rise could be that maintenance issues are becoming more complex as the codebase and applications get larger.
All in all this data makes one thing very clear: there is a huge opportunity for organizations to find new ways to increase the percentage of time their developers spend writing code, especially in large organizations!
And this represents major opportunities for developer tools focusing on engineering efficiency - Exciting times!