Section

open-source

Kind

Editorial

Reading time

5 min

Updated

8 September 2026

Governance in Small Projects: Deciding Before You Have to

A project starts small and with great enthusiasm. Maybe it is built by one or a few members. GitHub issues, community discussions, and code reviews are how decisions are made. Then at some point, something happens:

Somebody talks about the project in media or at an event and starts getting asked for an official position. A newcomer pushes code including a flagrant violation of the code of conduct or contributor covenant. Months of work on an important feature merge sits idle. A vulnerability appears in an older codepath that nobody’s covered for a year. A major corporation buys the technology or a tiny start-up comes with free sponsorship and wants to talk with the project about their top-priority feature.

All those could be good news for a community project. All could become something bad for the project’s prevailing communication habits. And all bring an implicit question: who’s in charge here?

“Who Decides Anything?”

Projects don’t need a long governance document but they do need an answer to that question. Projects that outgrow consensus get a bad reputation in the open source community.

If the project's maintainers get stuck, what happens? What if users try to pay for priority access or a company wants named credit next to your organization in a presentation? What’s acceptable to discuss on Telegram or in community calls, and who gets to speak for the project in print and on platforms like Reddit?

The OpenSSL Library Bylaws are an example of clear, minimalist, and specific governance designed for a specific problem set, describing the “who makes which decision” in dry but unambiguous command: the OpenSSL Project Foundation and Corporation handle strategic direction and management, the Maintainers approve new Maintainers, and the Steering Committee or Project Lead decide on disputes.

Fairlearn's governance documents are briefer, defining consensus explicitly. But like the OpenSSL approach, they replace implicit assumption with guidelines, saying that explicit agreement of Maintainers is required, and that Maintainers document evidence of consensus.

NS-3 divides authority into the software and the project’s administrative and financial matters, with the Lead Maintainer having final authority. Changes to the document that define authority are requested via pull or merge requests.

Merge Rights and Deadlock

Merge permissions matter, but they are not the same as authority to decide the project's strategic and operational direction. Founded-led projects can still get to a place where leadership by a single founder, or by a small and trusted group of engineers, is not enough to guide the technical or operational decisions.

Who fills in for wind-down and project transitions? What if the founder or project lead is unavailable? What if two maintainers or maintainer groups have deep disagreements such as over design decisions, threats or countermeasures, or fallback response during a security emergency?

Releases, Committers, and Objections

Releases get more complicated when more stakeholders and audiences depend on them. Reputational and compliance issues about releases grow when corporations use third-party software and have to answer legal questions about it.

Release schedules aren’t something to figure out in a Tuesday chat with no agenda told casually to people who can’t replicate it. Release issues, time-range, and components get decided ahead of time and published. Release audit and release staging fall to a named lead or team. Committers, their nomination and review, get their decision owners.

Objections and merge blocking need clear validity criteria, clear escalation paths, decision scheduling, and rule of law added to it. Blocking contributions out of spite, or disagreements without specific counts or facts, get review and mediation by someone who knows all the counterparts of the issue.

Projects - especially pragmatic or goal-driven implementors like OpenSSL - have their ground rules about their logging, their release notes, direct attributions to sponsors or users, and their standards for code reviews. Part of the right to maintain the project includes the responsibility to steward and operate some of those documents.

Security Contact and Response

Security response has to outpace the development cycles and still get access. How publicly or privately can the project’s security issues and response be reported and escalated, who has the legal authority and enough knowledge to respond, how is the project billed for wide-scale remediation, and how is all that logged and reported with the project’s reputation?

Projects that do not have a regular security response or even an explicit policy about data delete requests either have to ad-hoc each one or have a ready and accountable security response.

Money and the Neutral Home

Projects can accept money and even fundraise, but even more than government projects, payees have fiduciary responsibilities. Having a neutral home for the project, such as a pure-play foundation rather than a tech company, can separate project control from fiscal and legal control, help recruit contributors who like the cause but do not want to sign up with any one company, and help get funding, even to the extent of allowing them to accept third-party audit requests, investigative inquiries, or notes of advice on global compliance.

What Usually Breaks When the Project Grows

It’s not only grandparents, civil rulings, and movie sequels that say size is a differentiator, but even small projects can feel the pressure when they are used in more diverse domains, by more teams or major corporations, or something else has made them harder to sustain as a small or volunteer-based project.

The illusion that a single founder can set up a two-person project and that it will sort out its disputes naturally as it scales is a plan for:

1. disputes over financial and reputational issues
2. policy, attribution, or compliance disputes
3. issues about someone with limited context joining the code review community and not being heard
4. rotated decision-making for the project’s big and for the much more common incremental releases and release rotations
5. more frequent and more severe incident response that needs personable local leadership with enough status to handle stakeholders

“The default is bills pass and disputes stand. We have bills to pass, a proposal for a domain sorter on switch types, and disputes between two models leading to conflict.”