There is a lot of complexity in the world of open source, yet there is also surprising commonality among governance approaches and commercialization strategies It’s been a . In April, Chef made the surprise announcement that it would make available the codebase of its entire product suite. Then in July, Cloudera with the announcement that it would open its closed source products and commit the whole company to open source, in line with Hortonworks, which it acquired earlier in the year. crazy year in open source doubled down on open source For all of the forces at work in open source, I’ve found that the viable business strategies can be distilled into just a handful of governance factors and commercialization models. This article is my attempt to formalize these commonalities into a useful taxonomy. After all, there are nuances to how a given open source project is funded and governed, and the relationship the company has with the project. All of which affect the visibility of the project (whether or not there’s marketing boost) and long-term control over the codebase and project direction. Ultimately, these are the factors that inform how successful and valuable a company will be. Let’s step through the primary governance factors then move on to the three key commercialization models. Governance Factor 1: Financing “Project-Community Fit” Key question: How is “project-community fit” funded? Incubated in an institution VC financed Bootstrapped Demonstrating traction is a prerequisite for an open source company to reach product-market fit. We might call this milestone “project-community fit.” By that, I mean, the point where a project finds a sustainable base of users. Production users will harden the offering, report and fix bugs, and provide proof-points. Contributing users are nice as well but not as critical. If the project doesn’t get there, the company has no value. If it does, the company has a chance at success. Funding the project largely boils down to two choices: VC/bootstrapped or growing the project within a company or institution. Venture investment and self-funding are self-explanatory. Founding a project within an institution or company is less common but certainly a viable path. For anyone but celebrity developers, being able to say that your project started inside Google, Uber, or LinkedIn attracts attention and lends credibility. There are many examples of successful open source projects started inside organizations like Google, LinkedIn or UC Berkeley. In fact, I’d say there is probably a better hit rate of people starting successful projects this way than pursuing an independent path from the outset. Of course, the downside here is the lack of control: Google, for example, will insist on handing off the codebase to a foundation like Apache. That decision will be made for you. Going it alone is the only way to ensure complete control from the beginning. Governance Factor 2: Long-Term Project Governance Key question: Who governs the project long term? The company or a single project foundation? Major foundation? Alongside project-community fit, long-term governance is a key consideration: Who owns the code and decides the fate of the project? You can put it in a major foundation, like Apache or Linux, or manage it yourself in a new foundation or otherwise. Putting it in a major foundation leans more “open” and lends itself to greater cross-project collaboration. It will likely give your young project a marketing boost. But it will also curtail the control you have over it and limit your monetization options. The typical alternative is to manage it yourself or create a single project foundation that you control. Governance Factor 3: The Role of Project Founders Key question: Who runs the company? Founders Committers Neither The project team’s relationship to the project itself is critical. Are the founders of the company the founders of the project? Does the company employ committers? Much of the glow that open source provides is channeled to the project founders. Having them on the team gives a marketing boost. Employing committers may give the company greater influence in the direction of the project and an insider view of where it is headed. It also reinforces the association with your company and the project. Perhaps the only draw-back is that the committers have a responsibility and passion for the project that may limit their interest in commercialization efforts. Finally, and most common, are team members that have no formal relationship to the project. While they don’t help on the marketing front, they are much easier to find and more likely to be generalists flexible enough to take the company in any direction. Three Models of Open Source Commercialization From these factors I’ve found 3 archetypes for building open source software companies. Here’s a description and illustrative examples. Model 1: Institutional This model represents cases where a big institution (company or university) develops an open source project, gives it to an established foundation, and the founders leave the first institution to start a company around it. I call it institutional because the codebase goes from a founding institution to a governing institution. This is a proven path for companies. The founding institution funds the growth of the project and provides a brand halo. The founders get to move to a startup after the open source project is validated while still keeping the founder halo and/or the governing institution halo. The downside to this approach is that you don’t control the core-code and can face commercial tension working with the governing foundations. Model 2: Independent This model represents cases in which founders create an open source project on their own or with venture backing. This is the high risk, high return model. This has the advantage of  retaining the control that can be lost from placing the project under the control of a governing institution. It can be a lot of work to bootstrap a project, but if it works, you stay in control of the codebase and own the brand/trademarks of the company and project. Most of the examples in the table below have in the last year or so, something that can’t be done for foundation-donated code. All of these projects have named their company the same as the project, which isn’t true of the Institutional examples above. It can be hard to build the brand as you don't have the halo of the founding institution. But once you do, it is all yours. changed open source licensing *In many cases the first project releases were before a company formed, but it is the closest thing to the founding institution. Also, in many cases companies changed names between formation and today, but we’ll use today’s names for consistency. Model 3: Co-Opt This model represents the many cases of companies founded by co-opting an existing open source project. Even if you haven’t created an open-source project, you can create a company around one. This is a newer model that is less proven but certainly promising. There are a bunch of great open source communities in which, for whatever reason, the founders aren’t in a position to or interested in pursuing commercial development. Here, you don’t get any halos, but you are able to skip the work of building a community -- just join a thriving one and commercialize it. I’m curious to watch how these companies play out. The founder halo is extremely valuable in commercializing something that is otherwise already free, but cloud and SaaS models give additional opportunity to extend value. Open Source Has Fostered Many Successes No one said that wearing the two hats of project founder and CEO would be easy. There is endless tension between the democratic spirit of open source and the many attempts to build successful companies on open source projects. Yet just look to a Chef or a MongoDB to see that it is indeed possible to turn open source into commercial success. Recognizing the commonality shared by these success stories can be useful for any founder seeking to grow a company using an open source approach to its codebase. Eric Anderson is a Principal at Scale Venture Partners where he invests in cloud infrastructure and open source.

Alongside

Apache

BUNCH

Cloudera

Funding

Google

Uber

Why Cloudera, Yugabyte, and Chef Went Open Source

Read My Stories

Too Long; Didn't Read

A Taxonomy for Open Source Software Companies: Governance and Commercialization

A Taxonomy for Open Source Software Companies: Governance and Commercialization

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Creator-User-Buyer Is a Mouthful. It’s also the Biggest Trend in Enterprise Software.

Why Cloudera, Yugabyte, and Chef Went Open Source

2 Lessons From The Early Years Of Impact DAOs

4 Ways Businesses Can Practice Effective Data Governance

5 Tech Best Practices for Smooth Business Transition

Creator-User-Buyer Is a Mouthful. It’s also the Biggest Trend in Enterprise Software.

Why Cloudera, Yugabyte, and Chef Went Open Source

2 Lessons From The Early Years Of Impact DAOs

4 Ways Businesses Can Practice Effective Data Governance

5 Tech Best Practices for Smooth Business Transition

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps