"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
- 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
- Dual license
- Open core
- Foundations & consortiums
- Venture capital
- Shared source
APPENDIX: Contributing to this guide // License & attribution
TRANSLATIONS: Traditional Chinese(繁體中文) // Simplified Chinese(簡體中文) // Italian(italiano) // Japanese(日本語)
*"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. SFC 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
- Gitcoin
- Bountysource
- Internet Bug Bounty
- Google Patch Rewards
- GitHub Bug Bounty Program
- Status Open Bounty
- FundRequest
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
- GDAL Coordinate System Barn Raising
- Dave Gandy + Font Awesome
- Michal Papis + Rvm (personal effort)
- Andrew Godwin + Django (personal effort)
- ribasushi + CPAN (personal effort)
- RESTful WP-CLI
- Monero Forum Funding System (FFS)
- Dash Budget Proposal Tracker
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
- Evan You + Vue.js Patreon
- Eran Hammer + hapi Patreon
- webpack
- Babel
- GnuPG
- Tom Christie + Django REST framework (personal effort)
- Ruby Together
- Clojurists Together
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
- Lua
- Daniel and Audrey Roy Greenfeld + Two Scoops of Django (personal effort)
- Sandi Metz + Practical Object-Oriented Design in Ruby (personal effort)
- Kyle Simpson + You Don't Know JS (personal effort)
- CocoaPods (fundraising for charity)
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
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
- Donald Stufft + Hewlett-Packard and Python packaging (personal effort)
- Rich Hickey + Cognitect and Clojure
- Aaron Patterson + ManageIQ and Ruby, Rails (personal effort)
- 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
Grants are effectively large donations 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
- Dat
- Andrey Petrov + Stripe Open-Source Retreat and urllib3
- Libraries.io grant applications
- Django + Mozilla Open Source Support
- Segment Open Fellowship
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
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
- Prism - supporting their Patreon gives you access to their community Slack channel for project support
- Tidelift paid subscriptions
- Red Hat
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
- Moodle
- Forge Laravel
- Sentry
- Travis CI
- WordPress.com
- Discourse
- Ghost
- GitLab (also uses open core licensing)
Companies 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 dual-license approach: the default project license is copyleft, but they sell either proprietary 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
- Docker
- Elastic
- Mesosphere
- Phusion Passenger; see also their talk, "Bootstrapping a Business Around Open Source" (video)
- Sidekiq
- Caddy; see also retrospective
- GitLab
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
Shared source licenses (reminiscent of the older shareware movement) are not open source because they do not meet all the required freedoms of an open source license. With shared source, the source code is available (either publicly or at least to customers who pay for a license), but they may limit the freedoms to redistribute and modify or to use the software commercially, and so on. Still, they are tangentially related to open source work.
- 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)
- Fair Source, used by Sourcegraph
- BSL (Business Source License), used by MariaDB
- License Zero
- 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. 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.