Awesome OSS Monetization v1.1

A curated list of awesome monetization approaches for open source software. Currently, probably with a slight bias towards open source libraries (like react.js, core-js, etc.) rather than open source programs (like OpenOffice, MariaDB, etc.).

Furthermore, the monetization approaches are meant for maintainers of the OSS - not external third-parties trying to make money with an OSS (e.g., by getting hired as an Consultant for an OSS).

Table of Contents

Awesome OSS Monetization

This list is the result of extensive internet research, compiling all the monetization approaches we could find from various sources. Please note that the list, classification and terminology represents a subjective opinion on the subject.

Feel free to commit corrections, additions, or further examples. The contribution guidelines are here

Monetization Approaches

In the following sections you can find the categorized list of monetization approaches for open-source software. The categories are based on the concept the payer is paying for - e.g., the category "Paid Content" combines approaches where a User pays for some additional content such as Merchandise.

An explanation of the Used Characteristics with metrics can be found below.

Unconditional Funding

Paid Access

Paid Content

Paid Licences

Paid Services

Paid Use

Paid Work

Special Monetization Approaches

Notes

Used Characteristics

In order to compare, evaluate, and explain the monetization approaches, several characteristics were used. In general, we are assuming that all contributors are on board and have agreed on a distribution key for the income.

Maintainer-specific Characteristics

Effort to set-up: The amount of work required to start the monetization approach. Measured in time [None; Hours; Days; Weeks; Months; Years; N/A]
Effort to maintain: The amount of work needed to keep the monetization going. Measured in [None; Low; Medium; High; N/A]
Cost to set-up: The monetary cost to setup the monetization approach (e.g., for external services) - excluding cost for private bank accounts, tax advisors, etc. Measured in [None; Low; Medium; High; N/A]
Cost to maintain: The monetary cost to maintain the monetization approach over time (e.g., for the hosting of certificates). Measured in [None; Low; Medium; High; N/A]
One-time Income: The level of one single contribution. Measured in [None; Low; Medium; High; N/A]
Recurring Income: The level of monthly contribution that can be expected. Measured in [None; Low; Medium; High; N/A]
Income Predictability: The stability of the income in the future. Measured in [None; Low; Medium; High; N/A]
Full income Threshold: The amount of clients/payers necessary to get to 5k USD (pre-Tax) per month. Measured in [Number of Payers]
Recipient: The entity receiving the monetization result - and who might distribute it further. Measured in [I: Individual; C: Collective/Company]
Additional Work: The amount of (continuous) work required in addition to working on the OSS. Measured in [None; Low; Medium; High; N/A]

Payer-specific Characteristics

Visibility: The ease with which a payer of the OSS notices the monetization approach. Measured in [None; Low; Medium; High; N/A]
Necessity to pay: The need for the user of an OSS to accept and pay. Measured in [None; Low; Medium; High; N/A]
Entry Threshold: The amount of effort necessary to contribute money. Measured in [None; Low; Medium; High; N/A]
Countervalue: The value a contributor of money gets in return, if he pays. Measured in [a thing]
Scalability: The ease and number of users or companies that can be reached to pay. Measured in [None; Low; Medium; High; N/A]

Monetization Approach-specific Characteristics

Effort for marketing: The amount of work necessary to make the monetization opportunity known to the public. Measured in [None; Low; Medium; High; N/A]
Competitors: The kind of competitors for this monetization approach. Measured in [M: Other maintainers; C: Contributors; O: Other Developers, Companies, or Content creators]
Software types: The types of OSS that would benefit the most from this onetization approach. Measured in [a type]

Monetization Risks

If you want to monetize your open-source project several factors have to be considered. For legal and tax related info you should ask a lawyer or tax advisor - potentially, for all countries in which your contributors live in.

Not having a License: If the current version your project has no declared license, its legal status in undefined and you should clarify it (esp. with all other maintainers and contributors). Without a license, each user of the OSS needs explicit permission from each contributor/author to use it.
Not having a CLA: If your project does not have a CLA (Contributor License Agreement) each contributor still holds the full rights to their contributed source code and could sue against a monetization. Github has a clause in their ToS which covers this, but if you want to monetize you all should agree on the terms and sign a CLA or remove code from contributors unwilling to sign the new terms. Furthermore, a CLA protects the project if a contributor has copied (stolen) code from somone / somewhere else.
- To setup a CLA you can use the Contributor Agreement Chooser.
- To automatically prompt and collect "signatures" of your CLA for pull request you can use SAP's CLA Assistant within GitHub
Not having a concensus about monetization itself can become a problem - esp. when mixing monetization efforts (e.g., donations) by individuals and projects. If you want to monetize you should ask all contributors if, who, and how you should monetize. A contract clarifying the willingness to monetize might be a good idea (Please ask a lawyer for help).
Not having a concensus about distribution of income in the collective can become a reason for dispute. If you want to monetize you should vote on how you want to distribute the income. The recipients of the money can be contributors but also bug bounties, conferences, or non-profits. A contract defining the distribution might be a good idea (Please ask a lawyer for help). Since recently there are services to distribute income for JavaScript packages such as StackAid, PayItFwd, or thanks.dev
Receiving money as a private person: might be a bad idea - esp. if it is meant for the project. The money would have to be taxed twice - first by the individual and then by the final recipient. Furthermore, the taxation depends on the country / jurisdiction the recipients live in (or pay taxes in if they are Digital Natives). If you collect money for the project it might be a good idea to use a fiscal host. As an individual it would be good to be registered as a Freelancer, to tax the income - but in some countries the normal income tax declaration might be sufficient (Please ask a tax advisor in your country).
Not paying taxes (as a project or individual) is always a bad idea. Even if you get only a dollar as a donation you should clarify how you have to declare the income and pay taxes (Please ask a tax advisor in your country).
Using a private bank account for collecting funds for your project is not a good idea. An extra bank account or fiscal host for the project to collect the funding and distribute it from there will help in being transparent.