Deciding on how to use your money
How to use funds for your OSC project!
This is a guide based on an Open Source Collective workshop led by Sumana Harihareswara of Changeset Consulting in January 2022. It focuses on helping Open Collective-hosted open source software projects decide how to use money they have already raised. All examples are in US dollars.
Why you should (or shouldn't) spend your money
A reasonable frugality can sometimes creep into needless hesitation to spend any money. However, your donors gave you this money so that you could spend it, and you should:
Advance your project in ways and at speeds you currently can't. There are tasks, chores, and infrastructure that are much scarcer if you only rely on volunteer labor. For example, it's hard to get donated laptops that would work as good development environments.
You need to spend it in order to attract more sponsors! If donors notice that you collect money but never spend it, they may reasonably ask why you need the money, and choose to donate to a project where their money will be used.
Experiment with different project approaches to improve your flexibility. Open source projects can fail to notice opportunities because they require an outlay of money. Trying out a pilot engagement with buying a service, hiring a contractor, or otherwise spending money (that you can spare to lose) helps you understand whether this will work for your project, so you have more flexibility for the future. There's no guarantee that your spending will prove to be the right choice; every purchase or contract is a bet. You and your team, through experience, can learn to make better and worse bets. Even if an experiment goes poorly, you can learn from it and course-correct to run better experiments in the future.
Aid intangible morale for your contributors and constituents. Don't underestimate the power of acknowledgment and the power of shared identity. A relatively small investment in stickers, awards, t-shirts, and similar merchandise can go a long way to aid in contributor retention, marketing to users, and general team morale.
Generally speaking, spending less than 10% of the money you already have saved, or making a one-time expenditure of less than 20% of the stable recurring monthly income of the project, should be something your project can do without an agonizing decision-making process. The first time you do it will be harder than the fifth or tenth.
But there are good reasons to save up your money as well, in some specific circumstances:
Saving money towards specific activities. If you know you want to save up $8,000 for a particular contractor engagement, and you only receive $500 per month in donations, it makes sense to concentrate on improving your fundraising (see the "Recruiting financial sponsors" resource) and avoid frittering it away on smaller opportunities.
Self-insuring specific risks. Instead of thinking in general that "we should have a buffer," consider your project's likely risks, and keep enough in the bank to cover the outcomes of those incidents. For example, if your website hosting provider suddenly shut down, what would it cost to get new hosting, perform data recovery, and migrate? Or, if your project operates in legally controversial territory, what would it initially cost to hire a lawyer to protect yourself from litigation (assuming that, if sued, you would also launch a specific time-sensitive fundraiser to cover legal expenses)? Or: Collectives that hire employees via Open Collective "must maintain a budget of at least 3x monthly employment costs, to ensure funds are available to pay employees."
Developing a budget helps you avoid just saving for the sake of saving, because it helps you delineate how much money shouldn't be touched (because it's there for self-insurance or to put towards specific future activities). That way, if you have more than that in the bank, you know you can choose to spend it.
Driver and supporter/protector activities
To start thinking about how to usefully spend your money, try the "drivers and supporters" framework:
drivers: activities that directly advance your mission
supporters: infrastructural activities, goods and services that support the drivers
For instance, in this diagram...
...labor for software development is a driver, because writing the software directly advances the mission of making and improving the open source project. An example of a supporter activity: organizing a conference where the contributors can meet to improve and speed up their work. An example of a supporter purchase: buying a new laptop for a contributor to use.
It's also helpful to think about "protector" activities or expenses that reduce potential risks for the project. For example, paying for a lawyer to file a trademark application for you might protect contributors from future headaches when users get confused by imitators. And organizing a code of conduct and paying for an implementation training workshop could prevent headaches, time-consuming incidents, and contributor attrition -- especially if you're planning to host in-person events.
Therefore, you can invest in, broadly, two categories of work, goods, and services:
fundamental capability: paying for driver activities that are on your roadmap, usually through labor.
support and protection: digital platforms and services, administration, equipment and supplies, convening and travel, auditing, legal counsel, and more.
Advancing your goals and roadmap
Take five minutes to consider: what's on your roadmap and how could you spend to support it?
If you do not currently have any explicit project goals or a written project roadmap, please see Open Source Collective's resource document on developing a roadmap. While you're working on developing a consensus for project goals/roadmap, you can still make solid investments with the money in your account:
pay a consultant to help you make a roadmap
if your existing team is constrained by their hardware, pay for hardware upgrades for them
if your team has time to mentor, sponsor and mentor an Outreachy intern to build capacity
If you do have project goals or a roadmap, a great approach is to pay new contractors (who don't have to be existing volunteers) to do support work that is currently going undone, or pay for services that will enable existing volunteers to avoid repetitive toil.
Some examples of specific expenses: a. A part-time ongoing salaried or contracted worker along the Django Fellow or Jupyter contributor in residence: approximately $50K/year. This role could be a driver (directly advancing features) or a supporter (reviewing others' code, working on infrastructure, and so on). b. Outreachy intern: one-time cost, USD$6,500. Probably a driver role. c. Professional education and tools for developers -- trainings/books for a book club, commercial task-tracking systems such as Todoist or The Amazing Marvin, laptops, continuous integration, etc. Cost could range from $5 to $3,000, one-time or recurring. A supporter expense. (Note that, depending on a contributor's country of residence, they may need to account for equipment that you give them in their yearly income tax return; a local accountant or tax adviser can tell you whether to note it as taxable income.) d. Fly one person to meet another for a one-week in-person hack week: maybe $1,500 for the flight, $750 for the hotel, and $250 for assorted transit and food expenses, so $2,500 total. A supporter expense. e. Pay someone $200 to design a logo (or, hold a logo contest with open voting, and offer a $100 reward), and then make stickers available for people to buy (or bulk-order $150 worth to share at a conference). Resources: Heidi Waterhouse's guide on stickers, sticker.how, and StickerApp. A supporter expense. f. Pay $100 in fees to help a contributor getting a passport for the first time, so they can travel to international conferences. A supporter expense. g. Pay $30-50 per hour to a virtual assistant firm to hire a secretary to take meeting minutes for conference calls, and/or pay for human or automated captioning services on video/audio calls to provide accessibility and a record for later reference. A supporter expense.
Also check out recommendations in this Open Collective article from 2017.
Hiring contractors or employees
You can, through Open Collective, pay new or current contributors to work on your project. Under some circumstances you can hire someone as an employee rather than a contractor, but that is rare so the rest of this section will assume that you will hire them as a contractor.
You could make a specific decision to start paying a specific existing contributor or new contributor without any public or open decision making process. Or, you could write up a job description and ask for applications, as the Python Software Foundation has done, or give contributors the option to ask for compensation/sponsorship, as Mautic does.
One project's experience: a current contributor was doing great work, and needed to pay the bills to support that work, was open about needing to step back in the future if no compensation was available. The project tried hiring a consultant from outside the existing contributor group via UpWork, but had mixed results because the consultant did not have needed specialist skills. The project decided that contract was unsuccessful.
So the project decided to offer a paid engagement to the existing contributor, at $40 per hour for up to 10 hours of work per week, to take care of backlogged chores that block other contributors. The contractor has flexibility to work fewer than 10 hours in any given week, but cannot go over that amount unless they get approval from the project. This engagement is run as a contract, using HR services offered through Open Source Collective 501(c)(6) using the Remote platform, rather than as a reimbursable expense; this is to provide both the project and the contractor with legal protection and an actual contract with terms of engagement. This engagement is very successful, enabling new features, and focusing on tasks that will make a difference to the project community.
Using bounties cautiously
Some open source projects are open to using money to pay for specific development work to be done via patch bounty programs such as BountySource. (Patch bounty programs are distinct from bug bounty programs, which are incentive programs that pay security researchers to report vulnerabilities they've discovered.)
There are reasons to be cautious about working with patch bounty platforms. If the platform is slow or unreliable in paying bounty winners, your project will have to do additional work corresponding with the platform and the developer, possibly navigating their frustration publicly on social media. Also, new contributors incentivized by a bounty are apt to act competitively rather than collaboratively, which may lead them to nag overworked maintainers to review and merge their code, plagiarize (or claim someone has plagiarized) work, and write hasty fixes that suffer from poor maintainability. What's more, these platforms usually only pay the developer of the patch, and do not compensate maintainers for reviewing it.
As Mako Benjamin Hill has observed, paying for the kind of work that is demonstrably not already being done for free by volunteers can prevent resentment from existing volunteers. If your project needs particular kinds of development work that your volunteers are disinclined or not skilled enough to do, such as integration into an obscure framework, and this need is blocking you from achieving your goals, concentrate on those tasks for bounties you offer.
Decision-making and governance
Who can make decisions about how to spend an Open Collective's money? Per the expenses documentation:
The decision is up to you as a project. Some projects are informal, and any Core Contributor can approve any expense. Others have a formal decision-making or budgeting process, or only pay expenses for specific things. We advise you to have a discussion with your collaborators and agree on guidelines for approving expenses.
(Please also review the documentation on budget and expense policies as well as "ten ways to make decisions about money".)
Some common concerns about spending and governance, and ways to address them:
You're not certain what legal or tax paperwork a particular purchase or payment will incur, especially across national borders. Contact Open Collective support; this is part of what they're there for.
You can predict that a particular abrasive person will loudly disagree with you about what you spent, what you spent it on, and whether it was a wise choice, no matter how well-grounded your decision. If this contributor or spectator is known to argue in bad faith, perhaps they are someone you and the rest of the team should be nudging out the door in any case. Until then, act in good faith and work to persuade everyone else, not them, that you acted in accordance with the group's policies.
Other people will have reasonable concerns about what you spent, and why and how you spent it, and you're not sure how to preempt or respond to those concerns. You have two major options:
Intense up-front transparency: invest in publishing details about the decisions transparently. Give contributors and spectators advance notice of possible expenditures, make it clear who has the power to decide, and offer a public comment period before approval (as in this Gratipay example). Do this consistently, and use Open Collective's tools to leave the records up for future inspection. This is relatively easy if you are managing all the expenses via Open Collective invoices.
Post-decision accountability: don't offer a pre-decision public comment period, but run an explicit private comment period among the decision markers, and offer accountability for past expenses such that anyone who wants to can ask for details on particular expenditure choices. This allows you to make more decisions privately, and gives you the option of providing some details privately in response to questions, but keep in mind that your payees or people you answer may publish details on their own.
Last updated
