In the open source industry, creating an American nonprofit to serve and fund a project is not uncommon. These structures can choose a fiscal status depending on their needs within a wide range defined by the IRS. The 501(c)(3) status is widespread in the industry. These structures must follow specific legal and tax requirements, which means that sometimes, their interests can seem misaligned with the project they originate from.
In this post, I will take my perspective as a former GNOME Foundation board member to explain why some foundations can feel disconnected from their projects and how to solve the problem. I will cover some of the constraints of the 501(c)(3) status and how the GNOME Foundation can make it an advantage, what the various stakeholders expect, and how the Foundation can deliver its full potential. This is a case study and doesn’t necessarily apply to all nonprofits.
Open source is weird
Open source is a very particular method of software development. Since there is no incentive for customers to buy open source software, most stakeholders make a living by selling expertise around the project they maintain or contribute to. Several competitors can collaborate on advancing the project and ensure it stays relevant and attractive for their customers.
When the project’s contributing community grows, it needs a neutral custodian to take care of the governance, trademark, infrastructure, and other support services around the project. That neutral custodian is usually a nonprofit, to prevent commercial incentives from turning it into an additional competitor with unfair advantage.
Several legal forms exist to fulfil that purpose, including the 501(c)(3) and 501(c)(6). Both can get exempted from federal income tax, but the 501(c)(6) status allows nonprofits to conduct a wider range of activities than the 501(c)(3).
While the 501(c)(3) status has stronger compliance requirements, it has two major benefits:
- Nonprofits under this status are also exempt of state and local taxes.
- Donations to a 501(c)(3) are tax-deductible, making it more attractive to donors. Some grant-making organisations will even require the 501(c)(3) status for grantees.
The GNOME Foundation is a 501(c)(3). Let’s cover some of the constraints that come with this status to shed some light on its activities.
Tax deductibility doesn’t come for free
First, the organisation must have a charitable purpose, defined in the IRS Publication 557 as one of Religious, Scientific, Testing for public safety, Literary, Educational, Fostering of national or international amateur sports, Prevention of cruelty to animals and children or, finally, Charitable. The latter is a broad definition for which the organisation “must show that it is organised and operated for purposes that are beneficial to the public interest.”
In the Form 990 for the year 2022, the GNOME Foundation reported its activities as a charitable organisation and described its purpose as
Building a diverse and sustainable free software personal computing ecosystem.
Nonprofits with the 501(c)(3) status are also limited in their activities. More particularly, according to the Compliance Guide for 501(c)(3) for Public Charities:
- A public charity is prohibited from allowing more than an insubstantial accrual of private benefit to individuals or organizations.
- Public charities are prohibited from […] participating in […] any political campaign on behalf of […] any candidate for elective public office.
- A public charity is not permitted to engage in substantial legislative activities.
This is just an overview of the major compliance areas. There are other subtleties, such as excess benefit transactions. In particular, according to the same compliance guide:
No part of an organisation’s net earnings may inure to the benefit of […] a person who has a personal or private interest in the activities of the organisation, such as an officer, director or a key employee. […] Any amount of inurement may be grounds for loss of tax-exempt status.
In short, hiring board members can put a 501(c)(3) at risk of losing its status, must be declared to the IRS, and is often off-putting for grant-making organisations. Where these transactions are made, additional processes must be put in place and records kept to show that the transactions are priced at a fair market value, and no excess benefit is flowing to an insider.
Compliance and making sense
In service of following these constraints, nonprofits can come up with generic plans that tick the boxes of the IRS but don’t seem to connect with the projects they serve. In the case of the GNOME Foundation the Five-Year Strategic Plan can look very abstract, as if the Foundation was more interested in its 501(c)(3) status than in contributing technically to GNOME. This is a false dichotomy: the Foundation must be all about promoting GNOME as a charitable project worth investing in and setting up programmes that advance GNOME and its purpose. This allows donors to know what they’re funding, what problem they’re contributing to solve, and it allows them to hold someone accountable. It also allows the Foundation to support the community financially in working on GNOME, as the solution to higher level problems.
Of course, this can only work if the community and Foundation work together to elaborate those programmes and if they both benefit from them. The Five-Year Strategic Plan is a good draft to open the conversation with the community. This plan is a high-level narrative to explain our purpose as a project and community to those who are less hands-on than us. This is the value proposition of our community and project for donors. To earn grants, we must articulate what problem GNOME solves and who it solves it for. We must involve those people in the process, and show results. We’re part of something bigger than building software for people with the time and knowledge to install it.
As a community, we must express our perspectives on what activities make sense, what needs to happen, and what needs to be funded to achieve our goals. The Foundation has a crucial role in facilitating these discussions and meeting the contributors where they are. Our Discourse provides the ideal space for these open discussions, fostering transparency and inclusivity within the community.
The community and Foundation must act as one for the greater benefit of GNOME
The Foundation must be about promoting the project and giving it a tangible, accountable face. The community must contribute to writing the story of the project, giving a meaning to its own activities. The Foundation is responsible for making the conversations happen in the open.
When two worlds collide
There are three major stakeholders around a tech nonprofit: the contributing community, the grant-making organisations, and a specific set of people that the two former want to help. They have different expectations, and the role of the foundation is to bridge the gap between them.
Contributors want support
GNOME’s contributing community is largely made up of volunteers. They donate their time to contribute to the project. For an organisation, a volunteer donating their time is much more valuable than someone donating money.
In my experience, an hour of work usually costs at least €50 for a nonprofit. For a person doing 5 hours of average volunteer time per week, that’s the equivalent of €13K donated yearly!
While volunteer time is invaluable, specific tasks require professional expertise or a paid commitment. These include sensitive data management or infrastructure tasks, tasks demanding a significant or consistent time commitment such as event or project management, or carrying a legal liability. In such cases, the Foundation must hire staff or contractors. The community, in turn, relies on the Foundation’s staff to support their contributions.
The contributing community also expects the Foundation to transparently publish job descriptions when it hires people so that members who are familiar with the context and have relevant skills can apply, be rewarded for the time they invested in the project, and increase their contributions by spending paid time on it.
Finally there is another type of contributor. Organisations can have an interest in contributing to a technical project too. They can reuse the product in their own offering, or they monetise the expertise they gained by contributing to the project. Open source changes radically the relationship between organisational contributors and the project they support.
In other fields, corporations donate time and resources to a foundation that distributes those resources as it sees fit. In open source, corporations usually contribute technically to or even maintain components directly with little oversight from the nonprofit.
Putting their paid contributors in direct contact with time—and resource-constrained volunteers gives those organisational contributors a lot of leverage to steer the project in a direction that works best for them.
The solution to this lies in a balanced governance: the nonprofit in charge of the project must formalise processes around it to give it enough structure and prevent the project from being derailed, but it must also preserve enough flexibility for organisations to find a financial interest in the project, and for volunteers to spend time on what they enjoy rather than administrative trivia.
Grant-making organisations want a social impact
Except for the Sovereign Tech Fund and NGI Zero who are already familiar with the issues of underfunded software infrastructure, grant-making organisations are usually primarily interested in addressing social problems.
They rely on programme officers, programme managers, or grant managers to distribute grants to organisations that can partner with them in their mission. Those programme officers monitor whether the grant winners deliver on their promises. Some grant officers might be interested in the technical details of a solution, but their primary focus will always be ensuring that the organisations they support address the social and human problems they focus on.
It’s not about wrapping up the project in an inspiring narrative; this often requires fieldwork with rigorous methodology: the programme needs to focus on a specific set of people we want to help, meet them and understand their problems, involve them in the solution development, and implement the solution, and iterate. Most of the time, grants aren’t final but serve a larger goal.
This exercise is notoriously difficult for very technical projects since they tend to attract primarily engineers who enjoy focusing on their technical aspects and don’t have the tools or infrastructure to involve a well-defined set of final users. This is also a cause of frustration for maintainers who see their issue trackers derailed by many different audiences with conflicting interests.
Far from being a marketing exercise, developing goals in coordination with our primary audiences is a much-needed opportunity for self-reflection. If we create a product we like that never ends up in people’s hands, who are we working for beyond ourselves? How can we fix that? How do we know we’re making the world a better place and not just creating software for people with free time and a spare laptop?
The board and the ED must connect the two
The Executive Director is the interface between the project’s community, its board, the grant-making organisations, and the people the project serves. An effective Executive Director is a good strategist, an excellent communicator, and someone who involves and empowers the stakeholders rather than trying to control everything.
The major challenge is to connect two completely different worlds: the very hands-on, technical and often volunteer community with the grant-making organisations that need to see the social impact of their grants.
Individual contributors who spend their free time volunteering for a project can sometimes develop resentment toward nonprofits spending resources on cultivating a field of application for the project instead of supporting the volunteers financially. They can feel like the nonprofit is freeloading on their time.
In practice, healthy nonprofits complement and support volunteers’ work, including financially. Building a compelling case for the project is a non-engineering, long and critical step to make it appealing to donors and eventually hire contributors willing to do paid work on the project.
In the specific case of GNOME, the Foundation must operationalise those four internal pillars to increase its technical contributions to the project:
- Strategists build a case for GNOME as a solution to specific problems, serving specific users, and develop tools to measure its impact. This includes the executive director as the primary coordinator, grant writers to shed some light on the fundraising opportunities, and the board to steer and validate the strategy. This strategy must be developed in collaboration with the people we are serving.
- Solution Architects translate the needs assessed in the first step into an actual implementation strategy. In more business terms, the Foundation must rely on Solution Architects to come up with a sound budget that factors in the designers’ and developers’ time to implement the solution. To operate sustainably, the Foundation must, of course, add a markup to amortise all the preliminary work to get there.
- Developers & Designers are the implementation arm of the Foundation that deliver the solution drafted previously. As much as possible, those people must come from the contributing community when they have relevant experience and availability.
- Communications & Narrative builders give visibility to the actions taken and impact the programs had. Prospective donors and grant makers need to know that the Foundation can be trusted to deliver and see out impact in the world. Volunteers need to see how the work they’ve done has come together and generated funding, impact and investment into GNOME, that ultimately they can benefit from.
Of course, those 4 categories must have a certain level of porosity to nurture each other.
An efficient nonprofit connects its community and grant-making organisations to solve real-life problems
To sustainably support its core project, a nonprofit must act as a bridge between all its stakeholders. This requires extensive communication, and is a time-intensive task that must be seen as an investment.
Failure modes
In a mature nonprofit, the board doesn’t intervene in the organisation’s day-to-day operations. The directors oversee the operations at a high level by helping the Executive Director find how the project can solve social issues. The Executive Director, in turn, formulates an implementation strategy and budget, seeks the board’s approval, and then executes the strategy.
A regular failure mode for nonprofits is when the board is too involved in day-to-day operations. To prevent this from happening, there are two major actions a Foundation can set up:
- Set clear expectations for the board before the elections. Joining a board of directors is a lot of work, including administrative work, that many community members are not familiar with. By setting clear expectations for prospective board members, nonprofits can build stronger boards with a wider range of skills to support the ED in its mission.
- The board and ED must define metrics to measure success, and agree on a specific timeframe to review them (e.g. every quarter, or every year). This lets the ED set up programs and manage staff without having to seek approval for every step. This also keeps the board informed of what is happening, and allows it to support the ED in its mission when needed.
Effective communication is a cornerstone of the Executive Director’s role. While total and absolute transparency about every single penny leads to ineffective bikeshedding, detailed board updates and high-level community updates are mandatory to build internal trust. This trust comes naturally within the community when the staff works with the rest of the contributors. Proper communication with the outside world and grant-making organisations is also crucial to show the project’s positive impact on the world.
Open source nonprofits are weird because they (must) go beyond tech
We have seen that open source nonprofit organisations operate with a precise set of constraints. Those constraints are what opens them to significantly larger donations and grant funding opportunities.
Their mission rarely concerns engineering, but they should rely on engineering to achieve their objectives. Their core goal is to promote and fund the project they originate from, but there are several, sometimes long, preliminary steps to get there.
Healthy tech nonprofits keep all their stakeholders informed about their activities to build trust and confidence and grow their original project to solve real-life problems.
A massive thank you to Al Smith, Director of Fundraising of the Tor Project, who demystified the world of fundraising for me, and to Richard Littauer, Interim ED at the GNOME Foundation, for sharing his nonprofit experience.
