Open-source development has been seen as the last bastion of meritocracy. The feeling goes that for a software project, the only principle which should matter is the technical details of the code. All developers strive to simple, faster, cleaner technical solutions and can agree alignment on these simple self-evident facts.
Anyone who has spent significant time in these communities knows that the truth is more complicated. Governance, conflict, power, and trust shape the day-to-day life of an open source developer as much as writing code and fixing bugs. How can it be that reasonable, technically skilled people spend so much time arguing over seemingly trivial details? There must be more to these disputes than the specifics of the code.
This project begins from the observation that "open source is human work".
In order to best participate in open source development, and to manage your own and other's contributions to projects, understanding the social dynamics at play is critical.
What are some of the important principles?
-
Agency and Boundaries. A healthy project sets clear expectations of volunteers, and volunteers choose to participate at a level they are comfortable with. Consent and choice sustain participation over a long period.
-
Conflict happens, the important thing is how it's dealt with. A community should strive to recognise directly when there is conflict, and deal directly with the issue rather than letting resentment simmer.
-
Each person has their own truth, shaped by their past history, values and expectations. This insight allows us to reframe frustrations around "incorrect" technical thinking to a difference in lived experiences. Recognising that there are many different truths allows a project to cultivate a broad consensus where many people feel welcome.
-
Technical Disputes Are Social Disputes. Forks, debates about meritocracy, and arguments about "clean code" are rarely only about code. They reflect values, identities, and relationships. Naming the social layer helps communities navigate these disputes more honestly.
-
Governance is never neutral. Informal inner circles or decisions detached from those doing the work can disenfranchise contributors. Principles, transparency and alignment allow decentralised decision making whilst still fostering belonging amongst developers.
-
Trust is the foundation. Without trust, no amount of technical excellence will hold a project together. Trust requires visibility, accountability, and repair when harm occurs.
It's from this starting point that we begin to write code and contribute to an open source project. If we understand these principles, then making technical contributions becomes significantly easier and less confusing, since it will be possible to identify and name the many non-technical aspects of working in public.
These topics focus on the principle that an individual has the agency to decide themselves about at what level they are comfortable participating in. A community should advertise openly what level of obligation is expected of a volunteer and a volunteer should determine themselves if it is an obligation that they are able to undertake.
Open source often rewards those who say “yes” — to issues, to pull requests, to community needs. Yet the health of a project depends just as much on contributors who set limits. Saying “no” preserves energy, clarifies priorities, and protects against burnout. Boundaries are not refusals to participate but signals of sustainability: they keep individuals whole and allow communities to distribute responsibility more fairly.
Volunteering is a choice, but open source can blur the line between choice and obligation. When a hobby project suddenly serves millions, maintainers can feel trapped by expectations. A trauma-informed view reminds us that agency — the ability to decide how and when to participate — is foundational. Communities that respect consent foster resilience, while those that pressure volunteers risk eroding trust.
Many projects orbit around a single “hero maintainer” who does everything: coding, triaging, mentoring, releasing. This structure is fragile and often unhealthy. Building sustainable projects means distributing responsibility, creating pathways for new contributors, and resisting the mythology of the lone savior. Communities that normalize collective stewardship avoid both burnout and bottlenecks.
These topics discuss the conflict and disagreement as inevitable when collaborating. Conflict should be accepted, and dealt with openly in a manner which allows the project and individuals to move forward.
Disagreement is inevitable when passionate people collaborate. The real test of a community is not whether it avoids conflict but how it navigates it. Disagreement can generate new insights and innovative solutions if handled with respect and openness. Rather than fractures, healthy conflict becomes the forge where shared principles and better designs are hammered out.
In moments of tension, the easiest response is withdrawal. Yet communities that stay present with difficult conversations are the ones that grow stronger. “Staying in the room” means listening to perspectives we dislike, resisting the urge to retaliate, and tolerating discomfort long enough to find common ground. This is the art of community resilience.
Consensus is a noble goal, but it can also paralyze. Sometimes communities face decisions where agreement is impossible. The challenge is to create decision-making processes that feel legitimate even when some disagree: transparent, predictable, and fair. By focusing on process rather than unanimity, communities can move forward without alienating dissenters.
Every conflict carries information about what a community values, fears, or neglects. Instead of treating friction as failure, projects can use it as a diagnostic tool. Disagreement often signals resource bottlenecks, unclear priorities, or deeper social tensions. Listening to what conflict reveals transforms it from a threat into a guide for healthier governance.
Technical flamewars can leave scorched earth behind them — hurt feelings, broken trust, or even forks. Yet few communities practice repair once the dust settles. Repair means more than resolution: it is about acknowledging harm, rebuilding relationships, and restoring a sense of belonging. Without it, conflicts repeat. With it, communities can emerge stronger.
These topics focus on how the concept of truth is relative to the experience and context of an individual. Understanding that different things appear to be true to other people can lead to a more collaborative and productive working environment.
What seems obvious to one contributor may be opaque to another. Truth in open source is filtered through experience, expertise, and context. Recognizing this plurality of perspectives doesn’t mean abandoning evidence — it means acknowledging that facts are always interpreted. Communities that accept multiple viewpoints can avoid mistaking narrow consensus for universal truth.
In software as in life, certainty is often an illusion. Epistemic humility — the practice of acknowledging the limits of one’s knowledge — is an antidote to arrogance and unnecessary conflict. By assuming that we might be wrong, we open the door to learning, collaboration, and error correction. Humility turns fallibility into strength.
Open source communities don’t just exchange code; they exchange stories. Narratives about who “really” fixed a bug, why a fork happened, or how a project “almost died” shape the community’s sense of truth as much as commit histories do. Recognizing the power of stories helps communities reflect on whose voices are amplified, whose are erased, and how truth gets constructed over time.
Contributors rarely persist in communities that don’t affirm their identity and presence. Belonging is the glue that holds projects together, often more than technical alignment. Understanding why people stay — recognition, shared purpose, or simple human connection — sheds light on how to nurture durable communities in the long run.
When contributors debate endlessly about “technical debt,” “quality,” or “process,” the underlying issue is often social: who feels heard, whose time is respected, who has authority. By calling the social dimension what it is, communities prevent technical debates from becoming proxy wars over belonging and power.
4. Power, Governance, and Hidden Labor
In a decentralised community there are still leaders and people who make decisions. How those leaders are chosen, how decisions are recorded and who is included in the decision making process affect how much a part of the community contributors feel.
Every community risks forming an inner circle: an informal group whose influence outweighs its accountability. While leadership is necessary, personality-driven authority can stifle new voices and erode trust. Clear principles, applied consistently, prevent the slide into favoritism. When principles govern, communities become more inclusive, resilient, and just.
Trust grows when decisions are not only made fairly but also seen to be made fairly. Hidden channels and opaque choices fuel suspicion and resentment. By documenting decisions, opening up discussions, and explaining rationales, communities make governance visible. Transparency is not bureaucracy; it is the oxygen that keeps trust alive.
Rules without kindness are brittle; kindness without rules is arbitrary. Sustainable communities need both: structures that make expectations clear, and cultures that apply those structures with compassion. The best governance frameworks blend clarity and empathy, creating spaces where contributors know what to expect and feel welcomed as human beings.
Code may run the servers, but it is care work that sustains the people. Mentoring newcomers, mediating disputes, writing documentation, and offering encouragement are often invisible forms of labor. Yet these contributions are as critical as technical ones. Recognizing care work as infrastructure shifts our understanding of what really holds communities together.
A long-standing open source principle is that authority flows from contribution. When decisions drift away from the people writing and maintaining the code, communities risk disenfranchisement. External committees, foundations, or corporate boards may have resources, but if they override the voices of those doing the work, the result is resentment, loss of agency, and sometimes forks. This piece could unpack why legitimacy in OSS depends on aligning decision-making with labor.
When a contributor resists review comments on their pull request, what should be ordinary project maintenance can be perceived as exclusion. This often reinforces a self-fulfilling “outsider” identity, where refusal to adapt confirms the boundary between contributor and maintainer. The result is stalled contributions and hardened divisions. This article sketches how to break that loop: maintainers grounding feedback in shared project goals, contributors reframing review as inclusion rather than rejection, and communities clarifying standards to make the path from outsider to peer visible.
Disputes about forks, burnout, meritocracy, or clean code are rarely just technical. They reflect values, power, and belonging. Seeing these choices as social as well as technical helps communities respond with empathy and make more sustainable decisions.
Forking is often framed as a technical event — a divergence in code. In reality, forks usually signal unresolved social fractures: disagreements about governance, values, or recognition. By examining forks as social schisms, communities can better understand how conflict escalates and how it might be avoided in the future.
Dependencies are often counted in code, but the real dependencies are human. A single maintainer’s exhaustion can cascade into widespread technical risk, as seen in high-profile incidents. Recognizing that burnout is not just personal but infrastructural reframes support for maintainers as risk management for the entire ecosystem.
Arguments about who is “skilled enough” to contribute often present themselves as neutral technical judgments. In practice, they mask social boundaries about who belongs and who doesn’t. The myth of meritocracy obscures power, privilege, and access. Naming these dynamics is the first step toward genuinely inclusive contribution.
One developer’s "technical debt" may be another’s "pragmatic compromise." Disagreements about clean code often reflect differences in values, resources, or lived context rather than absolute standards. By reframing these disputes as value-based rather than technical-only, communities can approach them with empathy and negotiation instead of dismissal.
Trust is the foundation of collaboration. Many "technical disagreements" mask deeper questions of fairness and accountability. Repairing trust through acknowledgment and action prevents cycles of conflict and keeps projects resilient.
An apology alone rarely restores trust; neither does technical excellence. Repair requires a sequence: acknowledgment of harm, accountability for what went wrong, and concrete action to prevent recurrence. Communities that skip any of these steps risk repeating the same cycle of conflict and disappointment.
Many flamewars and forks begin as disputes over code style, architecture, or release cadence. But underneath the technical surface is often a deeper concern: “Do I trust you to hear me? Do I trust the process to be fair?” Naming the trust issue prevents communities from endlessly patching the wrong bug.