Sustainable Free and Open Source Communities – Business Models

Docs: None

Wed, 09 Jan 2019 00:00:00 +0000

No business model

This is a common archetype for Sustainable Free and Open Source Communities. The business model is to not have a business model. That is okay, because not every sustainable open source project needs or wants a business model.

In this case the project has set up means and rules of collaboration, has a formal membership, usually without a formal position of authority or any other hierarchy and does not deal with monetary contributions.

Sustainability in this non-model focuses on collaborator growth (quality and quantity) and shared responsibility to address its biggest risk: contributor churn.

Who uses it?

When should it be used?

In the early phase of projects when it’s not clear that the idea/implementation is a viable option in the free software ecosystem. Or when it’s clear from the beginning, that the target audience is rather limited in size.

Sometimes this model is also used as a way out of entrenched corporate influence. Incubating a new project, while blacking out monetary interests, trying to supersede the fought-over-project by technical means. Kind of a fork of the problem space (not the technology), resetting the relationship of the involved parties. A prominent example for this would be systemd or the GNOME desktop environment.

What kind of monetization is possible?

Cash flow is avoided in this model because there is no legal entity behind the project (just individuals) that can handle the added complexity (control, reporting, taxes etc.) that monetization brings.

The individuals involved cover the development costs for the project by donating their time. Infrastructure costs are avoided by utilizing free to use plans of services like gitlab/github, travis-ci/circle-ci, netlify etc. or by donations of goods by members (like paying for a domain name etc.).

Does this model help create a Sustainable Free and Open Source Community?

Yes. This model can be applied for a very long time as long as the community sucessfully addresses contributor churn.

Docs: Support

Thu, 06 Dec 2018 14:37:03 -0800

Software is available under an open source license, and support is provided for a fee.

The Support model is one where the software is available under an open source license, but in order to have the company available to answer questions, assist in implementation, etc., you must purchase a support contract.

This model is often confused for the Free Software Product model.

Who Uses it?

XenSource (very early on - moved to loose open core over time)
Ntop
Zabbix
MySQL

When should it be used?

This is typically an early way to bring in revenue for an open source project. If/when the company or project needs to scale, it tends to transition into another model.

What kinds of monetization is possible?

Any, essentially.

Does this model help create a Sustainable Free and Open Source Community?

Yes.

Docs: Tight Open Core

Thu, 06 Dec 2018 14:37:03 -0800

Software has primary functionality covered under an open source license (the core) but has direct (often critical) features that are only available under a proprietary license.

Tight Open Core is a model where the software has its primary functionality covered under an open source license (the “core”), but has direct (often critical) features that are only available under a proprietary license.

Take, for example, the feature of authentication and authorization. Some amount of these are critical for almost all software. In a Tight Open Core model, this functionality will not exist in the open source core: instead, it will be pushed to either proprietary plugins or exist only in fully proprietary builds.

Who Uses It?

When should it be used?

Frequently used by venture backed startups, with a single company putting in the bulk of the engineering and product resources. The goal is to have successful enough core offering to generate substantial demand for the proprietary functionality.

What kind of monetization is possible?

These types of software are usually intended to be monetized from the beginning, although some (like Elastic) have shifted to this model over time. With this model, it is easier to determine if a given piece of functionality should be in the core or not: if it is critical to the success of your target market, it should be proprietary.

Does this model help create a Sustainable Free and Open Source Community?

No. There is evidence it is more effective as a business model than its cousin, loose open core. However, the dynamics of keeping vital functionality out of the core means that, should the community decide to replicate the feature, it is directly at odds with the company’s monetization model.

Docs: As a Service

Thu, 06 Dec 2018 12:27:40 -0800

The As a Service model is for software released under an open source license, and available as a service by the company.

The As a Service model is when the software is released under an open source license, and available for anyone to run, while also being made available As a Service by the company.

Who Uses it?

When should it be used?

When the software is primarily consumer oriented, or has a large operational overhead. The goal here is that the software has the simplest on-ramp possible, and requires no effort to maintain over time.

What kind of monetization is possible?

In its most pure form, such as Discourse, the software is always 100% free. That means that, while there is often a single company offering it as a service, the community itself is free to do so as well.

In other cases, the software will be covered under an aggressive form of copyleft, potentially combined with dual licensing, or non-free licenses (such as the commons clause) may be used to create a monopoly on offering the software as a service.

Does this model help create a Sustainable Free and Open Source Community?

Maybe. With the example of Discourse above, the answer is yes. The community is sustained through the service, but any member of the community would be free to compete. With any model that uses dual licensing combined with aggressive copyleft, or non-free licenses, it trades the fundamental liberties in the core commitment for revenue.

Docs: Donations

Thu, 06 Dec 2018 12:27:40 -0800

When a system of donations is set up to sustain a project.

Not really a “business model”, but let’s go with it anyway. The donations model is when the project sets up a system of donations, which are used to sustain the project.

Who uses it?

Vim
Webpack

When should it be used?

When the project is core infrastructure, primarily run by volunteers, or simply to do good in the world.

What kind of monetization is possible?

Anything that is valid under the license. In this model, though, sponsorship and individuals alike are solicited to cover the infrastructure and development costs for the project.

Take a look at the Webpack Open Collective for a great example of the donation model in action.

