As a nonprofit fiscal host (a.k.a. fiscal sponsor or foundation), we provide the financial and legal infrastructure for thousands of open source projects. We’re the ‘API' between open source communities and the world of accounting and invoices.

Discover some of the projects we host here or watch the video below to learn more about what we do.

For Open Source Maintainers

We handle your accounting, taxes, invoices, and administration. You decide where the money gets spent, and then we make it happen. Through us, you can:

• Manage your open source project’s funds transparently

• Receive financial contributions by credit card, PayPal, electronic bank transfer, or crypto (beta)

• Receive funds through our partners, including GitHub Sponsors, Drips, Google Summer of Code, and Google Season of Docs

• Receive funds from corporate supporters, including Microsoft and Google. We’re registered as a supplier to many corporate sponsors.

• Register trademarks, sign contracts and legal agreements, and apply for grants

• Pay yourself, your team, contractors, vendors, and suppliers

• And much more...

For Sponsors

Support the open source projects you rely on. See how projects use their finances, engage with and stay updated with progress, and get recognition for your contributions. Through us, you can:

• Manage all your open source support in a single place, with Open Source Collective acting as a single ‘supplier’ to your organization

• Support projects instantly on a one-time or recurring basis using a credit card, PayPal, or electronic bank transfer

• Hold funds with us to cover your contributions throughout the year

• Issue gift cards to your staff, which they can then use to contribute on behalf of your organization

Contact Us

Didn’t find what you are looking for? 🔍 Use the Search Bar in the upper right corner!

💌 Email us at hello@oscollective.org

💬 Join our Discord and find us in the #opensource channel

🐦 Follow us on Mastodon, BlueSky & Linkedin

📍 Our mailing address & Other Important Docs

Open Source Collective (OSC) offloads operational and administrative tasks necessary to run an open source project.

Joining OSC is great for projects that have reached their limit for administrative workload, but for projects that have little to no admin, fiscal hosting may feel like it is adding additional administration where there was none.

Joining OSC is a good option if:

• You have multiple contributors or maintainers who can help manage administrative duties like approving expenses.

• You need to pay out project funds to multiple people on a semi-regular basis.

• You want your financial transactions to be transparent.

• You need help with things like offering employment contracts, and health insurance to your contributors.

• You need help writing contracts, collecting incoming funds from vendors, or managing vendor procurement systems.

• You don't want to hold the project's funds in a personal or company bank account.

• You have contributors in different countries who need funds.

• You do not want to take responsibility for your Collective's accounting, taxes, liability, payments, and financial admin.

If the above sounds like you, you should consider applying at https://opencollective.com/opensource/apply.

Joining OSC may not be a good option if:

• You are the only person who can manage or whom you trust to handle the administration and finances of your project.

• You only ever need to pay out one person (yourself included).

• You don't expect your project to eventually bring in more than $600 of donations annually.

• Your project does not use an open license.

• You're not interested in building a community that will eventually take over ownership of the project.

• You want to hold your money in a currency that is not USD. OSC only holds funds in USD.

Every project has unique needs, and if a fiscal hosting relationship feels overwhelming, we recommend exploring fundraising platforms that prioritize individual attention, such as:

• https://github.com/sponsors

• https://en.liberapay.com/

• https://ko-fi.com/

• https://www.patreon.com/

You can see a side-by-side comparison of these platforms and ours to compare pricing and feature options here: https://docs.opencollective.com/help/product/comparison

Use Open Collective as an Independent Collective

You don't need to be part of a fiscal host to benefit from the platform and its functionality. If your organization or project already exists as an LLC or a nonprofit, you can use the platform as an Independent Collective.

More about that here: https://docs.opencollective.com/help/independent-collectives/about-independent-collectives

As per this announcement made on Feb 27th, 2024, Open Collective Foundation will dissolve its nonprofit entity effective December 31, 2024. If you are currently hosted by OCF and considering OSC as your new fiscal host, here are some things to consider before applying.

We are different business entities

• Open Collective Foundation (OCF), a 501c3 nonprofit

• Open Source Collective (OSC), a 501c6 nonprofit

• Open Collective (OC Inc), a US-based LLC

OCF and OSC are different types of nonprofits

OCF is a 501(c)(3). A c3 nonprofit is for public benefit.

OSC is a 501(c)(6). A c6 nonprofit is for member benefit.

OSC's income is not used for private or shareholder benefit. Our resources, such as the fees we collect, are all invested back into our mission: to promote a sustainable and healthy open source ecosystem.

Here are examples of how we redistribute our profit:

• Grants to our collectives for attending conferences (here)

• Sponsorship of open source related conferences and gatherings

• Sponsorship of research or development that benefits the open source community

• Donations to other charitable organizations

But why is OSC a c6?

The governing body that classifies what projects are considered a public benefit does not generally consider open source projects a public benefit. Few exceptions are made for projects with an educational or scientific research focus.

Please refer to a lawyer for more information regarding your designation. Here are some articles written by nonprofit lawyers to help explain the decision by the IRS and examples of projects:

• https://www.mill.law/blog/more-501c3-rejections-open-source-software-edition

• https://www.beavandenberk.com/ip/computer-internet/developing-open-source-software-not-an-exempt-purpose/

What does the difference between a c3 and a c6 mean to me and my project?

As a c6, OSC's mission is to promote a sustainable and healthy ecosystem to sustain open source technology for the future, from its maintainers to its funders. Because we are a member-benefit organization, our primary purpose is to support our members.

• As a c6, we have a wider range for what type of open source projects we can accept than a c3 can. (please refer to our guidelines on what we need to accept a project)

• We have straightforward requirements around the documentation needed to process expenses. Please see our guides on what we need to see in expenses here.

• We are not restricted to a location. We can host open source projects around the globe and pay non-us-based maintainers.

That said, there are some things we won't be able to offer that c3's can, including

• tax-deductible receipts to donors

• fundraising support

Here is a handy chart written by Reshama Shaikh to help explain the difference between the entities. (originally posted here)

OK, I want to join OSC

Great! To transfer your collective from OCF to OSC please do the following

1. Spend down the balance in your OCF collective to $0. You can do this by paying out expenses or invoices or by donating your remaining balance to another c3 organization.

2. Unhost your collective from OCF (steps outlined here).

3. Submit an application to be hosted by OSC here.

Mission

Our mission is to promote sustainability and health in the open source ecosystem, while working to benefit all those who create and use open source software.

Vision

To create an environment where it is as rewarding and financially secure to build and maintain software for the commons as it is for corporations.

Values

Impact: we are not a neutral platform Collectivity: we are building collective power Inclusivity: we are here for many different kinds of people Honesty: we act with integrity Transparency: we are authentically and accessibly open Privacy: we respect individual privacy Dignity: we treat others with respect Sustainability and resilience: we are here for the long haul

Strategy

In January 2022 we published our strategy which included three strategic goals to help us deliver on our mission:

Taking an ecosystem-wide approach to supporting open source software Enabling projects to use their money as well as raise it Make financially contributing to open source not only a good business decision but an easy one

To Open Source Communities

Open source, but for money

There are many incentives to contribute to open source software. We believe money can be one of them.

By using the Open Collective platform, our hosted organizations can easily raise funds, pay or reimburse contributors, share financial administration, and publish their finances openly.

Accounting

We take care of invoices, bank transfers, tax filings, contracts, and legal issues. As a fiscal sponsor, we help open source communities focus on the work they love to do rather than the work they have to do.

Services

In addition to being our projects' legal and financial home, we provide:

• Fundraising, budgeting, and grantmaking tools. More.

• Backend integration with other fundraising platforms, like GitHub Sponsors. More.

• Virtual debit cards linked to your project’s balance that you can use online. More.

• Administrative support for organizations participating in funding campaigns or support programs. More.

• Vendor registration and invoicing on behalf of corporate supporters. More.

• Register and hold trademarks on behalf of your project. More.

Representation and unity

With over 3,000 registered projects, we are one of the largest fiscal host organizations in the world. We are here to represent you, your community, and the broader ‘open source’ movement in conversations that impact our work.

Networking, development, and peer support

We provide forums to learn from one another, help one another, and work to solve the challenges that our community faces. We do this through events, forums, debate, and mentorship programs.

Opportunities

We continue to experiment with ways and reasons to contribute to open source projects, partner with individuals and organizations to build capacity and develop skills within projects, and work with institutions to bring the benefits of open source to under-resourced communities.

To Financial Contributors and Sponsors

Flexibility

Whether you lead an open source project or a team looking to sponsor projects, we offer a range of flexible ways to manage your money. We can work with and alongside other foundations, charities, and organizations to give you more freedom in how you choose to manage your projects.

Services

Through us you can:

• Manage the financial support of multiple open source projects in a single place with Open Source Collective acting as a single ‘supplier’ to your organization.

• Support projects instantly on a one-time or recurring basis using a credit card, PayPal, or electronic bank transfer. More.

• Hold funds with us in a dedicated 'pool' to cover your contributions throughout the year. More.

• Issue gift cards to your staff, which can be used to contribute on behalf of your organization.

Fiscal hosting is when an organization holds funds on behalf of smaller projects (which we call them C_ollectives_). A fiscal host becomes the financial and legal representative for otherwise unincorporated groups.

Fiscal hosts often provide administrative support and services such as financial oversight and management. We use the Open Collective platform to manage all financial transactions with the collectives we host.

This platform enables us (OSC and the collective) to be transparent with our finances and it allows our collectives to administer their funds directly! Learn more.

Fiscal Sponsorship, Fiscal Hosting, and Fiscal Agents

“Fiscal sponsorship” and “fiscal hosting” mean exactly the same thing.

In the US, you will primarily hear the term “fiscal sponsorship,” but since Open Collective works with groups all over the world, we use the term “fiscal hosting” to be inclusive of a variety of similar international arrangements between sponsoring or hosting organizations and smaller groups they are working with.

One other term you may run into is “fiscal agent.” This term is often mistakenly used to refer to fiscal sponsors/hosts, but actually refers to a different type of legal arrangement.

Our Approach

As the fiscal host, we hold our collectives’ funds in our bank account and are responsible for taxes, accounting, legal compliance, and financial administration. While our hosted collectives have a great deal of autonomy within the bounds of our Terms, Open Source Collective ultimately is responsible for the oversight of collectives’ funds.

You can read more about what we offer our Collectives and contributors here.

Choosing a fiscal host

We encourage you to read through this guide (our Documentation), especially What We Offer, our Policies, and our fees.

Our services are great for a variety of community-focused and collaborative projects, but consider your long-term needs before selecting a fiscal host!

Fiscal hosts using Open Collective

Open Source Collective is just one of many fiscal hosts on Open Collective.

Tax Deductible Hosts

As a 501c6, we are not a registered charity so we do not offer tax-deductible donations to contributors. If this is important, you may wish to look at NumFOCUS, or if your project has a direct charitable or social impact that benefits the public good, you should consider a 501c3 fiscal host.

Geography Specific Hosts

If you are based in Europe, need to handle VAT reporting, and would like European legal protection for your project, you may want to apply to Open Collective Europe.

If you're based in New Zealand and need a host to manage GST reporting you may want to look at Open Collective NZ

Fiscal sponsors outside Open Collective

There are also fiscal sponsors that operate without the Open Collective platform. Some may be within your sector or offer different services that fit your specific needs. Before you move forward with another fiscal sponsor, make sure to consider whether they are aligned with your mission, whether their technology and processes are smooth and straightforward, and whether they are transparent to their donors and sponsored projects.

Manage your finances

The Open Collective platform gives every open source community we host a profile online where they can:

• Raise money

• Manage and pay expenses

• Display their transparent budget

• Host Events, Projects

• Post Updates

• and more!!

Learn more about the Open Collective platform features.

To see all this in action, check out OSC's hosted Collectives. Thanks to transparency, you can see all their activities and how they use the features for yourself.

Transparency

One of the greatest strengths of our platform is the full transparency of both where money comes from and where it goes. When expenses are approved or contributions come through, the balance is updated in real time!

With a transparent process, team members and contributors can feel confident that the funds are being put to good use, while private details like emails, names, and addresses are only visible to administrators. Financial transparency creates stronger collaboration. Plus, when it’s time to report back to funders, you can just send them a link to your Open Collective profile.

The platform’s financial features also encourage best practices:

• No more messy spreadsheets

• Clear system of approvals and oversight

• Financial processes are accessible to your team, funders, and community

Administrators, team members, contributors, and third parties such as potential funders or partners can all see what funds are coming in and what funds are going out (don’t worry - sensitive personal details remain private).

About

Projects fiscally sponsored by OSC can offer employment benefits to their contributors. This allows you to employ people as contractors or full-time employees and enables you to provide access to benefits including health insurance.

How it works

Project admins define who to hire (themselves or others), how much to pay in salaries, and the job description(s).

Projects decide their own internal management structure, work practices, hours, and other day-to-day aspects of the job.

Costs related to employment are paid from your initiative's budget.

OSC (or the PEO) will be the employer ensuring legal compliance with employment regulations, and will take care of payroll, liability, taxes, workers comp, and all paperwork, working with our preferred PEO or EOR.

What are PEO's and EOR's?

Professional Employer Organizations (PEOs) and Employers of Record (EORs) are organizations that enable us to employ staff for your project. PEOs and EORs are generally (and confusingly) used interchangeably, but are different in one key area:

PEOs provide payroll services to clients like OSC. They are the employer with regard to tax filings and accounting but they do not have an employment agreement with the employee. We (OSC) are the official employer, this arrangement is also called 'co-employment' in the US.

EORs provide payroll services to clients like OSC but, importantly, they are also the official employer of employees. Clients like OSC sign a separate agreement with the EOR that determines how and who is responsible for directing and managing the employee, namely the client.

To all intents and purposes daily, weekly and monthly work will be the same regardless of how we employ you, but it is worth knowing who your legal employer is

Healthcare

Benefits are available to full-time employees (30+ hours per week).

Because we use a PEO/EOR we can access large group health insurance plans only available to employers. This lowers costs and increases available options.

Employees can decide whether or not to sign up for healthcare or other benefits, and the initiative's budget is only charged for benefits if they opt-in. Each initative can choose what proportion of benefits costs are paid by the initiative vs out of pocket by its employees.

Retirement & Pension Contributions

In many countries employers are legally obliged to provide a contribution to retirement or pension plans. If employing in a jurisdiction with this requirement we will ensure that we do so. Otherwise we will work with you to establish an appropriate policy for the inidividual and ourselves as the employer.

Costs

The following costs are charged to the Collective's budget for employment:

• Wages (and associated taxes, levies, and fees as required by law) - salary amounts are set by the initiative

• Local employment taxes - OSC can employ people in over 75 territories (and growing) we pay taxes local to the territories we employ in

• Benefits - if the employee chooses to opt into benefits such as healthcare we will pass these on to you.

• PEO/EOR fees - payroll provider costs ($49 or $99 per month per employee within the US — depending on benefits status, quotes available on request in other territories)

• Insurance - coverage for the initiative under OSC's employment practices liability insurance and related policies (varies depending on initiative activities, but commonly $250 per year)

• Administrative fee - $50 per employee per month

Costs are deducted monthly from the initiative's budget. Once employment is set up, employees will be paid by direct debit and initiatives do not have to take any action to manage ongoing expenses.

Requirements & Policies

• Employees must be located in one of the countries covered by our PEO provider, and be allowed to work legally in that country.

• OSC can currently support salaried, exempt, part-time, full-time employees. For other types of work, you may pay people as independent contractors instead (employment laws allowing - see below).

• All employees have unlimited paid time off (PTO) and we do not track or pay out PTO.

• Initiatives must maintain a sufficient budget to ensure funds are available to pay employees for the minimum terms of their agreements. (For fixed-term employment situations, it may be possible to drop below this threshold toward the end of the contract.)

• Employees and initiative admins have to agree to the terms of the standard OSC employment agreement (template).

• Employees must agree to follow the policies in the OSC Employee Handbook, which covers things like non-harassment, various kinds of statutory leave, health and safety, etc. Each state has slightly different required policies so the handbook varies by state (here is the New York handbook as an example).

Worker Classification

Anyone who wishes to be employed and meets the above requirements is welcome to be employed by OSC. Conversely, there are situations where the law says we must make someone an employee instead of a contractor. Defining whether someone is an employee or an independent contractor is called worker classification.

There are laws designed to prevent worker exploitation and ensure workers are afforded the protections and benefits of employment where appropriate. Regulations vary by state—someone in California may need to be employed while someone in Texas doing the same work might be allowed to be a contractor.

If you'd like to learn more about classification, read the guide below. It's a complex topic and we regularly run scenarios past our lawyer to be sure. If you have any questions about classification, please contact us.

Terminating Employment

OSC is an at-will employer in the US, and OSC or the employee may end the employment relationship at any time. In most circumstances, OSC will terminate employment at the instruction of the initiative's admin named as the employee's supervisor in the employment contract. In other territories OSC will abide by local employment laws.

Fixed-term employment contracts will expire upon the end date specified, unless they are extended. If the initiative or employee no longer meets the basic requirements for employment, such as lacking budget to cover costs, the employment relationship will end.

Where possible, we ask initiatives to give us advance notice, so we can take care of the termination process in a timely manner.

Virtual Cards can be issued to hosted Collectives for paying recurring payments, bills, online resources and tools, subscriptions, vendors (e.g. hosting providers), etc.

How it works

• Funds are spent only as transactions occur. - Setting up a card does not remove any money from your Collective's budget.

• Submit a virtual card request (click 'Actions' > 'request virtual card on your Collective's page) with the intended use of the card and the amount budgeted for that monthly. The virtual card with that limit will be set up for your collective.

• If, at any point, your collective needs a higher limit on your virtual card, please request a limit increase by contacting us at hello@oscollective.org with the intended use and the amount increase needed.

• Cards must be used in compliance with our policy below.

• Each collective can have one virtual card.

Requirements / Policy:

• These are virtual cards. No physical card will be issued, so these cannot be used in-store.

• Receipts must be submitted within 30 days. If a receipt is not submitted within 30 days, the card access will be paused until you do submit the receipt

  • The card's Assignee is responsible for collecting and uploading the receipts.

• All transactions should comply with normal usage of Collective funds as outlined in our Terms of Fiscal Sponsorship

• Virtual cards should not be used for personal expenses or entertainment, or they will be paused.

Limitations and Exclusions

• Virtual cards may not be used for paying/reimbursing people - that should be done on the OC platform.

• Open Source Collective will pause or deactivate cards without notice if found any odd payments are found that don't support or benefit the open source project directly.

If you need to input Cardholder contact details/address:

• Name: Open Source Collective

• Address: 440 N Barranca Ave #3939 Covina, CA 91723

Steps

Setup the card:

1. Collective admins request the card

   1. Visit your Collective's page

   2. Click Actions -> Request a Card

   3. Please include vendor details and pricing details in your request (estimates are ok).

   e.g.:

   Zoom Monthly Subscription $50/month

   Uhaul Storage Unit $500/month

   Amazon cleaning supplies $80/month

   Target Household Supplies $20/month

   Total: $650/month

2. We will assign the virtual card (please allow 2-3 working days to process your request)

3. Once assigned, the card assignee will be notified via email. The card's details will appear in the Collective's Settings for admins to use. (in accordance with this policy)

​After a purchase is made:

