Skip to content

Commit df6a0c9

Browse files
richardgitbook-bot
richard
authored andcommitted
GitBook: [#96] Adding in Sumana's Workshops
1 parent 54a6da7 commit df6a0c9

18 files changed

+409
-26
lines changed

.gitbook/assets/Information Flow.png

159 KB
Loading
417 KB
Loading

.gitbook/assets/People Flow (1).png

119 KB
Loading

.gitbook/assets/People Flow.png

119 KB
Loading

.gitbook/assets/Slide 16_9 - 1.png

60.4 KB
Loading

.gitbook/assets/Slide 16_9 - 2.png

83.2 KB
Loading
18.7 KB
Loading

.gitbook/assets/Slide 16_9 - 3.png

18.7 KB
Loading

.gitbook/assets/Slide 16_9 - 4.png

72.6 KB
Loading

.gitbook/assets/Work Product Flow.png

455 KB
Loading

SUMMARY.md

+5-1
Original file line numberDiff line numberDiff line change
@@ -32,14 +32,18 @@
3232

3333
## Guides
3434

35-
* [Using Funds](guides/using-funds.md)
35+
* [Growing Your Contributors](guides/growing-your-contributors.md)
36+
* [Deciding on how to use your money](guides/deciding-on-how-to-use-your-money/README.md)
37+
* [Using Funds Directly](guides/deciding-on-how-to-use-your-money/using-funds.md)
38+
* [Marketing, Publicity, Roadmaps, and Comms](guides/marketing-publicity-roadmaps-and-comms.md)
3639
* [Recruiting Financial Sponsors](guides/recruiting-financial-sponsors.md)
3740
* [Companies and Trust](guides/companies-and-trust.md)
3841
* [Project Hygiene](guides/project-hygiene.md)
3942
* [Accepting Sponsorships](guides/accepting-sponsorships.md)
4043
* [Accepting Event Funds](guides/accepting-event-funds.md)
4144
* [Crowdfunding](guides/crowdfunding.md)
4245
* [Handling Burnout and Career Planning](guides/handling-burnout-and-career-planning.md)
46+
* [Promoting maintainers and handling conflict](guides/promoting-maintainers-and-handling-conflict.md)
4347

4448
## About
4549

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
---
2+
description: How to use funds for your OSC project!
3+
---
4+
5+
# Deciding on how to use your money
6+
7+
_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._
8+
9+
### Why you should (or shouldn't) spend your money
10+
11+
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:
12+
13+
* _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.
14+
* _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.
15+
* _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.
16+
* _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.
17+
18+
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.
19+
20+
But there are good reasons to save up your money as well, in some specific circumstances:
21+
22+
* _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](https://opencollective.com/workshops/events/recruiting-financial-sponsors-595f4cc3)) and avoid frittering it away on smaller opportunities.
23+
* _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](https://docs.opencollective.foundation/what-we-offer/employment) "must maintain a budget of at least 3x monthly employment costs, to ensure funds are available to pay employees."
24+
25+
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.
26+
27+
### Driver and supporter/protector activities
28+
29+
To start thinking about how to usefully spend your money, try the "drivers and supporters" framework:
30+
31+
* drivers: activities that directly advance your mission
32+
* supporters: infrastructural activities, goods and services that support the drivers
33+
34+
For instance, in this diagram...
35+
36+
![Money and Resources, shown by those that go into a project and then what comes out of it](<../../.gitbook/assets/Money resources flow.png>)
37+
38+
...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.
39+
40+
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.
41+
42+
Therefore, you can invest in, broadly, two categories of work, goods, and services:
43+
44+
1. fundamental capability: paying for driver activities that are on your roadmap, usually through labor.
45+
2. support and protection: digital platforms and services, administration, equipment and supplies, convening and travel, auditing, legal counsel, and more.
46+
47+
### Advancing your goals and roadmap
48+
49+
Take five minutes to consider: _what's on your roadmap and how could you spend to support it?_
50+
51+
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:
52+
53+
* pay a consultant to help you make a roadmap
54+
* if your existing team is constrained by their hardware, pay for hardware upgrades for them
55+
* if your team has time to mentor, sponsor and mentor an [Outreachy](https://outreachy.org) intern to build capacity
56+
57+
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.
58+
59+
Some examples of specific expenses: a. A part-time ongoing salaried or contracted worker along the [Django Fellow](https://www.djangoproject.com/fundraising/#fellowship-program) or [Jupyter contributor in residence](https://blog.jupyter.org/lessons-learned-from-jupyters-contributor-in-residence-pilot-427e2b361a7b): 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](https://www.outreachy.org/mentor/). 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](https://heidiwaterhouse.com/category/stickers/), [sticker.how](https://sticker.how/), and [StickerApp](https://stickerapp.com/). 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](https://whitecoatcaptioning.com/) or automated captioning services on video/audio calls to provide accessibility and a record for later reference. A supporter expense.
60+
61+
Also check out recommendations in [this Open Collective article from 2017](https://medium.com/open-collective/has-your-open-source-community-raised-money-heres-how-to-spend-it-3e9dd957dad).
62+
63+
#### Hiring contractors or employees
64+
65+
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](https://docs.opencollective.foundation/what-we-offer/employment), but that is rare so the rest of this section will assume that you will hire them as a contractor.
66+
67+
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](https://github.com/python/request-for), or give contributors the option to ask for compensation/sponsorship, [as Mautic does](https://contribute.mautic.org/policies/paying-contributors).
68+
69+
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.
70+
71+
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](https://docs.opencollective.com/help/collectives/expenses); 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.
72+
73+
#### Using bounties cautiously
74+
75+
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](https://bountysource.com/). (Patch bounty programs are distinct from _bug_ bounty programs, which are incentive programs that pay security researchers to report vulnerabilities they've discovered.)
76+
77+
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.
78+
79+
As [Mako Benjamin Hill has observed](https://mako.cc/writing/funding\_volunteers/funding\_volunteers.html), 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.
80+
81+
### Decision-making and governance
82+
83+
Who can make decisions about how to spend an Open Collective's money? Per [the expenses documentation](https://docs.opencollective.com/help/collectives/expenses):
84+
85+
> 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.
86+
87+
(Please also review the documentation on [budget](https://docs.opencollective.com/help/collectives/budget) and [expense policies](https://docs.opencollective.com/help/collectives/collective-settings/expense-policy) as well as ["ten ways to make decisions about money"](https://blog.opencollective.com/ten-ways-to-make-decisions-about-money/).)
88+
89+
Some common concerns about spending and governance, and ways to address them:
90+
91+
* 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.
92+
* 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.
93+
* 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:
94+
* _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](https://github.com/gratipay/inside.gratipay.com/issues/319#issuecomment-166757830)). 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.
95+
* _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.

guides/using-funds.md guides/deciding-on-how-to-use-your-money/using-funds.md

+11-9
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,10 @@
11
---
2-
description: Wondering how best to spend your project's funds?
2+
description: >-
3+
Wondering how best to spend your project's funds? Here are some short-term,
4+
actionable ideas
35
---
46

5-
# Using Funds
7+
# Using Funds Directly
68

79
We get a peek at how lots of open source communities power up their projects with financial resources. Depending on the shape, scale, and sort of project you're running, here are some ideas.
810

@@ -22,11 +24,11 @@ If someone delivers a valuable piece of work, you can thank them with money or a
2224

2325
Break the tradeoff between taking paid consulting work and spending time on your project. Pre-committing a chunk of time makes it easier to complete long-term goals.
2426

25-
### **Community Facilitation**
27+
### **Community facilitation**
2628

2729
Community support, onboarding, discussion moderation, answering newbie questions.
2830

29-
### Support Dependencies
31+
### Support dependencies
3032

3133
Donate upstream and downstream, because we're all in the open source ecosystem together.
3234

@@ -38,32 +40,32 @@ Make your software and website visually stunning and level up the UX snd brand.
3840

3941
Help guides, how to contribute, roadmaps, FAQs. Good documentation makes for a good open source.
4042

41-
### Come Together
43+
### Come together
4244

4345
Pandemics permitting, meeting in person can really elevate your community to the next level. You can have rich discussions, build relationships, and put faces to the online names. If you can't meet in person, try an online conference or team retreat.
4446

45-
### **Sponsor Relationships**
47+
### **Sponsor relationships**
4648

4749
Spend money to make money. Resource the time and attention it takes to interface with companies who use your tool and make major funding happen.
4850

4951
### **Productize**
5052

5153
Unlock bigger funding tiers with offerings like VIP support, ethical advertising deals, and paid services on top of your open source project. Developing these kinds of products takes time and effort.
5254

53-
### **Print stickers and t-shirts**
55+
### **Print stickers and T-shirts**
5456

5557
Swag is a jumping-off point for people to tell their friends about your project (“Hey, what’s that sticker on your laptop?”), and a fun way to build a sense of identity.
5658

5759
### **Encourage contributors to give conference talks**
5860

5961
Help cover costs to get them there if it's in-person, or cover their hours prepping their online presentation.
6062

61-
### **Inclusion & Diversity**
63+
### **Inclusion & diversity**
6264

6365
For all kinds of reasons, some people will face more barriers to getting involved — but we all win when different kinds of contributors are welcome. It could be mentoring and education, creating a code of conduct, donating to local charities, offering childcare at events, or doing outreach into new communities.
6466

6567
### **Newsletter and blog**
6668

6769
Comms is an important but sometimes overlooked skill in open source. Think about resourcing time to send Updates via your Collective, blog about your project, or build out your mailing list.
6870

69-
_And read this blog post:_ [_Has Your Open Source Community Raised Money? Here’s How to Spend It._](https://blog.opencollective.com/has-your-open-source-community-raised-money-heres-how-to-spend-it/)\_\_
71+
_And read this blog post:_ [_Has Your Open Source Community Raised Money? Here’s How to Spend It._](https://blog.opencollective.com/has-your-open-source-community-raised-money-heres-how-to-spend-it/)

0 commit comments

Comments
 (0)