Does this model help create a Sustainable Free and Open Source Community?

Yes.

Docs: Dual Licensing

Thu, 06 Dec 2018 12:27:40 -0800

The software is released under an open source license, but has a single entity with full control of the software’s copyright.

Dual Licensing is a model where the software is released under an open source license, almost always a copyleft license, but has a single entity with full control of the software’s copyright. This enables the company to re-license the software as they see fit - either to sell it under a non-copyleft license, to run it as a service, or to sell proprietary versions, while restricting the rights of others to do the same.

Who Uses it?

MySQL (as a secondary model)
MongoDB

When should it be used?

A tool used primarily by venture backed startups, with a single company in control of the asset. The goal here is that the software is useful to a wide market with the copyleft terms attached, but for certain segments of the market, or to create your own proprietary derivative, you retain the rights to remove the copyleft.

What kind of monetization is possible?

Depending on the type of copyleft license, it ranges from simply selling identical software without copyleft terms (for embedding, as an example), to being allowed to run the software as a service, to being allowed to build fully proprietary distributions with enhanced functionality.

In any case, it is used to create a functional monopoly on monetization for the company.

Does this model help create a Sustainable Free and Open Source Community?

No. It trades the fundamental liberties in the core commitment in exchange for revenue.

Docs: Free Software Island

Thu, 06 Dec 2018 12:27:40 -0800

A project (usually enabled by a foundation) where everyone agrees that the software is created purely for the public good.

A Free Software Island is a project, usually enabled by a foundation, where everyone agrees the software is created purely for the public good. Individuals and businesses alike agree to co-operate with each other on the software that is contained on the island, for mutual benefit.

Who uses it?

Projects like Envoy were free software islands even before they joined a foundation (the CNCF in this case).

When should it be used?

If the project will have many collaborators, often large institutional ones, then a free software island may be the best home for it. While being on a free software island does not guarantee this kind of collaboration, it is designed for it.

What kind of monetization is possible?

Often, there is no direct monetization of the projects allowed at all. The Apache Foundation, for example, is very clear on this.

Instead, there are often downstream monetization of the software. For example:

The relationship between Apache Cassandra and DataStax - Cassandra is upstream, and DataStax is a proprietary downstream for Cassandra.
Kubernetes has a myriad of downstream monetization - companies with proprietary software offerings built on top, open source product extensions such as OpenShift, and cloud providers offering it as a service.

Does this model help create a Sustainable Free and Open Source Community?

Yes. The only risks in this model are that it only affirms the rights of the community within the island itself - it may result in the creation of more proprietary software, outside the community’s sphere of influence.

Docs: Free Software Product

Thu, 06 Dec 2018 12:27:40 -0800

Has 100% of the software covered by an open source license, but distributes the software as a supported product under a proprietary license.

The Free Software Product model has 100% of the software covered by an open source license, but distributes the software as a complete, supported product under a proprietary license.

Free Software Product companies use their trademark rights, along with the license of the software itself, to create proprietary derivatives. If there is a 100% open source distribution, it uses different trademarks and naming conventions, and receives little or no direct support for users from the upstream.

A cornerstone of this model is that the company produces little or no proprietary software. It allows the community to collaborate and makes it harder for proprietary derivatives to thrive.

Who Uses It

Red Hat

When should it be used?

When a single company provides the bulk of the effort to create and sustain the project, and has a clear target market for the product (typically the large enterprise).

What kind of monetization is possible?

Any kind of monetization is possible on the product. Because it is being distributed under proprietary terms, the options for monetization are unlimited. For those who might wish to create downstream versions of the project, they too are free to monetize as they see fit.

Does this model help create a Sustainable Free and Open Source Community?

Yes. By keeping 100% of the software open source, and not producing any proprietary features, the community is free to collaborate with the upstream. A 100% free downstream distribution can be created, and distributed - optionally with complete monetization.

Docs: Loose Open Core

Thu, 06 Dec 2018 12:27:40 -0800

Primary functionality is covered under an open source license (the core), and proprietary software is wrapped around it.

Loose Open Core is a model where the software has its primary functionality covered under an open source license (the “core”), with proprietary software wrapped around it. This model encourages widespread distribution of the core software, and tries to ensure that enough value exists in the proprietary software around it to convince their target market to make a purchase.

Who uses it?

When should it be used?

This is model that is frequently used by venture backed startups, where a single company puts in the bulk of the engineering and product resources. If the core project is successful, it leads to a large funnel of users that can then be sold the proprietary software.

If the core of the software has broad applicability to a wide market, and you can envision a proprietary product targeted at some segment of the market, this model can work well.

What kind of monetization is possible?

These communities are often monetized from the beginning, or at least are intended to be. The difficulty with this model is that it can be hard to determine where the right line is for a given feature - does it belong to the proprietary software, or the open core?

Typically, there is a single company that monetizes the core software.

Does this model help create a Sustainable Free and Open Source Community?

Maybe. If we treat the core software as essentially a free software island with a single downstream derivative, then yes, assuming others are allowed to also build proprietary software around the core.

However, this is often murky - since the company’s strategy depends on convincing a segment of the population that they must purchase the proprietary software, it will be easy for the company to turn to other models, which may mean it is no longer sustainable by the community.