1. The funds will be withdrawn from your Collective

2. An "Invitation to submit an expense" will be sent to your Collective admins

   1. Admins will be asked to submit your receipt. (If the receipt is not submitted within 30 days, the card access will be paused until you do submit the receipt).

Notes:

• Any refund to the card will be automatically credited to your collective budget.

• OSC may proactively deactivate or adjust the balance of the card if it remains unused for an extended period of time.

Domains

Open Source Collective uses Namecheap as our domain registrar. Transferring a domain to Namecheap costs around ~$15 or more depending upon TLD names. Renewal costs will vary depending on the top-level domain. All costs are charged to your Collective.

Transferring a domain to Open Source Collective will require you to 'unlock' the domain with your current registrar and share an Authorization Code (or Auth Code/EPP Code) with us.

Domain Manager

Following the successful transfer of the domain, Open Source Collective will extend an invitation to the respective collective admin as Domain Manager. The Domain Manager will manage the domain billings such as coordinating Domain Renewal with OSC, and will get limited permissions like changing name servers, etc.

Open Source Collective will be managing the domain renewal and the Domain Manager will be tasked to coordinate and remind the fiscal host to renew the domain and responsible for domain renewal reimbursements. The domain Manager or the Collective Admin also needs to make sure that the collective has the appropriate budget for the domains.

Using a CDN

It is recommended that you use a CDN like CloudFlare to manage your domain. This enables Open Source Collective to act as the domain owner while you maintain your own domain's DNS configuration.

If you have not done so already, we recommend that you set your domain's nameservers to those provided by your CDN before initiating a transfer. Instructions to do so can be found in your CDN's documentation.

Updating Nameservers

Open Source Collective or the collective Domain Manager can update the domain's configuration as necessary but, as detailed above, we prefer that your organization remain in control of day-to-day configuration through a CDN provider like Cloudflare.

For Admins of Collectives

Open Source Collective will legally be the organization entering into the contract and will be the signer on behalf of your project. Please remind the preparer to draft the contract with Open Source Collective as the signatory.

Contact OSC before entering into any contract and we will discuss the details with you and review/amend/sign on behalf of your collective.

For Financial Contributors & Sponsors

OSC is the legal and financial home of our hosted projects. If you would like to support a project or collective on behalf of your company we can:

• Register as a vendor to your organization, issue invoices, and manage payments on your behalf.

• Provide facilities to manage your financial contributions over the course of the year, like Funds, Prepaid Budgets, and Gift Cards to your employees that can be used to donate monies to open source collectives on OSC.

• Issue template agreements for general or event-specific sponsorship.

There are instances where we can not sign for you.

For example, the Apple Developer Program. Unfortunately we can not offer this to collectives. Apple's agreement would be between Apple and OSC. If there was an infraction by one collectives, it would impact all of the collectives under OSC's Apple agreement.

Trademarks

Open Source Collective can work with you to register new trademarks or transfer existing trademarks to our protection.

Having a trademark does not prevent someone from forking the code and publishing it under a different name. OSC can also work with you, through our Open Source IP counsel, to notify those who infringe marks and, if necessary, begin proceedings against abusers.

OSC does not automatically take ownership of intellectual property for projects we fiscally sponsor, but you may have us hold assets, including trademarks, for your project.

Related expenses are paid from your Collective’s budget. The costs below are an estimate of a typical registration however, depending on the countries you register your trademark in or the complexity of your application, your fees may vary.

Options and Prices

Each option includes one hour with Chestek Legal to help you understand your trademarks and how to use and protect them, as well as advice about creating your trademark guidelines explaining how people may and may not use your name/logo. We suggest two half-hour calls: one initial call to discuss strategy and a second call to review and discuss the plan's implementation.

• US Single application for name and/or logo US (one class; price increases $350 for each additional class): $1200

• Trademark transfer - preparing assignment of single, already registered US trademark and recording assignment with the USPTO (the price of recording increases by $25 for each additional trademark): $350

• Non-US trademark(s) transfer or registration: Please get in touch with hello@oscollective.org for a quote.

FAQ

Why might an open source project want to register a trademark?

A trademark is “a recognizable sign, design, or expression which identifies products or services of a particular source from those of others.” They are typically words and logos, but can also be colors, sounds and shapes. A trademark ensures that users can identify where a particular piece of software came from and who built it, which is an important tool for building trust and reputation in your project.

While open source software is created to be shared and modified, a modified version should not also be characterized as equivalent to the original through using the same name.

A trademark registration will help you stop those who put out a bad product or even introduce malware and pass it off as your authentic code. It will also help you stop those who try to exploit your name by creating complementary products using your name or something similar to it. Having a trademark does not prevent someone from forking the code and publishing it under a different name.

Do I need to renew the trademark or will it expire?

Unless otherwise notified, we will renew your trademarks and invoice your Collective when needed. If your Collective does not have sufficient funds to renew, we will notify you as soon as possible and work with you to establish a successor or let the trademark lapse.

Depending on the type of maintenance filings, the USPTO charges either $425 or $525 per class in the registration. Our fee to prepare and file the maintenance documents is $450.

Maintenance filings are due 6 years after registration and 10 years after registration. Once you make the filing for the 10 years, the maintenance is due every 10 years after that.

What happens if someone is infringing my trademark?

It’s up to you to monitor use of your trademarked name and/or logo and decide what if any action to take if you think your trademark is being infringed. As part of the setup process with Chestek Legal, you’ll get an idea of some likely scenarios and possible responses.

If an issue arises, you can take some steps yourself, like contacting the person directly and asking them to respect the trademark, or submitting takedown requests to online intermediaries like social media platforms and app stores. If the infringement occurs on a platform like GitHub, Twitter, or Facebook you can ask support that the works are removed from their services.

If you have attempted to contact those involved, and you have been ignored or rebutted, feel free to contact us at hello@oscollective.org and we will notify our legal counsel (or you can work with your lawyer of choice) who can provide legal advice, write a cease and desist letter or bring an appropriate action in court. Any action that incurs extra expense (e.g. lawyer fees) needs to be funded from your Collective budget.

Do I need to register trademarks in multiple countries?

A trademark is only enforceable in countries where you’ve registered it, but registering in multiple countries can be very expensive (each country multiplies the cost).

If you have the budget and wish to register in multiple countries, you can, but registering in just one country still has value. A valid trademark in any country enables you to submit takedown requests to online intermediaries (like Twitter, Google, and app stores), gives you a basis to send a cease and desist letter, and, on the positive side, opens the door to things like commercial licensing agreements.

The vast majority of trademark issues are resolved without going to court, so you don’t necessarily need to have a trademark registered in the country where the infringer lives in order to achieve some degree of compliance.

If you register your trademark in non-US countries, Chestek Legal will coordinate with lawyers in those countries to perform the services on your behalf. Their fees will be billed to you without any markup.

What are trademark guidelines?

We include help creating your trademark guidelines in our service because it’s an important part of the process. These guidelines are normally hosted on your website, repo, or Collective page, and they help people understand how they can and cannot use your name and/or logo, and how your trademark interacts with your open source license.

Here’s a model trademark guidelines template developed for open source projects by Pam, to serve as a starting point.

Leaving Open Source Collective

If you are moving to another fiscal sponsor or starting your own entity, and that entity meets certain criteria, we can transfer your trademarks over to it (the criteria are determined by what we’re allowed to do by law as a US 501(c)(6) nonprofit, e.g. we can’t usually transfer assets to a for-profit proprietary company).

If the project is shutting down completely, or you don’t have a successor entity that we are allowed to transfer assets to, we will allow the trademarks to lapse.

If your Collective runs out of money and can’t (or doesn’t want to) pay the trademark renewal fees after 5 years (the first time) or 10 years (thereafter), we will allow the trademark to lapse. (See OSC’s terms of fiscal sponsorship section 6 for more details about termination).

How can I learn more?

Here’s a detailed article based on one of Pam’s presentations about open source trademarks. Another good resource is FOSSmarks. Please get in touch with us if you have any questions.

For attendees

We're delighted to support to open source maintainers to attend non-technical conferences. We recognize that many maintainers find themselves in a leadership role within their community but may not have the necessary resources to expand their knowledge outside of technical areas. We believe that by attending these events, maintainers can improve their project management skills and become more well-rounded leaders.

We encourage collectives to use their budget to reimburse their members for attending such events. However, we understand that not all collectives have the financial means to do so. In such cases, we're happy to cover the cost of your ticket.

To apply for funding, simply submit an expense (here) from your collective and make sure to include the cost of the ticket.

You can find more information about our decision and the types of conferences we support on our announcement here.

For organizers

In addition to supporting individuals with conference attendance, we're also excited to share that Open Source Collective will offer support to open source conferences. Please read below to learn more.

Financial Support

We can help with specific costs, such as venue fees, room sponsorship, and accessibility options. We also understand that organizing an event involves many different elements, so if there’s another area where you could use support, we’d love to hear about it.

The amount of financial support we provide will depend on the event's specific needs and the availability of our sponsorship funds.

Promotional Support

To boost awareness and attendance, we can help promote events through our channels, such as our monthly community update sent to our hosted collectives.

When deciding to sponsor an event, we consider:

Shared Values

• Events must align with OSC’s mission to promote open source sustainability, focusing on community, learning, and education, not major industry gatherings.

• Supported events must have a code of conduct, be inclusive, and feature diverse speakers.

Open Source Focus

• We prioritize events benefiting open source maintainers, especially those sharing content openly.

Financial Need

• We prioritize smaller events needing financial support over large, well-funded ones.

Impact and Reach

• We support conferences that make a difference, offer in-person and virtual attendance, and encourage participation over lectures.

How to Apply for Financial Sponsorship

1. Initial Inquiry

   • Email us at hello@oscollective.org. Provide some basic details about the event, what you’re hoping to achieve, and what kind of support you need, considering the criteria listed above.

   • In your email, please include the following:

     • Event overview and objectives

     • What specifically you’re asking OSC to sponsor

     • What the funding will be used for

     • How our support will impact the open source ecosystem

     • Any other sources of funding or support your event is receiving

2. Review and Decision

   • Our team will review inquiries based on the criteria above and reach out with questions.

   • Please send any requests for funding at least 30 working days before the event.

How to Apply for Promotional Support

We can share your event information with our community through our marketing and communication channels. To do so, please send an email to hello@oscollective.org with the following:

• name, date, location of event, including URL

• short description and target audience

• associated cost or ticket price

• social media handles for tagging

After the Event

We'd love to hear about your event's success! Please follow up with us afterward, as we’d love to share your event’s materials with our hosted projects. We'd appreciate it if you could share:

• A summary of the event

• Photos or videos you're comfortable sharing

• Links to recordings or other materials

Not only does this help us showcase the impact of our support to the broader community, but it also increases your event’s visibility, potentially attracting future collaborators and participants.

When you are ready, you can apply to Open Source Collective here.

If your project is registered with GitHub we may be able to verify and accept your application immediately. Select ‘verify using GitHub’ and follow the instructions. Read more.

Otherwise, we will ask you some questions about your project and manually approve your project within a few working days. Read more.

Before you apply:

1. Read through our full documentation and review the Terms of Fiscal Sponsorship Agreement

2. Ensure that you meet our acceptance criteria and are familiar with the Open Collective Community Guidelines

3. Have at least 2 community members ready to add as admins. Admins have full permissions to change settings, approve expenses, and make financial contributions from the budget balance of your collective. Applications with less than 2 admins will not be accepted.

4. Review our fees.

As a reminder:

• You retain ownership of all your intellectual property.

• We will hold and manage funds on behalf of your collective, and we won't use them for anything else.

• If you want to enter into an agreement with anyone else as your collective, such as a contract with a vendor or providing a specific service to a sponsor, you need to get in touch. Legally the agreement would be with Open Source Collective.

Moving to Open Source Collective

Moving from another host on Open Collective

If you are transitioning from an organisation that uses the Open Collective platform, the process is relatively simple.

Moving from an organisation not on Open Collective

If your collective is currently with another organization that does not use Open Collective, the process will depend on that organization’s requirements. Generally they will transfer your money to OSC and we will get you up and running on Open Collective.

Please be sure to communicate your plans to us within your application and your current organisation in advance of your application to ensure a smooth transition.

Once you have tied up any loose ends with your current host, they can transfer the funds to us electronically. We can issue an invoice to them and sign agreements if needed. Our normal fees apply to funds transferred in.

What is Github Stars Verification?

Open Source Collective offers the option to verify your Collective by showing that it has at least 100 Github stars. Meeting this requirement can expedite the approval of your Collective.

What if I can't verify with Github stars?

If your project is not centred on a Github repository, or you can't get the automated verification system to work for you even if you have 100 stars, please request manual verification instead.

Github Verification Troubleshooting

I can't find my repository or my organization's repository.

There are a few possible causes for that:

#1: You may be using the wrong GitHub account in the authorization process

If you believe that you may have linked the wrong GitHub account to your Open Collective account, you will need to manually revoke access from the current linked GitHub profile. You can do that by either accessing https://github.com/settings/applications or following our guide:

1. On GitHub, go to Settings.

2. On the Settings menu, click on Applications.

3. On the Applications page, open the Authorized OAuth Apps tab and look for Open Collective.

4. Click on the three dots on the right labeled "Show me more options" to revoke the authorization.

#2: You used the right account, but you didn't grant access to organization repositories

During the authorization process, GitHub lists the organizations in which you are a member. Depending on the permission level you have at each one of them and their third party access policy, you may have to either grant permission on that page or request it.

My repository is listed but I can't create a Collective (Error: We could not verify you are the admin of the GitHub organization).

Depending on the permission level you have at an organization, you may not be authorized to perform that action. Contact other members of your organization to discuss that process.

There are too many repositories listed on my page. How can I find the right repository?

Use the search bar to filter repositories by name:

The permissions you ask for are overly generous and my organization doesn't want to grant them.

We agree the permissions are overly generous. Unfortunately, there's not much we can do at the moment since this is the only scope we can use to read the info we need. We've discussed this at length on issues #355, #1034 and #2333.

If you have any suggestions on how to handle this better, feel free to join the discussions, start a new one, or send us an email support@opencollective.com.

If your project is not centred on a Github repository, or you can't get the automated verification system to work, you can request manual verification.

1. Ensure your project meets the acceptance criteria.

2. Go to https://opencollective.com/opensource/apply

3. Agree to the terms of fiscal sponsorship

4. Click 'Request manual verification'

5. Proceed to create your Collective and await manual review

When we review your Collective, we will look at the information you've provided, including links to your website and social media, and the info in your Collective's 'About' section. Please ensure these are up to date and correct on your Collective page.

Be sure to check your Spam folder for correspondence from OSC. Sometimes our emails end up in there.

Open Source Projects

When applying on behalf of an open source community, your project must meet the following conditions:

Legitimacy

• Your project must be novel or a substantial fork of an existing project.

• Your project must show recent activity and/or a significant degree of usage.

• The applicant(s) must demonstrate an appropriate level of access and standing in the community to act as a representative i.e. be a 'maintainer' rather than a 'contributor'.

We look at the ownership, activity, usage, and originality of the project.

License

Since the goal of the Open Source Collective is to support a Free and Open Source ecosystem, your project license is critically important. The list of Open Source Initiative Approved License List can serve as a gauge for valid open license criteria to the collective.

• Your project must have a license clearly defining how your project can be used, modified, redistributed and referenced by others.

The goal of the Open Source Collective is to promote a sustainable and healthy ecosystem to sustain open source technology for the future, and your project license is critically important to us.

Other valid licensing guidelines include the following:

When determining whether a project's license is appropriate, we look to guides like Open Source Initiative's Approved Licenses and other licensing guidelines like:

1. Free Software Foundation License List

2. Debian Free Software Guidelines

3. Fedora Software License List

4. Open Source Hardware Association Statement of Principles

Governance and Autonomy

• If possible, your project should include two or more administrators.

• Your repository should belong to an entity with appropriate access control i.e. not a personal repository.

Open Source Collective does not impose a structure, a process, or a statute on you and your community but as a small organisation supporting a broad range of open source communities we rely on you to operate a robust and effective decision-making process within your project. It is important to take into consideration how easily a project could continue if you or another core contributor takes leave.

We encourage projects to publish contributing guides, onboarding documents, codes of conduct, and other forms of governance documentation.

If you are looking for guidance or best practices in setting these up, we publish a range of guides and host regular community calls to facilitate new projects tackling this work.

Validation

If you are an open source project on GitHub you will likely be immediately approved. We have a built-in process that automates validation using GitHub authentication (more info).

If your project is on GitLab or hosted on an another platform you'll need to complete our application form (more info).

Open Source Adjacent Communities

We also consider applications from communities with a strong link to free and open source software. We use the following criteria:

• Your project must be strongly affiliated with or related to open source, not proprietary technology or any other topics.

Meetups, conferences and other groups

• should have at least 50 members,

• should have organized at least 2 events previously,

• should be able to show a history of activity by members.

As further evidence, you agree to send photo/video documentation of your first event after joining Open Source Collective.

Moving to Open Source Collective

If you already have a fiscal host, please help us understand why you think Open Source Collective would be right for you.

My project doesn't fit, but it should

Get in touch by emailing hello@oscollective.org. We are interested in learning about why. However, our decisions are final.

Before you join Open Source Collective, make sure to review our Terms of Fiscal Sponsorship Agreement, the legal agreement that defines the relationship between OSC and a hosted collective.

It includes a “plain English” version alongside it to help you understand the ins and outs. And we really encourage you to read the whole thing.

Have any questions? Reach out to us.

Open Collective (the platform)

Open Collective is the software platform Open Source Collective (OSC) uses with our hosted collectives to manage financial contributions and payments. Open Collective has a ton of features like transparent budgets, custom collective profiles, donation tiers, fundraising goals, and other tools now at your disposal.

Open Collective is also an open-source project that manages its own budget on the platform!

✅ For an overview of features and how to use the Open Collective platform, check out their documentation.

Receiving Funds

The Open Collective platform offers multiple ways for you to fund your project. Check out the Quick Start Guide, which offers a few great ways to get started.

Our documentation includes information on how people can contribute directly to your collective. Feel free to share this Financial Contributions overview with your contributors.

In addition to direct donations, some of our collectives developed innovative ways to fund their projects. Read more about different funding options here.

Receiving Crypto

Open Source Collective offers limited support for cryptocurrency donations. Due to the impracticalities of running a payments service at scale and fluctuations in various crypto markets, we do not hold crypto on behalf of our member projects. Instead, we will accept crypto, convert it to fiat (USD), and attribute the balance to member projects accordingly.

Projects wishing to accept crypto should email ops@oscollective.org to receive a wallet address managed by Open Source Collective.

Managing Expenses

Expenses are processed and paid out by Open Source Collective twice per week (on Tuesdays and Thursdays).

OSC can pay out funds via PayPal and electronic bank transfer via Wise (f.k.a. Transferwise). Make sure to review the Expenses and Getting Paid section of Open Collective’s documentation for a complete overview of the process.

If you have any issues with a specific expense, the best way to get an answer is to post a comment on that expense page.

Using different methods, you can use the funds from your collective’s budget to pay for expenses.

Virtual Cards

Open Source Collective provides virtual cards to Collectives on request. Virtual cards act like credit cards and allow you to pay for expenses online using your Collective's balance.

