Open Source Business Strategy

Many software companies today – from Microsoft and IBM to scrappy startups – use, publish, and promote open source software. Especially in developer tooling and cloud infrastructure platforms, open sourcing your software is often considered table stakes.

At the same time, it's easy to misunderstand the nuances of various open source licenses, or to have an unclear business strategy around open sourcing. While big tech companies have legal teams to handle this, startups often "fly by the seat of their pants" and make quick, uninformed decisions – with legal, reputational, and business consequences later.

What open source is

The first major misunderstanding is what exactly open source means. The Open Source Initiative has a good definition (short and easy read), which boils down to two essential properties:

Allows distribution (both free and paid) of software, its source code, and any modifications under the same license, without requiring a separate license or fee.
Does not forbid anyone, anywhere, from using the software, at any time, for any purpose.

Beyond these legalities, open source is also understood as a way of organizing communities of software developers and users. In this broader sense, open source software often (but not always):

Is developed in the open – everyone can see what is being worked on, report problems, and suggest features.
Fosters an active user community – through forums, bug trackers, chats, meetups, and conferences.
Accepts outside contributions – people outside the core developer group can submit contributions, which may or may not be accepted.

Both the legal and community aspects of open source originated in the free software movements (focused on user freedoms) in the final decades of the 20th century. Open source is a refinement of those ideas, aiming to align them with business. It has seen large uptake since the early 21st century. Software under open source licenses is used by every major software company and incorporated into systems used by most people worldwide, with an estimated value of $8.8 trillion.

Why companies do open source

For clarity, by "use" or "do" open source, I mean companies publishing some of the software they develop or contribute to under open source licenses, and participating in open source communities.

Open source, by itself, is not a business model. While this mistake is sometimes made by aspiring indie developers, companies usually understand that open source doesn't generate revenue directly. What they often struggle with is whether and how to incorporate open source into their overall business strategy.

Companies publish their products as open source to:

Sell related services – Hosted versions, support packages, or consulting tied to the product or domain.
Upsell software – Enterprise editions, upgrades, or plugins that build on the open source core.
Marketing – As a loss leader or to support other revenue-generating products.
It's expected – In some niches (e.g., developer tooling), open source is the norm.
They don’t know any better – Imitating others without understanding the trade-offs.

How companies do open source

When it comes to implementing open source strategies, companies take a wide range of approaches. Some align closely with the spirit of open source, while others merely pay lip service to it.

Typical approaches include:

Fully open development – These companies fully embrace open source, including community involvement. They build in public, accept outside contributions, and external contributors often have meaningful influence. Examples include Astral and Sentry. These companies often start as corporate backers of existing open source projects and maintain their community roots.
Open source, open development, no contributions – Development happens in public with visible issue tracking and repositories, but the company doesn't accept outside patches. SQLite is a good example (though its test suite remains proprietary).
Open source, closed development – Development happens privately, with periodic public releases under an open source license. The company maintains a user community and accepts bug reports, but the internal development process is closed. Common in areas where open source is expected as a norm, like dev tooling.
Open washing – Companies label their products as open source when they’re not. Meta's Llama models are a prominent example: weights are released under a restricted license, and key training data is withheld. Gumroad is another, offering source-available code with usage and distribution restrictions.
Open source platform clients – SDKs, libraries, and packages for interfacing with the company’s platform. These are typically open source because they have limited standalone value but help adoption. Examples include SDKs for AWS and OpenAI.
Content marketing – Open source projects used primarily to drive interest in commercial offerings. Examples include LangChain (lead-in to LangSmith and LangGraph) and Next.js (lead-in to Vercel hosting).
Open Core – A core project is open source, while advanced features are proprietary. This freemium model converts some users into paying customers. Examples: Nginx, Red Hat/Fedora.
Copyleft + Premium – Uses a restrictive license (like GPLv3 or AGPL) that deters commercial use; companies must buy a separate license for business use. Qt used to follow this model.
Rug pull – Start with a permissive license, then switch to a restrictive one after widespread adoption to block competitors. Examples: Redis, Elasticsearch, MongoDB. Typically done to block hosting providers (e.g., AWS) from monetizing the product without contributing.
Eventually open source – Use a time-delayed open source model. Products launch under a restricted license (e.g., FSL) to prevent immediate competition, then transition to a standard open source license later. Example: Sentry, which also created FSL.

Many companies combine these approaches across products, or even within a single product.

License options

A major part of an open source strategy is the license you choose. The permissions and restrictions in the license directly influence what strategies a company can use. Copy-pasting a license choice without understanding its implications is a common and easy way to sabotage both your open source and overall business strategy.

While some companies create custom licenses, this comes with major drawbacks: it requires a strong legal team specializing in IP and licensing, and potential users are often wary of untested licenses. It's generally better to use a well-known, widely adopted, and legally tested license that aligns with your strategy.

Common open source license types:

Permissive – Users can use, modify, and distribute the code with minimal restrictions. Modifications don’t need to be shared. These are considered business-friendly and are the most common open source licenses. Examples: MIT, BSD, Apache 2.0. Special case: Public domain, which waives all rights (e.g., SQLite).
Copyleft – Users can use, modify, and distribute the code only if they release modifications under the same or compatible license. These licenses are often seen as "viral" due to their reciprocity requirements. Examples: GPLv2, GPLv3, LGPLv2.1, AGPL. Prominent users: Linux kernel, GNOME.
Fair Source – Source-available licenses that restrict use to protect the authoring company, with planned conversion to a permissive license after a set time. Examples: FSL, BSL, see also Fair Source.
Almost-but-not-quite Open Source – Example: SSPL, similar to AGPL but with an added clause requiring anyone offering the software as a service to open source all their own code under SSPL. Used by MongoDB, Elastic, and Redis to block cloud providers like AWS. Not recognized as open source due to this clause.
Creative Commons – Designed for content, not code. Suitable for docs, media, or other non-code assets. Not appropriate for software.

Accepting Contributions

One key decision with long-term implications is whether to accept external contributions and how to manage them. If a company publishes a project under an open source license and accepts contributions, the contributors retain copyright over their submissions. To relicense the project in the future, the company must get permission from all contributors or remove their code.

This is typically addressed with a Contributor License Agreement (CLA). A CLA is a contract that contributors must accept (explicitly or implicitly), outlining the terms of their contribution. It usually confirms that:

The contribution is made under the same license as the project.
The contributor owns the rights to the code they are submitting.

Some companies include a clause allowing them to relicense contributions in the future. While this adds flexibility, it can also trigger community backlash.

Implementing an Open Source Strategy

Companies considering open source should have a clear why (goals) and how (execution). Open source is not a business model or marketing strategy in itself, but it can support both. Before committing, understand the licensing details, community expectations, and be transparent with yourself and your users about your goals.