Investing in Open Source: The FOSS Contributor Fund

Chapter 1. Project Eligibility

The first component is project eligibility, that is, defining which projects are eligible for your FOSS Fund program. Your organization most likely relies on hundreds or even thousands of pieces of free and open source software. As much as we would like to define all projects as eligible, we have found pitfalls with that idea. The following criteria, considerations, and lessons learned will help you reduce confusion about which projects are eligible for funding.

Project Usage

The broadest possible criterion is “any project the organization uses.” If you needed tighter constraints, you could limit eligibility to projects that you use in a business unit or in a product.

Project License List

Which list of free and open source licenses are you working from? Rather than make your own list of licenses, there are several existing lists that are actively curated and well maintained. Two examples are the OSI Approved License List and the curated list of licenses, which follow the Debian Free Software Guidelines. Don’t write one yourself, though! There are hundreds of open source and free software licenses, each with its own nuances. Curating a list yourself is no small task, and well-maintained lists are already available.

Lesson Learned: Don’t Keep a Rigid Project List

Your list of eligible projects you use to determine nominations and eventual funding should align with your goals. If this list isn’t flexible, you can easily become beholden to process over principle.

For example, someone might nominate a project that fits into the goals of your FOSS Fund but doesn’t appear on your canonical list. This could include an important open data project, a project focused on content that is licensed Creative Commons, or a project with an unusual license. If so, find a way to say yes. You may need to create a transparent process for how you’ll handle these types of nominations. Remember that you still have a voting process to go through, which will help you make good decisions.

Project Funding

At a minimum, require that projects have a publicly posted method of receiving financial support. You may decide to be constrained to projects run by nonprofit foundations. Any significant procurement restrictions will necessitate tighter controls.

Lesson Learned: Don’t Fund Projects That Haven’t Requested Funding

Not all projects want to raise or accept money. The maintainers may be well funded already or decide not to accept funds on principle. The project might not be large enough for fundraising or lack a governance structure mature enough to handle the funding responsibly. Whatever the reason, if the project doesn’t want to receive funds, you need to filter it out before the vote.

You may be tempted to reach out and work with the project to set up a way to receive funds. This approach can be problematic. If you reach out to the project maintainers before the vote, you may be asking them for work or attention that doesn’t yield any positive result for them. Further, you can have an unexpected effect if they haven’t yet worked through the logistics of how to receive and distribute funds: adding money to an open source project will change things, and those changes should be intentional. It’s not always easy to decide how to spend funds or which contributors should be paid, and you can unintentionally lead projects into muddy waters by showing up with the best of intentions and offering money.

Lesson Learned: Don’t Fund Projects That Have Strong Corporate Backing

If a project receives a substantial amount of funding from corporations, you may want to remove it from consideration. Some large open source projects are funded by groups of companies or trade associations; others might be wholly owned by one company. These projects have strong name recognition, multimillion-dollar budgets, and significant support.

While there isn’t anything wrong with directing donations to these projects, sometimes the only way to give such projects money is to pay for consulting or services. Doing so may be a good idea, but it will require more time, effort, and paperwork—and some companies don’t allow it at all. You can make a more significant impact with your one-time donation by finding projects that are underfunded or lack strong corporate backers.

Project Ownership

Employee-owned projects are good candidates for exclusion. You may also want to set some constraints around single-vendor open source projects. You should think about how you feel about projects owned by large trade organizations.

Lesson Learned: Avoid Employee-Owned Projects

Consider legal constraints at the company level to fund projects owned by an employee. These constraints are inherently difficult to navigate and add complexity to the FOSS Fund. There can be bias in voting with an employee-owned project, because the voters may know or recognize the employee. You will also want to consider the optics: if you’re running a fund designed to financially contribute to open source, and it appears to be returning that money to the company by funding an employee, how will that look? For these reasons, we encourage you to remove employee-owned projects from eligibility.

Recent Awards

Projects with strong name recognition are more likely to receive more votes, so it’s a good idea to limit the number of times a given project can receive an award or how often a project is eligible. You may want to exclude any project that receives funding from elsewhere in the organization or apply a “cool-down” period before the project can receive a subsequent award.

Project Reputation

If you work in an organization that is strongly driven by values, you could find yourself in an awkward position if a project is nominated that is inconsistent with the values of your organization. This could show up in the project’s culture (“historically toxic”), leadership (“racist maintainer”), or reputation (“popular with trolls”). You can head off this situation by making it clear that projects must be consistent with your organization’s values to be eligible. If you take this approach, you may need to give examples of projects that would not be eligible or actions that would disqualify a project.

Indeed: Finding Flexibility in Project Criteria

Tight eligibility constraints do come at a cost. The more a participant has to read and understand before they can nominate a project, the less likely they are to participate. If they participate without understanding eligibility, they might ignore the constraints and nominate any project, which will complicate the processes in running your FOSS Fund. Keeping your eligibility criteria short will make the process easier for participants and easier to run.

To that end, we use project eligibility criteria that align with our funding principles and allow for flexibility. Initially, we started by accepting any project in use at Indeed—regardless of the context—as long as it was relevant to work. Then, we used the OSI-Approved License List as our canonical license list. We required that projects have some existing way to receive funds, such as an Open Collective or GitHub Sponsors or a PayPal link. Finally, we excluded all employee-owned projects as well as any project that had received a FOSS Fund award in the last 12 months.

Discovering Projects at Indeed

The primary mechanism for discovering eligible projects is the nomination process. For example, curl is one of the most widely used pieces of free and open source software in the world. The project was nominated for a FOSS Fund. As we looked at the nomination and checked the eligibility criteria, we were surprised to see that curl’s license was unique—almost but not precisely an MIT license. Because the license was not quite MIT, the license was not technically on the OSI-Approved License List. Though this should have meant that curl was disqualified, we determined that curl was eligible because the broad consensus viewed curl as free and open source software.

We also noticed that many organizations rely on OpenStreetMap for location-based services. It is licensed under an open data license, which would have made it technically ineligible for our FOSS Fund: the OSI-Approved License List only deals with software licenses, not data licenses. However, it was demonstrably in the spirit of the FOSS Fund, and the OpenStreetMap Foundation is an affiliate of the Open Source Initiative. We determined the project was eligible.

Aside from nominations, we also found other mechanisms to explore eligible projects.

Compliance tools

Most organizations have a tool in place for ensuring software security and license compliance. These tools typically generate inventory reports or a Software Bill of Materials that contain links back to the source for every free and open source library that you use. We looked at these reports as a starting place.

Dependency analysis tools

We also used online tools to take a project manifest (such as a package.lock-json or pom.xml) and analyze its dependencies, which gave us projects to add to our project funding list. Tools like Back Your Stack will show you which projects have a way to receive funds so you can ensure you’re not funding a project that doesn’t want funding.

GitHub sponsors

Like many organizations, Indeed has repositories on GitHub, which means the GitHub Sponsors program will automatically scan dependencies and display which projects are part of the GitHub Sponsors program. This does not give you a complete view, especially if your organization uses a different source control system internally, but GitHub-sponsored projects can easily go on your project list if they meet your criteria.

As you discover projects and assess them against your established criteria, allow for flexibility and growth. No one list will perfectly capture your funding goals, but staying close to those goals means your choices will be more meaningful, and that encourages more meaningful participation.