This is a great way to pay for recurring charges like domain hosting or any upcoming project expenses you don't want to cover with personal funds.

Click here for more information about virtual cards.

Invoices

Invoices are used to pay individuals for work or services completed on behalf of the collective. Here's the documentation on how to create an Invoice on the platform, in summary:

• Someone can submit an expense on your collective's page, OR collective admins can draft an expense and send an invitation to someone else to complete and submit it.

• Once an expense is created, a collective admin (someone on your team) must review and approve it as an accurate and expected expense.

• Next, a member of OSC's team reviews and approves the expense. This is done to ensure the expense meets requirements, e.g., having a valid receipt.

• Once the expense is verified, the expense recipient gets paid.

You can upload your own invoice or create one directly on the platform within the invoice option. Here are examples of what we need to see in the invoice to approve it for payment.

Reimbursements

Reimbursements are used to pay for purchases or subscriptions made on behalf of the collective.

• Reimbursements can not be used to pay contributors for work or labor spent on the project.

• Reimbursements are used to pay people (often volunteers) back when they have made purchases for the group.

• Receipts are required so that we can ensure the requested amount matches the purchased amount in order to approve the reimbursement.

Please look at the examples of what information we need to see in the expenses in "Invoices and Reimbursement Examples"!

Invoice vs. Reimbursement: What's the Difference?

Invoice: Use an invoice when you're getting paid for work (like coding, designing, or contributing to the community). An invoice should include:

• Description of services provided

• Timeframe of work, such as "February 2023,"" Q1 2023," or "5 hours in September 2023"

• Total amount due

• Payment details (e.g., bank account, PayPal)

Example: If you've spent 10 hours coding a new feature, you will submit an invoice detailing your hourly rate and the total amount for those hours.

Reimbursement: Use this when you're getting paid back for expenses you’ve already incurred on behalf of the project (like purchasing software, hosting services, or equipment).

Reimbursements require Receipts showing:

• Vendor’s name (who you paid)

• Transaction date

• Description of the item or service

• Amount paid

• Currency and form of payment (cash, credit, etc.)

• Name of the hosted project or payee who made the purchase

Example: If you bought a domain name for the project, you'd submit a reimbursement request with the receipt containing your name or the hosted project's name.

Examples

Reimbursements

Receipts are required so that we can ensure the requested amount matches the purchased amount. A valid receipt needs to be issued by the vendor and contains:

1. The name of the vendor (person or company you paid)

2. Transaction date (when you paid)

3. A detailed description of goods or services purchased (what you bought)

4. Amount paid

5. The currency in question. This is usually clear from the address and the currency symbol.

6. Form of payment (cash, check, or last four digits of the credit card)

7. The name of the payee or hosted project.

When uploading the receipt into Open Collective, the date, currency, and amount given must match the receipt exactly. The name of the vendor or detailed description should also be generally clear.

Invoices

1. Must include a detailed description of the work completed. This part is very important. Our accountants and auditors check records so make your descriptions easy to understand and concise. Instead of writing "maintenance" or "support," specify what you are maintaining or supporting. Using words like "work" or "payment" is too vague.

2. If attaching a .pdf invoice that requires an address, the invoice should be made out to OSC: Open Source Collective 440 N. Barranca Ave #3939

   Covina, CA 91723

3. For any invoice over $5,000 USD: the payee can’t be the one who approved the expense (unless they are the sole admin), and; payments must be made by electronic bank transfer via Wise, not PayPal

Invoice Examples

You can include the details of the work done in the description field of each line item.

You can create one invoice for the total and attach your own invoice or time tracker to detail the work done. You do not need to attach your own invoice or time tracker for OSC, unless your collective requires it.

Another thing you could do is note something like: "Maintenance on core for the month of April, 2023." Here are examples of attachments:

Grants, Awards or Donations

Grants, awards, and donations should be used to reflect "gifts". Gifts can be given when there is no expectation of work to be performed on the project. However, we need an example of how this gift benefits the community. A URL to the award announcement or link to a discussion on your forums/discord is sufficient.

Example: 'Aosus writing contest' award announcement

Expense Basics

• OSC will only process payouts approved by an admin of the collective.

• OSC doesn't pay future expenses, such as invoices for work scheduled in the future. For instance, an invoice can only be paid for work completed before the expense submission.

• If a vendor requires partial payment to reserve their services, you must submit a written invoice from the vendor containing information about the reservation and partial payment.

• Expense submitter must have their "Legal Name" in their profile info setting.

• Payouts must be broken down into individual expenses that detail the money spent. We do not pay out undifferentiated chunks of money and can not issue funds for future expenses.

• All expenditures must be permitted under 501(c)(6) regulations and adhere to our mission statement: 'To promote a sustainable and healthy ecosystem that will sustain open source technology for the future.'

• We cannot process payments for expenses incurred before Open Source Collective started hosting the collective.

• Due to IRS regulations, we may need to collect W9 forms before we can pay someone. If this applies to you, we will let you know.

• If your collective also has an LLC related to the open source project, you can not use donated funds for any expense related to the LLC and we can not transfer donated funds to the LLC.

Permitted Countries, OFAC Checks, and Payments to Certain Countries

• OSC cannot pay people in territories in the following sanctioned countries: Crimea, Cuba, Iran, North Korea, Sudan, Syrian Arab Republic, and Venezuela.

• In addition, we may be unable to pay people in Afghanistan, Burundi, the Central African Republic, Chad, the Congo Republic, the Democratic Republic of the Congo, Eritrea, Iraq, Libya, Somalia, the Republic of South Sudan, and Yemen.

• We may have issues processing payments to some countries because Wise, our payment processor, doesn't support all countries. If your bank or country is not supported by Wise or PayPal, we cannot guarantee payment. The list of countries can be found on this website: https://wise.com/help/articles/2571942/what-countriesregions-can-i-send-to. Note that some banks that Wise can send to may require assistance from intermediary banks, which may result in additional charges. We have no control over these charges, as they are determined by the payment processors.

• Due to the high fees charged by banks, sending payments to certain countries, such as Nigeria, may be difficult. Unfortunately, we have no control over this. If you are based in Nigeria, please be aware that you must have a minimum balance of over $30 for payouts, as the fees are typically more than $15. Please be aware that there may be instances where the fees are higher than the actual payouts you receive.

Methods of Payment

• The payment method must be owned by the person submitting a claim to be paid.

• OSC only makes expense payments via PayPal and bank transfers.

  • We can't make direct payments via Cash App, Venmo, and similar services (because they don't allow nonprofits like OSC to sign up, among other reasons).

• Collectives can use OSC-issued virtual cards for expenses (more info here).

PayPal Limits

• We limit PayPal expense payments to a maximum of $5,000 USD. For expenses larger than $5,000 USD, payments must be made by electronic bank transfer via Wise. This allows us to prevent potential risks and protect our community and its financial assets.

Paying Upwork, Fiverr, or Kofi contractors

You can create a reimbursement or use a Virtual Card to pay for these services if it is easier. Fiverr, Kofi, and Upwork all issue a 1099 for their contractors/users.

Reimbursing shipping, duty, or import fees

For any payment reimbursing costs related to import or duty fees, please also include a receipt for the package/item related to the shipping fee. We need to see that the shipping expense was related to a purchase/cost directly associated with your hosted project for tax purposes.

Outstanding or Incomplete Expenses

The responsibility for ensuring payment completions lies with the collective and/or payee. In case of a payment error

• OSC will notify the collective and payee by commenting on the expense ticket and marking the ticket as 'incomplete.'

• Should payment still be required once the expense is marked as 'incomplete,' the collective and/or payee should edit the expense accordingly.

• If the collective and/or payee fails to respond and rectify the issue within 30 days, OSC will proceed to close the expense request. If payment is still required, the submitter should resubmit the expense request.

By declining unresolved expense requests after 30 days, OSC can avoid having many unresolved tickets pile up. This will help the OSC team avoid confusion, inaccurate financial reporting, and potential budgetary complications.

At the end of the year, OSC will make one final attempt to reach out and confirm the necessity of the payment. The expense will be closed if no response is received within 30 days.

We receive funds for which the intended recipient can not be identified. When this happens, we put the funds in a 'holding' account (here).

If you sent a payment but don't see it registered on the platform,

Check the holding account (here) to see if one of the transactions matches the amount you expected to receive. If you find one that matches your donation, please contact us at hello@oscollective.org.

To transfer the funds, we will need the following:

• The name and email address of the person who made the bank transfer

• With this person, we will confirm the date of their transfer and the last few digits of the bank account number that sent the funds

Once verified, we will move the funds from the OSC holding account into the collective's account.

If we received a GitHub payout on your behalf

Please contact us at hello@oscollective.org and send us your GitHub profile. We might need to follow up with a few questions, but once resolved, we will send an expense request via the platform to transfer the funds to your bank or PayPal account.

How to give

There are many ways you (or your company) can support open source projects hosted by Open Source Collective:

• Credit Card, PayPal, or Bank Transfer

• Purchase Orders and Procurement

• Invoices (For Companies and Institutions)

• Crypto

• Stocks

• Funds

• Company-issued gift cards

• GitHub Sponsors

On behalf of our collectives, thank you for your support! We value all of our contributors. If there is anything you need as a donor, please reach out.

Credit Card, PayPal, or Bank Transfer

To contribute to an initiative online on the Open Collective platform via Credit Card, PayPal, or Bank Transfer (a.k.a. ACH or wire transfer), please see this overview of the process.

Once you choose to contribute from the collective’s profile, our platform will guide you through the rest of the process, including choosing between credit card, PayPal, and electronic bank transfer via ACH (US banks only) or wire.

Bank Transfers

If you select to make a contribution via bank transfer, you will automatically be given bank transfer instructions, on-screen and by email, along with a unique reference ID code.

You must include the unique ID code as a reference with your bank transfer, so we can match up the transaction.

Once the money has arrived, we will credit the amount to the initiative’s balance and you will automatically receive a receipt.‌

When you arrange the transfer, if you have the option of sending an email notification for the transaction, please use our email.

Invoicing (For Companies and Institutions)

Sometimes companies need to receive an invoice before they can make a financial contribution. This is primarily done only for amounts >$1000. If a potential donor cannot donate directly through the project's Open Collective page and needs an invoice, please contact us at hello@oscollective.org. We handle invoice creation using Quickbooks.

In your email, please include:

• Link to Collective's page

• Donor company name and email address

• Preferred date for the invoice, if if should be issued in the future

• Description of the service the project is providing

• Donation amount, in USD

• Any specific Purchase Order (PO) number that needs to be on the invoice

• Any other specific instructions

Unless a different agreement is made, our standard payment term for invoices is 30 days.

After the invoice is paid, it typically takes a few days for the payment to appear. As soon as our team confirms the payment has been received, we will direct the funds to your collective.

Crypto

On May 19, 2023, we disabled our automated crypto donation functionality because we received a donation from a sanctioned country. You can read the announcement here. Because of this incident,

• We are changing our donation procedures and collecting personal information from the person making the crypto donation to follow KYC and AML procedures.

• We will only accept crypto donations in amounts equal to or over $2,500.

If you want to donate or accept a crypto donation, we will accept it on your behalf, convert it to fiat (USD), and attribute the balance to a hosted collective.

To initiate this process, please fill in this form with the donor's information (including full legal name, place of birth, date of birth, and current address), and we will reach out regarding the next steps.

Giving Anonymously

If you would like your contribution to be partially or fully anonymous, see our incognito and guest contributions documentation.

Secure Contributions

Open Source Collective doesn't store donor credit card numbers on our servers. Instead, we partner with Stripe, a secure solution that is widely adopted by the industry, to process one-time and recurring contributions.

Donations By Check

Open Source Collective does not accept check donations.

Fees

Open Source Collective charges our hosted Collectives a fixed 10% fee on all contributions received in return for our fiscal hosting services.

Read more about our fees.

Policy & Actions

If we notice an abnormally large amount of disputed/flagged donations to a collective, we will do one or more of the following actions:

• Freeze contributions to the collective and suspend any expenses.

• Investigate all donations and return any flagged or disputed within our refund window.

• Follow up with the collective admins to implement additional security checks on donations and expenses until the percentage of fraudulent charges decreases.

Open Source Collective is a 501c6 non-profit, registered in California. We offer a range of options for companies to make and manage contributions on the Open Collective platform.

We are a registered service provider to many companies including:

Microsoft, Google, Amazon, Meta (nee Facebook), Salesforce, Adobe, Stripe, Samsung, AirBnB, Shopify, Etsy, Indeed, Coinbase, Cloudflare, and O'Reilly Media.

How it works

We'll work with you to establish the best vehicle for you and your organization, for instance setting up a Fund, issuing employee gift cards, or simply making a large, one-off donation. Then:

• Open Source Collective will register as a provider to your organization including signing any necessary agreements. We also have template agreements of our own and experienced legal counsel to review yours.

• Your procurement team may generate a purchase order.

• We'll issue an invoice to your organization.

• When the invoice is paid we will distribute the funds as agreed.

Fees

Open Source Collective charges a fixed 10% fee on all contributions received on the initial deposit. i.e. we do not charge an additional 10% to Collectives when donation distributions are made.

Read more about our fees.

What is a Fund?

A Fund is a specific type of profile created under OSC for the purpose of moving money frictionlessly to multiple open source projects. Some Funds are created on behalf of a particular company while others are focused on a topic.

Here are examples:

• Google's Open Source CMS Fund

• General Google Open Source Fund

• Airbnb Fund

• Indeed Fund

• Facebook Open Source Fund

• Igalia’s Open Prioritization Fund

Why should I create a Fund?

If your organization has multiple funding programs, you want a strong identity for your funding program, or you want to simplify the invoicing process around funding open source projects - Funds are for you.

Simplify invoicing

Instead of managing multiple invoices/POs for donations to multiple projects or even to one project over multiple months, you can request one invoice to cover all your funding needs and hold the balance in your account on Open Collective.

Your money, on-demand

You decide when and how to support projects with your fund, we handle the payments, accounting, and legal processes.

You can even use the balance in your fund to contribute to projects that are not hosted on the Open Collective platform by inviting a third party to submit an expense!

Creating a Fund

If your company wants to set up a Fund, please get in touch.

Contributing using a Fund

Funds appear as a source for any administrator when making a one-off or recurring contribution to a project on Open Collective. Select the Fund during the 'contribute as' step:

Read more about contributing to projects.

Invoices and Reimbursements

Individuals and projects can request payments direct from a fund. Reqeustors provide receipts or invoices that are passed to Fund administrators for approval.

Read more about expenses and invoices.

Grants

Funds come with some lightweight 'grantmaking' features:

Projects and individuals can request a grant directly from a Fund's profile page. We invite the requestor to provide a description of their activities and upload any supporting documentation. This information is passed to the Fund's administrators for approval.

Fees

Open Source Collective charges a fixed 10% fee on all contributions received into the platform.

For funds, this means the 10% host fee is collected when a deposit is made into the fund. This is different from a user account where the 10% fee is collected when the donation is made to the open source project and comes out of the donation amount. This fee is only collected once so donations from a fund to a collective do not incur additional fees.

Read more about our fees.

For Financial Contributors

Tax-deductible status

For Admins of Collectives

OSC collects all the necessary tax information from financial contributors and payees (W8 or W9 forms). We file taxes and issue 1099s on behalf of all our hosted projects.

You can accept grants as a fiscally-sponsored project with OSC as your host organization. Before you apply for a grant, make sure they can give grant funding to organizations that are 501c6 (mutual-benefit nonprofit). Some grants can only be awarded to nonprofits that are 501c3 (public-benefit nonprofit).

For Payees from Collectives

Tax forms we require

If you submit invoice expenses totaling $600 USD or more per year, you will need to provide us your W9 (for US persons) or W8-BEN/E (for non-US persons) form. Receipt reimbursements don't count toward the $600 limit, only invoices.

When you submit an invoice that puts you over the $600 threshold, you will be sent an email with a link to complete your tax form online. This email will come from Dropbox Forms and say "Open Collective sent you a request via Dropbox Forms".

Reporting income from OSC

For tax purposes, you will be treated as an independent contractor, and if you are a US citizen or a dual citizen of the US, you will be issued a 1099 if your earnings from OSC exceed $600 in a year. Here is a good explanation of how W9s work for independent contractors, and there's more info on what a 1099 is here.

If you don’t meet the $600 threshold, report your earnings as miscellaneous self-employment income when you file your taxes.

If you are not a US person, we will only keep your information on file, and it's up to you to meet any tax reporting obligations in your country.

Open Source Collective collects a 10% fee on incoming funds. This is in addition to processor fees that are collected by payment providers.

Why do you charge a fee?

To ensure that our services are sustainable and continuously improving, we charge a Host Fee on funds contributed to the initiatives we host. Charging fees like this is standard in the fiscal sponsorship world.

There are no setup fees, balance minimums, monthly or annual fees, or any other charges. Besides the Host Fee, the only other fees you'll see are payment processor fees charged by Stripe, PayPal, Wise, or other third-party services you may opt to pay through.

How do the fees compare?

The standard fee for fiscal sponsorship is 5%-15%. Different fiscal sponsors offer different services so it can be hard to directly compare, but we think our rates are quite a good value for the service we offer.

Some people compare our fees with crowdfunding sites which tend to charge 0%-5%. These services do not provide fiscal hosting, support for ongoing & recurring donations, or budget transparency. Read more about what OCF offers as a fiscal host.

What do we use fees for?

A lot of our work is behind the scenes, so to understand why we have to charge fees, it might be useful to know what we do:

Our small team reviews applications, reviews and pays expense requests, responds to your questions and feedback, handles partnerships with funders, manages corporate procurement processes, and signs contracts.

We work to support our community: writing the blog and newsletter, maintaining this documentation, hosting community events, running funding campaigns, and providing opportunities for projects to offer and engage the services of specialists. We’ve played a significant role in developing the broader community and tackling the shared challenge of sustaining open source software.

Finally, we are active contributors to the Open Collective platform continuously improving our features and services so that it can do even more for hosted projects!

Our staff are our primary cost, but we also use our revenue to pay for:

• OSC shares our revenue with Open Collective, which makes the software platform that enables everything we do. We have a close partnership so that the platform can continue to evolve.

• Professional services, such as lawyers, accountants, and developers. There are a lot of legal, financial, and technical tasks and responsibilities involved in running OSC.

• Compliance is an important part of being a fiscal sponsor. It's our job to ensure that all money is used legitimately to forward the goals of each Collective, and that our Collectives align with our mission. There are a lot of regulations and laws we have to follow. We have to file taxes with the IRS and respond to audits.

• There are also operational costs like software subscriptions, office expenses, maintaining our website, etc.

Wondering how Open Source Collective’s funds are used? We also use the Open Collective platform, so you can see our transparent budget for yourself.

Can we have a discount?

Unfortunately, we are not able to provide any discounts on fees. As you can see from the above, providing fiscal sponsorship services to thousands of open source projects is no small task, at every stage of the process. We are more than just a payment platform! Our standard fees are already as lean as we can make them given our very real costs. As we seek to build new tools and programs in support of the open source ecosystem’s long term sustainability, we need to keep OSC healthy and vibrant.

As a nonprofit fiscal host, it's important to distinguish between the types of funds we manage on behalf of our hosted Collectives. In this document, we'll review two types of funding: Contributions/Donations and Payments/Funds from Customers/Contract-based Funding

