# Welcome to Open Source Collective Docs Open Source Collective is a nonprofit that promotes a healthy and sustainable open source ecosystem for those who create, maintain, and rely on open source software. ## Not Sure Where to Start? This documentation is your go-to resource for understanding and working with OSC. Whether you're: * A [**prospective open source project or community**](/interested-in-joining-osc/is-osc-right-for-me) exploring fiscal hosting with OSC * A [**sponsor or funder**](/for-donors-companies-organizations-and-individuals/companies-and-organizations) looking to support an open source project * An [**existing OSC-hosted member project**](/for-hosted-member-projects/your-project-was-just-accepted-now-what) in need of policies, procedures, or support *** ## New Here and Wondering Who We Are? A lot of folks land here looking for insight into who we are and what OSC actually *is*. Here are a few helpful starting points to better understand OSC: * [**What is fiscal hosting?**](/welcome-and-introduction-to-osc/what-is-fiscal-hosting) Get an overview of the support we offer through fiscal hosting to help projects raise and manage funds without needing to form their own nonprofit. * [**Our services and benefits.**](/welcome-and-introduction-to-osc/our-services-and-benefits) Find out what we offer to projects, communities, and organizations. * [**What are your fees?** ](/welcome-and-introduction-to-osc/fees)Learn about our fee structure and what those fees support. * [**Why do projects become members of OSC**](/for-donors-companies-organizations-and-individuals/why-projects-use-open-source-collective-for-donations)[**?**](/for-donors-companies-organizations-and-individuals/why-projects-use-open-source-collective-for-donations) Discover why thousands of projects rely on us as their fiscal host. * [**What are your terms of hosting?**](/welcome-and-introduction-to-osc/terms-of-fiscal-sponsorship) Read more about our expectations, agreements, and the responsibilities of being hosted by OSC. * [**Who we are and what we do**](/about-osc/what-is-osc)**.** Learn more about our mission, the team at OSC, and how we help sustain open source * [**Explore our hosted member projects**](https://opencollective.com/opensource)**.** Browse the many projects and communities that we're proud to support. # What is Fiscal Hosting? What is fiscal hosting, and how does Open Source Collective do it? ## What is Fiscal Hosting, And What is OSC's Approach? [Fiscal hosting](https://opencollective.com/fiscal-hosting) lets your project access financial and legal infrastructure without needing to form your own legal entity. At Open Source Collective (OSC), we offer this service to projects, communities, and funding initiatives focused on their code and community. If your project is approved, OSC provides: * **Fund management** — we hold the project's funds, providing you with the tools to fundraise and track expenses. * **Contribution processing** — we manage third-party payment processors, such as PayPal and Stripe, and handle refunds, chargebacks, and fraud prevention. We are also registered with vendor portals to receive funds from organizations, including Meta, Google, Amazon, Intel, and others, when a donation invoice is required. * **Payment processing** — we process payments to your vendors and maintainers, including individuals and organizations worldwide, while navigating international currencies and compliance requirements. * **Tax and legal compliance** — we handle tax filings, issue receipts, and ensure compliance with nonprofit regulations. * **Legal contract review** — we draft, review, and sign agreements on behalf of our hosted member projects. * **Oversight and accountability** — we ensure funds are used responsibly and in line with your project's open source work. This setup lets you focus more time on building your project and serving your community. Under the fiscal hosting model we’ve adopted, projects retain their autonomy. However, OSC remains responsible for financial oversight, ensuring your funds support open source initiatives. *** ## Using the Open Collective Platform OSC uses the [Open Collective platform](https://opencollective.com/opensource) as our public financial ledger. This offers our hosted member projects a transparent, accessible, and real-time way to manage their funds. Using this platform means: * **Direct contributions —** our hosted member projects can receive contributions directly via credit card, PayPal, and more — just share a direct link to your Open Collective profile to make it easy for supporters to donate to your project\*. * **Public visibility** — anyone can see where money comes from and how it's spent * **Real-time tracking and reporting** — your balance updates instantly when contributions are received through the platform or expenses are paid. **Privacy Note**: While transactions are publicly visible, private details (such as emails, names, and addresses) are only visible to admins. The platform also includes tools to help you engage with your community, share updates, set funding goals, and more. Learn more about what you can do on Open Collective [here.](https://docs.opencollective.com/help/collectives/quick-start-guide) {% hint style="info" %} *\*If an organization prefers to contribute via an invoice, we can facilitate that and allocate the funds directly to your Open Collective balance, too.* {% endhint %} *** ## How We Differ From Other Fiscal Hosts OSC is a U.S.-registered 501(c)(6) nonprofit that supports the infrastructure needs of open source projects. Unlike charity-based fiscal sponsors, which are typically 501(c)(3) organizations, our model works a bit differently. Here are a few key points to know: **Projects can hold funds outside of OSC** Unlike some fiscal hosts that require all project funds to remain in a single fiscally hosted account, OSC offers flexibility. We don’t have a “no outside money” policy, so projects can hold funds in separate business entities. Keep in mind that OSC can only help you manage the funds we hold on your behalf, nothing else. **Donations are not tax-deductible** Because we are a 501(c)(6), OSC is not a registered 501(c)(3) charity; donations to hosted member projects are not tax-deductible. This is consistent with IRS guidelines — open source donations aren't automatically classified as charitable simply because they are FOSS. If your project has a clear charitable purpose, a 501(c)(3) fiscal sponsor may be a good fit. *** ## If We're Not the Right Fit Not every project is a match for OSC. If your project doesn't fit within OSC's scope, other fiscal hosts may be a better fit. If you're considering other fiscal hosts, here are a few questions to ask: 1. Do they align with your project's mission? 2. Do their tools and processes support your needs? 3. Are they transparent to their donors and sponsored projects? If you want to use the Open Collective platform but need a different fiscal host, you can [browse the other fiscal hosts](https://opencollective.com/search?isHost=true) that use the Open Collective platform to find one that better suits your project's needs. Looking for more guidance? Check out [Ten Things to Look for in a Fiscal Sponsor](https://taicollaborative.org/ten-things-to-look-for-in-a-fiscal-sponsor) from Tai Collaborative. # Our Services & Benefits What Open Source Collective offers to hosted member projects and open source funders. ## For Open Source Projects and Communities We take care of the paperwork, payments, and overhead so you can focus on maintaining your project and your community. ### Fiscal Hosting OSC provides the legal and financial framework for open source projects that do not have their own formal legal status. OSC handles the banking, legal compliance, taxes, and bookkeeping so the project can focus on its core work. This means the legal, financial, and compliance risks associated with that money rest with OSC, not with your personal bank account. ### Transparent Fundraising and Expenses Every hosted project gets its own public page on Open Collective. Donors and community see exactly what's been raised and how it's being spent in real time. Use those funds for project costs (servers, bug bounties, maintainer payments, conference travel) by submitting an expense. ### Virtual Cards Use the money directly from your balance without waiting on a reimbursement. You can get a card tied directly to the project's balance, so spending happens in real time and shows up in the ledger immediately. Cards can be issued, capped, or shut off per project, so there's a spending control in place without anyone needing to share a physical card. ### Contracts, Invoices, and Legal Agreements Signing a contract, accepting a grant, or sending an invoice usually requires a legal entity. OSC signs and reviews these on the project's behalf, so a maintainer can say yes to a conference sponsorship or a grant with legal terms attached without needing to create a legal entity first. ### Employment, Payroll, and Benefits We'll draft the contractor agreement so you can pay contributors properly. If the project can support it, we can put someone on full-time payroll with benefits, so maintaining stops being a side project and can become an actual job. ### Trademark Registration and Holding OSC will help you file for and hold the trademark on the project's behalf, so there's a legal owner of record and someone with standing to act if a company starts using your name without permission. It also means the mark isn't tied to any one maintainer, so it doesn't disappear if that person steps away from the project. ### Domain Transfers and Registration Project domains usually end up registered to whoever happened to buy one first. If that person forgets to renew, loses access, or moves on, the project can lose its own domain. We can handle registration for you, or you can transfer your existing domains to OSC, so it's not reliant on one person's memory or credit card. ### Apply for Grants We receive grant funding on your project's behalf, including acting as a subawardee for NSF grants, and help with the paperwork along the way. ### Conference Support We help maintainers attend conferences and support organizers in hosting their own events. ### A Collective Voice and Representation We advocate for open source projects and promote sustainability in the ecosystem on your behalf. ### Networking and Peer Support With a network of over 2,500 hosted projects, we provide a built-in network that offers connections and support from the open source community. *** ## For Open Source Donors and Funders Our goal is to make it easy to fund the projects you care about. Whether you're giving back to a single project or managing financial contributions across multiple dependencies, here's how OSC helps you contribute: ### Centralized Funding Management Streamline your contributions by working with OSC as a single supplier for multiple open source projects. ### Flexible Funding Options Contribute using a method that works best for you or your organization, including credit card, PayPal, bank transfer, invoicing, or a dedicated Fund in your organization's name. ### Simplified Invoicing Consolidate payments — one invoice can support multiple projects — to reduce administrative overhead ### Full Financial Transparency Track your contributions in real time through the Open Collective platform, ensuring clear reporting and accountability. ### Custom Financial Workflows Do you need a tailored funding approach for your organization? We can develop custom workflows that can align with your organization's accounting, legal, and compliance requirements. # Fees Open Source Collective's fee structure ## How Our Fees Work #### Host Fee Open Source Collective (OSC) charges a fixed **10% host fee** on incoming funds. This means that when money enters a hosted project from an external donor, the fee is collected at that time. This is a payment from the hosted collective or fund account to OSC. OSC does not charge for any other services it offers. There are no setup fees, minimum balances, or recurring charges to be part of OSC. OSC does not charge any fees for moving money between hosted collectives or funds. #### Payment Processor Fees We use third-party payment processors, such as Stripe, PayPal, and Wise, which apply their own processing fees to incoming donations and outgoing expenses. **Their fees vary** based on payment method, currency, and the country involved in the transaction. These fees are deducted from the collective balance at the time of the transaction. There are ways to reduce these fees, including bundling your transactions, using a bank transfer instead of PayPal, or having the recipient set up a personal Wise account to receive the funds. *** ## What Our Fees Pay For Host fees cover our costs for operational, legal, infrastructure, and financial services provided to hosted member projects. Beyond fiscal hosting, these fees also support our [broader community work](/about-osc/oscs-broader-work). :point\_right: [**Our budget is fully transparent — view it here.**](https://opencollective.com/opensource#category-BUDGET) *** ## Can OSC Give Our Project a Discount? Open Source Collective does not offer discounts. We maintain a small buffer, lasting 6-12 months, in our core team costs to help us weather challenges such as pandemics, recessions, and other financial risks. In exceptional cases, we may consider a fee reduction for an extraordinarily high one-time donation or a balance transfer from another nonprofit. Any fee reduction is at OSC’s sole discretion and will be reviewed on a case-by-case basis. # Terms of Fiscal Sponsorship Read Open Source Collective's terms of fiscal sponsorship before applying. Before you apply to join Open Source Collective, make sure to review our [Terms of Fiscal Sponsorship Agreement](https://docs.google.com/document/u/1/d/e/2PACX-1vQbiyK2Fe0jLdh4vb9BfHY4bJ1LCo4Qvy0jg9P29ZkiC8y_vKJ_1fNgIbV0p6UdvbcT8Ql1gVto8bf9/pub), the legal agreement that defines the relationship between OSC and a hosted member project. {% embed url="" %} It includes a “plain English” version alongside it to help you understand the key points. We strongly encourage you to read the full document. Have any questions? [Reach out to us.](mailto:hello@oscollective.org) # Is OSC Right For My Project? How to determine if Open Source Collective is the right fit for your project. If managing the financial or legal aspects of your open-source project is consuming too much time, fiscal hosting can help. The Open Source Collective (OSC) handles the financial, legal, and administrative work, allowing you to focus on your project. Fiscal hosting isn't right for every project, though. If you don't need help managing money or legal agreements yet, OSC's structure might introduce more process than you need at this stage. Continue reading to see when OSC suits your project, when it doesn't, and what other fundraising tools are available if fiscal hosting isn't the right fit. ## When We Might Be a Good Fit
OSC Might Be a Good Fit If You:Why:
Don't want to manage financesOSC handles accounting, taxes, and compliance
Receive corporate or institutional fundingOSC is registered as an approved vendor and can facilitate payments from organizations
Prefer not to hold project fundsFunds are securely held by OSC, so you're not personally liable — except for taxes on payments made to you
Need to pay multiple contributorsEasily distribute payments to your team in different countries
Want financial transparencyWe use the Open Collective platform, which provides a transparent ledger
Make regular payments to people or companiesSimplifies financial workflows for ongoing expenses
Want to offer employment and benefitsOSC supports employment contracts, payroll, and benefits
Need help with contracts that will involve funds that OSC holdOSC can review and sign agreements for you, as long as they are contracts that we have the ability to oversee
Have international contributors who receive paymentsOSC can distribute funds globally
Will be receiving general contributions to support your project's open source work, rather than business transactions that do not benefit the open source aspect of your projectOSC is designed to support open source sustainability by handling funds that benefit open source. We are not structured to process business income intended for individual benefit or specific client transactions.
If this sounds like you, review our [Ready to Apply? page](/how-to-apply) and then apply [here](https://opencollective.com/opensource/apply). *** ## When We Might Not Be a Good Fit
OSC May Not Be a Good Fit If You:Why:
Are the only person handling finances and don't need transparencyOSC is designed for collaborative projects that benefit from financial transparency
You only need to pay one person (including yourself)Fiscal hosting is better suited for projects with multiple contributors that require payment
Expect to receive less than $600 USD in donations annuallySmaller projects may find other platforms more suitable
Don't use an open source licenseWe only host projects with active licenses
Don't want to share or open up ownership of your projectOSC does not host projects that are tied to an individual's personal repository. To be eligible, projects must be organized under organizational repositories to ensure shared ownership
Want to hold funds in a currency other than USDAs a U.S. nonprofit, we only hold funds in USD. The Open Collective platform will convert payments automatically from other currencies into USD.
Need payments sent to a country under sanctionsAs a U.S., organization, we cannot process payments to sanctioned countries
Are looking to accept funds for services or business transactions that directly benefit an individual or customer, rather than general contributions to support open source work.OSC is structured to facilitate funding for open source, not to serve as a payment processor for business income when it benefits an individual rather than the broader project or open source ecosystem.
*** ## Alternative Fundraising Platforms Every project has unique needs, and if fiscal hosting feels unnecessary, you may want to explore fundraising platforms better suited for individuals to collect contributions directly, such as: * [Github Sponsors](https://github.com/sponsors) * [Liberapay](https://en.liberapay.com/) * [Ko-Fi](https://ko-fi.com/) * [Patreon](https://www.patreon.com/) # Eligibility Requirements Open Source Collective's eligibility requirements for projects and communities Open Source Collective (OSC) welcomes open source projects of all kinds — from anywhere in the world, in any language (spoken or programming). That includes software projects, open source advocacy groups, open source meetups, open source conferences, open source research efforts, and more — as long as they're clearly connected to open source. That said, not every project will be the right fit with OSC. We review each application carefully to ensure it aligns with our mission and structure. If we feel your project isn't the right fit for our services, we may decline your application. While our decision is final, you're always welcome to reapply when your project meets our requirements. ## Open Source Software Projects To be fiscally hosted by OSC, your open source software project must meet the following requirements: ### 1. Legitimacy Your project should demonstrate active development and meaningful impact. We assess ownership, activity, usage, and originality to determine eligibility. * The project should be original or a substantial fork of an existing project. * The project should show recent activity and/or have a significant degree of usage. * Applicant(s) must have an appropriate level of access and standing in the project's community to act as a representative (e.g., be a maintainer, not just a contributor) ### 2. License Your project license is very important. * Your project must use an open source license that clearly defines how it can be used, modified, redistributed, and referenced by others. * We follow the licensing standards from: * [Open Source Initiative Approved License List](https://opensource.org/licenses) * [Free Software Foundation License List](https://www.gnu.org/licenses/license-list.html) * [Debian Free Software Guidelines](https://wiki.debian.org/DFSGLicenses) * [Fedora Software License List](https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing) * [Open Source Hardware Association Statement of Principles](https://www.oshwa.org/definition/) ### 3. Governance and Autonomy To ensure sustainability and shared ownership, we look at a project's governance structure. * The project must be hosted under an organizational repository, not a personal account. * When possible, the project should always include two or more administrators on the Open Collective page. While we don't impose strict governance structures, we do strongly encourage: * Publishing [contributing guidelines](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), onboarding documents, and a code of conduct. * A clear decision-making process for how the project operates and for its future, especially in the event of leadership changes. * We recommend using best practices for collaborative decision-making. If you are looking for guidance or best practices in governance, we've published a range of guides to help you tackle this work. *** ## Reviewing Your Application * **GitHub Projects:** If you apply using the "verify using GitHub" feature and your project clearly meets our eligibility requirements, your project will likely be approved automatically. Our system uses GitHub authentication to streamline validation — [more info](/how-to-apply/github-verification). * If your project doesn't meet all requirements, our team will manually review your application within a few business days. * **Non-GitHub Projects:** If your project is on GitLab or another platform, you'll need to complete our application. Our team will manually review and process your application within a few days. *** ## Projects & Communities Adjacent to Open Source We also consider applications from communities that are not software-related, with a strong affiliation with or related to open source, such as: * Meetups, conferences, and other in-person or virtual groups or events * Advocacy, research, and awareness initiatives related to open source To be eligible, these communities and projects must: * Have a clear connection to open source, not proprietary tech * Be an active and engaged community, as demonstrated by: * At least 50 members * A history of activity, including at least two past events As further evidence, you agree to send photo/video documentation of your first event after joining Open Source Collective. ### For Larger Events Looking To Join OSC * Larger events may require additional and specific risk assessment by our board. * Projects must have sufficient funds before committing to venue contracts, speaker engagements, or other vendor payments. * All contracts with vendors (including a venue, contractors, etc) must be approved in writing by OSC *** ## What If My Project Doesn't Fit, But I Think It Should If your project doesn't meet our criteria but you believe it should be hosted by OSC, [email us](/about-osc/contact) and tell us why. However, our decisions are final. # Moving to OSC from Another Fiscal Sponsor If you're currently hosted by another fiscal sponsor and considering a transition to Open Source Collective, here's what you need to know. ## Already Have a Fiscal Host/Fiscal Sponsor? If you're considering moving to Open Source Collective (OSC) from another fiscal host, please share why you believe OSC is a better fit for your project. [Contact us](/about-osc/contact) to ensure we can support you quickly and appropriately. ### Moving to Open Source Collective #### Moving from another host that uses the Open Collective platform If you are transitioning from an organization that uses the Open Collective platform, the[ process is relatively simple](https://docs.opencollective.com/help/collectives/change-fiscal-host#what-is-the-process-for-changing-fiscal-hosts). #### Moving from a host that *does* *not* use the Open Collective platform If your project 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 funds to OSC, and we will get you set up on Open Collective. Please be sure to communicate your plans to us [within your application](https://opencollective.com/create/opensource) and your current organization 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](https://docs.oscollective.org/getting-started/fees) apply to funds transferred in. *** ## Moving from a 501(c)(3) Fiscal Host/Fiscal Sponsor ### Key Differences between the Nonprofit Types * 501(c)(3) — A c3 nonprofit is for public benefit. * 501(c)(6) — A c6 nonprofit is for member benefit. ## What does the difference between a c3 and a c6 mean to me and my project? As a 501(c)(6), 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. As 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](/interested-in-joining-osc/acceptance-criteria) 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](/for-hosted-member-projects/spending-money-and-getting-paid/invoice-and-reimbursement-examples). * 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 501(c)(3)s can, including: * Tax-deductible receipts to donors * Fundraising support # Ready To Apply? Applying to be hosted by Open Source Collective takes only minutes! Thinking about joining Open Source Collective (OSC)? Awesome! Before you submit your application, take a moment to review the checklist below. This will help ensure you're set up for success and your application goes smoothly through our process. ## Before You Apply: Make sure you've: 1. Read our [Terms of Fiscal Sponsorship Agreement](/welcome-and-introduction-to-osc/terms-of-fiscal-sponsorship) 2. Review our [fees](https://docs.oscollective.org/getting-started/fees) so that you understand the costs involved 3. Checked that you meet our [eligibility requirements ](/interested-in-joining-osc/acceptance-criteria)and will follow the [Open Collective](https://docs.opencollective.com/help/about/community-guidelines)[ Community Guidelines](https://docs.opencollective.com/help/about/community-guidelines) 4. Have, preferably, 2 community members ready to be added as[ admins](https://docs.opencollective.com/help/collectives/core-contributors) on the Open Collective page. Admins have full permissions to manage settings, approve expenses, and manage the budget. *** ## How We Verify Applications We have two different methods of application: GitHub verification and manual verification. Each method has its own steps and you can read more about those here: * [GitHub Verification](/how-to-apply/github-verification) * [Manual Verification](/how-to-apply/manual-verification) *** ## **Ready To Apply?** :point\_right: [**Ready to apply?**](https://opencollective.com/opensource/apply/intro) [**Submit your application here**](https://opencollective.com/opensource/apply/intro)**.** *** ## What Happens After You Apply If your project meets our acceptance criteria and has no conflicts with our Terms, you're likely to be approved. We aim to review incoming applications weekly. If we have any questions, we'll follow up with you directly about the application. Please note that final approval is at our discretion. We receive a high volume of applications, so there may occasionally be delays in responding to your application. We appreciate your patience and interest in being hosted by OSC. # GitHub Verification For applicants using GitHub Verification ## What is GitHub Verification? Open Source Collective offers the option to verify your project by showing that it meets our requirements. This can expedite the approval of your project. ## What if I can't verify with GitHub? If your project is not centered on a GitHub repository, or you can't get the automated verification system to work, please request [manual verification](/how-to-apply/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 or following our guide: **1.** On GitHub, go to **Settings**. ![](/files/-MNaTPxjUthZJhQUzMVc) **2.** On the Settings menu, click on **Applications**. ![](/files/-MNaTPxijr8OAQzgrafq) **3.** On the **Applications** page, open the **Authorized OAuth Apps** tab and look for Open Collective. ![](/files/-MNaTPxhgWI-cuHanDWd) **4.** Click on the three dots on the right labeled "Show me more options" to revoke the authorization. ![](/files/-MNaTPxgbqFmcimsotZ-) **#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](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization) you have for each one and their third-party access policy, you may need to either grant permission on that page or request it. ![](/files/-MNaTPxenH48L5fxxkAV) ### My repository is listed, but I can't create a **C**ollective (Error: We could not verify you are the admin of the GitHub organization). Depending on your [permission level](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization) within the 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: ![](/files/-MNaTPxaq4VZZW-YbtEH) ### The permissions you're requesting are overly generous, and my organization doesn't want to grant them. We agree that 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](https://github.com/opencollective/opencollective/issues/355), [#1034](https://github.com/opencollective/opencollective/issues/1034), and [#2333](https://github.com/opencollective/opencollective/issues/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 . # Manual Verification For applicants using manual verification If your project is not centered on a GitHub repository, or you can't get the automated verification system to work, you can request manual verification. ## What To Expect One of our team members will manually review your application, so providing as much detail as possible is very helpful. ## What We're Looking For During Manual Verification: In addition to our acceptance criteria, we're looking at... 1. Clear Project Information 1. Tell us who you are and why you're interested in fiscal hosting. with us. Please avoid generic copy-pasting — give us a personal, descriptive look into your project's goals and future plans, and how fiscal hosting fits into that. 2. Your Project's Online Presence 1. Provide us with links to your repos, website, and social media accounts. This helps us get a full picture of your activity and community. 3. Alignment with OSC's Acceptance Criteria 1. Most importantly, make sure your project meets our eligibility criteria before applying ## How To Apply Via Manual Verification 1. Go to 2. Agree to the terms of fiscal sponsorship 3. Click 'Request manual verification' 4. Proceed to create your Collective and await manual review ![](/files/SWvrnaT6303IQQ2YPNB8) ## What Happens Next? * If we have questions, we may reach out to you to request additional information. If we do, we will likely message you via the application itself, so keep an eye on it. You should receive a notification email, but be sure to check your Spam folder for correspondence as well. * If your application is approved, congratulations! Once you've set up your Collective's Open Collective page, you can begin accepting contributions. * If your application is rejected, we almost always inform you of the reason. You are welcome to reapply in the future once you either meet the requirements or make any necessary adjustments. # Companies and Organizations Open Source Collective makes it easy for companies, OSPOs, and institutions to fund and support open source projects. ## Supporting Open Source With the Help of OSC Whether you're looking to invest in your organization's dependencies for the first time, streamline your financial contributions to open source projects, or want to gift grants to open source projects, Open Source Collective (OSC) provides the infrastructure to make it happen. :point\_right: [**Explore our full range of services for funders here.**](/welcome-and-introduction-to-osc/our-services-and-benefits) *** ## Why Fund Open Source Through OSC? * **Streamline Funding Across Multiple Projects** — Manage financial support for multiple open source projects in one place, with OSC serving as a single supplier. * **Flexible Contribution Methods** — Choose what works best for you: * Fund projects instantly, one time or on a recurring basis via credit card, PayPal, or bank transfer * Invoicing through our accounting platform or your vendor portal * **Easily Hold and Distribute Funds** — Set up a "[Fund](https://docs.opencollective.com/help/financial-contributors/organizations/funds)" to easily track and manage your giving on your preferred schedule * **Ensure Financial Transparency** — Track all contributions and project expenses through Open Collective's transparent platform. * **Increase Public Recognition and Visibility** — Your organization's name and logo can be displayed on the Open Collective profile of the projects you support, highlighting your commitment to sustaining open source * **Engagement and impact tracking** — See how projects use their funds, stay updated on their progress, and engage with the communities you support :point\_right: [**Read more about the ways to contribute to projects here.**](/for-donors-companies-organizations-and-individuals/supporting-projects) :point\_right: [**You can see some of the Funds that we host here.**](https://opencollective.com/search?q=\&type=FUND) If you want to create a Fund, register OSC with your procurement team, or explore other ways to collaborate, [email us!](/about-osc/contact) # Individuals Donating to an open source project as an individual ## Supporting Open Source as an Individual Donor Whether you want to support the open source projects you use, or support the ecosystem as a whole, Open Source Collective (OSC) makes it easy to contribute. If you'd like to learn more about who we are, our involvement with and how we handle your contribution, and why the project you support is hosted by us, [click here to read more.](/) *** ## What Contributing Through OSC Means For You * **Directly Support the Projects You Use** — Your contributions go straight to the projects you choose * **Flexible Giving Options** — Make a one-time or recurring donation through the Open Collective platform using a credit card, PayPal, or bank transfer. * Some projects also participate in programs, such as GitHub Sponsors, where you can also contribute. If a project is enrolled, we often manage its funds through that program as well. * **Transparency and accountability** — OSC is responsible for ensuring funds are tracked and managed appropriately. We use the Open Collective platform, which provides full financial transparency, so you can see how your donations are used. * **Public or anonymous contributions** — Choose to have your name displayed as a donor or give anonymously. * **No minimum donation amount** — Every contribution counts. Support whatever level works for you. :point\_right: [**Read more about the ways to contribute to projects here.**](/for-donors-companies-organizations-and-individuals/supporting-projects) *** ## What if I Want My Contribution to Be Anonymous? You can make an anonymous payment by choosing [incognito](https://docs.opencollective.com/help/financial-contributors/payments#profile) when picking a profile to pay from. If the contributor contributes as a [guest](https://docs.opencollective.com/help/financial-contributors/payments#contributing-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](https://opencollective.com/opencollective/updates/new-legal-and-display-name-settings) a public display name from their private legal name. # How to Donate Learn more about how you or your company can donate to open source projects via Open Source Collective ## OSC's involvement in the contribution process As a fiscal host, we manage and process financial contributions for the projects we host. Here's how that works: 1. **We receive and hold the funds** Contributions are made to OSC on behalf of the project, rather than directly to the project itself. As the fiscal host, we ensure compliance, oversight, and proper fund management. **Please note**: All transactions processed in U.S. dollars (USD). If someone contributes in another currency, the amount will be converted during the transaction. 2. **We allocate the funds to the project** Your contributions are designated to the project's balance on the Open Collective platform. * If you make a contribution via the Open Collective platform (the quickest and easiest way), it will be credited to the project's balance immediately. * If you make a contribution via an invoice (which sometimes accounting teams prefer), once we receive the funds, we manually credit the project's balance. 3. **We provide transparency and reporting** Every contribution is publicly logged on Open Collective's transparent platform, making it easy for the project, donors, and the public to see where funds come from (unless they're anonymous) and how they are used. *** ## Understanding the Types of Funds We Handle **Not all contributions are the same.** Learn more about the different types of funds we handle, including donations and contract-based payments, each with different ways they're handled. :point\_right:[**Learn more about the types of funds we accept here.**](/for-donors-companies-organizations-and-individuals/understanding-the-types-of-funds-we-handle) *** ## Tax-related Information Contributions to projects hosted by OSC **are not tax-deductible**. OSC is a 501(c)(6) nonprofit, not a 501(c)(3) charitable organization, and open source status alone does not make a project charitable under IRS rules. **For international contributors:** Contributions are voluntary payments to a U.S. nonprofit (not purchases of goods or services), so OSC does not charge VAT or sales tax. Most contributors outside the U.S. do not need to account for VAT, but you should confirm with a local tax advisor if you’re unsure. *** ## Ways to Financially Contribute * [Credit](#credit-card-paypal) [Card](#credit-card-paypal) * [PayPal](#credit-card-paypal) * [Bank Transfer](#bank-transfer) * [Invoices](#invoices) (for orgs) * [Procurement systems & purchase orders](#po) (for orgs) * [Funds](#funds) (for orgs) * [Cryptocurrency (via Drips)](#cryptocurrency) * [GitHub](#github-sponsors) [Sponsors](#github-sponsors) * [Polar](#polar) *** ## Credit Card and PayPal Contributing through credit card or PayPal is the quickest and easiest way to support a project hosted by Open Source Collective. ### How It Works: 1. Visit the project's profile page on Open Collective 2. Click 'contribute' and select a one-time or recurring donation option 3. Choose your preferred payment method: PayPal or credit card 4. Complete the payment. Your payment will be credited to the project's balance instantly. :point\_right: [**You can** ](https://docs.opencollective.com/help/financial-contributors/payments)**r**[**ead more about the overview and see the contribution flow here**](https://docs.opencollective.com/help/financial-contributors/payments)**.** *** ## Bank Transfer All transactions should be set up on Open Collective whenever 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 . If you choose to donate via bank transfer (ACH or wire transfer), the process is straightforward but requires a few extra steps to ensure your contribution is properly recorded. ### How It Works: 1. Visit the project's profile page on Open Collective 2. Click 'contribute' and select a one-time or recurring donation option 3. Choose your preferred payment method: bank transfer 4. You will receive detailed bank transfer instructions, both on-screen and via email, including a unique reference ID code. 5. Include the reference ID in your transfer details — this is essential for matching your transaction to the correct project. 6. Once the funds have been received and processed, they will be credited to the project's balance ### Important Notes About Bank Transfer * **Processing time** — bank transfers take longer to process than credit card or PayPal contributions. It may take 3-5+ business days for funds to clear and be allocated to the project. * **Receipt from your bank** — If your bank allows, once you initiate the transfer, please send us an email notification to help speed up the processing. This will help us match the contribution. *** ## Invoices (for orgs) For organizations, companies, and institutions that require an invoice before making a financial contribution, OSC offers invoice-based contributions. ### How It Works: 1. **Request an invoice** — Contact us at with the following details: 1. Link to the project's Open Collective 2. Your organization's name, mailing address, and contact email 3. Preferred invoice date (if it should be issued in the future) 4. Description of the contribution 5. Contribution amount (USD) 6. Purchase Order (PO) number (if applicable) 7. Any additional instructions Unless otherwise agreed, our standard payment terms are 30 days. 2. **Payment and allocation** — once the invoice is paid, funds typically take a few days to clear. After we confirm receipt, the contribution is credited to the project's balance on Open Collective under your organization's name. ### Fees: * OSC charges a fixed 10% host fee on all incoming contributions.
 * If you would like to cover the 10% host fee instead of deducting it from the total contribution, [use our guide here](https://docs.google.com/document/d/1fPxFh3RO2I0UiAZYcs9_hiFQdaMeLOHH-ET7dxkqutU/edit?tab=t.0#heading=h.kz3tmqs2n7vk) to adjust your invoice accordingly. :point\_right: [**Read more about our fees.**](/welcome-and-introduction-to-osc/fees) *** ## Procurement systems & purchase orders (for orgs) If your organization requires vendors to be registered in their procurement system before making payments, OSC may already be registered on your system. If we're not, we can register as a provider in your vendor portal to facilitate financial contributions. ### How it Works 1. If we aren't already, OSC can register as a provider in your company's procurement system, including signing any necessary agreements. We can also provide template agreements or work with legal teams to review existing ones. 2. Your procurement team generates a Purchase Order (PO), if required 3. OSC issues an invoice to your organization 4. Once the invoice is paid and funds are received, OSC allocates the funds, as agreed ### Companies We Are Already Registered With We are already a registered vendor for many major companies in major procurement systems. Some of the companies we are already registered with include: * Microsoft * Google * Amazon * Meta * Salesforce * Adobe * Stripe * Samsung * Spotify * Airbnb * Shopify * Etsy * Indeed * Coinbase * Cloudflare * O'Reilly Media If your company is not listed above, please contact us, and we'll complete the registration process for your procurement portal. ### Fees * OSC charges a fixed 10% host fee on all incoming contributions. * If you would like to cover the 10% host fee rather than deduct it from the total contribution, [use our guide here](https://docs.google.com/document/d/1fPxFh3RO2I0UiAZYcs9_hiFQdaMeLOHH-ET7dxkqutU/edit?tab=t.0#heading=h.kz3tmqs2n7vk) to adjust your Purchase Order accordingly. For assistance, contact us at . :point\_right: [**Read more about our fees.**](/welcome-and-introduction-to-osc/fees) *** ## Funds (for orgs) ### What is a Fund? A Fund is a dedicated profile within OSC designed to streamline financial support for multiple open-source projects. Companies and organizations often create funds to manage their contributions more efficiently, while some Funds are centered around specific topics or initiatives. Here are some examples of current funds that we host: * The General [Google Open Source Fund](https://opencollective.com/google) * The [Airbnb Fund](https://opencollective.com/airbnb) * The[ Indeed Open Source Fund](https://opencollective.com/indeed) * The [Meta Open Source Fund](https://opencollective.com/fbopensource) ### Why should I create a Fund? If your organization has multiple funding programs, wants a strong identity for its funding programs, or wants to simplify the invoicing process for funding open source projects, Funds are for you. **Simplify invoicing** Instead of managing multiple invoices/POs for donations across various projects, you can consolidate everything into a single invoice. The balance remains in your Fund, ready to be distributed as needed. **Flexible fund management** * You control when and how to distribute funds, while we handle the payments, accounting, and legal compliance * Funds can also be used to support projects not hosted on the Open Collective platform by [inviting third parties to submit an expense](https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses/nviting-a-third-party-to-submit-an-expense) through your Fund. ### How to Create a Fund If your company is interested in setting up a Fund, please reach out to us at . ### Contributing To An Open Source Project As a Fund Fund administrators can select their Fund as the payment source when contributing to projects on Open Collective. Simply choose the Fund during the "contribute as" step. :point\_right: [**Read more about contributing to projects.**](/for-donors-companies-organizations-and-individuals/supporting-projects) ### Paying Requesters via Expenses by Fund Individuals and projects can also request payments directly from a Fund. * Requesters provide receipts or invoices * Fund administrators review and approve expenses. :point\_right: [**Read more about expenses and invoices.**](https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses) ### Grants Features Funds come with some lightweight 'grantmaking' capabilities: * Projects and individuals can submit grant requests directly from the Fund's profile page. * Requests include a description of activities and any required documentation for review. * Fund administrators review and approve grants. ### Fees Open Source Collective charges a fixed 10% fee on all contributions received into the platform and into a Fund. * For Funds, this 10% fee is applied when money is deposited into the Fund. * Contributions from a Fund to a hosted OSC member project **do not** incur any additional fees. * If you are adding money to your Fund via invoice and prefer to cover the 10% host fee rather than deduct it from the total contribution, [use our guide here](https://docs.google.com/document/d/1fPxFh3RO2I0UiAZYcs9_hiFQdaMeLOHH-ET7dxkqutU/edit?tab=t.0#heading=h.kz3tmqs2n7vk) to adjust your invoice accordingly. For assistance, contact us at . :point\_right: [**Read more about our fees.**](/welcome-and-introduction-to-osc/fees) *** ## GitHub Sponsors GitHub and Open Collective work together to ensure that projects registered with GitHub Sponsors that use Open Collective for fund management receive their funds seamlessly. If a project is registered on GitHub Sponsors and uses Open Collective, funds can be automatically transferred monthly — no extra steps needed. Simply sponsor the project on GitHub, and we'll do the rest. Please [see this page for additional information.](https://docs.oscollective.org/campaigns-programs-and-partnerships/github-sponsors) *** ## Cryptocurrency As of May 2023, automated cryptocurrency donations are disabled due to compliance issues related to receiving funds from a sanctioned country. [Read the full announcement here.](https://opencollective.com/opensource/updates/open-source-collective-is-disabling-contributions-in-cryptocurrencies) We now accept cryptocurrency donations on a case-by-case basis and only in partnership with Drips. If you're interested in donating cryptocurrency to one of our hosted projects, [please see this page.](https://docs.oscollective.org/campaigns-programs-and-partnerships/drips) *** ## Polar.sh As a hosted member project, OSC can receive funds from Polar.sh and allocate them directly to your Open Collective account. If your project is fiscally hosted by us and your project has a Polar account, you can follow Polar's guide to set up payouts to your Open Collective profile. Please [see this page for additional information.](https://docs.oscollective.org/campaigns-programs-and-partnerships/polar.sh) *** ## Tax Deductibility OSC is a 501(c)(6) nonprofit. Contributions made to OSC are not tax-deductible. *** ## Does Open Source Collective fully cover the required solicitation licenses? Open Source Collective has confirmed with its council that state charitable solicitation laws only apply to charitable organizations (501c3), and as OSC is registered in the state of California as a Mutual Benefit Corporation (a 501c6 nonprofit for member benefit), we are exempt from state registration. Attached below is a letter from the California Attorney General's office for reference with our designation. Please note that donations are not tax-deductible since we are not a charity. {% file src="/files/bcRAvhn5CvVP1y5H99Iv" %} *** ## Payment Security Neither OSC nor the Open Collective platform stores any credit card information, as Stripe and PayPal handle payments on the platform. You can learn more about [Open Collective's payment security here.](https://docs.opencollective.com/help/product/security#payments-security) ### Suspicious activity monitoring If we detect any unusual donation activity, we may: * Freeze contributions to the project and suspend expenses. * Investigate all donations and return any flagged or disputed charges. * Follow up with the project admins to implement additional security checks on donations and expenses until the percentage of fraudulent charges decreases. *** ## How Do I Cancel Recurring Donations? See instructions on how to cancel recurring or ongoing donations, subscriptions, payments, etc., [here](https://docs.opencollective.com/help/financial-contributors/payments#change-the-amount-payment-method-or-cancel-an-existing-contribution). # Why Projects Use Open Source Collective for Donations Why do open source projects use Open Source Collective? If you're wondering why the open source project you support is hosted by Open Source Collective (OSC) and why your donation is processed through us — great question! Many open source projects depend on funding from users or organizations, but accepting and managing those funds independently can be a heavy lift. It often requires setting up a legal entity, handling financial reporting, managing taxes, distributing funds to contributors, and staying compliant with regulations. For many projects, that’s time and energy better spent on their community and their code — not on financial and legal administration. That’s where OSC comes in. As a fiscal host, we provide the structure and support projects need to receive and manage funding responsibly, without having to go it alone. :point\_right:[**Read more about fiscal hosting here.**](/welcome-and-introduction-to-osc/what-is-fiscal-hosting) *** ## Want to Know More About What OSC Does? * **No Need to Set Up a Legal Entity**\ Starting a business or nonprofit to accept donations comes with legal, tax, and operational responsibilities. By using OSC as a fiscal host, projects can receive funding without the burden of managing a separate legal entity and taxes, regulations, and compliance that come with it. * **Financial Accountability and Transparency**\ OSC ensures that donations are handled securely, expenses are tracked, and financial reporting is fully transparent via Open Collective. This means you can see exactly where the money goes. * **Efficient Fund Distribution**\ Open source projects often involve multiple contributors. OSC provides the infrastructure to pay maintainers, reimburse expenses, and manage funds efficiently so projects can keep moving forward with their community and code. * **Access to Grants or Corporate & Institutional Funding**\ Many companies and funding organizations prefer to donate through an established, well-known nonprofit rather than make direct payments to individuals for a host of reasons. As a hosted member project with OSC, the project gains access to grants, sponsorships, and corporate contributions that might not otherwise be available. By donating through OSC, you're ensuring your donation is handled responsibly and used to support the long-term sustainability of the project you are about. If you have any questions, feel free to reach out! # Understanding the Types of Funds We Handle What kind of money does Open Source Collective handle? As a 501(c)(6) nonprofit fiscal host, Open Source Collective (OSC) receives and handles funds on behalf of our hosted projects. While we support a wide range of funding types, all funds must be used to advance the project's mission in a way that aligns with OSC’s purpose: supporting the sustainability and health of the open source ecosystem. This page explains the most common types of funds we handle and how we approach them from a compliance and operational perspective. ## Contributions (General Support/Donations) These are voluntary contributions made by individuals, companies, or foundations to support an open source project’s mission and activities. These are not charitable donations (and therefore not tax-deductible), but they are still made without the expectation of direct benefit or a specific deliverable. **Key characteristics:** * No exchange of goods or services * Intended to support the project’s general mission or community impact * Not subject to sales tax or refund * Donors may receive public recognition, but not a transactional benefit *** ## Payments with Deliverables (Contract or Agreement-Based) 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 can still be received through OSC and must * Be used in ways that serve the open source project that we host * Be documented with a written agreement (grant letter, contract, etc) 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 501(c)(6) nonprofit, OSC must ensure that all funds we manage support open source. Properly classifying and handling incoming funds helps us: * comply with IRS and nonprofit law * maintain transparency * uphold the trust of contributors, hosted projects, and funders # Refund Requests Open Source Collective's refund policy ## Refund Requests As a nonprofit, Open Source Collective (OSC) operates on the principle that donations are voluntary contributions supporting the mission and activities of the projects we host. Since donations are not payments for specific deliverables or services, refunds are generally rare and granted only in exceptional circumstances. Please keep in mind: * Donations are voluntary and are not tied to any deliverable or service. [You can learn more about this and the types of funds OSC handles here](/for-donors-companies-organizations-and-individuals/understanding-the-types-of-funds-we-handle) * Refunds cannot be issued more than 120 days after the original donation date. *** ## How to Request a Refund To request a refund, email us at with the following information: * Donation URL — the full URL of the donation transaction (e.g., `https://opencollective.com/opensource/expenses/123456`) * Transaction Details — confirm the date and amount of the donation * Authorization Confirm — whether the contribution was made with your authorization As a reminder, refunds are generally not granted. # Your Project Was Just Accepted! Now What? Your project is now fiscally hosted by Open Source Collective -- now what?! ## Welcome to Open Source Collective! :tada: First off, congratulations! We're excited to support your project! Now that your project is a fiscally hosted member project with OSC, there are a few important steps to help you get started. You’ll receive emails with key resources — take some time to review them, and if you have any questions, let us know. We’re here to help. This guide will serve as a go-to resource for managing your project with OSC. *** ## What Happens Next? 1. **F**i**ll out the Newly Accepted Project Form** You'll receive a Typeform survey titled "**Newly Accepted Project Form**" from us. Please take a few minutes to complete this short form (it should take around 5 - 7 minutes). It helps us understand your project, its goals, and how we can best support you. We review every survey submission, and your input truly helps us tailor our support and offerings! 2. **Review the OSC** **Onboarding** **Video** Take a few minutes to watch our Onboarding video, which covers: * Overview of fiscal hosting * How to use Open Collective * Key things to know as a hosted member project :pushpin: [**OSC Onboarding** ](https://onboarding.oscollective.org/)[**Video**](https://onboarding.oscollective.org/) 3. **Set up your project's Open Collective Profile Page** Your Open Collective page is more than just a place to receive funds — it's your project's public home for managing your project's finances, fundraising, and expenses. By default, every OSC-hosted project gets its own dedicated Open Collective profile, making it easy to stay transparent, organized, and connected to your community. It's worth taking a little time to customize your page — adding your logo, story, and goals helps your community understand what your project is and why your work matters. :pushpin: [**Quick Start Guide to the Open Collective platform**](https://docs.opencollective.com/help/collectives/quick-start-guide) :pushpin: [**Customizing Your Page**](https://docs.opencollective.com/help/collectives/collective-settings/customize-collective) 4. **Join the Discord** OSC has a presence on the Open Collective Discord in the #open-source-collective channel. There, you can connect with other open source projects, get platform support, and engage with other community groups. :pushpin: [**Discord**](https://discord.gg/AtKhYFgrgc) 5. **Review OSC's Policies** It's important to understand our policies and procedures, especially regarding expenses. Be sure to familiarize yourself with the requirements for submitting and approving expenses. # Managing Project Funds Managing funds with Open Source Collective As an admin of a hosted member project, your project benefits from infrastructure that enables you to receive, manage, and spend funds transparently. This section gives you everything you need to know about how money flows through your project, and what you're responsible for as an admin. Whether you're receiving funds from an external program, approving expenses, or want to know how we handle refunds, we've broken the information down into focused subpages so you can find what you need. *** ## What You'll Find Here: * [Admin financial and compliance responsibilities ](/for-hosted-member-projects/managing-project-funds/admin-financial-responsibilities) * [Handling donation refunds: what projects should know](/for-hosted-member-projects/managing-project-funds/handling-donation-refunds-what-projects-need-to-know) * [GitHub Sponsors overview](/campaigns-and-partnerships/github-sponsors) * [Polar.sh overview](/campaigns-and-partnerships/polar.sh) * [Drips overview](/campaigns-and-partnerships/drips) * [Google Summer of Code overview](/campaigns-and-partnerships/google-summer-of-code) * [Where unknown funds are held](/for-hosted-member-projects/managing-project-funds/holding-unknown-funds) * [Reviewing expenses as an admin](/for-hosted-member-projects/managing-project-funds/reviewing-expenses-as-an-admin) * [Making financial contributions to another open source project](/for-hosted-member-projects/managing-project-funds/giving-to-other-open-source-projects) * [Paying a contractor through Fiverr, Upwork, Ko-fi](https://app.gitbook.com/o/-LWSZizNMEjL8_DrMNdF/s/WyTQOYegtF2WGqciaf2V/~/changes/68/for-hosted-member-projects/managing-project-funds/using-fiverr-upwork-or-ko-fi) # Admin Financial Responsibilities These guidelines help ensure that funds entrusted to your project,and to Open Source Collective on your project's behalf, are managed responsibly and used to support and sustain your open source work. ## Purpose This document provides an overview of your responsibilities as an administrator of an Open Source Collective (OSC)- hosted project, including how your actions support OSC’s compliance processes and financial integrity standards. Our shared goal is to ensure that all funds are used ethically and transparently in support of open source. ## Why this Matters As an OSC project admin, you play a frontline role in supporting OSC to maintain our financial integrity. You help ensure:
* All spending furthers your open source project’s goals and our mission to create a healthy and sustainable open source ecosystem. * Donors and contributors to your project can trust that their contributions are handled responsibly *** ## Key Principles You Support * Transparency: all project funds held by OSC must be accounted for through OSC’s systems and processes * Verification: every expense, transaction, and payee must be reviewed * Fairness: only legal, documented, and mission-aligned expenses are approved * Compliance: We abide by US sanctions laws and global best practices * Confidentiality: You may see sensitive information related to contributors and community members – handle it responsibly ## Your Core Responsibilities as an Admin 1. Reviewing and Approving Expenses 1. Confirm that each expense submitted to your project supports your open source project’s purpose and goals. 1. Verify submitted documentation (receipts, invoices, and descriptions) and ensure they are well described 2. Do not approve personal, duplicate, or requests for pre-payment 3. If unclear, communicate with the expense submitter before approving 4. Contact for support. 2. Supporting OSC’s compliance processes 1. Be alert for unusual or suspicious activity, such as: 2. Large or repetitive payments from unfamiliar accounts 3. Requests to pay unrelated third parties instead of the expense creator/vendor 4. Attempts to conceal identity, bypass documentation requirements, or avoid processes. 5. Report concerns to the OSC team by emailing . 3. Protect Confidential Information 1. Treat any information concerning a donor or community member that is not publicly available as sensitive information. 2. Do not download, copy, or share sensitive information with other donors or community members. 3. If you believe sensitive information has been mishandled, contact for support. ## Quick Checklist for Every Expense * Expenses are legitimate and project-related * Documentation is clear and complete (receipts/invoices or written expense documentation) * No duplicative expenses * No personal (not related to the hosted project) or prepayment requests * Aligned with your project's purpose and goals *** ## How OSC Supports You * Contribution monitoring: We monitor contributions to ensure illegal or fraudulent contributions are rejected and/or refunded. * Payment Review: After you approve an expense for payment, OSC performs additional verification checks before processing any payment * Training and Support: OSC staff are available to clarify what qualifies as an expense, what documents are needed, and how to spot irregularities contact . * External Oversight: We work with independent accountants to help maintain compliant and auditable accounts for each of our member projects. *** ## Reporting and Ethics * If you see something concerning, report it to * Good faith reporting is protected, and retaliation is not tolerated * Remember: asking questions before approving an expense is a sign of diligence, not distrust. *** ## Summary By following these steps, you help ensure that every dollar entrusted to your project and to OSC on behalf of your project is used for its intended purpose – supporting and sustaining open source. # Handling Donation Refunds: What Projects Need to Know How Open Source Collective handles refunds Open Source Collective (OSC) generally does not provide refunds on contributions made to your projects — [learn more about that here. ](/for-donors-companies-organizations-and-individuals/refund-requests) OSC has seen an increase in refund requests from businesses claiming they donated in lieu of a marketing opportunity with the project. To prevent misuse and ensure clarity, OSC no longer issues refunds based on claims of non-delivery of goods or services. We ask all hosted member projects to add the following disclaimer to their page (along with any website containing an OSC Donation widget): > This is a donation. No goods or services are expected in return. Any requests for refunds for those purposes will be rejected. *** ## Handling Special Cases That said, while refunds are not guaranteed, donors and project admins may submit a refund request to OSC if an issue arises. Each request will be reviewed on a case-by-case basis, and approval is at OSC's discretion. # I Was Expecting Money, Where Is It? What is the OSC Holding account and how do I claim unclaimed funds? Sometimes Open Source Collective (OSC) receives funds for which the intended recipient cannot be identified. When this happens, the funds will be placed in a Holding Account for Unknown Funds until we determine where it belongs. This often happens when: * bank transfers are missing a reference number, invoice number, or a project name * a GitHub Sponsors payout is sent to an open source project that OSC does not fiscally host *** ## How to Claim Unassigned Funds 1. How OSC handles unassigned funds * OSC reviews pending transactions on the Open Collective platform to find a possible match * If still unclear, we contact the sending bank to request more information * If the funds remain unidentified, they are placed in a Holding Account until they're claimed by the appropriate project 2. Checking for Missing Funds If you sent a donation but don't see it reflected on the project's Open Collective balance: * Check the [OSC Holding Account](https://opencollective.com/osc-holding) to see if a transaction matches the expected amount * If you find a match, contact us at with the following details: * Name and email of the person who made the payment * Date of transfer * The last few digits of the bank account number that sent the funds * Once verified, OSC will move the funds from the Holding Account to the correct project. *** ## If We Received a GitHub Sponsors Payout for You If OSC received a GitHub Sponsors payout on your behalf, please contact us at and provide: * your GitHub profile link We might need to follow up with a few more questions, but once they are resolved, we will send an expense request via the Open Collective platform to transfer the funds to your bank or PayPal account. # Reviewing Expenses as an Admin What to know if you're an admin of an Open Source Collective hosted member project As an admin of an Open Source Collective (OSC) hosted project, you are responsible for reviewing and approving expenses before they are sent to and paid through OSC. In this page, we'll review reviewing expenses and things to keep in mind. If you have any questions, feel free to reach out — we are here to make this as simple as possible for your project! *** ## Admin Responsibilities in Expense Review * Verify the legitimacy of the expense — ensure it aligns with your open source project * Check for duplicate submissions — make sure it's a unique expense and hasn't already been submitted and paid * Confirm sufficient documentation — ensure expenses contain all required information * Approve only allowable expenses — no personal, prepayments, or non-open source payments are allowed *** ## Steps to Review an Expense When reviewing an expense, follow these steps: 1. ### Confirm Expense Eligibility * is this a legitimate expense? * ensure it's not spam * does this expense directly support your project? * is it allowable? * OSC cannot process personal expenses or prepayments 2. ### Verify Required Documentation * is all supporting documentation on the expense? 3. ### Approve or Request Changes * If the expense looks good, click approve * If something is missing or incorrect, leave a comment * If the expense isn't valid and seems to be spam, mark it as spam 4. ### OSC Review and Payment Processing * Once approved by an admin, the expense will be sent to OSC's "ready to pay" queue. We will: * Conduct a final compliance review * Reach out to payee or the admin if any additional information is required *** ## Common Issues to Watch For Some common expense issues to pay attention to when reviewing expenses are: * duplicated expenses or expenses that payees submit twice * reimbursements that are missing receipts * invoices that are missing timeframes * invoices that don't clearly explain what work was completed * expenses that do not align with our guidelines. :point\_right: **Review our** [**Invoice vs. Reimbursement guide here**](/for-hosted-member-projects/spending-money-and-getting-paid/invoice-and-reimbursement-examples) **to learn about the differences and what each requires.** :point\_right: **Review our** [**expense policies and limitations**](/for-hosted-member-projects/spending-money-and-getting-paid/expense-policies-and-limitations) **to learn more about what funds can and cannot be used for.** *** ## When Does OSC Process Payments? The OSC team processes payments twice per week. To keep things running smoothly, we review and process expenses on those days within a set timeframe. We do not process expenses outside of this particular schedule. # Giving to Other Open Source Projects Can I donate funds from my project to another open source project? ## Giving To Another OSC-Hosted Project Hosted member projects can [easily contribute to other projects that are also hosted by OSC](https://documentation.opencollective.com/giving-to-collectives/giving-to-other-collectives#within-the-same-fiscal-host) . You can make a financial contribution directly through the other project's Open Collective page. ## Giving To A Project on Open Collective, But Isn't Hosted By OSC If you want to donate to a project on the Open Collective platform that is hosted by a different fiscal host, [additional steps may be required](https://documentation.opencollective.com/giving-to-collectives/giving-to-other-collectives#across-different-fiscal-hosts). Please reach out to us if you'd like to give across fiscal hosts. ## Giving To Projects Via Other Platforms OSC is happy for member projects to make donations to other projects through other platforms, so long as those projects align with the organization's mission (i.e., sustaining the open source ecosystem) and advance the project's cause. # Using Fiverr, Upwork, or Ko-fi Paying someone with OSC when you're using a contractor platform ## Getting Paid or Paying Someone Through a Contractor Platform? When working with vendors from these platforms, the original payee can submit a reimbursement request for the payment. [Fiverr](https://www.fiverr.com/support/articles/360011135837-W-9-Collection?segment=seller), [Kofi](https://help.ko-fi.com/hc/en-us/articles/10792069957661-How-Tax-Works-on-Ko-fi#01H8PEJ62CHRQEC48B6SR8CHS8), and [Upwork all issue a 1099](https://support.upwork.com/hc/en-us/articles/211063958-Report-Income-from-Upwork) to their contractors/users, ensuring tax compliance. # Spending Money & Getting Paid Getting paid or spend money with Open Source Collective If you’re looking to submit an expense or to better understand what OSC-held funds can be used for, you’re in the right place. This section covers how to get paid by an OSC- hosted member project, what kinds of expenses are allowed, tax information, and the key rules and limitations that apply when spending from a hosted project’s budget. Open Source Collective (OSC) is a registered nonprofit, which means all spending must meet legal, financial, and mission-aligned requirements. Every payment must directly support the hosted project's open source work — whether by funding development, design, infrastructure, events, or other contributions that advance the project’s open source goals. *** ## What You'll Find Here: * [The difference between invoices and reimbursements, and what each requires](/for-hosted-member-projects/spending-money-and-getting-paid/invoice-and-reimbursement-examples) * [What kind of expenses and payments are allowed, and what's not](/for-hosted-member-projects/spending-money-and-getting-paid/expense-policies-and-limitations) * [Tax and accounting information to be aware of](/for-hosted-member-projects/spending-money-and-getting-paid/tax-info) * [What to know if your expense is marked as incomplete](/for-hosted-member-projects/spending-money-and-getting-paid/expenses-marked-as-incomplete-or-otherwise-have-not-been-paid) # Invoices vs. Reimbursements Submitting an invoice and a reimbursement to Open Source Collective When submitting an expense to Open Source Collective (OSC), it’s important to understand the key differences between an **invoice** and a **reimbursement**. These terms may be used differently depending on your location, but they serve different purposes and must be submitted correctly. We know this page includes a lot of information, and we’ve found it helpful to keep both expense types in one place for easy comparison. To make it easier to find what you need: * **Purple headings = Invoices** * **Orange headings = Reimbursements** ## **TL;DR: What's the Difference?**
Expense TypeUse WhenKey Requirements
InvoiceYou're requesting payment for work/services you did
  • Detailed description of the work provided
  • Timeframe that you completed the work
  • BONUS: links that support the work completed
ReimbursementYou've already paid out-of-pocket for a project expense
  • Receipt from vendor
  • Amount equal to or lower what was spent
{% hint style="warning" %} **Note**: In addition to the key requirements listed above, OSC has broader expense policies that apply to all expense submissions. [**Before submitting an expense, please review our Expense Policy and Limitations page as well.** ](/for-hosted-member-projects/spending-money-and-getting-paid/expense-policies-and-limitations) {% endhint %} *** ## **Invoices** ### **When to Use** Submit an [invoice](https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses#invoices) when you're requesting payment for **work or services provided** to the hosted member project. ### What to Include 1. Clear description of what you did 2. When you did it 3. How it supported the project Explain what you did in clear, specific terms, and when you did it. Write it as if you're describing the work to someone who doesn't know the project. Tell us when you performed the work or service. ### **Why this Matters:** Our accountants and potential auditors may use this information to verify that funds are being used appropriately. Your description should clearly explain how and when you supported open source. *** ### **Examples of**** *****Acceptable***** ****Descriptions:** 1. "Fixed critical security bugs in February 2024" 2. "Maintenance on project infrastructure, March 1-7, 2025" ### **Don't:** * Use vague or generic terms without specificity (e.g.: "work", "services", "payment") * Use terms like "grant", "donation," and "reward" — those words don't imply that work was performed. ### **Examples of**** *****Unacceptable***** ****Descriptions:** * "Work done on the project" * "Payment for involvement" * "Donation for service" {% hint style="warning" %} :sparkles:**TIP: Include Links** To speed up payment processing and improve transparency, consider including relevant links that support the expense (especially important when you're a sole maintainer/admin): * Changelogs * Repositories * Blog posts * GitHub commits {% endhint %} *** ### Invoice Attachments * A PDF invoice is **not** required by OSC, but may be required by some hosted member projects * If including, it needs to be addressed to: > Open Source Collective > > 440 N. Barranca Ave. #3939 > > Covina, CA 91723 ### For Invoices Over $5,000 USD: * The payee shouldn't approve their own expense (unless they are the sole admin) * Payments must be made via electronic bank transfer, not PayPal. *** ## Reimbursements ### When to Use Submit a [reimbursement](https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses#reimbursements) when you've already paid for something that directly supports the project (such as, but not limited to: web hosting, swag, domain renewals, etc) using your own money. ### What to Include 1. **Receipt or approved proof of payment showing:** 1. **Vendor** (who or what company you paid) 2. **Purchase description** (what you bought) 3. **Transaction date** (when the purchase was made) 4. **Amount paid** 5. **Project name or payee's name** (who made the purchase) ### Why OSC is responsible for ensuring all funds are used to support open source. Reimbursements must show how it directly benefits the project. *** ### Reimbursement Guidelines * The amount and currency must match the receipt. We can't reimburse you for money you didn't spend. * The required information listed above must be clear and legible in the updated receipt. * If it's not obvious, the expense should include a short explanation of how the purchase supported the project. * Reimbursements for personal expenses (such as personal subscriptions, travel unrelated to the project, or groceries) are not allowed. ### Paying For Large Expenses That Can't Be Covered Out-of-Pocket and 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](https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses#inviting-a-third-party-to-submit-an-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 we pay them directly. *** ## **Example Scenarios** ### *Scenario 1: Submitting an Invoice* A developer contributes a security patch to a project hosted by OSC. The developer receives approval from a project admin to submit an expense for her contribution. 1. **Completing the work** 1. The developer fixes security bugs in the project and tracks the time spent. In total, it took around 2 hours in December 2024. 2. **Submitting the expense** 1. She submits an invoice on the project's Open Collective page with 1. **Expense type:** Invoice 2. **Description:** Fixed critical security bugs, 4 hours in December 2024" 3. **Total amount requested:** Pre-agreed amount with project maintainer 4. **Payment method:** They choose bank transfer ### *An invoice for this scenario could look something like this:*

Good: descriptive title, described what work was done, timeframe, filed as 'invoice'

*** ### *Scenario 2: Submitting a Reimbursement* A project maintainer is attending a conference on behalf of the project and books a flight and a hotel using pre-approved expenses. 1. **Getting approval** 1. Confirm with the project admins that your expense(s) can be reimbursed 2. **Book travel** 1. Save all receipts after booking 3. **Submitting the expense** 1. **Expense type:** Reimbursement 2. **Description:** "Travel expenses to attend \[conference name]." 3. **Attachment:** Receipt from the hotel and airline in the submitter's name showing that the purchase was already paid 4. **Total amount requested:** Preapproved amount 5. **Payment method:** PayPal ### *A reimbursement for this scenario could look something like this*

Good: Descriptive title, receipts attached on separate lines, filed as 'reimbursement'

*** ## More Examples of Real Expenses ### *Invoices* You can include the details of the work done in the description field of each line item.

Bug bounties can include a link to the fix. Links are very helpful.

Including versions and project names is very helpful.

You can create one invoice for the total and attach your own invoice or time tracker to detail the work performed. You do not need to attach your own invoice or time tracker for OSC unless your project requires it. Another option is to include a note such as: "Maintenance on core for the month of April, 2023." ### *Reimbursements*

If your expense has multiple receipts, use separate line items for each receipt

*** ## Reminder In addition to the key requirements listed above, OSC has broader expense policies that apply to all expense submissions. :point\_right: [**Before submitting an expense, please review our Expense Policy and Limitations page as well.** ](/for-hosted-member-projects/spending-money-and-getting-paid/expense-policies-and-limitations) # Virtual Cards How to request, use, and manage a virtual card Virtual cards allow approved project expenses to be paid directly from your project’s Open Collective balance. This page explains who is eligible, how to request a card, what it may be used for, and the responsibilities of cardholders and Open Source Collective (OSC) hosted project admins. ## What Is a Virtual Card? A virtual card allows eligible project expenses to be paid directly from your project’s balance on Open Collective. It can be used for hosting, subscriptions, and other approved project-related expenses without requiring someone to pay personally and request reimbursement afterwards. Virtual cards provide additional spending controls because OSC can set spending limits, restrict certain types of purchases, and suspend or cancel a card when necessary. For some cardholders outside the U.S., using a virtual card may also reduce currency conversion or VAT costs. *** ## Eligibility OSC reviews each virtual card request individually. When determining eligibility, we consider: * How long the project has been hosted by OSC * Whether the project is in good standing with OSC * The requesting admin’s history with OSC * The project’s available balance and transaction history * Its typical incoming contributions and outgoing expenses * The anticipated monthly spending amount * The proposed use of the card ### **Requirements** * All transactions should comply with normal usage of initiative funds as outlined in OSC's [Terms of Fiscal Sponsorship](https://app.gitbook.com/o/-LWSZizNMEjL8_DrMNdF/s/-M9Neg20-zKzu0MhF2d2/getting-started/terms) * All purchases must comply with OSC’s Expense Policies and Limitations [Expense Policies and Limitations](/for-hosted-member-projects/spending-money-and-getting-paid/expense-policies-and-limitations) * Cards that have not been used for more than 90 days will be frozen. * A receipt must be submitted for every transaction. If a receipt is not submitted within 30 days, the card will be frozen until the receipt is provided. * ​Admins are personally liable for misuse *** ## Requesting a Virtual Card To request a virtual card: 1. Log in to the Open Collective platform. 2. In the left navigation menu, select Virtual Cards -> Request a Card. 3. Enter the card’s intended use, including the names of the services you plan to pay and the expected monthly amount. For example: “GitHub and DigitalOcean, up to $300 per month.” 4. Submit the request for review. OSC will review the request and contact you if additional information is needed. If approved, the assigned cardholder will receive an email, and the card details will appear on the Open Collective platform. ### Spending Limits OSC determines each card’s spending limit based on the intended use, expected monthly expenses, and the project’s available balance. To request a higher limit, email and include: * Your project’s name * The intended purchases * The requested limit * The reason for the increase The project must have enough available funds to cover the requested spending limit. OSC may approve a different limit based on the project’s balance and anticipated expenses. *** ## Eligible Card Purchases Virtual card purchases must follow the same policies and limitations as other project expenses. If OSC could not approve the purchase as an invoice or reimbursement, it cannot be paid using a virtual card. Virtual cards may be used for eligible expenses such as: * Hosting and infrastructure * Software subscriptions * Domain registration * Other approved services that support the project’s open source work Virtual cards cannot be used to pay individuals or contractors, including through platforms such as Fiverr or Upwork. These payments must be submitted through the Open Collective platform as an invoice. *** ## After You Use Your Virtual Card When the virtual card is charged: * The transaction amount is deducted from the project’s available balance immediately. * The project admin will receive an email inviting them to create an expense for the transaction. * A project admin must upload an itemized receipt. If a receipt is not submitted within **30 days**, access to the card will be paused until the missing receipt is provided. *** ## Lost, Stolen, or Compromised Cards If your card is lost, stolen, or used for a transaction you do not recognize, contact us immediately at . Include your project’s name and the last four digits of the card. If your card is replaced or reissued, update its details with any vendors or subscription services that have the previous card information on file. # Expense Policies and Limitations What Open Source Collective can and cannot pay As a fiscally hosted member project under the Open Source Collective (OSC), the funds we hold must be used for expenses that align with your project's open source work and comply with nonprofit regulations. Below is a guide to what is permitted and what is not. ## Expense Basics * All expenses must comply with 501(c)(6) regulations and align with OSC’s mission: *To promote a sustainable and healthy ecosystem that will sustain open source technology for the future* * OSC only processes expenses approved by an admin of the hosted project. * Expenses **cannot** be paid in advance; invoices must be for completed work, and reimbursements must be for purchases that have already been paid for. * This includes travel; OSC cannot pay anticipated costs such as flights, hotels, or other bookings before travel occurs. * If a vendor requires partial payment for a reservation, a written invoice must be submitted that includes the reservation details and clearly defines a reimbursement policy. * The payment method (Bank or PayPal account) must be in the Payee's name. Expense submitters can add their "Legal Name" in their profile settings. This field remains private and is only viewable to fiscal host admins. * Payouts must be detailed and itemized; lump sum payments or future expenses are not allowed. * We cannot process payments for expenses incurred before OSC started hosting the project. * Due to IRS regulations, OSC may be required to collect tax forms before issuing payment. * Projects with an associated LLC cannot use funds held by OSC for LLC-related expenses or transfer donated funds to the LLC. * OSC's ability to fulfill requests is bound by IRS regulations, staff capacity, and technical limitations. * All funds are held in USD. When submitting an expense, the amount can be paid out in your local currency based on the exchange rate, and any applicable currency conversion fees may apply. {% hint style="warning" %} Hosted member project admins can[ set additional expense policies](https://documentation.opencollective.com/collectives/creating-a-collective/creating-your-policies) to give guidance to expense submitters. {% endhint %} *** ## **Things We Can and Cannot Pay For** ### **Eligible** **Expenses** If an expense directly supports your hosted open source project, it's usually eligible. Sometimes we may ask for more context, not to make things harder, but because we’re a nonprofit and need clear documentation for audits and compliance. When we ask for extra details, it's to ensure the expense meets legal and tax requirements. All submitted expenses must follow the general expense guidelines described on this page and our Invoices vs Reimbursements page. You can use OSC-held funds for: * Payments to contributors for completed work (via invoice) * Reimbursements for project-related purchases * Infrastructure costs (e.g., domain hosting, software subscriptions, servers) * Travel costs for project-related events * Shipping, duty, and import fees related to your project * Please include proof of the item being shipped so we can confirm it’s project-related * Funding programs or community awards * Some projects run programs such as hackathons, community awards, or other community-centered opportunities that provide financial support to project or community contributors. The submitted expense should include an explanation of the work completed or how the award relates to the project. * Please note that these payments generally cannot be processed as "gifts" or "grants." Expenses must still demonstrate a clear connection to the hosted project's open source work and should be publicly documented (for example, on a repository, project website, or program page). ### **Ineligible Expenses** OSC-held funds cannot be used for: * Personal expenses unrelated to the project (eg: rent, groceries, clothing) * Non-project-related travel or entertainment * Donations to unrelated causes or organizations * Future payments or funds for work that has not yet been completed * Anticipated travel costs (e.g., flights, lodging, or other reservations booked before the travel has occurred) * Transferring funds to an LLC related to the project * Expenses that do not align with OSC's mission (eg: unrelated business activities that do not support open source) * Expenses without a clear connection to the project's open source work * Gift cards, pre-paid credit cards, and/or pre-paid debit cards. * Gifts or grant-style payments * Expenses cannot be processed as "gifts" or "grants". *** ## Not sure if something qualifies? If you're unsure whether an expense is eligible, reach out to us before spending. We're happy to help clarify — asking first can save time and prevent headaches later. *** ## Methods of Payment * Payment methods must be owned by the expense payee * OSC only makes payments via * Wise (bank transfer) * PayPal * Payments via PayPal are capped at $600 USD. *** ## Permitted Countries, OFAC Checks, and Payment Restrictions * OSC cannot process payments to [sanctioned regions](https://orpa.princeton.edu/export-controls/sanctioned-countries) * Payments may also be restricted in certain [other countries ](https://orpa.princeton.edu/export-controls/sanctioned-countries) * Payments are processed via PayPal and Wise, but some banks and countries may not be supported by their services * [PayPal supported countries can be found here](https://www.paypal.com/us/webapps/mpp/country-worldwide) * [Wise supported countries can be found here](https://wise.com/help/articles/2571942/what-countriesregions-can-i-send-to) * Some bank transfer fees may be charged by [intermediary banks](https://stripe.com/resources/more/what-are-intermediary-banks-and-how-do-they-work#intermediary-banks), resulting in additional fees beyond OSC's control. * Payments to certain countries may incur higher banking fees due to banking infrastructure, regulatory environments, currency exchange practices, and interbank agreements. One country that has such practices is Nigeria. As such, a minimum balance of $30 USD is required for payouts, as these fees often exceed $15 USD. *** ## Additional Verification and Policy Compliance * Some expenses may require additional verification. OSC may request further documentation, such as links, supporting materials, or proof of work, to help verify submitted expenses. In some cases, we may also need to conduct KYC (know your customer) checks. If we do ask for additional information, please know that this is part of our responsibility as a nonprofit to maintain clear records, ensure regulatory compliance, and be responsible stewards of funds held. * Failure to follow expense policies may result in a hosted project's page being frozen. # Tax & Accounting What to know about taxes and Open Source Collective ## For Payees/Expense Submitters ### Tax Forms Required * If your invoiced payments from OSC total $600 USD or more per year, you must submit: * **For U.S. payees** — W-9 form * **For non-U.S. payees** — W-8BEN/E form * When your invoices exceed $600, OSC will send you an email from Dropbox Forms with a secure link to complete your tax form: * "Open Collective sent you a request via Dropbox Forms." * Your expense will not be paid until your tax form is submitted. ### Reporting income from OSC * **U.S. payees** — * If you earn over $600 in a year, OSC will issue you a 1099 form for tax reporting. * If you earn less than $600, you won't receive a 1099 but you still need to report it as miscellaneous self-employment income when filing your taxes * [Here ](https://turbotax.intuit.com/tax-tools/tax-tips/Self-Employment-Taxes/Filing-IRS-Form-W-9/INF19741.html)is a good explanation of how W9s work for independent contractors, and there's more info on what a 1099 is [here](https://turbotax.intuit.com/tax-tools/tax-tips/Self-Employment-Taxes/What-is-an-IRS-1099-Form-/INF14810.html). * **Non-U.S. payees** — * OSC will not issue a tax form. * However, we are required to collect your tax form for accounting purposes to confirm that the payment was made to a non-U.S. citizen. This helps us accurately report payments and differentiate between U.S. and non-U.S. payees. * You are responsible for complying with your country's tax regulations and obligations. *** ## For Financial Contributors/Donors * Contributions to hosted member projects managed by OSC are not tax-deductible. OSC is a 501(c)(6) nonprofit organization and not a 501(c)(3) charitable or public-benefit organization. * The IRS does not automatically classify open source projects as charitable just because they use an open source license. To qualify as a charity, an organization must serve a specific charitable group or purpose, and open source alone does not fulfill that requirement. * **For international contributors:** Contributions made through Open Collective are treated as voluntary contributions to a U.S. nonprofit and are not considered purchases of goods or services. As such, OSC does not charge VAT or sales tax on contributions. Contributors outside the United States generally do not need to account for VAT on these transactions. If you are unsure how this applies in your jurisdiction, please consult your local tax advisor. *** ## For Project Admins ### Tax Handling * OSC manages tax requirements for your project for the funds that we hold. This includes: * Collecting the required tax forms (W-8 or W-9) from financial contributors and payees * Filing taxes * Issuing 1099s, as required As a fiscally hosted project, you do not need to register or file anything for tax purposes related to the funds we hold. One of the core benefits of being fiscally hosted by OSC is that we handle tax compliance on behalf of the projects that are raised through us. ### **The exception would be personal taxes.** As shared above, individuals who receive income from Open Source Collective (or one of its hosted projects) will be asked to submit a W-9 or W-8 (depending on the 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 the individual was paid throughout the year. The individual will receive a notice from the IRS for any taxes due to the US, as OSC is based there as a business. **If you have questions about your own personal tax situation, we recommend reaching out to a tax professional.** *** :point\_right: [**For more information on taxes and the Open Collective platform, please see their documentation**](https://docs.opencollective.com/help/expenses-and-getting-paid/tax-information#info-for-expense-submitters-getting-paid) [**here**](https://docs.opencollective.com/help/expenses-and-getting-paid/tax-information#info-for-expense-submitters-getting-paid)**.** # Expenses marked as "Incomplete" or otherwise have not been paid Why your expense may not have been paid by Open Source Collective ## Why Was My Expense Marked as "Incomplete"? If your expense was marked as "incomplete", it means that we need more information before processing your payment. * This does not mean your payment was canceled; it was just paused until an issue or question is resolved. * If there is action that the payee or project admin must take, OSC will leave a comment in the expense. * Sometimes, if no comment is left, it means our team is reviewing the payment for another reason, and no action may be required from you. *** ## My Payment Didn't Go Through. It's the payee's responsibility to ensure their payment method is set up correctly and that all necessary sections are completed on Open Collective, but if something doesn't go through, we're here to help. If the issue is tied to a specific expense, the quickest way to get support is by commenting directly on that expense. You can also email us at . Please include the expense link. Keep in mind: sometimes payment processors (like banks or PayPal) may take longer than expected to complete a transaction. *** ## What Happens if OSC Identifies a Payment Issue? 1. **Notification** 1. OSC will notify the hosted project and/or payee by commenting on the expense and marking the expense as 'incomplete'. 2. **Required Action Within 30 Days.** 1. The payee or project admin must edit and correct the issue. 2. The project admin must re-approve the expense after the changes are made. 1. If no corrections are made within 30 days, OSC will close the expense request. 2. If payment is still required, the payee should resubmit the expense. 3. **End-of-Year Check** 1. At the end of the calendar year, OSC will make one final attempt to confirm whether the payment is still needed. If no response is received within 30 days, the expense will be closed. ### Why does OSC Close Unresolved Expenses? By declining unresolved expense requests after 30 days, OSC prevents: * Confusion in expense tracking for the project and OSC * Inaccurate financial reporting and budget complications OSC can[ pay out funds](https://docs.opencollective.com/help/expenses-and-getting-paid/expenses#by-what-method-can-i-get-paid) via PayPal and electronic bank transfer via Wise. Make sure to review the[ Expenses and Getting Paid](https://docs.opencollective.com/help/expenses-and-getting-paid/expenses) section of Open Collective’s documentation for a complete overview of the process. # Leaving Open Source Collective Unhosting your project from Open Source Collective Once you join OSC, there is no contractual obligation to stay with us. It is a sign of success when hosted projects scale beyond our fiscal hosting program! ## Moving to a New Nonprofit We are happy to transfer any funds or assets held on behalf of your project to another non-profit fiscal host/sponsor, as long as the funds will continue to support open source. To start the process, please email us at ** and let us know you would like to transfer your assets to a new fiscal host. We will send you a form to fill in with some of the information we need to complete the request, which includes: * Name and URL of the OSC project's Open Collective profile * Name and URL of the nonprofit entity acting as the new 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 *** ## Closing My Project If your project is closing down, you will need to do the following: * If OSC employs maintainers on your project's behalf, please email us at ** to ensure we have enough time to transition the employee. * Verify all associated expenses with your project have been submitted, approved, and processed for payment. * If you have virtual cards, update your card information on any external services that store payment information. Virtual cards associated with your project 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 provide a complete list of all assets to be transferred. * Notify funders with recurring sponsorships or any institution that has provided grants. Inform them that you are shutting down the project and ask what they would like to do with any remaining grant funds. # Applying for and Accepting Grants Being fiscally hosted by OSC opens doors to funding that isn't always available to an individual maintainer or an unincorporated project — including grants, sponsorships, and corporate contributions. ### How it works When your project applies for a grant, OSC acts as the receiving organization on your behalf. Grant funders pay us, and we deposit the funds into your account on the platform, where you can use them for reimbursements or invoices just like any other contribution. Because **we're the receiving organization**, we need to be involved from the early stages of your application, not just once the money arrives. Many grant applications ask for details about the fiscal sponsor (our EIN, financial or organizational information, sometimes signatures), so reach out to us as soon as you start putting an application together, and we can help fill in any paperwork that nam. ### A note on nonprofit status Some grants are restricted to 501(c)(3) organizations. Open Source Collective is a 501(c)(6) nonprofit, so before applying, confirm that the grant you're interested in allows funding to a 501(c)(6). If you're not sure, ask us; we're happy to help you check. ### NSF grants We can help with National Science Foundation (NSF) grants, but there's a structural limit to our involvement. OSC can only act as a secondary awardee (subawardee), never as the primary awardee. That means: * Your university (or other primary awardee) applies for and receives the award directly from the NSF. * Your university names OSC as a subawardee on the application and issues us a subaward agreement. * OSC invoices the university — not the NSF — and deposits the funds into your account on the platform, which you can use to pay out reimbursements or invoices. **Primary awardee** — receives the total award directly from the NSF. Responsible for distributing the approved budget to subawardees and for overall financial reporting. **Secondary awardee (subawardee)** — receives funding through a subaward agreement issued by the primary awardee, and invoices the primary awardee rather than billing the NSF directly. If your project is considering an NSF grant, reach out early so we can help structure the subaward relationship with your university. ### Getting started Thinking about applying for a grant — NSF or otherwise? Email us at as soon as you start the process. The earlier we're looped in, the easier it is to get any required paperwork sorted before a deadline. # Signing and Entering Into Legal Contracts How Open Source Collective handles contracts and legal agreements ## Signing Contracts and Entering Into Legal Agreements As the legal representative, Open Source Collective (OSC) will need to review and likely sign any agreement for or on behalf of the projects we host. *** ## **For Admins of Hosted Member Projects** Open Source Collective will be the legally designated 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](/about-osc/contact) OSC before entering into any contract, and we will discuss the details with you and review/amend/sign on behalf of your project. *** ## **For Financial Contributors & Sponsors** OSC is the legal and financial home of our hosted member 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 support to manage your financial contributions over the course of the year, similar to [Funds](https://docs.oscollective.org/how-it-works/supporting-projects/funds-for-open-source). * Issue template agreements for general or event-specific sponsorship. *** ## There Are Instances When We Cannot Sign for You For example, the Apple Developer Program. Unfortunately, we cannot offer this for projects. Apple's agreement would be between Apple and OSC. If there were an infraction by one project, it would affect all projects under OSC's Apple agreement. # Conference Policy Open Source Collective's conference support policy {% hint style="warning" %} Open Source Collective only supports non-technical conferences. We believe many maintainers assume the role of ‘community leader’ but have limited support for expanding their knowledge in non-technical areas, which could significantly enhance their ability to manage their projects. We believe that attending these events can help maintainers improve their project management skills and become more well-rounded leaders. {% endhint %} ## For Attendees We're delighted to support to open source maintainers to attend non-technical conferences. 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**. You can find more information about our decision and the types of conferences we support on our [announcement here](https://opencollective.com/opensource/updates/subsidising-confrence-and-events-for-open-source-maintainers-inc-foss-backstage-17-18th-march). #### Next Steps To apply for funding, simply submit an expense [here](https://opencollective.com/conferences) from your Collective, and make sure to include the ticket cost. *** ## For Organizers In addition to supporting individuals with conference attendance, we're excited to share that OSC also supports 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 rather than on major industry gatherings. * Supported events must have a code of conduct, be inclusive, and feature diverse speakers. **Open Source Focus** * We prioritize events that benefit open source maintainers, especially those who share 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 both in-person and virtual attendance options, and encourage participation over lectures. ### Next Steps 1. **Email** **us** * Email us at . Provide some basic details about the conference you're organizing, 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: * What type of support are you requesting: funding or promotional * Event overview and objectives * What specifically are you asking OSC to sponsor * How our support will impact the open source ecosystem * Any other sources of funding your event is receiving 2. **Review and Decision** * OSC will review inquiries based on the criteria above and reach out with questions. * Please send any funding requests at least 30 working days before the event. ### After Your 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. # Employment, Payroll, and Benefits Open Source Collective can offer employment and benefits to projects ## Overview Projects that are hosted by Open Source Collective (OSC) may be able to offer employment and benefits to maintainers and/or contributors. This allows projects to hire contractors or full-time employees and provide access to benefits, such as health insurance or retirement contributions. *** ## How it Works OSC partners with a Professional Employer Organization (PEO) and an Employer of Record (EOR) to manage employment for hosted member projects. ### PEO vs EOR: what's the difference? * **PEOs** — handles payroll and tax filings. They are the employer with regard to tax filings and accounting, but they do not have an employment agreement with the employee. OSC is the official employer. This arrangement is also known as "co-employment" in the U.S. * **EORs** — handles both payroll services and employment agreements, making the EOR the official employer while OSC handles the operational oversight. *** ## Key Things to Know About Employment * Before rolling out a job, OSC must be consulted to ensure adequate budget, compliance, and proper setup. * Project admins define the role — admins create the job description, decide who to hire (themselves or someone else), and set pay rates. * Projects manage their own internal structure — admins determine work practices and schedules. * Employment costs are covered by the project — wages, taxes, and benefits are paid from the project's budget. * Either OSC or our EOR is considered the official employer, not the project. The official employer will ensure compliance with employment or contractor regulations, payroll, taxes, liability, and other responsibilities. *** ## Benefits: What To Know * Employees must be located in one of the countries [covered by our PEO provider](https://remote.com/country-explorer?layout=list) and be legally allowed to work in that country. * For other types of work, projects may hire independent contractors, if allowed by employment laws (see info on worker classification below) * OSC supports salaried, exempt, part-time, and full-time employees. * 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 to sign up for healthcare or other benefits — the project is charged only if an employee opts in. * Each project determines which portion of benefit costs is covered by the project and which is paid out-of-pocket by employees. * Unlimited PTO — OSC does not track or pay out PTO. * Employee and project admins must agree to OSC's standard employment agreement. * Employees must follow policies outlined in the OSC Employee Handbook, which includes mandatory workplace policies. Since employment laws vary by location, each handbook is tailored to the specific legal requirements of the employee's location. As a result, handbooks may differ depending on where an employee is based. *** ## Retirement & Pension Contributions * In many countries, employers must contribute to retirement or pension plans. OSC and/or the EOR ensures compliance wherever this applies. * In locations without these legal requirements, we work with projects to establish an appropriate policy for the individual and ourselves as the employer. *** ## Associated Costs The following costs are deducted monthly from the project's budget:
ExpenseDetails
Wages & TaxesSalaries (amount set by project's), legally required taxes and levies
BenefitsIf employee opts into healthcare or other benefits, the cost is passed to the project
PEO/EOR Fees

$49–$99 per employee per month (U.S.), depending on

benefits status. International quotes available upon request

InsuranceCoverage under OSC’s employment liability insurance (typically $250 per year, varies by project type)
Administrative Fee$50 per employee per month
All costs are deducted monthly from the hosted project's budget. Once employment is set up, employees automatically receive direct deposit payments. Projects must maintain sufficient funds to cover relevant costs for the minimum term of an agreement (for fixed-term employment situations, it may be possible to drop below this threshold toward the end of the contract) *** ## Worker Classification: Employee vs. Contractor * Worker classification laws prevent worker exploitation and ensure individuals receive the correct protections and benefits. * Some work must be classified as employment, while others are more appropriately classified as contract work. * Regulations vary by location. Because classification is a complex legal issue, we regularly review scenarios with our legal team to ensure compliance. {% file src="/files/OzvCzRWibfe64NvcxwGk" %} *** ## Terminating Employment ### General Termination Policy * OSC is an at-will employer in the U.S., meaning that either the employee or OSC may end the employment relationship at any time. In most circumstances where the employee is not making the decision, termination will occur at the request of the project's admin, who is designated as the employee's supervisor in the employment contract. * In countries outside of the U.S., OSC follows local employment laws regarding termination procedures and notice periods. * If the project or employee no longer meets the basic requirements for employment, such as lacking the budget to cover costs, the employment relationship will end. * Where possible, we ask the project to give us advance notice, so we can take care of the termination process in a timely manner. ### Fixed-term Employment Contracts * Fixed-term employment contracts automatically expire on the specified end date, unless extended. # Trademarks & IP Open Source Collective can help you register a trademark or become the registered keeper of your trademark. ## Overview Open Source Collective (OSC) can hold and manage trademarks on behalf of our hosted member projects. This ensures that projects maintain legal protection over their intellectual property. *** ## Trademarks: What to Know * OSC can help register new trademarks and transfer existing ones * Having a trademark does not prevent someone from forking your project's code — it only protects your name, logo, or branding from unauthorized use. * OSC works with Open Source IP counsel and will assist you if the need to notify parties who infringe on your trademark and, if necessary, initiate legal proceedings to protect your rights. * OSC does not automatically take ownership of the project's intellectual property. However, we can hold assets (including trademarks) on behalf of your project, if desired. Related expenses are paid from your Collective’s budget. The costs below are estimates for a typical registration. Depending on the countries in which you register your trademark or the complexity of your application, your fees may vary. *** ## Trademark Costs and Options OSC works with an attorney specializing in open source and trademarks to ensure your project's name, logo, and brand are properly protected. When you register or transfer a trademark through OSC, you'll receive one hour of legal guidance to: * Understand your trademarks and how to use and protect them * Develop trademark guidelines that clarify how others may or may not use your trademark We recommend scheduling two calls: 1. **Strategy call** — discuss your trademark approach 2. **Review call** — discuss the implementation plan As of February 2025, the costs are as follows: * **U.S. Single Trademark Registration** — $1200 USD * Covers a single trademark (name or logo) in one category (class) * Adding an extra category: +$350 * **U.S. Trademark Transfer** — $350 USD * Covers transferring a single, already USPTO-registered U.S. trademark to OSC * Recording additional trademarks: +$25 USD each, preparing assignment of a single, already registered US trademark * **Non-U.S. Trademark Registration or Transfer**: Varies by application and country. * Contact us via email for a quote. ## Next Steps If you're interested in registering or transferring a trademark through OSC, please fill out [this form](https://forms.gle/WMkeYFGfDN9TuzHK6). Once submitted, we'll review your request and follow up with the next steps. *** ## FAQ ### Will OSC own our intellectual property? Per[ our Fiscal Sponsorship Agreement,](https://docs.oscollective.org/legal/terms-of-fiscal-sponsorship) you retain ownership of all your project's intellectual property. If you would like us to hold non-monetary assets, such as trademarks, please reach out. ### 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 helps users identify where a particular piece of software came from and who built it, which is an important tool for building trust and reputation for 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 by using the same name. A trademark registration will help you stop others from releasing a poor-quality product or even introducing malware and passing it off as your authentic code. It will also help you stop those who try to exploit your name by creating complementary products that use your name or a similar one. 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, as needed. If your Collective does not have sufficient funds to renew, we will notify you as soon as possible and work with you to either establish a successor or let the trademark lapse. Depending on the type of maintenance filings, the USPTO charges either $425 USD or $525 USD per class in the registration. Our fee to prepare and file the maintenance documents is $450 USD. Maintenance filings are due 6 and 10 years after registration. Once you file for the 10 years, maintenance is due every 10 years after that. ### What happens if someone is infringing on 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, you’ll get an idea of some likely scenarios and possible responses. If an issue arises, you can take some steps yourself, such as contacting the person directly and asking them to respect the trademark, or submitting takedown requests to online intermediaries, such as social media platforms and app stores. If the infringement occurs on a platform like GitHub or Facebook, you can ask the platform to remove the works from its services. If you have attempted to contact those involved and you have been ignored or rebutted, feel free to contact us at , 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 additional expense (e.g., legal fees) must 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 do so, 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, Waterman 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 typically 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](http://modeltrademarkguidelines.org/index.php/Model_Trademark_Guidelines) developed for open source projects by Pam Chestek to serve as a starting point. ### Leaving OSC If you are moving to another fiscal host or starting your own legal 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 to which we are allowed to transfer assets, 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](https://docs.google.com/document/u/1/d/e/2PACX-1vQbiyK2Fe0jLdh4vb9BfHY4bJ1LCo4Qvy0jg9P29ZkiC8y_vKJ_1fNgIbV0p6UdvbcT8Ql1gVto8bf9/pub) section 6 for more details about termination). ### How can I learn more? Here’s [a detailed article](https://lwn.net/Articles/673677/) based on one of Pam’s presentations on open source trademarks. Another good resource is [FOSSmarks](https://fossmarks.org/). # Domain Transfers and Registration Open Source Collective can help with domain transfers and registration ## Domain Transfers Open Source Collective uses Namecheap as our domain registrar. If your project would like to transfer a domain to OSC, here's what you need to know: * Transfer costs start at \~$15 USD but may vary depending on the top-level domain (TLD). * Renewal costs vary based on the TLD. * All costs are charged to your Collective's budget. * To transfer a domain to OSC, you must unlock your domain with your current registrar and provide us with the Authorization Code (Auth Code/EPP Code) ## Eligibility Please note that we will generally host domains for projects with an established relationship with OSC. In most cases, this means the project has been active on the Open Collective platform for at least six months and maintains a sufficient balance before we agree to host its domain. ## Next Steps If your project wishes to transfer its domain to OSC, please [fill out this form](https://docs.google.com/forms/d/e/1FAIpQLSePU6JP5AF6xlrvfIsubmsoilIrPgmEavq5s--1eey8hPXSdA/viewform) and email us at . *** ## Domain Management Once a domain is successfully transferred, responsibilities are divided as follows: **OSC will:** 1. Invite the Collective admin as the Domain Manager 2. Maintain full domain ownership 3. Manage domain renewals **The Domain Manager will:** 1. Coordinate domain renewal with OSC 2. Ensure sufficient funds in the Collective's balance for renewal costs 3. Have limited permissions *** ## Using a CDN We recommend using a Content Delivery Network (CDN), such as Cloudflare, to manage your domain's DNS settings. Before transferring your domain, we recommend updating your nameservers to those provided by your CDN. You can find step-by-step instructions in your CDN provider's documentation. Using a CDN allows you to maintain full control over your DNS configuration while OSC is the domain owner. ### Updating Nameservers Both OSC and the Domain Manager can update the domain's configuration, as needed. However, we strongly prefer that your Collective manage the day-to-day DNS configuration through a CDN provider, such as Cloudflare, to ensure greater flexibility and control. # Governance and Mediation What project admins should know about governance for OSC-hosted projects OSC supports the infrastructure needs of open source projects, but our model might differ from other fiscal sponsors who take a more hands-on role on a project level. We expect project administrators to manage their project’s leadership structure, decision-making processes, and access to shared resources like the codebase as part of their governance. OSC supports your autonomy — you know what’s best for your code and community. However, we also recognize that governance challenges can arise. While we can’t step in to resolve every issue, this section outlines how OSC responds in situations that affect project stability, access to funds, or our responsibilities as fiscal host. We plan to expand this section with more guidance over time. In the meantime, you can explore our Resource Guide for additional support, including blog posts and tools on governance and project stewardship. ## 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 significant event, since other admins on your project should still have access. Please contact GitHub. However, if you lost access due to internal governance breakdowns, security incidents, etc., we will freeze your account at the first instance to ensure that the money we hold on behalf of your project 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 multiple admins again have access to your code, please get in touch. OSC will keep accounts frozen until all of our original fiscal sponsorship terms are met. This can also include other incidents, such as the deletion of Codes of Conduct or a severe loss of community membership (e.g., through a forking event). *** ## The other admins have locked me out! What can OSC do? Please see the above. Email us immediately at . *** ## I am unable to permanently access my original codebase. Can OSC release funds to me individually? No. OSC holds funds on behalf of communities. We will work with you if you can show that 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](https://docs.oscollective.org/getting-started/terms-of-fiscal-sponsorship), the Termination section, for more information on how we manage funds if we decide to terminate our agreement with your collective due to unresolvable issues. # Google Summer of Code This page has instructions on how to accept GSoC payments through OSC * As a project hosted by OSC * As a project not hosted by OSC * And as an individual contributor or mentor {% hint style="info" %} [Google Summer of Code](https://summerofcode.withgoogle.com/) is a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors. {% endhint %} ## For projects currently hosted by OSC Please use the following information when answering the form's questions to ensure accurate invoicing and payment processing. \ \ **On the first page of the form:** * The email address of the person responsible for accepting payment at your Organization is -- **** * Does your Mentor Organization have an account with Payoneer and is it 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? -- **** * 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, email us at '*****'* to confirm you will be participating, and we can better track the payment associated with your organization. ## For projects NOT currently hosted by OSC If your organization or open source project has been accepted to Google Summer of Code (GSoC), you can apply to Open Source Collective to receive and spend the money. **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 will participate in the Google Summer of Code (GSoC) program and doesn't have a legal status. Being fiscally hosted by Open Source Collective, you don't need to have a bank account, 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 GSoC Contributors and Mentors. Steps to create a collective profile and apply to OSC. 1. First, you need to create a personal account. Visit to create a personal account. 2. Once your personal account is set up, you can create a Collective profile for your project. Visit the guide to create a collective profile at . 3. Apply to Open Source Collective at . (add a note that your project has been accepted by the Google Summer of Code 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/organizational profile if your project doesn't have one at the Open Collective platform ## If you are participating as a GSoC Contributor or Mentor 1. Create an Open Collective profile at if you don't have an account on the Open Collective platform yet. 2. Visit the Google Summer of Code (GSoC) guide on receiving the funds and reach out to your organization administrator/mentor, who will guide you on how to submit an expense and receive your stipend. \ Please reach out with any questions to '*****'* # Google Season of Docs Google Season of Docs partners with OSC as a fiscal host and uses the Open Collective platform to distribute grants to accepted projects. This page has instructions on how to accept GSoD payments through OSC * As a project that would like to be hosted by OSC * As a project with a legal entity different than OSC * And as an individual contributor or mentor *** ## Benefits of Joining OSC as a GSoD Project Joining OSC offers numerous advantages, such as the ability to easily receive, manage, and spend funds. More information about the benefits of having OSC as a fiscal host is available [here](/interested-in-joining-osc/is-osc-right-for-me). If your open-source project has been accepted into the Google Season of Docs (GSoD) program and needs a fiscal host, you can submit an application to be hosted by Open Source Collective (OSC). ## **How to Apply for Fiscal Hosting with OSC:** If your project needs a fiscal host for GSoD, follow these steps: 1. Create a personal Open Collective account, if you don't already have one: 2. Set up a Collective profile: 3. Apply to Open Source Collective: 1. Add a note that your project has been accepted by the Season of Docs program *** ## **What if my project already has a legal entity?** You do not need to apply to OSC if your project already has a fiscal host or a legal entity. Instead, you may create a collective or organizational profile on the Open Collective platform to receive funds if your project does not already have one. More information on how to create a profile can be found here: . *** ## What if I am participating as a Technical Writer or Volunteer? 1. If you don't have a user account on the Open Collective platform yet, create one [here](https://opencollective.com/create-account). 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?** There are 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](https://docs.oscollective.org/how-it-works/fees) or contact us. **2. How do I contact Open Source Collective if I have any questions related to fiscal hosting and expenses?**\ Please reach out to . We will get back to you shortly. **3. How to contact the Open Collective platform if I have any account-related issues?** Please reach out to , and the Open Collective team can help you with your profile and account-related issues. **4. I have queries about Google Season of Docs programs and grants.** Please [contact](https://developers.google.com/season-of-docs/docs/contact) the Season of Docs team if you have any questions or concerns about grants or the program. # GitHub Sponsors Open Source Collective is an approved fiscal host for GitHub Sponsors GitHub and Open Source Collective work together to ensure that any project registered on GitHub Sponsors and using OSC to manage funds will automatically receive payments each month. *** ## 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. You can create a GitHub organization by following [this guide](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/creating-a-new-organization-from-scratch). * A[ Collective](https://opencollective.com/opensource/apply) on the Open Collective platform using Open Source Collective as your fiscal host. [Read more about applying to OSC here.](/how-to-apply) {% hint style="warning" %} *Organizations on Open Collective are not the same as Organizations on GitHub. You must create a **Collective** in order to manage your project's finances on Open Collective.* {% endhint %} To register for GitHub Sponsors, follow these steps: * Visit [github.com/sponsors](http://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: ) ![Be sure to select 'Open Source Collective' from the dropdown.](/files/2HJHl96BUJGe6T76d62w) * Click Join Waitlist. GitHub staff will review your application, and you'll be notified when you can proceed to the next step. {% hint style="info" %} Open Source Collective acts as your legal and financial home. You do not need to enter your own Stripe account or business information.\ \ If you reach this step, please contact , and we will amend your application with GitHub. {% endhint %} *** ## Receiving Financial Contributions GitHub sends payments to GitHub Sponsors participants monthly. We allocate these payments when we receive them, typically at the end of the calendar month. Funds will be automatically added to your project's Open Collective balance, minus our 10% administration fee, at the end of each month. You'll see 'GitHub Sponsors' listed as the source of these funds. If you have not received a payment that you expected by the end of the month, please contact us. ## Frequently Asked Questions ### When will we receive our contributions from GitHub Sponsors? We process payouts from GitHub monthly, typically at the end of the calendar month or in the 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 that sponsor open source projects, i.e., designed for paying money out, not accepting money like Collectives. # Polar.sh Open Source Collective can receive funds from Polar and allocate them to your Open Collective account. If your project is hosted by Open Source Collective (OSC), and you have an existing [Polar account](https://polar.sh/), you can set up payouts directly to your Open Collective balance. ## How To Set Up Polar Payouts Follow the official Polar guide: to link your Polar account to your Open Collective profile *** ## Important Notes * Payout frequency: Polar donations are processed periodically, or on a quarterly basis. * OSC fiscal hosting requirement: We can only accept Polar payouts for projects that are actively hosted by OSC. *** ## Need Help? If you have any questions or need assistance, contact us at . Be sure to include your project's name and your Open Collective URL. # Drips Open Source Collective can receive funds from Drips ## Supporting a project through Drips If a project is hosted by Open Source Collective (OSC) and is set up on Drips, funds sent through Drips can be automatically transferred 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](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/creating-a-new-organization-from-scratch). * A[ Collective](https://opencollective.com/opensource/apply) 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.](/how-to-apply) * Commit access to the corresponding code repository. * Optional: A hardware or software wallet that supports the Ethereum network. Once you have been accepted to Open Source Collective, contact us at to organize an onboarding call. 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 OSC generate and own a wallet for your project. * Decide on an amount to send to your project's balance, 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. {% hint style="info" %} Note that 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 back to the Collective if needed. {% endhint %} [Read more about using Drips with a Safe Wallet here.](https://docs.drips.network/usage-with-a-safe/) *** ## Receiving Financial Contributions Drips facilitates the constant stream of any ERC-20 token to any number of projects, represented by a GitHub repository. OSC 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% host 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 at a frequency that works best for your project, typically monthly. ### What fees will be charged? A standard 10% hosting fee applies to 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. # Other Payment Platforms Open Source Collective accepts funds from all major funding sources, we do not make payments to projects through other funding platforms with the exception of donations through Ecosystem Funds. ## Working With Other Platforms to Receive Funds Open Source Collective (OSC) is happy to accept funds through third-party platforms such as Thanks.dev, Stack.aid, Community Bridge, and more, where it's operationally possible for both OSC and the third-party platform. If you are already a hosted member project and wish to use a platform, get in touch. We will work with the platform provider to coordinate payment routing to your project's account whenever possible, depending on the platform’s capabilities and willingness to collaborate. Please note that acceptance also depends on whether the platform supports working with fiscal hosts # Who and What is OSC? What is Open Source Collective? ## About Open Source Collective Open Source Collective's (OSC) 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. Our primary service is fiscal hosting, a model that allows us to provide open source projects with the legal and financial infrastructure needed to. Think of us as an ‘API' between the world of open source communities and the world of accounting and invoices. *** ## Why is OSC a 501(c)(6) instead of a 501(c)(3)? OSC is a member-based nonprofit, with our hosted projects being our members. We are structured as a 501(c)(6) organization — a nonprofit designation for entities that promote the shared interests of a specific field or industry. In our case, that field is open source. This status gives us the flexibility to collaborate with other entities while staying focused on our mission. The IRS generally does not consider open source software a public benefit solely because it's free and open source software (FOSS). This means many open source projects may not qualify for 501(c)(3) status, which is reserved for organizations with charitable, educational, or similar public benefit. Want to learn more? Here are a couple of articles that provide additional information and context related to open source and the IRS: * * **Note**: this is not legal advice. For specific questions regarding IRS designations, please consult a nonprofit attorney. *** ## Our Mission Our mission is to promote the sustainability and health of the open-source ecosystem while benefiting all who create and use open-source software. ## Our 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. *** ## What We Think These philosophy statements describe how we approach our work: ### 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, diverse, community-centered approaches. We encourage members to consider sharing their responsibilities and building community. ### 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 benefit all members in our approaches. *** ## Our Strategy You can view our [2022-2025 strategy here](https://blog.opencollective.com/open-source-collectives-strategy-2022-2025/). *** ## How We're Organized ### Board of Directors OSC's Board of Directors provides strategic oversight, ensuring that our work has impact and is aligned with our community. #### Who's On The Board? You can find the members of our Board of Directors [on our website](https://oscollective.org/about/). #### Executive Director The board appoints an Executive Director who is responsible for executing agreements and advancing OSC's mission. Our Executive Director is Lauren Gardner. *** ## Our Team The OSC team works behind the scenes to support our hosted member projects, maintaining operations, and provides guidance to the community. Our team is globally distributed across different time zones, allowing us to easily work with projects where they are and provide support across time zones. :point\_right: **You can find out more about the OSC team** [**on our website**](https://oscollective.org/about/)**.** *** ## Our Code of Conduct OSC uses the general Open Collective [Community Guidelines](https://docs.opencollective.com/help/about/the-open-collective-way/community-guidelines). We also have a Terms of Service available [here](https://docs.oscollective.org/getting-started/terms-of-fiscal-sponsorship). Please take a look at them! *** ## What's the Difference Between Open Source Collective and Open Collective? If you're considering applying for fiscal hosting with Open Source Collective (OSC), you might be wondering how we relate to Open Collective — especially since our names are so similar. This is a very common question, and we want to clarify the distinction between the two. ### Open Source Collective (OSC): The Fiscal Host OSC is the fiscal host for open source projects and funds. We handle fund administration, compliance, and financial oversight so that the projects we host can focus on building and maintaining open source software. OSC was originally incubated by Open Collective in 2017, but we are now an independent organization with our own mission, board of directors, staff, and leadership. ### Open Collective: The Platform Open Collective is a fundraising and financial management platform. It provides the software that fiscal hosts — including OSC — use to process donations, manage expenses, maintain financial transparency, and more. We use Open Collective as a ledger, meaning it serves as our real-time, transparent record for every project that we host. All incoming funds, expenses, and transactions are tracked on the platform. Open Collective does not hold any money and is not the financial and legal home for the open source project — it is where financial activity is recorded and managed. # OSC's Broader Work We're best known for our fiscal hosting program, but that's not everything we do... In addition to our fiscal hosting work, Open Source Collective (OSC) actively engages with the broader open source ecosystem. Through partnerships, advocacy, and participation in key events, we strive to foster a more sustainable and collaborative environment for all in the ecosystem. *** ## **Free Data and Tools For Developers, Researchers, and Policymakers** Open Source Collective funded the development and maintenance of[ ecosyste.ms](https://ecosyste.ms): the world's most comprehensive and accurate, public and *free* dataset about open source production and use. [ecosyste.ms](https://ecosyste.ms) is a set of free services and tools for a growing community of researchers, policymakers, developers, and funders seeking to identify, secure, and sustain critical open source components. *** ## **Funding Campaigns and Services** Open Source Collective has a long history of driving sponsorships and *investments* in open source through a series of funding campaigns and tools:
* Working with Open Collective Inc. we developed [BackYourStack](https://backyourstack.com), an application to discover and support your open source dependencies. * We provided administrative and technical support to [FOSS Responders](https://fossresponders.com) during the first wave of the pandemic and subsequent lockdowns. * We pioneered a new approach to campaigns using quadratic or 'democratic' funding with GitCoin as part of [FundOSS](https://www.fundoss.com). Most recently, we joined The Open Source Pledge as a supporting organization through our work with Ecosystem Funds. *** \ **Funding Critical, Digital Infrastructure** -------------------------------------------- We developed [Ecosystem Funds](https://funds.ecosyste.ms) primarily to address concerns with the lack of financial support for critical open source components. \ \ Using billions of data points from [ecosyste.ms](https://opencollective.com/redirect?url=https%3A%2F%2Fecosyste.ms) we packaged millions of the most critical open source components into [a few hundred funds](https://opencollective.com/redirect?url=https%3A%2F%2Ffunds.ecosyste.ms%2Ffunds%2Fsearch%3Fquery%3DR) centered on a language, framework, or package, turning [a process that can take months](https://opencollective.com/redirect?url=https%3A%2F%2Fopensource.microsoft.com%2Fblog%2F2024%2F06%2F27%2F5-things-we-learned-from-sponsoring-a-sampling-of-our-open-source-dependencies%2F) into a five-minute conversation with your CTO.\ \ Ecosystem Funds takes a platform-agnostic approach to funding open source, paying maintainers where *they* choose to accept payments. We support all known platforms used by communities to support their work. \ \ *Open Source Collective donates 1% of its annual revenue to critical open source projects through Ecosystem Funds, and we call on others to do the same.*
*** ## **Partnerships** ### We work both as an administrative partner and/or payments processor for a number of well-known open source funding initiatives:
* Google's Summer of Code and Season of Docs projects * Digital Ocean's Hacktoberfest campaign * GitHub's Sponsors and Secure Open Source Fund programs Finally we are open to accepting payments from well known open source funding platforms like GitHub Sponsors, Drips, Thanks.dev, StackAid, FLOSSBank, GitTip/Gratipay, LibrePay, and more. :point\_right: [**See here for more information.**](/campaigns-and-partnerships/other-payment-platforms) *** ## Policy and Advocacy Open Source Collective is a founding member of the [Open Policy Alliance](https://opensource.org/programs/open-policy-alliance#:~:text=The%20Open%20Policy%20Alliance%20is,content%2C%20research%2C%20and%20education.) an organization educating and informing US policy related to open source content, research, and education. \ \ We actively engage in advocacy through partnerships with nonpartisan organizations and institutions such as the Atlantic Research Council, the Alfred P. Sloan Foundation, and the Ford Foundation, and directly through Sustain OSS. Sustain was created to move the emerging conversation around the sustainability of open source toward practical progress. In 2017 Sustain held its first in-person meeting, bringing together 100 people from a broad range of organizations and institutions. The [subsequent report ](https://sustainoss.org/assets/pdf/SustainOSS-west-2017-report.pdf)has formed the basis for discussions, events, and further publications since then. We also support a number of corporations in their internal policies on open source sustainability and support. *** ## **Education** In addition to our work with Sustain, we support member projects and the broader open source community through a number of educational and support initiatives, including: * A series of live, workshop-based training and subsequent guides published at guides.oscollective.org * Financial support for maintainers covering the ticket cost for non-technical conferences and events, which you can [learn more about here](/for-hosted-member-projects/conference-policy). # Logo & Brand Assets Open Source Collective's logo and brand assets Looking for the Open Source Collective (OSC) logo or other brand assets? You've come to the right place. ## Primary Colors * **Purple (Main) —** #4B3084 * **Purple (Light) —** #954AED ## Secondary Colors * **Mint —** #4CFFAE * **Tile Blue —** #68E1F4 ## Where to Direct Links If you need to refer or link to Open Source Collective, please direct links to , and feel free to use the images below. ## Our Symbols, Logo, and Cover Images ![logo with full name](/files/-MYcPslX7wnv_feUkFQq) ![small square logo icon](/files/qOPwgQJEFEhazMxWPwvY) ![cover image centered text](/files/pMNKMrSPkQgomC3XKVMv) ![cover image right text](/files/h5eWVrDfdhFRKXRxyRiP) ![cover image no text](/files/DCBKKZmfQt5P736yUSFc) ## Intellectual Property and Your Project ### **Will OSC own our intellectual property?** Per[ our Fiscal Sponsorship Agreement,](https://docs.oscollective.org/legal/terms-of-fiscal-sponsorship) your project will retain ownership of your project's intellectual property. If you would like us to hold non-monetary assets, such as trademarks, please reach out. # Official Documents & Tax ID Open Source Collective's legal status and compliance policies ## 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, including the fees we collect, are reinvested in our mission: promoting a sustainable and healthy open source ecosystem. Donations to OSC or any of the projects that we host are not considered charitable contributions and therefore are not tax-deductible. OSC is registered in the state of California as a Mutual Benefit Corporation. *** ## Tax ID & W9 You may provide this information to anyone who asks for it (sponsors or grantmakers may request it). Our EIN (tax ID number) is: **82-2037583** Our DUNS number is: **105389379** OSC’s NAICS code is [**813910**](https://www.naics.com/naics-code-description/?code=813910) {% file src="/files/cL6nNIHyhmtygSKaJLSc" %} # Anti-Money Laundering & Financial Integrity Statement ## Purpose Open Source Collective (OSC) is committed to maintaining the highest standards of financial integrity, transparency, and accountability. To protect our hosted projects, donors, and staff, OSC operates under a robust Anti-Money Laundering (AML) framework that prevents the misuse of funds, detects suspicious activity, and ensures compliance with applicable laws and international best practices. ## Commitment to Ethical Stewardship OSC voluntarily upholds AML and counter-terrorism financing standards, even though OSC is not a bank or Money Service Business. This reflects our commitment to good governance and to safeguarding the open source ecosystem we support. ## Scope of Application OSC’s AML and compliance standards apply to all of our financial activities. Including donations and expenses. All participants – including collective administrators, donors, and suppliers – must operate in accordance with applicable laws and regulations as put forth in our Terms of Fiscal Hosting. ## Risk Management and Oversight OSC maintains internal procedures to review, monitor, and assess financial transactions to prevent misuse of funds. Oversight is led by senior management and supported by all staff, with modern verification and monitoring tools. Risk assessments are conducted regularly to adapt to emerging threats. ## Due Diligence and Verification To protect the integrity of our financial systems, OSC verifies the identities of payees, vendors, and other relevant parties before funds are disbursed, when warranted. Donations and payments are accepted only through trusted, regulated payment processors. OSC may request additional information when transactions exceed certain thresholds, originate from higher-risk regions or sources, or are selected at random. ## Sanctions and Legal Compliance OSC complies with US sanctions laws. Any attempt to conceal identity, source of funds, location, or other aspects to evade sanctions or regulations will result in account suspension and potential reporting to authorities. ## Confidentiality and Data Protection All personal information, including financial information, collected for compliance purposes is handled securely and confidentially, in accordance with OSC’s[ Privacy Policy](https://oscollective.org/privacy-policy/). ## Reporting and Ethics OSC fosters a culture of transparency and accountability. Staff and community members are encouraged to report any suspicious behavior. Retaliation against individuals who raise good-faith concerns is prohibited. ## Our Assurance OSC takes its role as a fiscal host seriously. Every dollar entrusted to us is subject to diligent oversight. Through strong internal controls, regular reviews, and support from external accounting professionals, OSC ensures that all funds are used responsibly and in accordance with our mission to support open source initiatives. # Contact Us How to reach Open Source Collective The best way to get in touch with Open Source Collective (OSC) is by emailing us at ****. Please use this email for any questions or support inquiries regarding your hosted open source project or Fund. *** ## Other Places You Can Find Us * **Stay updated:**[ Updates from OSC](https://opencollective.com/opensource/updates) on Open Collective. * **Connect with us:** on [LinkedIn](https://www.linkedin.com/company/opensourcecollective), [Bluesky](https://bsky.app/profile/oscollective.org), and [Mastodon](https://mastodon.opencollective.com/@opensourcecollective) * **Discord:** find us in **#open-source-collective** on the [Open Collective Discord](https://discord.gg/AtKhYFgrgc) *** ## If you need Open Collective platform help 🎟 OSC does not manage the Open Collective platform. For platform support, go [here](https://opencollective.com/help). # Growing Your Contributors *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 ![A figure showing the contributor funnel, with more users, fewer contributions, even fewer maintainers, and ultimately a large emerita base. Along the way, attrition lessens the pipeline, with the crux of the funnel being the maintainers.](/files/L4c43rGfY6TgnZy3ojK8) 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](https://harihareswara.net/posts/2015/how-to-improve-bus-factor-in-your-open-source-project/), 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](https://changeset.nyc/resources/installation-audit.html) 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](https://opentechstrategies.com/), [Maintainer Mountaineer](https://maintainer.io/), [Changeset Consulting](https://changeset.nyc/), [pubstruct](https://pubstruct.com/), or [Galaxy Rise](http://www.galaxyriseconsulting.com/). If you can't afford to pay, ask new contributors to [write a tech discovery report](https://diff.wikimedia.org/2014/03/25/seeing-through-the-eyes-of-new-technical-contributors/), 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](https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html) and [Outreachy](https://www.outreachy.org/), or run courses like [Drupal Ladder](https://slidedeck.io/fureigh/get-more-contributors), 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](https://wiki.mozilla.org/Contribute/analysis) (see [the "Measuring Engagement" presentation for more details](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g4435d357b_20)), 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](https://zulip.readthedocs.io/en/latest/contributing/zulipbot-usage.html) 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](https://en.wikipedia.org/wiki/Wikipedia:Teahouse/About) 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.](https://harihareswara.net/posts/2017/how-to-teach-and-include-volunteers-who-write-poor-patches/) 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. # Deciding on how to use your money How to use funds for your OSC project! *This is a guide based on an Open Source Collective workshop led by Sumana Harihareswara of Changeset Consulting in January 2022. It focuses on helping Open Collective-hosted open source software projects decide how to use money they have already raised. All examples are in US dollars.* ### Why you should (or shouldn't) spend your money A reasonable frugality can sometimes creep into needless hesitation to spend *any* money. However, your donors gave you this money so that you could spend it, and you should: * *Advance your project in ways and at speeds you currently can't.* There are tasks, chores, and infrastructure that are much scarcer if you only rely on volunteer labor. For example, it's hard to get donated laptops that would work as good development environments. * *You need to spend it in order to attract more sponsors!* If donors notice that you collect money but never spend it, they may reasonably ask why you need the money, and choose to donate to a project where their money will be used. * *Experiment with different project approaches to improve your flexibility.* Open source projects can fail to notice opportunities because they require an outlay of money. Trying out a pilot engagement with buying a service, hiring a contractor, or otherwise spending money (that you can spare to lose) helps you understand whether this will work for your project, so you have more flexibility for the future. There's no guarantee that your spending will prove to be the right choice; every purchase or contract is a bet. You and your team, through experience, can learn to make better and worse bets. Even if an experiment goes poorly, you can learn from it and course-correct to run better experiments in the future. * *Aid intangible morale for your contributors and constituents.* Don't underestimate the power of acknowledgment and the power of shared identity. A relatively small investment in stickers, awards, t-shirts, and similar merchandise can go a long way to aid in contributor retention, marketing to users, and general team morale. Generally speaking, spending less than 10% of the money you already have saved, or making a one-time expenditure of less than 20% of the stable recurring monthly income of the project, should be something your project can do without an agonizing decision-making process. The first time you do it will be harder than the fifth or tenth. But there are good reasons to save up your money as well, in some specific circumstances: * *Saving money towards specific activities.* If you know you want to save up $8,000 for a particular contractor engagement, and you only receive $500 per month in donations, it makes sense to concentrate on improving your fundraising (see the ["Recruiting financial sponsors" resource](https://opencollective.com/workshops/events/recruiting-financial-sponsors-595f4cc3)) 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](https://docs.opencollective.foundation/what-we-offer/employment) "must maintain a budget of at least 3x monthly employment costs, to ensure funds are available to pay employees." 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... ![Money and Resources, shown by those that go into a project and then what comes out of it](/files/1Vazu7kQ7V2Q5b6CxLAD) ...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](https://outreachy.org) 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](https://www.djangoproject.com/fundraising/#fellowship-program) or [Jupyter contributor in residence](https://blog.jupyter.org/lessons-learned-from-jupyters-contributor-in-residence-pilot-427e2b361a7b): approximately $50K/year. This role could be a driver (directly advancing features) or a supporter (reviewing others' code, working on infrastructure, and so on). b. Outreachy intern: [one-time cost, USD$6,500](https://www.outreachy.org/mentor/). Probably a driver role. c. Professional education and tools for developers -- trainings/books for a book club, commercial task-tracking systems such as Todoist or The Amazing Marvin, laptops, continuous integration, etc. Cost could range from $5 to $3,000, one-time or recurring. A supporter expense. (Note that, depending on a contributor's country of residence, they may need to account for equipment that you give them in their yearly income tax return; a local accountant or tax adviser can tell you whether to note it as taxable income.) d. Fly one person to meet another for a one-week in-person hack week: maybe $1,500 for the flight, $750 for the hotel, and $250 for assorted transit and food expenses, so $2,500 total. A supporter expense. e. Pay someone $200 to design a logo (or, hold a logo contest with open voting, and offer a $100 reward), and then make stickers available for people to buy (or bulk-order $150 worth to share at a conference). Resources: [Heidi Waterhouse's guide on stickers](https://heidiwaterhouse.com/category/stickers/), [sticker.how](https://sticker.how/), and [StickerApp](https://stickerapp.com/). A supporter expense. f. Pay $100 in fees to help a contributor getting a passport for the first time, so they can travel to international conferences. A supporter expense. g. Pay $30-50 per hour to a virtual assistant firm to hire a secretary to take meeting minutes for conference calls, and/or pay for [human](https://whitecoatcaptioning.com/) or automated captioning services on video/audio calls to provide accessibility and a record for later reference. A supporter expense. Also check out recommendations in [this Open Collective article from 2017](https://medium.com/open-collective/has-your-open-source-community-raised-money-heres-how-to-spend-it-3e9dd957dad). #### 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](https://docs.opencollective.foundation/what-we-offer/employment), but that is rare so the rest of this section will assume that you will hire them as a contractor. You could make a specific decision to start paying a specific existing contributor or new contributor without any public or open decision making process. Or, you could write up a job description and ask for applications, [as the Python Software Foundation has done](https://github.com/python/request-for), or give contributors the option to ask for compensation/sponsorship, [as Mautic does](https://contribute.mautic.org/policies/paying-contributors). 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](https://docs.opencollective.com/help/collectives/expenses); this is to provide both the project and the contractor with legal protection and an actual contract with terms of engagement. This engagement is very successful, enabling new features, and focusing on tasks that will make a difference to the project community. #### 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](https://bountysource.com/). (Patch bounty programs are distinct from *bug* bounty programs, which are incentive programs that pay security researchers to report vulnerabilities they've discovered.) 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](https://mako.cc/writing/funding_volunteers/funding_volunteers.html), paying for the kind of work that is demonstrably not already being done for free by volunteers can prevent resentment from existing volunteers. If your project needs particular kinds of development work that your volunteers are disinclined or not skilled enough to do, such as integration into an obscure framework, and this need is blocking you from achieving your goals, concentrate on those tasks for bounties you offer. ### Decision-making and governance Who can make decisions about how to spend an Open Collective's money? Per [the expenses documentation](https://docs.opencollective.com/help/collectives/expenses): > 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](https://docs.opencollective.com/help/collectives/budget) and [expense policies](https://docs.opencollective.com/help/collectives/collective-settings/expense-policy) as well as ["ten ways to make decisions about money"](https://blog.opencollective.com/ten-ways-to-make-decisions-about-money/).) 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](https://github.com/gratipay/inside.gratipay.com/issues/319#issuecomment-166757830)). Do this consistently, and use Open Collective's tools to leave the records up for future inspection. This is relatively easy if you are managing all the expenses via Open Collective invoices. * *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. # Using Funds Directly Wondering how best to spend your project's funds? Here are some short-term, actionable ideas 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.*](https://blog.opencollective.com/has-your-open-source-community-raised-money-heres-how-to-spend-it/) # Marketing, Publicity, Roadmaps, and Comms How to think about how you talk about your project *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... ![A graphic showing how information flows through a project, between maintainers, contributors, and up- and downstream](/files/Tp4am1pdCgRun4AOqmBp) ...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](https://pip.pypa.io/en/stable/development/release-process/) 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](https://harihareswara.net/posts/2017/inclusive-or-hospitality-in-bug-tracking/), 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](https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf) 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](https://github.com/OpenTechStrategies/open-source-archetypes/blob/master/arch-houseplant.ltx) 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: ![A figure showing how designs lead to architectural decisions leads to testing to releases to distribution](/files/vEJxgAlYlRExW6VtU76L) 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](https://mail.python.org/archives/list/pypi-announce@python.org/message/YTZWD5H4H3VCQTQVPRDLH2TTHVTJS7JQ/) that links to a longer "how to test this" document [example](https://wiki.python.org/psf/WarehousePackageMaintainerTesting) 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](https://mail.python.org/mailman3/lists/pypi-announce.python.org/)) 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"](https://dw-dev.dreamwidth.org/104915.html) -- [here's how and why it works](https://harihareswara.net/posts/2011/discovering-an-origin/) and [here's how to write one](https://wiki.dreamwidth.net/wiki/index.php/How_to_do_a_Code_Tour). Another example: a [Python version release announcement](https://blog.python.org/2021/10/python-3100-is-available.html) or [an announcement of a new feature in PyPI](https://blog.python.org/2019/06/pypi-now-supports-two-factor-login-via.html). * 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](https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/), or discuss your principles and vision of your project's future, [as Zulip did](https://blog.zulip.com/2021/12/17/why-zulip-will-stand-the-test-of-time/). 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](http://akaptur.com/blog/2012/12/18/git-add-p-the-wave-of-the-future/), [videos](https://techcommunity.microsoft.com/t5/microsoft-mvp-award-program-blog/excel-influencer-teaching-the-tiktok-masses/ba-p/2528492), podcasts, conference talks, [zines](http://harihareswara.net/posts/2016/new-zine-playing-with-python-two-of-my-favorite-lenses/), etc. For example, the pip team [scripted, filmed, edited, and published a two-minute video to announce major changes to pip](https://youtu.be/B4GQCBBsuNU) 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: File bugs and give us feedback using this survey: For release highlights and thank-yous to our project funders, see . The full changelog is at . 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: Thank you again, \[name] Python Software Foundation P.S. For future pip announcements, please subscribe to , 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 # Recruiting Financial Sponsors How to attract corporate sponsors for funding for open source projects! *Based on an OSC workshop led by Sumana Harihareswara of* [*Changeset Consulting*](https://changeset.nyc) *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. ![Figure showing money and resources flowing into and out of a project](/files/1Vazu7kQ7V2Q5b6CxLAD) 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](https://thegnomejournal.wordpress.com/2010/03/30/canonical-upgrading-gnome-bugzilla-and-commercial-sponsorship/]\(https://thegnomejournal.wordpress.com/2010/03/30/canonical-upgrading-gnome-bugzilla-and-commercial-sponsorship/). 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. {% hint style="info" %} This is also a good moment to consider Tidelift as a sponsor aggregator that can fund your project, especially if your project is a library that gets integrated into other software. Look up your package [on Tidelift's site](https://tidelift.com/lifter/search/) to see whether your package is already earning income there. {% endhint %} #### **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](https://github.com/psf/fundable-packaging-improvements]\(https://github.com/psf/fundable-packaging-improvements). 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](https://www.beautifultrouble.org/toolbox/#/tool/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](https://docs.opencollective.com/help/financial-contributors/organizations/sustainer-resources). 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.](https://docs.opencollective.com/help/financial-contributors/organizations/organization-faq#can-we-get-an-invoice-in-advance) 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 <> 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.](https://harihareswara.net/posts/2021/sidestepping-the-pr-bottleneck-four-non-dev-ways-to-support-your-upstreams/) And if they wish they could make the case for sponsorship to their managers, [suggest these resources](https://docs.opencollective.com/help/financial-contributors/organizations/sustainer-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. # Companies and Trust Your open source project is starting to gain momentum and it's time to start seeking sponsorships. Here's how to get started. *Part 1 of 3, shared with permission based on* [*Making your open source project sponsor-ready, Part 1: Companies and trust*](https://humanwhocodes.com/blog/2021/12/making-open-source-project-sponsor-ready-companies-trust/) *by Nicholas C. Zakas. Published under* [*CC BY-NC-SA 4.0*](https://creativecommons.org/licenses/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](https://humanwhocodes.com/blog/2021/05/talk-to-your-company-sponsoring-open-source/) 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. # Project Hygiene Attracting sponsors isn't always about reaching directly. Sometimes it's about doing the little things right that make your project successful. *Part 2 of 3, shared with permission based on* [*Making your open source project sponsor-ready, Part 2: Project hygiene*](https://humanwhocodes.com/blog/2021/12/making-open-source-project-sponsor-ready-project-hygiene/) *by Nicholas C. Zakas. Published under* [*CC BY-NC-SA 4.0*](https://creativecommons.org/licenses/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](https://opensource.org/licenses/) 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](https://jshint.com/relicensing-2020/) (which inherited the infamous “no evil” license from JSLint) and [React](https://engineering.fb.com/2017/09/22/web/relicensing-react-jest-flow-and-immutable-js/). 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](https://arstechnica.com/gadgets/2018/09/linus-torvalds-apologizes-for-years-of-being-a-jerk-takes-time-off-to-learn-empathy/). 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. # Accepting Sponsorships When your project is ready to accept sponsorships from companies, there are several things you can do to improve your chances. This post describes how to prepare your project to ensure sponsorships ca *Part 3 of 3, shared with permission based on* [*Making your open source project sponsor-ready, Part 3: Accepting sponsorships*](https://humanwhocodes.com/blog/2021/12/making-open-source-project-sponsor-ready-accepting-sponsorships/) *by Nicholas C. Zakas. Published under* [*CC BY-NC-SA 4.0*](https://creativecommons.org/licenses/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](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository) 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. # Accepting Event Funds This guide describes how to accept funding when your organization participates in sponsored events such as 'Google Summer of Code' or 'Season of Docs'. 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 ''. ## Google Summer of Code {% hint style="info" %} This page is outdated, contact or visit {% endhint %} If you plan on participating in [Google Summer of Code](https://summerofcode.withgoogle.com), 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 -- * 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? -- * 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](https://opencollective.com/contact) to let us know you will be participating and we will track the payment associated with your organization. # Crowdfunding *This is a summarized version of* [*Ten Steps to Successful Open Source Crowdfunding*](https://blog.opencollective.com/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. # Handling Burnout and Career Planning *This is a guide based on two Open Source Collective workshops led by Sumana Harihareswara of* [*Changeset Consulting*](https://changeset.nyc) *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](https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird) * 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](https://harihareswara.net/posts/2021/what-would-open-source-look-like-if-it-were-healthy-video-transcript/#healthy-oss-legacy-ending) 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:
A figure showing the contributor funnel, with more users, fewer contributions, even fewer maintainers, and ultimately a large emerita base. Along the way, attrition lessens the pipeline, with the crux of the funnel being the maintainers.
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](https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/). 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](https://www.volunteeramnestyday.net/) 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](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories) 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"](http://amandinemlee.com/2018/10/28/A-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"](https://harihareswara.net/posts/2017/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*](https://www.burnoutbook.net/). (Also check their list of [ways to complete the stress response cycle](https://ideas.ted.com/emotionally-exhausted-burnout-completing-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](https://en.wikipedia.org/wiki/Self-determination_theory#Basic_psychological_needs) 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](https://changeset.nyc/resources/career-advice-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](https://recurse.com) or talk to a venture capitalist. # Promoting maintainers and handling conflict Ensuring that the project can survive its contributors 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](https://opencollective.slack.com) 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](https://strategy.wikimedia.org/wiki/Product_Whitepaper#Great_Movement_Projects:_Rich-text_editing_interface,_and_the_-1_to_100_edit_experience) 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](https://github.com/zulip/zulipbot) to \[create teams and improve the specificity of notifications]\((). Or: [carsonbot is an issue bot for the Symfony project that helps automate different issue and pull request workflows.](https://github.com/symfony-tools/carsonbot) 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](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)). 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](https://nm.debian.org/), which is basically [a Trello board to track the progress of applicants and see whom to ping/remind](https://nm.debian.org/process/). #### 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](https://changeset.nyc/resources/career-advice-open-source-interns/) 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](https://harihareswara.net/posts/2014/the-continuing-adventures-transitioning-from-intern-to-volunteer/). *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. # Growing from a one person project to a Collective What to do if you want to be eligible for OSC hosting 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](https://www.contributor-covenant.org/) 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](https://allcontributors.org/) 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!