"I do open source work, how do I find funding?"
This document aims to provide an exhaustive list of all the ways that people get paid for open source work. Hopefully, projects and contributors will find this helpful in figuring out the best options for them.
The list below is roughly ordered from small to large. Each funding category links to several real examples (using topical articles or pages wherever possible instead of just a project's homepage.)
The categories are not mutually exclusive. For example, a project might have a foundation but also use crowdfunding to raise money. Someone else might do consulting and also have a donation button. Etc.
- Donation button
- Bounties
- Sponsorware
- Crowdfunding (one-time)
- Crowdfunding (recurring)
- Books and merchandise
- Advertising & sponsorships
- Get hired by a company to work on project
- Start a project while currently employed
- Grants
- Consulting
- Paid support
- SaaS
- Copyleft + paid license
- Open core
- Foundations & consortiums
- Venture capital
- Restricted license
APPENDIX: Contributing to this guide // License & attribution
TRANSLATIONS: Traditional Chinese(繁體中文) // Simplified Chinese(簡體中文) // Italian(italiano) // Japanese(日本語) // Russian(русский)
*"personal effort" notes when a funding effort was led by an individual, not a project
Stick a donation button on your site. Stripe and PayPal are examples of services you can use to accept donations.
- Few strings attached
- Little work involved: "set it and forget it"
- Usually not much money unless you have dedicated fundraising efforts
- Need an entity to accept donations, which may take a fee for doing so. Examples are Stripe and PayPal.
- To make donations tax-free for the person/organization who is donating, may need a legally charitable entity (in the United States, a 501(c)(3) nonprofit entity) to accept donations. Software Freedom Conservancy and NumFOCUS are examples. Harder for individuals or international donations to manage
- Sometimes not clear who “deserves” money in a project or how it gets distributed. An entity like OpenCollective may help with this.
Sometimes, projects or companies post bounties for open source work (ex. "fix this bug and collect $100"). There are several websites, listed below, that help facilitate the posting and collection of bounties.
- Open to community participation
- Money is tied to doing specific work (more like paying for service than donations)
- Especially popular for security work
- Can create perverse incentives in a project (low quality PRs, distracting priorities)
- Conflicts can arise over whether work fulfills a bounty
- Usually not much money per bounty (~<$500)
- Doesn’t provide recurring revenue
- Bountysource
- Gitcoin
- GitHub Bug Bounty Program
- Google Patch Rewards
- Inkscape's "funded development" system
- Internet Bug Bounty
- IssueHunt
- The Bounties Network
If you'd like to open source a project but want to ensure that others will invest in its long-term maintenance, you could tell your community that you'll open source the project once you've hit a certain amount of sponsorship. (Writer Tim Carmody refers to this as "unlocking the commons.")
This is similar to Crowdfunding (one-time) described below, except that instead of funding the work in advance, you build the software from the get-go, then choose whether or not to open source it depending on whether you hit your goal.
- Can be recurring source of revenue after initial development, depending on how you set up the conditions of releasing the project
- It can be a useful signal as to whether people value the package
- Gives people immediate value – people can sponsor you and get access to the package right away
- Doesn’t restrict future potential growth of the project and upholds the spirit of open source
- Doesn't work for projects that are already released
- Likely only works for eye-catching projects where a demo or proof-of-concept is very exciting
If you have a specific idea you'd like to implement (rather than ongoing project work), a one-time crowdfunding campaign can help raise the funds you need. Both individuals and companies might be willing to donate to your campaign.
- Few strings attached
- Can be easier for an individual to legally manage via, e.g. Kickstarter
- Lots of work involved to market campaign
- Usually has to be tied to concrete outcome, perks
- Usually not that much money (~$50K for one time)
- Companies not always comfortable donating to campaigns
- Andrew Godwin + Django (personal effort)
- Dave Gandy + Font Awesome
- GDAL Coordinate System Barn Raising
- Michal Papis + Rvm (personal effort)
- Monero Community Crowdfunding System (CCS)
- RESTful WP-CLI
If you'd like to fund ongoing project work, you can set up a recurring crowdfunding campaign, with a monthly or annual financial commitment that renews indefinitely (or until the donor cancels). Those who use your project regularly (including both individuals and companies) might be willing to fund your work.
- Few strings attached
- Can be easier for an individual to legally manage via, e.g. Patreon, Salt, Liberapay, OpenCollective, Flattr
- Harder to get commitments to recurring donations (often requires preexisting brand/reputation)
- Harder to explain concrete outcomes, perks that come with recurring donations
- Usually not that much money (~$1-4K monthly)
- Companies not always comfortable donating to campaigns
- Babel
- Caleb Porzio + Laravel Livewire and more
- Clojurists Together
- Eran Hammer + hapi Patreon
- ESLint
- Evan You + Vue.js Patreon
- GnuPG
- Ruby Together
- Tom Christie + Django REST framework (personal effort)
- webpack
If you are an expert in a domain that other people might find useful to learn about, you could write and sell a book or series of books. You can find a publisher (like O'Reilly) or self-publish. In addition to selling books, some projects sell merchandise (ex. shirts, hoodies) to support their work.
- Outcome not tied to project work itself, so you retain creative freedom
- Can serve as marketing for the project itself
- Can be recurring source of revenue after initial development
- Often not a significant source of revenue
- Can distract from core development of project
- Merchandise can have upfront costs
- CocoaPods (fundraising for charity)
- Daniel and Audrey Roy Greenfeld + Two Scoops of Django (personal effort)
- Kyle Simpson + You Don't Know JS (personal effort)
- Lua
- Sandi Metz + Practical Object-Oriented Design in Ruby (personal effort)
If your project has a large audience, you can sell sponsorships to advertisers who might want to reach them. You probably have a very targeted audience (ex. if you have a Python project, you can assume your audience is likely people who are technically familiar with Python), so use that to your advantage.
- Business model aligned with something people are willing to pay for
- Need large enough audience to justify sponsorships
- Need to manage trust and transparency with user base (ex. no tracking)
- Can be a lot of work to find and manage clients
- Can involve ethical concerns about marketing
- Can introduce a conflict of interest; making controversial changes could result in losing sponsors/advertisers
- CodeFund
- GitFund
- Hoodie
- Read the Docs
- Feross's experiment with StandardJS
- Kite sponsorship of Minimap (summary)
- Caddy (exclusively sponsorships)
Companies sometimes hire individuals to do open source work. Find a company that uses the project you want to work on. Often this is a split arrangement (ex. 50% company work, 50% open source work). Alternatively, if you have an idea for a new project, find a company that would be interested in using what you produce. In these situations, having demonstrated experience you can point to will be very helpful.
- Taps into those who have resources (i.e. companies)
- Can be well-aligned with company needs
- Steady income
- Usually involves “getting lucky”: no clear, repeatable path to finding this arrangement
- Project already needs to be well-known and used
- Person not contributing to company’s bottom line, which makes them expendable
- Governance issues, company could have undue influence over project
- Can affect project dynamics + balance
- Aaron Patterson + ManageIQ and Ruby, Rails (personal effort)
- Donald Stufft + Hewlett-Packard and Python packaging (personal effort)
- Rich Hickey + Cognitect and Clojure
- Ryan Dahl + Joyent and Node.js (opens a YouTube video) (personal effort)
Many open source projects started as employee side projects. The project might eventually outgrow the company, but starting it as a side project can be a great way to incubate the idea.
If you pursue this path, make sure you understand your company's policy on open source work. Some companies encourage employees to contribute to open source during working hours. Some might treat your open source work as a company project. Don't assume anything; ask someone at your company before starting.
- Freedom to test new ideas without worrying about salary
- Can be well-aligned with company needs
- Suitable for newer, experimental ideas
- Need to do it as a side project or be approved to work on it during salaried time
- Risk of undue company influence
- Can lead to complicated governance later down the line
- Facebook and React
- Futurice's open source program
- Google and Go
- Mozilla and Rust
- Formidable's Sauce program, where they pay employees for their open source contributions
Grants are monetary gifts that do not require repayment. Oftentimes the grantmaker receives other benefits from giving you the grant, such as access to you, demonstration of impact, a report of your work, or tax benefits.
Grants can come from many places, including companies, software foundations, philanthropic foundations, and the government. The technical and legal aspects of a grant vary greatly depending on where it comes from. For example, a company might give you a "grant" but legally treat it as a consulting invoice. A philanthropic foundation can only make grants to nonprofits, so you would need to be a nonprofit yourself, or (more commonly) find a nonprofit to sponsor you. If you're unfamiliar with grants, the best way to understand how grants work is to talk to someone who has received one before. Some examples of grant recipients are listed below.
- Fewer strings attached
- Guaranteed money can help project focus for an unbroken period of time
- Gives project room to breathe and experiment
- There aren’t many software-related grantmakers (philanthropic, gov’t, corporate)
- Grants are finite. Still need to find sustainability beyond the life of a grant
- Andrey Petrov + Stripe Open-Source Retreat and urllib3
- Chan-Zuckerberg Initiative grant program for open source software in science
- Dash Budget Proposal Tracker
- Dat Project
- Django + Mozilla Open Source Support
- Grin General Fund
- Handshake community grant program
- Libraries.io grant applications
- ralphtheninja/open-funding has a list of grants
- Segment Open Fellowship
- Sentry Open Source Grant
Consulting can be a flexible way to fund open source work. You have more freedom to structure your time as you wish (for example, consulting 30 hrs of the week and spending 10 hrs of the week on open source work). Consultants can usually charge more for their time than salaried employees because the work is less steady, they don't receive benefits, etc. If you plan on doing this type of work regularly, you will probably want to set up an LLC (or equivalent outside of the US).
If your project is popular, you can also offer consulting & services around the project itself. For example, a client might pay you to implement the project for them, build something custom, or train them on how to use it.
- Business model aligned with something people are willing to pay for
- Consulting requires human power, doesn’t scale well (except for rare outliers)
- Business needs can distract from writing code or other tasks related to the project itself
- Can be at odds with making software simple to use
- Project needs to be sufficiently popular that people are willing to pay for related services
- Baroque Software
- Neighbourhoodie
- OpenSSL Software Foundation formerly OpenSSL Software Services
- Varnish Moral License
In this model, the code is freely available, but users need to pay to receive support from the project's maintainers. That might mean charging for access to the issue tracker, office hours, a community Slack, or an SLA (service-level agreement).
- Business model aligned with something people are willing to pay for
- Can be at odds with making software simple to use
- Project needs to be sufficiently popular that people are willing to pay
- Maintainers don't necessarily want to offer professional support
- Fody: Must be a Patreon supporter to open an issue or pull request
- Prism: Supporting their Patreon gives you access to their community Slack channel for project support
- Red Hat
- Tidelift paid subscriptions
SaaS means Software as a Service. In this model, the codebase itself can remain open source, but you offer paid services such as charging for use of a main hosted site or for handling the hosting of dedicated instances for customers. Typically, paying customers also get priority support.
- Can build community around open project and make money off of services for hosting
- Allows open source project to focus on users and as needs grow to help enterprises adopt the project
- Can scale by number of users
- Often means the hosting needs to be cheaper than hiring a dev to run the project for you.
- “Two tiers” of product support can make free users unhappy
- Discourse
- Forge Laravel
- Ghost
- GitLab (also uses open core licensing)
- Moodle
- Sentry
- Travis CI
- WordPress.com
Companies selling proprietary software prefer to include permissively licensed code (such as MIT or Apache 2.0) rather than copyleft licensed code (like the GPL) in their software, because the latter requires them to keep the same copyleft terms for their end products. So, some open source projects use a copyleft license by default, but they sell license exceptions, proprietary licenses, or permissive commercial licenses to companies who want to bypass the copyleft requirements.
- Business model aligned with something people are willing to pay for
- Can scale well if successful
- Can be at odds with making software freely accessible
- Project needs to be big enough that customer need exists
- Only works for upstream software that's being used in downstream software
- There can be legal or monetary barriers to moving code from open to proprietary
Under an open core model, some aspects of the project are free, but other features are proprietary and available only to paid users. Usually this works when there is enterprise demand for the project.
- Business model aligned with something people are willing to pay for
- Can scale well if successful
- Need to have something you can charge for (which means making certain features exclusive)
- Can be at odds with making software freely accessible
- “Two tiers” of product support can make free users unhappy
- May require a CLA (Contributor License Agreement) in order to accept code submissions from outside contributors while retaining the ability to relicense those submissions under the proprietary license
- GitLab
- Docker
- Elastic
- Mesosphere
- Phusion Passenger; see also their talk, "Bootstrapping a Business Around Open Source" (video)
- Sidekiq
A foundation is a legal entity that can accept and/or disburse donations. Because their purpose is not to make profits, they can be a great choice to signal neutrality and steward a project. In the US, foundations are either 501(c)(3) (nonprofit) or 501(c)(6) (trade consortium). Many software foundations are 501(c)(6) because 501(c)(3) require demonstrating a charitable purpose, which can be more difficult in software.
- Neutrality. Foundation protects the code and helps steward community
- Influence distributed across multiple donors
- Can legitimize project, companies might feel more comfortable giving to foundations than individuals
- Only really worth it for big projects
- Difficult to set up for IRS reasons (many do 501(c)(6) instead of 501(c)(3)), restrictions on what you can do
- Requires serious community effort and diverse skills (you still need to fundraise after setting up the entity!)
Venture capital is a form of funding for high growth businesses. Unlike a bank loan or other forms of debt financing, venture capitalists take equity (a percent ownership in your business) in exchange for funding. Unlike taking out a loan, you don't have to repay your creditors if your business tanks. If you do succeed, however, you should expect to return capital to your investor at a multiple.
Venture capital is "high risk high reward": VCs are more risk tolerant than banks, but they also expect a large payoff if you are successful. If you plan on raising venture capital, you should set up a business entity structured as a C Corp, preferably in Delaware. If you're unfamiliar with the venture capital process, the best place to start is by reaching out to similar founders who have successfully raised venture.
- Institutional support can be helpful for growing a business
- Large amounts of capital available
- Venture capital comes with expectations of an exit (i.e. returning the money to investors at a multiple). History suggests this is structurally difficult to achieve for open source businesses. Venture Capital isn't actually a business model but only investment capital for those who have some other business model for future revenue.
- Venture capital can change motivations and distract from priorities
- Unavailable to non-profits
Restricted licenses (reminiscent of the older shareware movement) are not open source because they do not meet the definition of an open source license. The source code is made available (either publicly, or to customers who pay for a license), but they may limit the freedoms to redistribute and modify or to use the software commercially.
- Business model aligned with something people are willing to pay for
- Potential to scale well if successful
- Not actually open source (so may fail to achieve many or most of the benefits of open source)
- Can be controversial, erode community trust
- BSL (Business Source License), used by MariaDB
- Fair Source, used by Sourcegraph
- License Zero
- Markdown Monster
- Source code is viewable, but a license must be purchased for continued use
- Project contributors are eligible for a free license
- Onivim 2
- Commercial license is pay-what-you-want, with the minimum pre-order price increasing as they get closer to shipping an MVP
- Anyone who financially sponsors the OSS project gets a free lifetime license
- Commits are dual-licensed with MIT after 18 months from commit's date to master
- Redis Commons Clause
- Ungit switched back from Faircode to MIT License
I wrote up this guide to aggregate my own knowledge. I recognize the pros/cons are somewhat subjective, but they reflect my views. If you submit changes, I may consider them but do not intend to cover everyone's viewpoints.
If something is factually incorrect (especially with a case study example), I welcome your edits. Case studies are organized alphabetically within each category. Also, if there's a category you know of that I missed, I would also welcome that addition.
This guide is available under the Creative Commons CC0 1.0 License, meaning you are free to use it for any purpose, commercial or non-commercial, without any attribution back to me (public domain). If you do use it, I'd love to hear about it! (Find me here: @nayafia) But you are in no way required to do so.