Contributions/Donations

Contributions, or donations, are funds provided by individuals or organizations to support the mission and activities of a project. These funds are managed by OSC with the following key principles in mind:

• No goods or services are exchanged for the contribution

• Contributions are intended to benefit the broader mission and activities of the project, rather than a specific individual or customer

• Refunds are generally not applicable, as contributions are not payments for specific deliverables or services

In alignment with nonprofit principles, contributions fuel mission-driven work that benefits the open source community as a whole, rather than payments tied to transactional agreements.

Payments/Funds from Customers/Contract-based Funding

Business payments, or contract-based funding, on the other hand, involve a transactional exchange. These funds often arise when a hosted project engages in activities that directly benefit a customer or client (in some cases, though, they might also come from a grant, which may have a broader scope and have a larger impact base). These payments typically involve:

• Providing goods or services or engaging in work that results in specific deliverables

• Formalized agreements

An example of this could include grants, which OSC can assist with. These often require a signed agreement to ensure accountability for certain deliverables. While OSC, as a nonprofit, does not have a 'No Outside Money' policy, we ensure that any expenses that we process are ultimately used to benefit the open source side of the project, adhering to our nonprofit mission.

Why this Matters

As a nonprofit in open source, transparency, compliance with nonprofit regulations, and trust with the community is of the utmost importance to us. Contributions drive collective impact and align with our mission to advance the open source ecosystem. While business payments can also assist with that, it also requires hosted projects to fulfill specific contractual obligations or client needs that OSC can only assist with in certain capacities.

Understanding this difference ensures that all funds are managed by OSC and our projects responsibly.

Open Source Collective projects can use Open Collective to receive financial support through GitHub Sponsors.

Supporting a project through GitHub Sponsors

GitHub and Open Collective work together to ensure that any project registered on GitHub Sponsors, that uses Open Collective to manage its money, will receive that money automatically on a monthly basis.

Simply sponsor the project on GitHub, and we'll do the rest.

Registering your Collective with GitHub Sponsors

To register your project for GitHub Sponsors you will need:

• A GitHub organization (not an individual user account) that hosts your repository/repositories on GitHub. You can create a GitHub organization by following this guide.

• A Collective on the Open Collective platform for your open source project. You will need to use Open Source Collective as your fiscal host. Read more about applying to OSC here.

To register for GitHub Sponsors follow these steps:

• Visit github.com/sponsors and sign your Github organization up for the Sponsors waitlist: - Select: "This organization is using a fiscal host" and select Open Source Collective from the menu. - Add your Collective's URL to the 'Fiscal host project profile URL' box for example: https://opencollective.com/babel

• Click Join Waitlist.

GitHub staff will review your application, and you'll be notified when you can proceed to the next step.

Receiving Financial Contributions

GitHub processes payments to GitHub Sponsors participants on a monthly basis. We allocate these payments when we receive them, typically at the end of the calendar month.

If you have not received a payment that you expected by the end of the month please contact our support team.

Frequently Asked Questions

When will we receive our contributions from GitHub Sponsors?

We process payouts from GitHub on a monthly basis, typically at the end of the calendar month or 1st week of the following month.

What fees will be charged?

The standard Open Collective and Open Source Collective fees apply to funds raised via GitHub Sponsors: 10%. GitHub does not charge a fee.

Should I create an Organization or a Collective?

Confusingly, GitHub and Open Collective use the word "organization" to mean two different things.

• On GitHub, you need to create an Organization to use Sponsors for your project.

• On Open Collective, you need to create a Collective for your project.

  • Organizations on Open Collective are a different profile type, for companies who sponsor open source projects, i.e. designed for paying money out, not accepting money like Collectives.

Supporting a project through Drips

Open Source Collective work with our member projects to ensure that any project registered on Drips, that uses Open Collective to manage its money, will receive that money automatically on a periodic basis.

Simply sponsor the project on Drips, and we'll do the rest.

Claiming your Collective with Drips

Open Source Collective can Claim a project on your behalf. Before requesting we claim a project you will need:

• A GitHub organization (not an individual user account) that hosts your repository/repositories on GitHub. You can create a GitHub organization by following this guide.

• A Collective on the Open Collective platform for your open source project. You will need to use Open Source Collective as your fiscal host. Read more about applying to OSC here.

• Commit access to the corresponding code repository.

• Optional: A hardware or software wallet that supports the Ethereum network.

During our onboarding process, we will:

• Provide a quick overview of how Drips works.

• Determine whether you would like to use a multi-signature wallet, or have Open Source Collective generate and own a wallet for your project.

• Decide on an amount to send to your Collective, to other maintainers directly and to other projects.

Using Drips with a Safe Wallet

Drips can be used through a multi-signature Safe wallet in much the same way Drips is used with an individual wallet. Transactions are 'proposed' to the Safe Wallet for signing by the Drips application, and executed once the threshold has been reached and execution costs paid.

Read more about using Drips with a Safe Wallet here.

Receiving Financial Contributions

Drips facilitates the constant stream of any ERC-20 token to any number of projects, represented by a GitHub repository. Open Source Collective initiates the collection of allocated funds on a periodic basis (typically monthly) based on the amounts received in order to reduce transaction costs.

Funds will be added to the Collectives' balance, minus our 10% administration fee, on a periodic basis. Drips will be indicated as the source of the funds. A project administrator may be required to sign the document containing the funds collected from Drips.

Frequently Asked Questions

When will we receive our contributions from Drips?

We will request funds from Drips on a periodic basis that works best for your project, typically on a monthly basis.

What fees will be charged?

A standard 10% hosting fee applies on funds credited to your Collective.

Gas fees will be due on transactions written to the Ethereum blockchain; this includes claiming a project on Drips, modifying splits, and collecting funds. Open Source Collective will pay for and charge these costs as needed.

Filling in the '2024 Google Summer of Code Organization Payment Request Form'

If you plan on participating in Google Summer of Code, please use the following information when answering the form's questions to ensure accurate invoicing and processing of payments. On the first page of the form:

• The email address of the person responsible for accepting payment at your Organization is -- hello@oscollective.org

• Does your Mentor Organization have an account with Payoneer and linked to the GSoC Program? -- Select the 'Yes' checkbox.

On the second page of the form:

• What is the EXACT name of your account in the Payoneer system? -- Open Source Collective 501 c 6

• What is the email address associated with this Payoneer account? -- hello@oscollective.org

• If you are accepting funds for several orgs, have Linux Foundation, NumFOCUS, Open Collective, Software Freedom Conservancy, Software in the Public Interest, or another fiscal sponsor, please note it here. -- Open Source Collective

Once you have completed the form, send us an email at 'hello@oscollective.org' to confirm you will be participating and we can better track the payment associated with your organization.

Please reach out with any questions to 'hello@oscollective.org'

If Your project has been accepted by the Google Season of Docs program join us!

If your project has no legal status and bank account or is not fiscally hosted by any organization.

• We recommend applying to Open Source Collective if your Open Source project is going to participate in the Season of Docs program and doesn't have a legal status. Being fiscally hosted by Open Source Collective, you don't need to have a bank account, and as the fiscal host manages everything on behalf of your project and you can use the Open Collective platform to receive the grant money and pay the technical writers and volunteers.

Steps to create a collective profile and apply to OSC.

1. First, you need to create a personal account. Visit at https://opencollective.com/create-account to create a personal account.

2. Once you have the personal account set up, you will be able to create a Collective profile for your project. Visit the guide to create a collective profile at https://docs.opencollective.com/help/collectives/create-collective.

3. Apply to Open Source Collective at https://opencollective.com/opensource/apply. (add a note that your project has been accepted by the Season of docs program)

Your project has a fiscal host or a bank account.

• If your project already has a fiscal host or a legal entity, you may not need to apply to OSC instead, you can create a collective profile if your project doesn't have one at the Open Collective platform https://docs.opencollective.com/help/collectives/create-collective

You are participating as a Technical Writer or Volunteer.

1. Create an Open Collective profile at https://opencollective.com/create-account. If you don't have an account on the Open Collective platform yet.

2. Visit the Season of docs guide on how to receive the grant and reach out to your project administrator, who will guide you on how to submit an expense and receive your stipend.

Frequently Asked Questions (FAQs):

1. Are there any fees to receive a grant from Season of Docs if our projects are fiscally hosted by Open Source Collective?

Ans. No fees for transferring funds to your collective profile if your project is hosted by Open Source Collective (OSC) for the Season of Docs program. Minimal expense processing charges for paying technical writers, volunteers, or maintainers from the collective. Check our docs for more on fees and contact us.

2. How do I contact Open Source Collective if I have any questions related to fiscal hosting and expenses? Ans. Please reach out to hello@oscollective.org, we will get back to you shortly.

3. How to contact the Open Collective platform if I have any account-related issues?

Ans. Please reach out to support@opencollective.com, and the Open Collective team will be able to help you with your profile, and account-related issues.

4. I have queries related to Google Season of docs programs and grants.

Ans. If you have any questions or concerns related to grants or the program, please contact the Season of Docs team.

If you have an existing Polar account and your open source project is already hosted by Open Source Collective, you can follow the Polar guide: https://docs.polar.sh/finance/accounts to receive the payout to your Open Collective profile (If your project is fiscally hosted by Open Source Collective)

Polar donations are processed periodically or on a monthly/quarterly basis. We can't accept donations if your project is not hosted by us. You can apply to Open Source Collective here.

Please get in touch with our support at hello@oscollective.org with your collective name/URL.

Open Source Collective is a 501c6 nonprofit working for the common interests of those who create and use open-source software. As a nonprofit fiscal host (a.k.a. fiscal sponsor or foundation), we provide the financial and legal infrastructure for thousands of open source projects. We’re the ‘API' between the world of open source communities and the world of accounting and invoices.

How we Think

People are more important than code

Open source software is a byproduct of active communities working toward a common goal. We prioritize the needs of people first.

One size does not fit all

Open Source Collective does not impose a structure, a process, or a statute on you and your community.

Strength lies in community

That said, we do believe that strength comes from broad and diverse community-centered approaches. We encourage members to think about distributing their responsibilities and building communities.

Solving problems together

We believe that we can address many of the problems we face by working together. Where possible, we try to solve problems from within and we try to benefit all members in our approaches.

Who we're for

For Maintainers

We take care of all the accounting, taxes, invoices, and administration. You decide where the money gets spent, then we make it happen.

Through us you can:

• Manage your open source project’s funds transparently.

• Receive financial contributions by credit card, PayPal, electronic bank transfer, or crypto (beta).

• Receive funds through GitHub Sponsors.

• Receive funds from corporate supporters (we’re registered as a supplier to many corporate sponsors).

• Register trademarks, sign contracts and legal agreements and apply for grants.

• Pay yourself, your team, contractors, vendors, and suppliers.

• And much more...

Financial Contributors and Sponsors

Support the open source projects you rely on. See how projects are using their finances, engage with and stay up to date with progress, and get recognition for your contributions.

Through us you can:

• Manage all your open source support in a single place, with Open Source Collective acting as a single ‘supplier’ to your organization

• Support projects instantly on a one-time or recurring basis using a credit card, PayPal, or electronic bank transfer

• Hold funds with us to cover your contributions throughout the year

• Issue gift cards to your staff, which they can then use to contribute on behalf of your organization

How we're organised

Open Source Collective is a non-profit 501(c)(6) mutual benefit organisation.

Our board of directors provide insight into the impact of our work and keep our goals aligned with those of our community:

Board of Directors

Our board of directors are:

• Pia Mancini, Open Collective

• Samson Goddy, Open Source Community Africa

• Henry Zhu, Babel

• Benjamin Nickolls, Octobox

• Justin Dorfman, Bootstrap CDN

• Duanne O'Brian, Indeed Open Source

• Alyssa Wright, Bloomberg Open Source

The board selects an Executive Director who has the authority to execute agreements and is tasked with delivering on the mission of the organization.

Executive Director

Our Executive Director is Lauren Gardner

Our Strategy

In January 2022 we published our strategy which included three strategic goals:

Taking an ecosystem-wide approach to supporting open source software Enabling projects to use their money as well as raise it Make financially contributing to open source not only a good business decision, but an easy one

We continue to iterate on our strategy, and we welcome feedback on our work, see contact details below.

Contact Us

Didn’t find what you are looking for? 🔍 Use the Search Bar in the upper right corner!

📧 Request support at hello@oscollective.org

💬 Join our Slack and find us in the #opensource channel

🐦 Follow us on Twitter, Mastodon, YouTube, and LinkedIn.

📍 Our mailing address & Other Important Docs

Nonprofit Status

We are a registered 501(c)(6) non-profit in the United States, meaning our income is not used for private or shareholder benefit. Our resources, such as the fees we collect, are all invested back into our mission: to promote a sustainable and healthy open source ecosystem. Donations to OSC are not tax deductible.

Tax ID & W9

You may provide this information to anyone who asks for it (sometimes sponsors or grantmakers will request it).

Our EIN (tax ID number) is: 82-2037583

Our DUNS number is: 105389379

OSC’s NAICS code is 813910

Address & Contact Info

Open Source Collective 501(c)(6) 440 N. Barranca Avenue, #3939 Covina, CA 91723

hello@oscollective.org

phone: ‪(802) 695-0005‬

Banking Info

All transactions should be set up on Open Collective wherever possible. If someone makes a contribution and selects 'bank transfer' as the payment method, they will automatically receive these details. However, if you need our banking info, please contact us directly at hello@oscollective.org.

However, if you need our banking information to initiate a transfer, please contact us at hello@oscollective.org.

If you are expecting payments outside the platform to arrive, these are not automated, so you must inform us so we can find and credit your funds.

Anti Money-Laundering (AML) Policy

Our Anti-Money Laundering Policy prohibits and aims to actively prevent money laundering and any activity that facilitates money laundering or the funding of terrorist or criminal activities under United States law by complying with the legal requirements of the U.S. Bank Secrecy Act (BSA) and its implementing regulations. Our AML Policy, procedures and internal controls are designed to ensure compliance with all applicable BSA regulations and FINRA rules and will be reviewed and updated on a regular basis.

Lauren Gardner - she/her, Executive Director

Benjamin Nickolls (aka BenJam) - he/him, Head of Strategy

Sourav Das - he/him, Operations Coordinator

Grace Powers - she/her, Operations Coordinator

Our Board of Directors

Pia Mancini

Alyssa Wright

Justin Dorfman

Samson Goddy

Duane O'Brien

Joel Wasserman

Color #4a2f79

If you need to refer or link to Open Source Collective, please direct links to https://oscollective.org and feel free to use the below images.

Learning & Reading

🔍 Use the Search Bar in the upper right corner to find detailed information about specific topics

