Recommendations

Understand that the path into FOSS is perceived as formative, and people often identify strongly with the path they themselves took; criticizing it can lead to developers taking the criticism personally. Instead of arguing for greater diversity, approach the issue by first helping the project work out which people, skills or perspectives the project needs to be successful – and where these could be found – and work from there.

Reach out to people who dropped out of a project in order to learn what factors contributed to them leaving.

The provision of free-to-access resources and examples of good practice about onboarding could help those who are willing to change the process, but do not know where or how to start.

Explicitly funding non-technical positions within tech projects can enhance their standing in the eyes of the FOSS community.

Our data on women is scarce, but there are indications that projects with community management and team leadership roles can help to keep women on board. Financially supporting these roles could help tackle the lack of diversity. However, especially for one-person-shops or collectives, this can mean the imposition of a governance structure on the project that the community is not willing to support.

Instead of attempting to bring more diversity into existing projects, supporting projects run by groups that are underrepresented in tech can help contributors hone their confidence, skills and reputation, and enhance their standing.

Establishing fellowships within existing projects exhibiting poor inclusivity can temporarily alleviate imbalances, but this unfairly puts the onus of reforming projects’ structure onto the fellows.

Providing examples of good practice for lightweight, result-oriented FOSS project structures can help communicate their benefits and make discussions about governance less dogmatic.

Facilitating dialogue between different actors in the field of open-source infrastructure (e.g. by supporting events that attract both communities and companies) can help both sides better understand their respective work culture and find ways to adapt.

Adopt an intersectional approach towards diversity that takes into account race, place of origin, gender, class and abilities.

Rather than encouraging diversity in existing projects, support projects run by groups that are underrepresented in tech as this can have a greater impact. Contributors benefit from honed confidence, skills and reputation, and can pave the way for incoming contributors from diverse backgrounds.

Bringing professional moderators to community events can help foster more constructive dialogue.

By choosing what kinds of work to support, funders send a message about what kinds of work are valuable. When working with projects in which essential management roles already exist, support them to the same degree as the developer positions. Refrain from focusing solely on developer positions. At the same time, avoid filling non-coding positions with people from underrepresented groups; this can reinforce the idea that coding is performed by higher-status people

Opening channels of communication and knowledge exchange with existing groups of experts who work on non-coding tasks (e.g. UX, security, finances) can make it easier for FOSS infrastructure projects to reach out to them. This can help foster respect for the people and the work, and lead to greater appreciation for these positions within the community.

Fiscal sponsors can be put in charge of financial administration; incorporate this into project overheads. Fiscal sponsors are mostly a North American phenomenon, uncommon in other parts of the world. Organizations on their way to becoming fiscal sponsors in their respective legal and tax system should be supported so as to make it easier for FOSS infrastructure projects outside the USA to comply with funders’ requirements.

By designating a specific contact person, funders can build stable relationships with their grantees.

If grantees do not make use of external offers of support, one reason might be the absence of a trusting relationship. Personal introductions and recommendations can help build this.

Explicitly support maintenance. Avoid focusing solely on innovation.

Support second and third implementations. This will help level the playing field and foster a healthy dialogue around standards.

Encourage knowledge exchange between people who work on standards, those who implement them, and those who provide services around how standards impact users.

In discussions about adoption, be consistent with the values of the ecosystem. Focus on scale rather than growth.

When using adoption as a metric of success, be sure to factor in the necessary support resources.

Try to avoid marketing terminology; e.g. use “identity” instead of “brand” or “outreach” istead of “market”.

To make discussions about results as “products” meaningful, frame them within the context of usability and usefulness instead of marketing.

Be aware of how your demands on grantees can unintentionally filter the projects you support (e.g. by supporting those with the requested structures rather than the projects that need your support most).

Be transparent about your demands on future grantees, both during the application process (paperwork, legal status, response time), and during the grant period (reporting, availability, communication).

Avoid a drawn-out application process. A two-tier process in which applicants get quick feedback on their chances for success can help. For each step, communicate clearly how far along in the process the applicants are, and what the next steps will be.

Be transparent about whether projects can only expect short-term support or more.

Work with your applicants to create a budget that avoids project “bloat” – especially with short-term funding.

Be aware that in some contexts, projects may not credit you because of the political implications of your funding. Trust them to make this choice in your and their best interest.