💬 Join our Slack to get in touch with the entire Open Collective community (& join in the #opensource channel)

🌱 Read the latest Updates from OSC on our page and on the Open Collective Blog

🐦Follow us on Twitter, Youtube, and Linkedin

📍 Our mailing address & Other Important Docs

Talking to a Person

💌 Email any OSC-specific questions to hello@oscollective.org

🎟 Request platform support here

💬 Join our Slack to get in touch with the entire Open Collective community (& join in the #opensource channel)

Reporting an Issue

👩‍💻 Open Collective on GitHub to file an issue or see what we are working on

💾 Open Source Collective on GitHub to learn more about us

How can I contact Open Source Collective? Where can I go with questions or concerns?

Email us at hello@oscollective.org. We answer Monday-Friday and strive to respond within 3 business days. If you are having issues with the platform, feel free to check out our help page.

You can also join our Slack to get in touch with the entire Open Collective community. Check in at the #opensource channel.

What is the difference between Open Collective and Open Source Collective?

Open Collective (OC) is the software platform, which is made by a company called Open Collective Inc.

Open Source Collective (OSC) is a separate 501(c)(6) entity that uses the OC platform to provide fiscal hosting services.

The two entities are legally completely separate, but share some of the same staff members and community guidelines.

What is the difference between fiscal hosting and fiscal sponsorship?

These two terms mean the same thing. See our Fiscal Hosting page for a detailed description.

What are your fees? Why do you charge a fee?

Our fees are 10% plus any payment processing fees. You can check our transparent budget to see where the money goes!

How does paying people from my collective work?

Payees should go to the collective page and submit an expense: either a reimbursement (with receipt) or invoice (for goods or services). A payee can receive payment via bank transfer (through Wise, f.k.a. TransferWise) or Paypal. A collective admin must then approve the expense, and then an OSC admin will process the payment. See how to submit an expense here. Collective admin can also invite payees to submit an expense.

When are payments processed?

Approved expenses are paid out by OSC twice a week, on Mondays and Thursdays, US time. If there are any issues with the payment or you can expect delays, an OSC admin will comment below the expense and you will receive an email about it (note comments are private to admins and payees). Generally approved expenses take less than a week to be paid out and to hit your account, but could be more if there are issues or the payment processor takes longer.

How can people donate to my collective?

To support, donors should go to the Collective page of the project they want to support, select a contribution tier, and set up their donation. Individuals and organizations can contribute to your collective in a variety of ways, including by credit card, bank transfer, and, if the collective has opted in, cryptocurrency. They can contribute on a one-time or a recurring basis, and you can incentivize different tiers of giving, or raise money towards specific Projects.

Will our application be approved?

If your group is legitimate and meets all of the acceptance criteria, and has no conflict with the Terms of our program, you can expect to be approved. We will follow up with you via email if we have any questions or concerns about your application. You can expect a response within a week, and you’re welcome to follow up if you haven’t heard from us at hello@oscollective.org.

How do I close my collective?

First, review the checklist below and note any tasks relevant to your collective.

• Verify all associated expenses with your project have been submitted, approved, and processed for payment.

• If you have virtual cards, change your card information on any outside services with payment information saved. Virtual cards associated with your collective will be deactivated once you are unhosted.

• OSC may need to hold back funds if you have any outstanding contracts with unbilled amounts or non-transferable grants.

• If OSC holds domains or trademarks on behalf of your project, please make a complete list of all assets that should be transferred.

• If OSC employs maintainers on your project's behalf, please get in touch with hello@oscollective.org to ensure we have enough time to transition the employee.

• Notify funders with recurring sponsorships or any institution that has provided grants. Inform them if you are shutting down the project or where you are moving to.

Closing and Archiving a Collective

You will need to do the following before you can close your collective.

1. Zero out the balance (more info here). Continue to pay invoices or reimbursements, transfer the funds to your new fiscal host, or donate the remainder to another nonprofit.

2. Publish a public update on the collective's page in the 'About' or 'Conversations' area to indicate the status change of the collective and where people can continue to support your project.

3. Let donors know they should cancel recurring contributions on the Open Collective platform. This can be done through public messages, or you can download the email addresses of your donors through the admin dashboard.

4. If you wish to close out with OSC, but still want to use the Open Collective platform to manage your collective's funds, you can also become an independent collective.

Switching Fiscal Hosts

Before we can initiate the transfer, we will need you to answer the following questions:

• Name and URL of collective

• Name of the nonprofit entity acting as fiscal host

• Country and/or State of registration of the nonprofit entity

• Assets that need to be transferred e.g. monetary funds, trademarks, domains, employees

• Full name and email address of the signatory for the collective

• Full name and email address of the signatory for the new fiscal host

• A copy of the new fiscal host's non-profit determination letter

  • If they are registered outside of the US, please send an equivalent letter from the country of registration

How do I cancel recurring donations/subscriptions/payments?

See our instructions on how to cancel recurring or ongoing donations, subscriptions, payments, etc., here.

What if a contributor wants their contribution to be anonymous?

Contributors can make an anonymous payment by choosing incognito when picking a profile to pay from. If the contributor contributes as a guest, then the given name will still show up, the contributor then just won’t have to log in to make the payment. All Open Collective users can also differentiate a public display name from their private legal name.

What if a financial contributor is unable or not comfortable with submitting their credit card information online?

If a donor is not comfortable with online credit card transactions, they can send the funds via PayPal or bank transfer.

Someone said they sent my collective money but I don’t see it in my account! Help?

~or~

I sent in money but I don't see my donation on the collective's page?!

Ping us! We often receive money in our bank account without any indication of where it should go. (This is why it's so important to include the order# in the bank transfer).

At the end of the month, unidentified funds are moved to a holding fund. We keep the money there until we can identify who it is intended for and then we transfer it.

Just send us a message (via Slack or email) with screenshots/receipts that include the dollar amount, the collective name, and the sender/any info about the bank transfer, so that we can send the funds to their happy home.

What if a financial contributor requests an invoice before making the donation?

Reach out to us at hello@oscollective.org. We are happy to procure an invoice of this kind when requested. Please provide: Donor name, Email, Collective Name, & Donation amount (+ screenshots/links if applicable) for context.

Can we accept tax-deductible or charitable funds from things like Benevity?

No, Open Source Collective is a 501c6 nonprofit (for member benefit). Benevity earmarks its funds for 501c3 nonprofits that use their funds for public benefit.

Can we use outside fundraising platforms to fundraise for our collective?

We recommend using Open Collective as much as possible so that you can manage your budget in one place, but you may use other platforms to raise funds for your community. At this time, we can not accept payments from third-party platforms like Patreon, GoFundMe, Kofi, etc. directly. You would need to move this money into OSC manually. Reach out to us at hello@oscollective.org with any questions on how to do this.

Can we receive earned income (i.e., non-donations) or sell stuff through OSC?

Yup! You'll want to move funds into your budget in some way, however. Feel free to reach out to us to discuss the proper logistics for your situation.

Can we offer financial contributors something in return for their donation?

Yup! This can be done through the Tiers feature. You'll want to think in advance about the proper way to gather any information you need in order to fulfill your promises.

Can my group offer memberships/accept membership fees?

Check out Open Collective’s Tiers feature!

Can my collective donate to another hosted collective?

Collectives can easily give to other collectives hosted by Open Source Collective. (If you want to give to a collective with another fiscal host there are some extra steps.)

Expenses

What does the approval process look like for expenses?

Once expenses are submitted, they need to be approved by a collective admin. Approved expenses are paid out by OSC twice a week, on Tuesday and Thursday, US time. If there are any issues with the payment or you can expect delays, an OSC admin will comment below the expense and you will receive an email about it (note comments are private to admins and payees). Generally approved expenses take less than a week to be paid out and to hit your account, but could be more if there are issues or the payment processor takes longer. Please see Submitting Expenses for more information on how to submit an expense.

Please Note:

• We can only issue a reimbursement for the amount listed on the receipt.

• We can only issue a reimbursement for the amount paid with a card or cash. For example, if you use coupons or vouchers in addition to paying with a credit card, we can not reimburse you for the amount paid with a voucher or coupon.

• The name of the person or business being paid must match the name in the method of payment.

Do I have to use my real name?

We now have the option to differentiate between your public display name, and your private legal name.

We do need your real name as your legal name for our accounting records. This private legal name will only be visible to admins.

Is private information on expenses publicly viewable?

The expense amount and title will be listed on the Collective's public page, but any private information, attached files, comments, and payment details are only visible to admins of the collective and admins of OSC who will be reviewing the expense.

How can we pay for large expenses that we cannot pay out-of-pocket and then get reimbursed later?

For large expenses that you cannot pay out-of-pocket, you can have your vendors and service providers submit invoices directly via your collective's page, or you can use the "invite expense" option, where you fill in the details and they receive an email and then just need to confirm. Vendors can invoice OSC through your page to get paid, and then we pay them directly.

Can I issue payment using cryptocurrency, Venmo, or CashApp?

Not at this time. We only pay out expenses via bank transfer or PayPal.

Can I refund a donation or get a refund for one I have made?

As a nonprofit organization, Open Source Collective operates on the principle that donations are voluntary contributions made to support the mission and activities of the collectives we host. Refunds for donations are generally not applicable, as they are not payments for specific deliverables or services.

Refund Request Procedure

If you believe a refund is appropriate, you may submit a request to hello@oscollective.org with the following details:

1. Donation URL: Provide the full URL of the donation transaction (e.g., https://opencollective.com/opensource/expenses/123456).

2. Transaction Details: Include the date and amount of the transaction.

3. Authorization Confirmation: State whether the contribution was made with your authorization (i.e., confirm that it was not a fraudulent transaction).

Refund Considerations

Refund requests will be evaluated on a case-by-case basis. As stated above, refunds are generally not applicable. You can read more about this here.

We appreciate your understanding and support in helping us maintain the integrity and effectiveness of our collectives' initiatives. For further questions, please contact us at hello@oscollective.org. (please note: we do not refund any contribution after 120 days from the donation date)

Taxes

What about tax forms?

Open Source Collective must collect tax forms for any individual who invoices (this does not apply to reimbursements) over $600 in a single calendar year. Those individuals will be automatically issued a 1099.

When you submit an expense that puts you over the $600 threshold, you will be sent an email with a link to complete your tax form online. This email will come from Dropbox Forms and say "Open Collective sent you a request via Dropbox Forms".

Expenses will not be paid out to you until you submit the tax form.

If you don’t meet the $600 threshold, simply report your earnings as miscellaneous self-employment income when you file your taxes as described above.

Does this apply to non-US citizens?

Yes. We need you to fill in the tax forms so we can show that the payment went to a non US citizen. This is needed for accounting purposes. We have to verify what payments went to US vs. non-US payees.

Reporting your income from OSC

For tax purposes, you will be treated as an independent contractor and, if you are a US person, you will be issued a 1099 if your earnings exceed $600. Here's a good explanation of how W9s work for independent contractors, and there's more info on what a 1099 is here.

If you don’t meet the $600 threshold, simply report your earnings as miscellaneous self-employment income when you file your taxes.

Open Source Collective is based in the US. If you are not based in the US, we will only keep your information on file and it's up to you to meet any tax reporting obligations in your country. It would be best to talk to a tax advisor on how to handle income from a US-based company as an overseas resident.

For more information on taxes please click here.

Do we need to set up a bank account?

Nope. We will hold your funds for you! If you are eligible, joining is fast and easy.

Do we need to file taxes?

You do not need to register anything for tax purposes for the collective.

The benefit of being fiscally hosted by Open Source Collective (OSC) is that we take care of taxes on your behalf for any funds raised for your project worldwide.

Collectives do not have a separate legal existence from Open Source Collective and thus should not submit tax forms to the IRS. Your financial activities are included in our annual filings.

The exception would be personal taxes.

Individuals who issue 'invoices' and receive income from Open Source Collective (or one of its hosted collectives) will be asked to submit a W9 or W8 (depending on what country you are in) and will be issued a 1099. If this applies to you, you will automatically be sent a notification. We take care of filing these with the IRS at the end of the year along with the total amount of money that individual was paid throughout the year. The individual will receive a notice from the IRS for any taxes due to the US because this is where OSC is based as a business.

If you have questions about your own personal tax situation, we recommend reaching out to a tax professional.

Will OSC own our intellectual property?

Per our Fiscal Sponsorship Agreement, you retain ownership of all your collective's intellectual property. If you would like us to hold non-monetary assets, such as trademarks, please reach out.

Can we receive international contributions or pay out international expenses?

Yes. But be aware that all of OSC’s transactions are denominated in USD and will then be exchanged into other currencies as part of the transaction.

Can you host groups that are based outside of the United States?

Yes!

What is the OSC Code of Conduct?

OSC uses the general Open Collective Community Guidelines. As well, we have a Terms of Service, available here. Please take a look a them!

What if I, as an admin, lose access to my GitHub (GitLab, etc) account?

OSC holds funds on behalf of a community. Ideally, a single maintainer losing access is not a substantial event, as other admins of your collective should still have access. Please contact GitHub.

However, if you lost access as a result of internal governance breakdowns, security incidents, etc., we will freeze your account at the first instance to do our best to ensure that the money we hold on behalf of your collective stays where it is until this is resolved. You will need to resolve your governance issues and access to your accounts directly, with your code hosting provider. Once you can show that you have multiple admins who have access to your code again, please get in touch.

OSC will keep accounts frozen until all of our original terms of fiscal sponsorship are met. This can also include other incidents, such as deletion of Codes of Conduct or a severe loss of community membership (through a forking event, etc.).

The other admins have locked me out! What can OSC do?

This stinks. Please see the above comment. Email us immediately at hello@oscollective.org.

I am unable to access my original codebase, permanently. Can OSC release funds to me individually?

No. OSC holds funds on behalf of communities. We will work with you if you are able to show multiple members of your team are interested in a fork. However, OSC does not make arbitration decisions and we are not professional mediators. Please see our Terms of Fiscal Sponsorship, the Termination section, for more on how we manage funds if we decide that we have to terminate our agreement with your collective due to unresolvable issues.

This is a guide based on an Open Source Collective workshop led by Sumana Harihareswara of Changeset Consulting in February 2022. It focuses on growing contributor bases for Open Collective-hosted open source software projects.

First, an overview: engagement/retention funnel

Here's a diagram describing how open source projects engage, retain, and lose people. You may recognize this as an "engagement funnel"; projects attract users, some of whom convert into contributors, and some of those convert into maintainers. (This diagram oversimplifies; some contributors were not initially users.) And eventually, maintainers leave or step down; some of them disappear while some remain in the project spaces.

A key thing to notice here is that retention is possibly more important than attracting contributors in the first place. Attracting new contributors without working to retain existing contributors can be a waste of effort; the funnel is a leaky sieve. Some attrition is normal and inevitable -- we don't know precisely how much, and this is the sort of thing researchers are figuring out -- but if you've never made an effort to retain contributors, there's probably some room for improvement.

For instance, to help retain infrequent contributors who have stopped initiating contribution but still respond to questions and requests, you can set up expert teams focusing on specific topics/domains and suggest that people join those teams. This makes a way for those contributors to stay connected and keep providing expertise, and sometimes -- spurred by a conversation -- they'll go on to do work on relevant issues.

Why grow?

Instead of reflexively thinking "growth = good," it's worth stepping back and considering what specific problems you could solve, or opportunities you could use, with a larger contributor group. What capabilities would help your project in new ways? Examples:

• to accomplish a project roadmap faster

• to increase marketing and developer relations capacity, so that more people will talk about the project in various settings and and attract more contributors and sponsors

• to increase maintainer capacity and improve bus factor, e.g., get comaintainers to co-lead so an existing maintainer can step back a bit or entirely and deal with burnout

• to increase general project resilience, e.g., get less dependent on 1-2 companies which currently provide most of the work

Thinking about your goals can help you focus your retention and recruitment efforts.

Specific things you can do

Retain your existing contributors by better understanding what they want and need.

Make a list of some high-potential contributors, e.g., 10 people who have contributed in the past year, and start making specific plans to talk with them:

• Find out more about what they want, why they are contributing to the project, and how you can help them with that. For example, if an engineer is contributing to your project to learn a new language, ask whether she'd like to explore using newer language features in the project.

• Ask them for advice; this not only gets you useful advice, but conveys to them that you value their opinion.

• Make some synchronous social/chat or coworking times available, such as online chat, videocalls, livestreams or open Jitsi/Zoom videocalls. Consider a more low-key structure such as "let's all cowork together", or set up a recurring stream (YouTube/Twitch) where you work on the project, show your environment setup and take questions. Or lead a more discussion-centric "office hours"/"open hours" chat, which can be "about anything" or carry a loose agenda such as "questions about the recent release". (This can also help you constructively funnel discussion of a particular current controversy.) This helps contributors who are interested in friendship grow into friends through increased conversation, proximity, and consistent interaction. Contributors with social ties to a project are more likely to stick around.

Recruit new contributors by easing their path to contribution and making it easy for them to find you and feel welcome.

• Check that you have a guide or checklist for new contributors, and work through it yourself to ensure it's reasonably complete.

• Pay for a developer experience audit in which a new contributor tries to get your development environment up and running, and documents or fixes all the snags along the way. Example vendors to hire for this: Open Tech Strategies, Maintainer Mountaineer, Changeset Consulting, pubstruct, or Galaxy Rise. If you can't afford to pay, ask new contributors to write a tech discovery report, and use it to fix problems they ran into. Try to get a fresh audit from new contributors regularly, perhaps every 6 months, to keep up with changes -- in your own setup process and in the larger world (operating system upgrades, etc.).

• When you do outreach, leverage the power of groups. Find local meetups/colleges/universities and offer "intro to open source contribution" workshops with them. This way, you can recruit groups of people who will consider your project special because you are local, And, since people like to hang out with their friends, getting a pre-existing friend/social group into your project increases the of likelihood of retention for the whole group.

• Personally invite individual users or other potential contributors to contribute; some people don't feel comfortable showing up and trying stuff unless someone invites them.

• Create structured opportunities for new contributors to interact with you and come aboard. You can join well-known apprenticeship programs like Google Summer of Code and Outreachy, or run courses like Drupal Ladder, but even if you don't have the dedicated mentorship time for those efforts, you can try smaller initiatives. For example, to improve communication and grow relationships, run regular "PR test Fridays" -- every Friday, make experts available who will help newcomers walk through how to test pull requests and help with the code review load.

• Every few days, look at recently merged pull requests and patches, and thank contributors and ask them whether they'd like a next issue to work on. Per Mozilla's analysis of new contributor trends (see the "Measuring Engagement" presentation for more details), this kind of invitation within 24-48 hours is much more likely to retain the contributor's momentum and enthusiasm than if you wait a week. In fact, constructive criticism that arrives quickly is more likely to keep the contributor engaged than uniformly positive feedback that takes a week to arrive!

• If you have trouble keeping up with GitHub notifications to make sure you get reminders to review new pull requests, you can extend GitHub's functionality using tools like zulipbot to create teams and improve the specificity of notifications.

• If you have many incoming newbies, create regularly scheduled or ongoing spaces for new contributors to get help. For instance, in your chat, create a "new contributors" channel and ask existing volunteers to form a team to help find them a first task and onboard them. As an example, see the Teahouse at English Wikipedia which helps new contributors acculturate to Wikipedia norms. Also see the videocall/chat/stream suggestion from the retention section above.

As you recruit new volunteers, you will find that some participants provide poor quality work and are slow to learn enough to contribute effectively. Here's how to work with them. It's ok to deflect some people into contributions they can do so you can concentrate on others -- but also, encouraging someone in this category can sometimes help you nurture someone who will be a really enthusiastic contributor in user support, marketing, or other areas.

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:

1. fundamental capability: paying for driver activities that are on your roadmap, usually through labor.

2. 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.

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.

Improve the developer experience

Resource a fixed amount of time regularly to go through issues and pull requests. A clean house is an inviting environment for more contributors.

Buy some test devices

Older model phones or tablets can help optimize code for different user experiences.

Thank people for significant work

If someone delivers a valuable piece of work, you can thank them with money or a gift.

Contract developer time

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.

Community facilitation

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

Support dependencies

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

Design

Make your software and website visually stunning and level up the UX snd brand.

Documentation

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

Come together

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.

Sponsor relationships

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.

Productize

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.

Print stickers and T-shirts

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.

Encourage contributors to give conference talks

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

Inclusion & diversity

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.

Newsletter and blog

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.

And read this blog post: Has Your Open Source Community Raised Money? Here’s How to Spend It.

This is a guide based on two Open Source Collective workshops led by Sumana Harihareswara of Changeset Consulting in early 2022. It focuses on writing roadmaps, publicity, marketing, and other communications for Open Collective-hosted open source software projects.

Your audiences and what you need to tell them

Your open source project needs to be able to announce stuff to the different groups in this diagram... \

...to ensure they know stuff, and they need to be able to depend on hearing from you about stuff they need to know. Let's mostly concentrate on the kinds of announcements you make to people who aren't already frequent contributors to your project, since that's mostly a different set of activities. So this means talking with, for example,

• your users (individuals, and downstream projects)

• prospective users

• prospective/infrequent contributors

What are the basics you need to write and send out?

1. roadmap: a document or dashboard that conveys the relative priorities of upcoming work, and possibly target dates for releasing near-term work

2. announcements and requests: event-based warnings/brags about or reactions to state changes -- announcements/explanations, requests for help/testing

3. consistent reminders of slow-moving state change/status, such as when you make substantial changes to your roadmap

Roadmaps

Why a roadmap?

A roadmap will help your project:

• assess and decide priorities for your team. What are you trying to get out the door next? Is everyone on the same page? Having these articulated makes it easier for people to ask each other to expedite specific tasks, or to make good use of sprints, meetings, and other opportunities. Volunteers can sometimes make commitments when asked, and even if they can't, if everyone knows what the group is trying to prioritize, volunteers are more likely to speak up and alert others when they can't do work others expected of them.

• set expectations for your users/downstreams, for features (e.g. PEPs) they're waiting for, and for deprecations to prepare for.

• say "no" or "not yet" to low-priority requests, and to and the siren songs of yak-shaving.

• keep deprecations in sight, to help lift morale in case you feel like you'll be dragging the old features and their support burden forever!

We make roadmaps to make it easier to decide and share priorities. The process of making a roadmap is a forcing function that helps your team think through:

1. sequencing: "that architectural rewrite is important because x, y, z depend on it"

2. bringing new resources to bear, such as interns, grants, corporate sponsors, and sprints

3. deprecation: when? what? why? (for example, tacking on new support for a new version of the language, and scheduling the deprecation for support of the old version)

Once it exists, a roadmap is one of your communication tools. For example:

• If you make a tool that consulting agencies reuse, and they ask "how can I do x," "why can't I do x," or "when will you release a version that includes feature x?" then you can tell them. Even if you can't pin it down to a date range, telling them "minor release +1" helps them set expectations.

• If downstream packages use your project as a dependency, you can use a roadmap to help them set deprecation expectations. One project in this position made an LTS (Long-Term Support) release. In response to feedback that their deprecations were too fast to keep up with, the project instituted a deprecation policy for their quarterly releases: a deprecation notice would start two release cycles before feature removal, giving downstreams a 6-month head start to adapt. The roadmap is part of the team's effort to be proactive, including warning messages and detailed release notes indicating "feature x will be removed, so if you're using it, change your workflow in the next 6 months."

Similarly, while you can always expect to get support queries about your choice to deprecate functionality, a strategy like the pip development process and deprecation policy helps cut down on queries and helps you answer them concisely.

You can start small

You can develop a roadmap slowly and thoroughly, with rounds of revision from all the contributors, laying out changes coming in the next several releases and writing a schedule of expected release dates. That's hard -- it's hard even for software projects where all the contributors are paid, by the same employer, to achieve that roadmap!

It's probably better to start with a quick, rough document laying out three goals:

1. what we're working on for this release

2. what we aim to do in the next release

3. later/after that

Once you have that, a good next step is to write down and publish your current release and/or deprecation process, even if it's as informal as "when one of the maintainers decides it's time for a new release, they package up whatever is on the main branch, and we may unpredictably remove any functionality or interface with no deprecation warning." This sets expectations for your users so they can stay prepared. If you have a deprecation policy, consider tying it to feature freezes a few weeks ahead of each release, to help you confirm and set expectations about what will be in each release. When you make releases, or decide on themes or overarching goals for your releases, make sure you consider whether there's anything you'd like to start deprecating, so you can give users the appropriate notice period.

Sometimes a roadmap is a document, but sometimes a dashboard can serve as a substitute. For example, one project uses GitHub issue milestones as a roadmap, bucketing tasks into "Current release series", then "+1", then "+2". Most of their users are not developers and aren't looking at GitHub, and are more likely to read blog post or corporate-style communications. In contrast, one project whose users are mostly marketers finds that they don't usually visit GitHub. A contributor has started gathering work plans and commitments from contributor companies. Instead of writing it in a document (which often sets unrealistic expectations for schedule certainty), they spoke about those priorities in a conference talk, framing the information as "here's what we are going to concentrate on" rather than making promises. (If you have users like this, you might even want to offer them a different way to take feature requests, outside of GitHub or your main collaboration platform, such as a forum or a live videocall; sometimes having a different medium is helpful!)

And different projects at different life stages need different things from their roadmaps; check out the Mozilla/Open Tech Strategies project archetypes to consider how the development lifecycle differs depending on how many different institutions are involved, and so on. A hobbyist project (a "houseplant" in OTS's lexicon might only need a one-line disclaimer that there's no set roadmap at all.

Announcements and requests

Consider this diagram as you think about the work your team does that needs to get publicized to others:

How do you communicate to your users, upstreams, and other interested people about new releases, new features, deprecations, and so on? How do you get users to take note?

Some approaches are:

• A mailing list. Here's an example post from the PyPI project that links to a longer "how to test this" document example hosted on a wiki. It's easier to get users to sign up for an announcement mailing list/newsletter (example for Python's package repository) if you commit to a very low frequency of posts, such as 2-10 per year.

• A blog sharing regular overviews of new features and fixes. For example, the Dreamwidth project does a regular "code tour" -- here's how and why it works and here's how to write one. Another example: a Python version release announcement or an announcement of a new feature in PyPI.

• In-application notifications. If you have a way to feed text notifications for users into your applications, consider judiciously using them. For instance, one project implemented a warning system via in-app instructions, console message logs, and GUI window messages to alert users that features they were using would be deprecated if no one stepped up to maintain them.

• Communicating personally or manually to particular important people and groups. You might keep a checklist of newsletters, podcasts, industry journalists, your liaisons in related projects or organizations, Slacks and Discords, relevant subreddits, your sponsors, etc. and then personally contact them via public posts, Twitter or Discord direct message, SMS/Signal, email, or some other personal mode of contact. For example, see below for an example "Dear sponsor" email the Python Software Foundation sent its sponsors to alert them of an upcoming change to Python packaging tooling.

Your checklist will grow organically over time, like a FAQ page. When users complain that "I didn't know this was happening," ask them: "where do you look for your news?" and build your list from there. Tune your communications to your audience and check every six months or so to learn what to add or discard; some users depend on new platforms. It's always going to be useful to have a single canonical blog post or mailing list post people can point to for the authoritative announcement, but you'll find ways of publicizing that post that reach more and more of your users over time.

Reminders

In between major announcements, you may want to send consistent reminders of slow-moving state change/status, such as when you make substantial changes to your roadmap. You might also celebrate when people go from Contributor to Maintainer, and commemorate when they go from Maintainer to Emeritus, as Guix did, or discuss your principles and vision of your project's future, as Zulip did.

Try to bundle these into low-frequency posts or emails, perhaps quarterly. More than four times a year will start verging on spammy for most users.

Discoverability outreach

If you have time, and especially if you maintain a complex and widely-used tool, you should also do discoverability outreach, which is finding and bring in stakeholders who don't already participate in your communication spaces, and helping them discover the features you already have and the workflows you already support.

Those tasks might involve branching out to more media -- asking your marketing squad to talk about it in blog posts, videos, podcasts, conference talks, zines, etc. For example, the pip team scripted, filmed, edited, and published a two-minute video to announce major changes to pip and encourage users to reach out with feedback.

Sample Dear Sponsor letter

Subject: Dear sponsor: your engineers should test this major Python change by 9/30

Dear [sponsor],

Thank you for supporting the Python community. We appreciate your past and future contributions to our community and wanted to take this opportunity to give your team a heads up regarding important changes to a core piece of Python tooling. The de facto tool for installing Python dependencies, pip, has been the focus of a long term funded project to update and improve a core piece of its functionality.

Please forward this email to your software engineering lead or developer as soon as possible! It will help your team make a smoother transition and provide invaluable feedback to the project ahead of launch!

The pip maintainers have just released version 20.2, which includes a beta of the next-generation dependency resolver. It is significantly stricter and more consistent when it receives incompatible instructions, and reduces support for certain kinds of constraints files, so some workarounds and workflows may break. Please test it with the --use-feature=2020-resolver flag.

Please test the beta resolver in your developer environments this month. We plan to make pip's next quarterly release, 20.3, next month, in October 2020. We are preparing to change the default dependency resolution behavior and make the new resolver the default in pip 20.3. To prevent major breakage, we need your feedback and bug reports by the end of September.

The new dependency resolver is off by default because it is not yet ready for everyday use.

Our guide on how to test and migrate:

https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-2-2020

File bugs and give us feedback using this survey:

https://tools.simplysecure.org/survey/index.php?r=survey/index&sid=989272&lang=en

For release highlights and thank-yous to our project funders, see

https://blog.python.org/2020/07/upgrade-pip-20-2-changes-20-3.html . The full changelog is at https://pip.pypa.io/en/stable/news/ .

We also have a special opportunity for you to sign up for our user experience studies, so you can help us shape the future of Python packaging: http://bit.ly/pip-ux-recruitment-sign-up

Thank you again,

[name]

Python Software Foundation

P.S. For future pip announcements, please subscribe to https://mail.python.org/archives/list/pypi-announce@python.org/ , our low-traffic announcement list.

A sample schedule for ongoing communications

Assuming your project makes 4 releases per year, here's a sample schedule you could use to plan your ongoing outwards communications.

1. 1 month before release:

   • send/post "how to test this" to the beta testing enthusiasts wherever they are

2. 1 week before release:

   • prepare FAQ and saved replies for bug triage/user support folks

   • release notes

3. at release:

   • announcement email/blog post

   • send to relevant newsletters and podcasts

   • post to subreddits/Discords/Slacks/Zulip/IRC

   • possibly do livechats

   • social media posts

4. one month after release:

   • find people talking about the upgrade & boost them

   • post a quarterly update about roadmap, releases, finance, maintainer promotions, first-time contributors, good first bugs

Based on an OSC workshop led by Sumana Harihareswara of Changeset Consulting on January 10, 2022. (Thanks Sumana!)

First, an overview

Here's a diagram describing how money and other resources flow through an open-source project.

Two key things to notice here:

• money donations from corporate sponsors are one of many ways to get resources (also consider free services from platforms, selling tickets to convenings, etc.)

• there are quite a few things you could spend money on: labor is a huge one, but also consider platform services, equipment, stickers, and more

Process summary

To recruit financial sponsors, you'll go through this basic sequence:

1. Inventory: look at existing donors and make lists of potential donors and fundable tasks or chores

2. Writing: prepare your requests and update your website and documentation to ensure you look credible

3. Asking: make the request and follow up on responses

This may cause you to feel weird

Many of us feel odd about asking for money. It's a good idea to check with yourself if you feeling aversion about it, and work out what you need in order to feel like this is okay. Maybe you have ideological, practical, or psychological barriers.

For example, you may feel a general sense that other people or projects deserve money more than yours does. Try to imagine a friend in your situation and think about whether you would judge that friend for raising money for a similar project, and what justifications you would demand from her.

Or you might feel averse to begging. An alternate way to think about this is that you are offering an opportunity: if the sponsor donates to your project, the project is much more likely to be able to do things that will benefit them. And there's nearly no way for them to figure that out unless you tell them.

Or you might think it's impractical to ask people to pay for something they can use for free. This is why it's useful to come up with and advertise fundable tasks whose completion will benefit your sponsors; they won't be able to use the thing for free, because it won't exist unless someone pays for it.

And remember that it'll get easier as you go; the first request is hardest.

Inventory

1. Write a case study about an existing sponsor.

Time: 2-4 hours

If you have any existing sponsors, then you can develop case studies about their sponsorship. Here's an example. You don't need a lot of fancy graphics and it can be as short as 4-6 paragraphs. This is a way to demonstrate that your project can effectively turn donations into useful work, and doesn't just sit on them or fritter them away.

Make sure you cover how much money the sponsor gave, what your project used the money for (and over what time period), and how this has benefited the sponsor. You may need to have a short email or phone conversation with someone at the sponsor to find out that last part, but it's important, because having a case study like that on your website makes it easier for a future sponsor to believe that sponsoring you will help them.

2. List potential sponsors.

Time: 30-60 minutes

You'll be more likely to be able to attract a sponsor if you can contact a specific human at the company. Look in your messaging archives (the mailing lists, bug tracker, social media) for the names of companies and your contacts at those companies. For example, look for people who have emailed your support mailing list from their work email addresses, or people who have submitted bug reports and mentioned that it's affecting their work.

Sort this list by how much of a relationship you have with that individual person. For instance, if you've ever met them at a conference, had a good experience reviewing their code, or had a good interaction with them on social media or in a chat. The more trust and good feeling you have with a person, the greater the chance they'll champion your request within their company.

3. Develop a list of tasks/goals.

Time: 4-5 hours

To attract sponsors, you should be able to explain what tasks or goals would be possible with their funding. Look through your project's TODO list but also be open to more widely imagining things you could do if you could hire people, buy equipment or services, etc. Here's an example list.

A good idea:

• is clearly wanted. There's already consensus among project maintainers, and you aren't waiting for a policy or architecture decision before you can implement it.

• is fairly well-scoped. You can define what success will look like. "Revolutionize e-book lending" is badly scoped; "add this DRM-free lending library to these browser extensions" is well-scoped.

• is fundable: would happen much faster if you got funding to implement the work. So, it has to be legal and physically possible. "Reverse-engineer and re-implement iOS" probably fails this test.

• has a theory of change. You have an assessment of what your users' life is like now, a vision of how their lives could be better, and a suggested course of action that would help get closer to that vision.

So, for example, good tasks include:

• get a long-delayed release out

• finish an architectural rewrite that enables features companies want

• add compatibility with an up-and-coming THING

• get a security audit for the first time and good goals that depend on paying people for chores include:

• get "time to first response" for bug reports and patches down from STATISTIC to BETTER STATISTIC

• get release cadence down from CURRENT FREQUENCY to FASTER FREQUENCY

• pay someone to wear a pager for incident response

You may need to do this step in a few passes, coming up with a lot of fresh broad ideas at first, then making them more specific and filtering out ones that don't yet have consensus from your team.

Writing

1. Choose a few ideas and budget them.

Time: 2-3 hours

To figure out how much money you want to raise from sponsors, start estimating how much time a few of your ideas would take. You may need to talk with your teammates to figure this out, and they may not see the point if they believe they won't have time to implement the idea, even if it's funded. That's okay - if you get funded, you can hire contractors who aren't part of your team already, as long as you budget time to onboard them.

Start with a few of the projects that have smaller scopes. For example, if one of your ideas is to finish rewriting a particular component in your codebase, then probably most of your money will go to wages, and maybe some fraction of it for hardware or similar expenses, and - if we can travel again someday - travel. If you are hiring in the US for skilled Python developers, assume you'll be paying somewhere from $80-$200 dollars per hour. So, let's say you're just paying for labor, $150 an hour. Five weeks at 35 hours per week is 175 hours, and 175 hours at $150 per hour turns into $26,250. So for about $27K you can do this task.

2. Prepare public-facing materials.

Time: less than an hour

When your contact asks their manager for approval to sponsor your project, that manager, or Accounting, will look up your project. Make sure you have the following public-facing webpages prepared so that, if a stranger looks you up, you look credible and legitimate.

On the About page or front page on your website, and in the README of your source code repository, include:

1. A link to your Open Collective profile, so that Accounting knows that the profile pn Open Collective isn't some scammy impersonation.

2. A one-paragraph explanation that explains what your project does at a level that managers can understand. Here's a template: FOO is an open source TOOL that DOES THIS THING. It HAS TWO OR THREE KEY FEATURES and thus ALLOWS USERS TO [ENJOY A KEY BENEFIT]. It is written in LANGUAGE [for use in FRAMEWORK] and was founded in YEAR."

3. Links to your roadmap, if you have one, and to a short list of tasks/goals that need sponsorship. (If you have written any case studies, link to them near these links or on those pages.)

3. Write a sponsorship request letter.

Time: 30-90 minutes

You don't need to write a completely new letter for each person you contact; you can develop a template text and then customize it for each contact, perhaps mentioning goals that would particularly benefit them, or times in the past when they've mentioned being interested in helping the project, or (if you know they're already enthusiastic about sponsorship) linking to resources to help them make the case for sponsorship internally. You can use the example email below as a template. It went to several organizations and was successful in raising money to accelerate a delayed project release.

Since you're with Open Source Collective, you can offer to make things easier for the company's accounting department by registering in their vendor system or sending invoices in advance. If that's something they want, Open Source Collective can set it up.

If you have any case studies of past sponsorships, you can link to the most relevant one in this email.

When your contact looks up your Open Collective profile, if they notice that you have more than about a thousand dollars in saved money that you haven't spent in several months, they'll start to wonder whether you really need the sponsorship. You can avoid this situation by usefully spending the money before sending your request. Or, you can in the letter explain what you're about to spend it on, as part of the initiative that needs further funding to succeed.

Example email, sent mid-July 2020:

Subject: Funding for Autoconf 2.70

I'm part of a small team working to get Autoconf back on track - stable, robust, and making regular releases. Can your company help?

There's lots of code out there already depending on autoconf. Converting it would be risky and expensive. Plus, competing build systems don't cover all the edge cases Autoconf does.

My team has already shipped a beta release of Autoconf 2.70 <https://lists.gnu.org/archive/html/autotools-announce/2020-07/msg00000.html> and we intend to make the final release in October.

Between now and then, we want to:

• test the upcoming release against emacs, gcc, python, and other complicated autoconf scripts

• set up proper CI so we can find regressions

• get the hundreds of disorganized patches and bug reports filed, so we can prioritize and assess our backlog

• uplift patches that downstream redistributors already carry

• work with existing maintainers + community to get the project on a more sustainable path

Project manager Sumana Harihareswara (cc'd) and I have detailed plans and availability. But we have bills to pay and need your help.

We already have one sponsor offering $15,000 towards this work - but only if we can find $15K in matching funds from other organizations. If you and two others each give $5,000, we can start the CI work, and we can inventory, migrate, and uplift many long-desired patches. And if we get more funding, we can do even more.

Interested? We want to kick off the work before the end of July. If you can support this effort, let's talk before then and arrange payment.

Asking

1. Email the request to three contacts.

Time: 10 minutes

Don't try contacting all your potential sponsors at once, because then it'll be hard to conduct several conversations at once in case all of them have questions for you. Start with your top three. Since emails asking for money often get spam-filtered, try to let your contacts know via some other medium - such as a social media or chat direct message - that you've sent them an email that might get spam-filtered and that they should look out for that.

2. Respond quickly.

Time: variable

If they say yes, great! Try to respond within 2 business days to help them get started.

They may want to fund you through a different mechanism such as Tidelift, at which point your project would need to decide whether to get onto that platform. You may need to deal with a lot of back-and-forths with your contact, their manager, and their accounting department to nudge things forward and to connect them with Open Source Collective to help them through paperwork. Even if it takes 15 back-and-forth steps, remember that it will be finite and that it's worth it.

If they say no, but your contact seems regretful and wishes they could donate money to you, you can ask them for something else that is not money. Some suggestions: continuous integration services support, or some engineer's or manager's time as secondary mentor for an intern. And if they wish they could make the case for sponsorship to their managers, suggest these resources.

Repeat

Once you've gone through these steps, you can iterate: picking more contacts to email, developing further fundable ideas, writing case studies, and so on.

Part 1 of 3, shared with permission based on Making your open source project sponsor-ready, Part 1: Companies and trust by Nicholas C. Zakas. Published under CC BY-NC-SA 4.0.

Early on, it was a battle to get sponsorship for open source projects. What used to require phone calls and drawn-out discussions has now been streamlined. Companies and individuals can now know if a project accepts donations just by looking at the project page on GitHub, and if you’re lucky, they’ll sign up without you needing to do anything. But is that really all you need to do? Just set up an Open Collective or GitHub Sponsors page and just watch the money roll in? Not quite. There’s a lot you can do to make your project attractive to potential sponsors.

While it’s possible to bring in a decent amount of money through individual sponsorships, the real path to open source sustainability is to get larger donations from the companies that depend on your project. Getting $5 to $10 each month from a bunch of individuals is nice, but not as nice as getting $1,000 each month from a bunch of companies. For that reason, this post focuses on making your project attractive to companies, and to do that, you first need to understand why a company might want to sponsor your project.

Why companies sponsor open source projects (or don’t)

There’s a fairly common mantra online about why companies should sponsor open source projects: because it’s the right thing to do. Many companies, especially startups, are able to get started because they are building on top of free and open source software. It would be difficult or impossible for companies to compete without the availability of zero-cost foundational software. Once they are profitable, it makes sense for companies to contribute back to the software that helped them become successful. Right?

The harsh reality is that companies don’t operate as charities. Their goal is to bring in as much money as possible, and that doesn’t include giving away money “because it’s the right thing to do.” For some, this is frustrating, but if you can move past the perceived unfairness of it all, you can come up with a strategy that works. Just because companies won’t sponsor your project out of gratitude for your work doesn’t mean they won’t sponsor your project. You just need to stop and think about the things that companies do spend money on regularly and then align your offering with those things.

And there are two things that companies readily spend money on: helping the business and publicity.

Companies invest in things that help the business

Companies generally spend money on things that accomplish one of three goals:

1. Saving time

2. Saving money

3. Generating more money

Open source projects must fulfill at least one of these goals to be attractive to a sponsor. Your project might save the company time by providing code that they would otherwise have to build and maintain themselves; your project might save them money because otherwise they’d need to buy a commercial product; your project might generate them money if it is user-facing. So the first thing to understand is what value your project is providing to companies.

In the business world, this is referred to as your value proposition. It’s often a one-liner that tells everyone exactly why your product is valuable. As an example, if you visit ESLint’s website, you’ll see this phrase featured prominently: “Find and fix problems in your JavaScript code.” That’s it. Simple, easy-to-understand. If you write JavaScript code, then ESLint is helpful for you. It helps by catching problems you might miss, and problems cost your company time and money; therefore, ESLint saves your company time and money.

Action items: Define the value proposition for your project and feature it prominently: on your README, on your website, on your social media accounts, etc. Make it a simple one-line sentence that can help explain how it saves companies time or money, or helps to generate more money.

Companies pay for good publicity

Companies are willing to pay for achieving their goals, but there is another consideration: will the sponsorship reflect well on the company? All companies care about their image in the marketplace and will not spend their money on anything that reflects badly on them. Think of the commercials you see while watching TV. Companies are buying advertising spots during specific shows because they want their brand associated with the show. Why? To generate more money by reaching the fans of that show. The opposite is also true: companies pull their ads when it becomes a risk to their reputation.

Make sure to have a website in addition to your README, as open source projects frequently promote their sponsors through logo placement on both. Companies need to be okay with having their logo in these spots, which means they need to be okay with the association between their company and your project. As a simple example, if you name your open source project “hotGirlXxXparse,” it’s doubtful that a company will want their brand associated with your project.

The ideal case is that the company gets good publicity for supporting your project. Companies care about publicity like this because it helps to attract new hires and retain their existing developers (similar to sponsoring tech conferences). There is a lot of enthusiasm for open source projects in the tech community, and publicly thanking a company for sponsoring your project helps to build their brand among the community. While companies may not expect much of an impact on their brand from sponsoring a project, it can result in more name recognition and even an increase in candidates for open jobs.

Overall, your job is to make your project into something that companies would be proud to have their brand associated with.

Action items: Ensure you’ve named your project appropriately and have a professional-looking website with spaces for company logos. Make sure the website is some place a company would be excited to be displayed.

The importance of building trust with companies

So you have defined your value proposition, picked a good name, and have a nice website up and running. The next step is just as important: how to signal to companies that you are trustworthy. A sponsorship is a business agreement, and you are a partner to that agreement. In order to do business with you, someone at the company must trust you. Companies do not do business with people or other companies they don’t trust.

Startups are intimately familiar with this problem. How do you get customers when you have no track record and no other customers? How do they know you’ll still be around in a year? How do they know you won’t just take their money and run? With open source projects the problem is even more complicated because there often isn’t a company backing it up (if there is, they might not need sponsorship, after all).

Your job from this point forward is to do everything you can to appear as trustworthy as you can. Remember, you are trying to convince a for-profit business to give you, some person who wrote some software on the weekend, a significant amount of money. This is no small task. You need to think of yourself more like a business than an individual and spend time building your reputation.

Part 2 of 3, shared with permission based on Making your open source project sponsor-ready, Part 2: Project hygiene by Nicholas C. Zakas. Published under CC BY-NC-SA 4.0.

You are either building or destroying trust with everything that you and your project do online. Making sure that the trail you are leaving speaks well of both is important for attracting potential sponsorships. Fortunately, most of the steps are straightforward and, if you’ve been running your project for some time, you are likely already doing them.

Use an OSI-approved license

The Open Source Initiative (OSI), which is the organization that officially defined the term “open source,” has a list of approved open source licenses. These licenses have been fully verified to be open source licenses, ensuring software using these licenses can be “freely used, modified, and shared.” This list is used by governments, companies, and lawyers when evaluating open source projects.

Double-check to make sure you are using an OSI-approved license without any custom modifications. Using other licenses creates a legal gray area for companies, which means they need to spend time reviewing the licenses with their legal team, and that might prevent them from using the project or sponsoring it. Companies are more likely to sponsor free and open source software than they are projects with custom licenses that might send a signal that the project isn’t going to be free and open source forever. Don’t make the companies do work to validate your license.

If you have already started your project with one license, don’t be afraid to change it. There are numerous projects that have changed their licenses based on feedback from their users, including JSHint (which inherited the infamous “no evil” license from JSLint) and React. Depending on how dramatic the license change, you may want to adjust your version number accordingly.

Action item: Double-check that your project is using an OSI-approved license and feature the license prominently on the README.

Set up a code of conduct

Imagine that you are in charge of open source sponsorships at a company and someone suggests a certain project. Wanting to do your due diligence, you go to the project’s GitHub page and look through recent issues and pull requests. What you see is a maintainer who is swearing and being defensive, commenters insulting code submissions, and just overall aggressive behavior by more than a few people. What message does that send about the project? Is that a recipe for attracting contributors and long-term support? Will a company want to be associated with such behavior? Of course not.

How you behave as a maintainer, and to a larger extent, the behavior of those who are collaborating on your project, reflects on the project as a whole. For the best example, look no further than Linux, which for years had a culture of conflict that ultimately led to the formal adoption of a code of conduct. Don’t wait for things to reach that point. Establishing a code of conduct early on in the life of a project makes it more appealing to both contributors and sponsors.

The Contributor Covenant is a good place to start if you don’t want to do much research. Keep in mind that you are expected to follow your code of conduct as well. Make sure your behavior is above reproach while interacting with (sometimes irrational) people on GitHub. Companies absolutely do look at issues to see how things are being handled. (And you never know when a new contributor might turn into an ally in getting their company to sponsor your project.)

Action item: Establish a code of conduct and feature it on your README and in GitHub.

Publish documentation

A project without users is a project without sponsors, and one of the biggest barriers to open source project adoption is a lack of documentation. At a minimum, your project needs two sets of documentation:

• Getting Started Guide - this documentation is targeted at your project’s users and guides them through installation and setup. If there are any prerequisites to installing your project, this should also be mentioned. The guide should continue through to using the project (executing it if it’s an executable, using the API if it’s an API, etc.).

• Developer Guide - this documentation is targeted at people who want to contribute code. At a minimum, this should describe how to get the source code and set up a local development environment. Ideally, it also describes any commit message formatting you require, the process for accepting contributions, and anything else between writing code and submitting a pull request.

Where the documentation lives is up to you. To start, it’s fine to put most of the documentation on your README. As the documentation grows, you may want to have a dedicated documentation folder in your project that the README links to. Eventually, if your project gets popular enough, having a dedicated documentation website will help your users tremendously.

Remember, the more users and contributors you have, the more likely one of them will lead to a sponsorship, and documentation is a key part of attracting people to your project.

Action item: Write your Getting Started and Developer guides. Include them in, or link to them from, your README.

Develop a roadmap and release plan

The most important question people ask about a project is “What’s next?” Both users and sponsors want to know where the project is headed. For users, they want to know that the project is continuing to grow and develop; for sponsors, they want to know what their money is paying for. To answer both groups, it helps to develop a roadmap and a release plan.

A roadmap is simply a list of the work you plan to do within a specific time period. Your roadmap can be for any length of time you think is reasonable, but typically they are in the range of three months to one year. On your roadmap, list out anything that you think is important for people to know is coming. Features are an obvious addition to any roadmap, but you can also add bug fixes, documentation updates, integration tasks, and more. People just want to know how you plan on spending your time to improve the project going forward, and a roadmap lays this out for easy reference.

A release plan is a companion to a roadmap and establishes a schedule for when to expect releases. A lot of smaller open source projects have a “whenever I feel like it” release plan that, unfortunately, doesn’t work as the project grows. Larger projects, and especially those that would like sponsorship, are well-served to come up with a release plan so users know when changes are coming. For example, Node.js has a well-defined release plan based on six-month intervals; ESLint does minor releases every two weeks. You can choose a schedule that works best for you. The most important thing is that this schedule is communicated so you can answer the question “When will this be released?”

When you do a release, be sure to explain how it relates to your roadmap. The easiest way to do this is to generate release notes from your commit history. GitHub can generate these release notes for you[^9] based on your pull request labels. Release notes are an important part of the release process so users and sponsors can see what changes are made.

Action item: Come up with a roadmap for the next year and establish a release plan for your project. Document both, either on your README or with your other documentation.

Be responsive on GitHub

No one starts an open source project dreaming of the fun they’ll have triaging issues and pull requests, yet maintaining a project often means spending a significant amount of time doing so.

Your level of responsiveness on GitHub speaks volumes about your level of commitment to the project. Few things say “abandoned project” more than GitHub issues and pull requests that don’t get responses from maintainers.

Does that mean you need to rush to respond to every issue or pull request? No. Those will come in 24 hours a day, 7 days a week, and it’s not reasonable to expect maintainers to be on call for every question or suggestion. However, you should have a regular schedule for responding to issues and pull requests. Maybe you respond just once or twice a week, and that’s fine. It’s more important to come up with a schedule you can keep than it is to respond immediately. If you know you won’t be able to respond within a week, then you might want to note this on your README or with an automated message on your issues and pull requests.

Action item: Come up with a schedule for dealing with incoming issues and pull requests. Optionally, publish this schedule in your README or with an automated message.

Establish support channels

Even though you’ll spend time writing documentation, people will still have questions about your project, and for that, you’ll need to establish one or more support channels. You probably don’t want people opening issues for every question they have, so where would you like those questions to go? You can choose whatever will work best for you. Some popular options include:

• GitHub Discussions

• Discord or Slack

• A mailing list

• A forum

It’s reasonable to just have one support channel for your project based on your preferred way of communicating, or you can establish multiple support channels if you have the team to respond. The important thing is that users (and sponsors) have a way to contact you that doesn’t involve opening an issue.

Action item: Set up at least one support channel for your users and mention it on your README.

Establish communication channels

Along similar lines, it’s important for you to have a way to communicate with your users directly. When there is a new release, or a new team member joins, or a new sponsor signs up, you need a way to let your project’s community know about these changes. Once again, the channel(s) you choose should fit with how you prefer to communicate. Some popular options are:

• Blog

• Twitter account

• Announcements channel in Slack/Discord

• Mailing list

Whichever channels you choose to use, be sure that they are listed in your README (and website, if you have one). It’s important for users to know where they can go to get the latest information about the project.

Action item: Establish one or more communication channels and add them to your README and website.

Conclusion

Doing all of these things won’t automatically result in sponsorships, but they will set your project up for success when seeking sponsors. High-quality, valuable projects are the ones that companies are more likely to sponsor, and following the suggestions in this post helps set your project apart from a hobby project that a maintainer might lose interest in after a few weeks. The more professional your project appears, the easier it will be to find sponsors.

Part 3 of 3, shared with permission based on Making your open source project sponsor-ready, Part 3: Accepting sponsorships by Nicholas C. Zakas. Published under CC BY-NC-SA 4.0.

Making it easy for companies to donate

If you only accept donations through Bitcoin, paper checks, or direct deposit into your personal checking account, what signal do you think you’re sending to companies? How you accept sponsorships largely determines how many you will receive in two ways:

• Establishes (or destroys) trust with the company

• Makes it easy (or hard) for the company to donate

Companies are not going to create a new process to pay you. You need to find a way to accept donations using the processes that companies already use. By accepting donations through a trusted intermediary, you’re signaling that you’ve taken the time to think through your sponsorship program and are comfortable with some transparency and traceability when it comes to your sponsorships. Both are important for making companies comfortable with donating. That’s where Open Source Collective and GitHub Sponsors come in!

Once you have set up your collective with Open Source Collective, be sure to configure your funding.yml file so GitHub will display a sponsor button on your project page. You can add Open Collective, GitHub Sponsors, and other links that will appear on your project page.

Action item: Set up Open Collective and GitHub Sponsors. Set up your GitHub project to show how people can donate.

Establish where sponsor logos will go and how they get there

Companies will sponsor your project to generate good publicity for them in the open source community. The most common way to deliver this to your sponsors is through placing their logos in highly visible places. If you’ve ever been to a tech conference then you’ve probably seen sponsor logos placed on the projector screen in between or at the end of talks as well as on the print schedules. As a maintainer, you are trying to deliver the same level of attention to your sponsors.

Projects typically display their sponsors’ logos in at least two places:

• Website - if your project has a website, then displaying sponsor logos on the homepage is the best way to promote your sponsors. Some projects also choose to show these logos throughout the site, sometimes in a sidebar or a footer.

• README - at a minimum, sponsor logos should be displayed on your README. Sometimes the README gets more views than a project’s website. Not every user will go to your website but most will take a look at the README. Because READMEs are often copied to other locations (such as npm for JavaScript projects), sponsor logos get the most visibility.

Once you’ve determined where the sponsor logos will go, the next step is to set up some automation to update those logos. Both Open Collective and GitHub offer APIs that allow you to pull your sponsor information for this purpose. Investing in this automation early will save you the time it takes to manually track down, resize, and place logos in the correct places for each new sponsor.

Action item: Determine where your sponsor logos will go and establish automation to update logos in those locations.

Explain how the funds are (or will be) used

If you’ve ever driven along a highway and seen a sign next to some construction that reads “Your tax dollars at work,” you’ll know the importance of letting sponsors know how their money is being spent. Similarly, another consideration for accepting sponsorships is how you will spend the funds. It’s important to think this through before you accept your first sponsorship because companies will want to know your plans for the money.

This is where having a roadmap helps. It’s an easy story to tell that money collected will go towards fulfilling the plans on the roadmap. While it’s not easy to estimate how much it costs to implement a feature, it can help to think about how many hours it will take. Then, multiply that by some hourly rate you’d feel comfortable working at and use that as the cost to implement that feature. That way, you can put together a funding goal that companies can contribute towards. For instance, let’s say that you estimated the cost to implement your 12-month roadmap is $20,000 USD. You can then set up your goal on Open Collective and GitHub Sponsors and explain how much of your funding goal needs to be reached to implement which parts of your roadmap.

The next step after a target funding goal is to describe how the money will actually be spent. Not every maintainer wants to work 40 hours a week on their project, nor is that required to receive sponsorships. ESLint, for example, started receiving sponsorships in 2019 and has never (up to the time of my writing) had a single full-time maintainer. Other projects like Babel and Webpack do have full-time maintainers. How you plan to spend your sponsorship money is up to you, but it is helpful to explain that to potential sponsors.

The best place to do this is right alongside your call for donations, but you can also do it in a blog post or a paragraph on your README. Just make sure this information is readily available for any potential sponsors who come along. Here are some examples:

• Donations will be used to pay the maintainer(s) with an eventual goal of working full time on the project.

• Donations will be used to pay the maintainer(s) with an eventual goal of working one eight-hour day each week on the project.

• Donations will be used to pay all contributors for their contributions.

• Donations will be used to fund community events, T-shirts, promotional materials, and speaking engagements.

• Donations will be used to implement a specific feature or hire outside help.

After you receive your first sponsorships, be sure to update everyone on how the money was actually spent. This can also be in the form of a blog post or a message to your sponsors (both Open Collective and GitHub Sponsors allow you to send messages directly to your sponsors). In general, it’s beneficial to post this information publicly because it can also send a signal to potential new sponsors about how your project is operating with the money it has already collected.

On the Open Collective platform, all transactions are visible to the public, which is a great way to show how the funds are being used, including GitHub Sponsors funds deposited into your Open Source Collective account. Since all funds are dispersed in a public ledger, sponsors can easily see how the funds are being used and also allows you to easily generate reports off the transaction data.

Regardless of how you decide to explain how funds are used, make sure you issue regular updates. Never give the appearance that the money is disappearing into a black hole. It’s going somewhere, so be sure to tell that story.

Action item: Come up with a plan for how sponsorship money will be used and publish it on your README or website in addition to Open Collective and GitHub Sponsors.

Be prepared to say “no”

An underrated part of accepting sponsorships is to choose your sponsors wisely. While you may think any company that is willing to give you money is a sponsor you’d want, think again. Some companies will sponsor your project because they use it internally and want to ensure its success, but others will see sponsorship a lot like buying an advertisement: it’s just publicity in exchange for money, and they don’t care what happens to the project.

If a less-than-reputable company signs up to sponsor your project just for publicity, you may need to use the moderation tools at your disposal to limit these companies’ ability to donate your project. Make sure to monitor incoming sponsorships to ensure that these are companies you want to do business with.

Aside from ensuring your sponsors align with your values, you also need to make sure you’re accepting sponsorships from companies that other companies want to have their logo next to. If your first couple of sponsor logos are for overseas online casinos, is that something Google or Microsoft or Amazon would want their logos next to? Of course not.

Your first sponsorships, in particular, may have a disproportionate impact on how potential sponsors see your project. If your first logo is Microsoft, that will encourage other companies to sponsor your project; if your first logo is Joe’s Tackle and Sports Book Shop, that’s not going to entice new sponsors.

Action item: Create a sponsorship policy that lists out what types of companies you will (or won’t) accept sponsorships from. Post this publicly so everyone is aware, though keep in mind that few companies will read this upfront. It’s just helpful to be able to point them to your policy when questions arise.

Conclusion

Early on in ESLint’s fundraising, several companies told the project they would sponsor the project if we signed up for Open Collective. Not all companies will be that forward with projects they want to sponsor. That’s where the suggestions in this post come in. By using trusted third parties to collect donations, display sponsor logos, explaining how you’ll use the funds, and being careful about which companies you accept sponsorships from, your project will be more attractive to companies. Meeting companies where they are, especially if they are already sponsoring other open source projects, is the best way to get started.

This guide is a work in progress and will be updated as we receive new information. If you have a request on how to receive funds from an even you do not see mentioned on this page, please reach out to 'support@opencollective.com'.

Google Summer of Code

If you plan on participating in Google Summer of Code, please follow the instructions below to complete your payment request form.

On the first page of the form:

• The email address of the person responsible for accepting payment at your Organization is -- support@opencollective.com

• Does your Mentor Organization have an account with Payoneer and linked to the GSoC Program? -- Select the 'Yes' checkbox.

On the second page of the form:

• What is the EXACT name of your account in the Payoneer system? -- Open Source Collective 501 c 6

• What is the email address associated with this Payoneer account? -- support@opencollective.com

• If you are accepting funds for several orgs, have Linux Foundation, NumFOCUS, Open Collective, Software Freedom Conservancy, Software in the Public Interest, or another fiscal sponsor, please note it here. -- Open Source Collective

Once you have completed the form, send us an email to let us know you will be participating and we will track the payment associated with your organization.

This is a summarized version of Ten Steps to Successful Open Source Crowdfunding.

So, your open source project is ready for community financial support. Great! Here’s how to nail it.

Before You Launch

1) Involve your community.

Open Collective is designed to fund collaborative communities, because that’s how open source is built. So it’s important that your key contributors feel like it’s theirs. Because it is! Start a discussion wherever your community hangs out, to let people know what to expect and give them a chance to share their ideas and concerns about raising money. If contributors feel a sense of co-ownership with fundraising, like they do with the codebase, they will be your first donors and most passionate champions.

2) Clarify your mission.

Have you ever sat down and very succinctly articulated why exactly your project exists, and what it offers the world? Can you explain your mission in one paragraph? How about one sentence? The better you communicate what you’re doing, the more people will support you. It’s ok if you’re not a marketing expert! You just need to be clear and honest about the value your project provides.

3) Ready your champions.

Early momentum is important in crowdfunding. People like donating to projects that other people are also supporting, because they want to have collective impact. Reach out to your potential funders before you launch, and ask them to donate on the first day to get the ball rolling.

When You Launch

4) Publish a blog post.

Launching your collective is exciting news for your project. Write a blog post so people know what’s going on, and so people have a link to share. Explain what you do, why you’re raising money, and how people can donate. Address any concerns people might have. This is a great opportunity to celebrate your community and paint a picture of what funding could make possible in the future.

5) Offer a menu of contribution options.

List the different ways people can contribute to your project on your website and README, donating money being one of them. The more options available, the more people can participate.

6) Celebrate your financial contributors.

Feature your community of contributors proudly, on your website, social media, and your repo. You can connect your Twitter account in your Open Collective settings to automatically thank donors.

7) Get the word out.

Many people need to hear about something new through a few different channels to get inspired to act. Tweet about your Collective and encourage donors to share on social media. Submit your blog post link to forums where your users and supporters congregate. If you have a mailing list, send out a special update.

After You Launch

8) Reach out to potential sponsors.

Having lots of small donors is great for community building, but big budgets are usually funded by companies giving larger amounts. An Open Collective page helps your pitch by showing your enthusiastic and active community and clearly stating your mission. What businesses rely on your project? Who might be harmed if your project wasn’t being maintained as well? These companies will have a real interest in your continued success.

9) Submit expenses

People donate because they want you to use their money to power up the project. So get proactive! Print stickers and other merch, cover costs associated with conference talks, and financially support people who make key contributions. Think about your community’s priorities for the project, and how money could help. For some projects it’s about code, but for others it’s more about community support, documentation, and outreach. If you’re not sure what’s most important to your community, ask them!

10) Keep engaging

Tell stories about what financial support has made possible. Listen to feedback about what tiers funders want and update your offerings. Set funding goals, and describe what that next level could look like when you reach it. Keep listening, learning, and sharing.

This is a guide based on two Open Source Collective workshops led by Sumana Harihareswara of Changeset Consulting in early 2022. It focuses on maintainer burnout and career planning for leaders of Open Collective-hosted open source software projects. Thanks, Sumana!

Start with the end

All maintainers eventually leave (or stop leading) projects.

In open source, this often happens messily, in a way that leaves users with unclear expectations and drains maintainers' morale as things shamble slowly to a stop. For example:

• none of the team will admit that the project is out of energy, so the public-facing communications are contradictory and set misleading expectations until a domain expiration or missed migration notice lead to an abrupt 404

• the lead maintainer refuses to either promote co-maintainers or address critical problems, so time and attention are wasted with a fork

• the sole maintainer completely disappears from public view or interaction, often due to feeling overwhelmed with obligation and compounding procrastination with anxiety over making up for lost time, and leaving users to find and share makeshift workarounds to their concerns

• maintainers think everything's quiet and it's safe to hand off maintainer control to a somewhat unknown contributor, who then turns out to be a malicious actor who inserts malware or other vulnerabilities into the code

As a maintainer -- and as a user -- you don't want those endings. It's worth taking a moment to imagine: what would a good departure look like for your involvement with your project? Or, if you can't imagine any of these things feeling good, what endings or departures would be better than the bad ones listed above -- clearer, more respectful, less wasteful?

Example better endings or departures:

• pass the project off sustainably to other maintainers

• work with upstreams or downstreams to merge your codebase into theirs, e.g., Enigmail ending support for Thunderbird as Thunderbird added built-in PGP support

• make an assessment that advances in other technologies render the need for the project obsolete, and archive the project to clarify expectations that there will be no further maintenance

• announce that the project is set to be sunsetted so your users can start planning their migrations, and invite your users to crowdfund labor to keep it going or help them migrate to an alternative, as in this hypothetical example

Certainly none of these changes would be painless, and some of them place a substantial burden on users. But, unless you have ongoing and reliable support from your users, they can have no reasonable expectation that the project will continue to update or that you in particular will continue to maintain it. You might need to leave due to unavoidable personal circumstances, from leaving a job to having a child to dying. Or, technological changes could cause a project to wither or no longer be necessary, as when it's written in a language that popular operating systems stop supporting, or another tool grows to include your tool's functionality. An explicit, publicly announced, scheduled sunsetting of a project or maintainer departure is better because it gives everyone else a better chance to make and execute plans to take care of their own needs.

Maintainer activities, of course, aim to keep a project going; we want to avoid its end, and maybe we feel obligated to do so and thus feel conflicted and averse about the possibility of someday leaving. The point of this exercise is to concretely imagine what a positive (or less-painful) end could be for the project or for your participation, so you can potentially start building a path to it or noticing when it's time to switch to a Plan B that involves ending the project or your maintainership.

Concrete steps towards maintainer succession

Consider this diagram of how people flow through a project:

You can encourage healthy movement with steps such as:

• when people go from Contributor to Maintainer, or from Maintainer to Emeritus, publicly salute all of them. This encourages other contributors to consider that they could earn promotion, and helps contributors and maintainers recognize that it's okay to leave after doing their bit.

• actively communicate with the people you might someday want to promote to co-maintainer. Many reticent contributors wait to be invited to co-maintain, or aren't certain how they need to grow to earn a promotion. Ask them about what their interests and help them understand what it would take for them to become co-maintainers. (More guidance is forthcoming in our "Recruiting and promoting maintainers" guide.)

• use rituals such as the twice-yearly Volunteer Responsibility Amnesty Day to regularly take inventory of your volunteer responsibilities. Check with yourself, and end (or plan to end) the commitments you need to end – maybe by taking a break, or by rotating it on to someone else, or by sunsetting a project.

• use GitHub's "assign a successor" setting to ensure continuity in case you die.

Perfectionism, procrastination, and burnout

Maintainers sometimes resist thinking about taking a break or leaving because we think no one else could do our work as well as we do it, or because we perceive ourselves to have made an unbreakable commitment, an obligation that nothing else can supersede (even our own mental health). We also procrastinate doing work we are averse to or afraid of, especially when we don't think we're up to doing it as well as it deserves. Here are some resources to help you reflect on these habits:

• on overcoming procrastination based on perfectionism: Amandine Lee's "Risk Assessment Analogy", discussing failure scenario generation, safety, and verification, says that knee-jerk caution can be reflex that leads to, as Lee calls it, "wasteful carefulness":

  • we often push to a small percentage of real traffic, do bug-bashes and conduct pre-mortems where we imagine different types of failures and what would have caused them. We're trying to smoke out the unknown unknowns that cause issues. It's a type of thinking I am actively learning how to lean into. As an optimist, someone who tends to seek out nuance, and a person who has a strong bias towards action, I tend to chafe against risk-aversion without a clear threat model. The term "Cover Your Ass" gets thrown around to describe extreme end of this - wasteful carefulness. .... ...People's intuitions and risk-friendliness also vary based on personality, and how they’ve seen things fail in the past. A lot of growing as an engineer is fine-tuning that initial response to design decisions.

• How do you tell the difference between needing a break and needing to stop? How can you decrease your involvement in a project without stepping away completely? "On Noticing That Your Project Is Draining Your Soul" offers some guidance.

• "Wellness is not a state of mind, but a state of action. It is the freedom to move through the innate cycles and oscillations of being human - from effort to rest and back, from connection to autonomy and back, from adventure to homecoming and back. But we have been lied to our whole lives about what wellness 'should' look like, and rejecting that lie, all those myths about 'having it all' and 'finally achieving lasting peace' is how we create space in our lives for that free action through the cycle of being human." Emily Nagoski and Amelia Nagoski, Burnout. (Also check their list of ways to complete the stress response cycle.)

One hint that you might be burned out: when you even think about the project, you feel massive don't-wanna-get-out-of-bed aversion. Perhaps you should try a 3-month break from the project, temporarily, and at the end, see whether you have any desire to return to it.

Career

Are you in a job you want to be doing? This may go beyond your maintainership work. Self-determination theory suggests that you need autonomy (you get to choose what you do), competence or mastery (you are good at your tasks and achieve the desired outccomes), and connectedness or relatedness (you and others care for each other; some people connect this to purpose, i.e., you can see the connection between your efforts and progress towards a goal you care about). Are you getting these things in your current roles?

Here's a 20-minute exercise you can do to help map out what you want next in your career, remixed from an exercise for Outreachy open source interns:

1. 5 minutes: What specifically do I like about my current role: what would I like to get more of? (Think specifically: what languages, tools, people, activities, and conversations do you enjoy? If you can't think of anything in your current role, think about past jobs, volunteer roles, etc.)

2. 10 minutes: What do I want next, and what are my constraints? (It's okay not to know! This is a good time to make a note to ask peers what they think you would be good at, and if you have peers you envy, ask them how they got where they are.)

3. 5 minutes: What are my next steps? Examples: update your resume/CV, ask your friends to schedule some mock interviews, reply to people you met at conferences, blog about what kind of job you want, apply for a grant, apply to Recurse Center or talk to a venture capitalist.

This is a guide based on several Open Source Collective workshops led by Sumana Harihareswara of Changeset Consulting in early 2022. It focuses on skills in handling conflict, addressing difficult issues, and recruiting and promoting maintainers for Open Collective-hosted open source software projects.

Handling conflict and tackling difficult issues

You can do this

We all develop skills in handling interpersonal conflict and dealing with sticky issues. You can use the skills you already have and bring them into your open source work.

Sometimes it feels like open source is an odd world, neither exactly like a workplace nor like a friends-and-family setting. But it has aspects of both, so when you need to resolve conflict, you can consider approaches you would use at work and approaches you would use with family and friends.

In a small team, it might feel very risky to bring simmering conflict out into the open, for fear of losing contributors and endangering the project. And, if the team is small, or the subset of the team that is willing to engage in confrontation or reconciliation is small, you might fear that you do not have the critical mass to persuade someone to behave differently, or to keep the project going if they leave. Or you might just have no one to talk with about what to do. In that case, consider talking with other OSC collective maintainers in the OpenCollective Slack to share perspectives and think about a path forward.

Systems and relationships

When you're dealing with a difficult person or issue, remember that you can use both systems and relationships.

On the systemic level, you can use and create social and digital structures to help encourage people to treat each other well, and mitigate the effects of people rubbing each other the wrong way. For example, you can add moderation to forums and issue discussion platforms. You can create a word or time limit, to reduce the soapboxing that any one person can force on the rest of the group. You can work to build a code of conduct and/or a Values statement to create a shared set of expectations for how people should treat each other, and use that to support the slow work of coaching or removing someone whose behavior isn't up to the standard. You can refocus someone's energy by offering them a badge and a committee so they can dig into the topic they're passionate about (while reducing friction with others).

You can also work using interpersonal relationships, talking privately (in text or audio/video chat) with specific people, including people who are proving difficult. Ask them for context and advice about how the project should be handling issues -- if you have private discussions with several different people, with different points of view, you'll often get insight into the underlying tensions that are causing conflict, and can address those causes. You can also, in private, sometimes ask questions that would look like sideswipes if you asked them in public, such as: "if you were new and you saw what you just wrote, would you feel it was welcoming?" -- as long as you genuinely follow up those questions with discussion.

If you have a working relationship with someone who is abrasive to a lot of their peers, and their uncongenial behavior is causing problems, you may be able to have a frank conversation with them to help them understand that their abrasiveness is making them less effective. As someone once told Benjamin Franklin (per Dale Carnegie's paraphrase in How To Win Friends and Influence People):

Ben, you are impossible. Your opinions have a slap in them for everyone who differs with you. They have become so offensive that nobody cares for them. Your friends find they enjoy themselves better when you are not around. You know so much that no man can tell you anything. Indeed, no man is going to try, for the effort would lead only to discomfort and hard work. So you are not likely ever to know any more than you do now, which is very little.

And: when you're having trouble handling someone who really gets under your skin, consider that they might be really bothering you because of ways they remind you of yourself. They may have a lot of your strengths but be taking them in an antisocial direction. Recognizing that can help you get a better handle on your own feelings so you can act productively.

Recruiting and promoting maintainers

To grow the number of maintainers for your project, you need to consider retaining and growing the contributors you already work with, using both systematic process and your own relationships with potential maintainers. Some steps here are similar to steps you can take to increase how many contributors you have and the quality and frequency of their contributions.

Assess contributor retention

If existing contributors are stagnating or leaving instead of staying and getting promoted, it probably makes sense to focus on increasing retention before increasing inflow. That's what Wikipedia and its sibling projects realized when facing a decline in contributions around 2011. English Wikipedia was getting people in the door to edit for the first time, but they often bounced off the process and stopped somewhere in their first dozen edits. So Wikimedia analyzed why, launched experiments, and worked to smooth obstacles that were getting in the way of retention.

Consider your "engagement funnel" -- what stages a contributor passes through to become a core member of your team. On Wikipedia, the stages could be summarized as going from "-1" to "100":

1. "-1": the user doesn't even realize they could edit Wikipedia.

2. "0": the user realizes they could, but haven't done so yet.

3. "1": the user has made their first edit, getting over their own hesitation and any technical obstacles.

4. "10": they've made 10 edits, which means they've successfully dealt with any unpleasant social interactions stemming from their first few edits.

5. "100": they've made 100 edits, so they're thoroughly used to the technical side and the social side of editing, and may have taken leadership of a topic area.

Try a similar assessment of your contributor base, putting your contributors in buckets based on how many times they've contributed. When you're finding potential maintainers to recruit, nurture, and promote, it's most productive to focus on users who already know the terrain, such as people who have made 10-100 contributions. (Think outside the box: these contributions might include translations, useful replies on an email list, good bug reports, or independent blog posts or StackOverflow replies.)

Patterns in your promising contributors

Spend five to twenty minutes to review the most promising contributors (who aren't already maintainers) you've had in your project, and think about their work and their judgment. What do they concentrate on? Are they better than you at anything? What would it take for you to entrust them with maintainer privileges?

Approaches to retain and upskill existing contributors

Provide alternate structures for high-quality contributions from strong contributors. One reason to promote contributors to co-maintainer is to get their expert advice and input more frequently, but in many cases, you don't have to share code commit privileges for the repository to share power and get input. Provide alternate structures for contribution:

• Give users privileges to triage issues in your bugtracker. Once you know a user has reasonable judgment, can take feedback well, and understands your project's features and workflow better than most users do, go ahead and give them privileges to resolve, close, merge, label, or assign issues.

• Do you have a private group chat that's only for the core team? Consider allowing the most productive contributors and helpful users in there even if they're not part of the core team. Social bonding using chat, video calls, meetups, and similar unstructured or semistructured gatherings can help people feel like part of a team, and cement their desire to help their friends make progress.

• Some people who inconsistently contribute have insufficient time to be official core contributors. Consider suggesting to them that they use another developer as a proxy, someone who can take their ideas as starting points and co-author the finished patches.

• Some contributors are subject matter experts in particular areas. You can create 3-5 person "tiger teams" or "advisory committees" of people who are specialist experts. Through meetings or through labels and notification settings, you can ask for those teams to review specific issues and patches, and possibly even give them final sign-off power.

Ask them to review patches/pull requests. Even before someone is a core team member with privileges to merge code into the main branch, their reviews can help find easy-to-notice problems, help them learn how the codebase works, and save time for other reviewers.

You can use technical tooling to help contributors get notified to review PRs. You can extend GitHub's functionality using labels, subteams, and tools like zulipbot to [create teams and improve the specificity of notifications]((https://zulip.readthedocs.io/en/latest/contributing/zulipbot-usage.html). Or: carsonbot is an issue bot for the Symfony project that helps automate different issue and pull request workflows. Depending on who has write permissions to the repository, you may also be able to use a CODEOWNERS configuration file for GitHub automation (see GitHub documentation). You could also develop tooling to automatically ping appropriate reviewers for each patch based on reviewers' commit history touching those files, but be cautious, as errors with this can lead to notification fatigue and reviewers feeling nagged.

Personally invite them. Many contributors assume that it's impolite to ask for maintainer privileges, and assume that they'll be invited if they're good enough. If you're not sure whether someone's interested, and you think they're a strong contributor, go ahead and ask them -- personally, not with a form letter.

Follow up on interest systematically: You don't have to manually remember whom you're trying to recruit and how they're doing. Check out what Asheesh Laroia and his colleagues in Debian did with the Debian New Members site, which is basically a Trello board to track the progress of applicants and see whom to ping/remind.

Approaches to attract new maintainer-track contributors

You can recruit people who aren't yet contributing to your project, and in particular, you can do this in a way that increases the chances those people will be future co-maintainers.

Mentor interns. Use Outreachy, Google Summer of Code, and similar mentorship programs. During internships, ask your interns about their career plans so you can help them find ways to pursue their career goals while continuing to contribute after the end of the internship; outline for them how they could become co-maintainers and how this would help them in their careers. Continue to actively engage with your intern alumni after the internship.

Hire contractors. You can hire a contractor who is reasonably skilled in a domain relevant to your project, and work towards getting them knowledgeable enough about your specific project that everyone can feel comfortable promoting them to co-maintainer. Then, when you have available money again in the future, you can hire the contractor again to help speed up project work.

Exercise: make a draft plan to promote someone

Imagine that you are considering promoting an existing contributor to co-maintainer. Plan it out. What are your criteria? What schedule would you expect? What privileges would you offer, and in what order?

For some projects, this is a very quick process with a fairly low bar. They'll offer maintainer privileges to all consistent contributors, as long as they have good judgment and are in frequent communication with the rest of the core team. They look for enthusiastic contributors who have created issues and/or pull requests, and who continue to stick around and communicate after their first few PRs.

It's okay to have a more deliberate process; maybe you'd like a potential maintainer to take a week or two to shadow a current maintainer while they reply to issues and review patches before you give them the keys. Or maybe you are more willing to share the chat moderation and social media posting privileges than you are to enable someone to upload a new release tarball/executable.

Whether your plan would be 4 steps over four weeks or fifteen steps over eighteen months, having an outline will help you -- and candidates -- understand what to expect.

Sometimes, we get applications from developers who are keen to have their personal projects hosted by Open Source Collective, but who don't have a huge amount of contributors yet. The main things we look for at OSC when we judge whether or not an open source project has a large enough community to justify hosting are:

• Active contributors to your code base (more than just the admin or maintainers, too!)

• That your GitHub (or other platform) project isn't hosted under your personal account

• A Code of Conduct

• Contributing guides

• Onboarding guides

• A filled out README file

• Governance documentation

• A website for your project

So, how do you take your project from one person to more?

Good question! First, I would work on the items mentioned above. Ask your friends, colleagues, or coding partners to help contribute to your project. If they don't seem interested, it means that you may need to work a bit harder, by incentivizing contribution:

• Make it clear in your README what your project is, what it is meant to do, and how you would like it to grow.

• Write a section in your Contributing guide about what a meaningful contribution means to you - is it opening bug reports? Issues? Attempting to install it locally? Submitting PRs?

• Make easy issues which new users can tackle in their first Pull Request. Don't close them yourself, but leave them for others to learn how to work on the project with you.

• Create a Code of Conduct to talk about what your project allows for interactions, and how poor interactions are dealt with. The Contributor Covenant is a good starting place.

• Write a section in your contributing guide about how people can ask to become maintainers. What do they need to show in terms of skill or involvement, first? What are the commitments and expectations for maintainers? What are the benefits? These are great questions to answer in your contributing guide.

• Praise contributions. Being nice and grateful goes a super long way towards making others feel valued.

• Ask your other maintainers if they want to help set up an organization on GitHub for the project, to cover not only the main repository but extra repositories, and to make it clearer to everyone that this project has long term plans for existing.

• Think about your goals for the project: where do you want it to be in ten days? A month? A year? Ten years? Write these down.

• Use a tool like all contributors to incentivize non-code contributions. You don't have to code for the project to be useful - PMs, designers, documentation writers, and others are all important for a project's health.

These are just some ways to get started. There are more guides in this GitBook that can help you out.

When you're ready, re-apply for OSC hosting!