By Mara Averick in Developer Relations —

Do you WANT contributors?

If you maintain an open-source project, your contributing file is where you set the terms—of the relationship, of the boundaries, of what you will and won't do. Own your answer. Change it when it stops working.

A fox on a hillside thinks of four open-source project shapes: castle, clique, university, and hippie commune.

My open-source origin story goes something like this: I fixed a typo, tweeted some stuff, tripped, fell, and found myself in the inner circle of a large-scale OSS ecosystem with an active, supportive community! It's trite but true—neither universal nor unique. But "inner circle of a large-scale OSS ecosystem" is where I landed, and it's colored a lot of what I've written since—including an implicit assumption that you (person who is reading this) are trying to build an ecosystem-scale project too.

POSE (Pathways to Enable Open-Source Ecosystems) has it right there in the name. It expressly describes this shape as the first item in the list of activities it's meant to support:

Building and maintaining a distributed community of external contributors who will actively participate in the ongoing development of the open-source product.

However, this isn't the only (or even the most common) experience for open-source maintainers or projects. Most projects run on one to three active maintainers.[1] Solo isn't a failure mode; it's the default.

There's a wide spectrum of how folks define open source: from "it's just a license" to "radically open and participatory." For the rest of this post to land, I need you to accept the license-end as at least legitimate—not right, necessarily, just legitimate. There's no need to re-litigate the decades-long disagreement in order to say that you, as a maintainer, get to decide the bounds of participation in your project.

An open-source project's first few artifacts are click-through: license (checkbox), README (template), .gitignore (whatever your framework spits out). Then you hit CONTRIBUTING.md—the first artifact that actually asks you what you want. Sure, there are best practices and helpful guides for you to follow, but it's where your project starts having opinions instead of defaults. So it's worth pausing and really unpacking what you want yours to look like. It's more than the mechanics of filing issues and submitting pull requests: CONTRIBUTING.md is the foundational framework for the relationship between your project and the unnamed masses who may or may not encounter it.

In fairness, the bare-bones version of contributor guidelines may work just fine for you. Or you and your project may have a version that was working in the past, but no longer feels sufficient.

For years, I had a Venn diagram I used in talks to illustrate what I called the "FOSS happy place":

Two overlapping circles labeled "things that are selfish" and "things that are useful to other people," with an arrow pointing to the overlap labeled "FOSS happy place."

It wasn't a lie—it reflected my early experience as a contributor to open source (even if my contributions weren't code-shaped). It's still not "wrong," per se. But it is guilty of radical oversimplification—not quite discretizing a continuous variable, but definitely improper dimensionality reduction. Critical features, like time, remuneration, and changing conditions/priorities are nowhere to be seen.

I'm not the only one whose journey was typo fix → full-time job/way of life. Kent C. Dodds (among the best in the game of open-source developer experience, in my opinion) describes a similar origin story in How getting into Open Source has been awesome for me (2020). I mention him for two reasons, and neither is throwing him under the bus: one, it's not just me; two, it's not dev-rel delusion—because (unlike me) he's a lines-of-code, PR-reviews, engineer-shaped maintainer of a widely used open-source project (Testing Library).

A career in open source isn't always a heart-eyes-emoji experience. Evan Czaplicki gave a great (aptly named) talk at Strange Loop 2018: The Hard Parts of Open Source. The challenges he describes seem somewhat inherent to the craft: you can't please everyone, conflicts will arise, things that once motivated you will be deeply draining at times. Anyone who's struggled through a group project in school will recognize the shape. None of that friction is new—LLMs didn't create maintainer burnout. In a 2019 piece by Nadia Eghbal, "The rise of few-maintainer projects", she wrote:

The salient issue for maintainers today is less about growing contributor numbers and more about navigating the flow of developers who are clamoring for their time.

Sounds familiar, right? AI has ratcheted things up. Maintainers are seriously rethinking what their relationship to their projects and users looks like. And here's where I return to CONTRIBUTING.md because this is a place where you get to be explicit about the choices you're making. Even if nobody reads every word (and most people don't read CONTRIBUTING files at all), writing one is how you set your boundaries in the first place. A CONTRIBUTING.md that reads:

No thanks! I'm gonna go it alone.
But feel free to fork and do whatever you like!

may not be what you're used to seeing (in fairness, that sentiment is likely carried through the absence of a CONTRIBUTING file), but it's legitimate. Or, maybe you think it isn't. Maybe it's anathema to open source, BUT it is a move that someone could make.

Am I recommending it? No. But I'm not you. I'm not everyone. And, importantly, it forces you to acknowledge that you get to set your boundaries and expectations. Again, this is an oversimplification. If you're maintaining a mature project with a set governance pattern and change-management process, waking up and burning your contributing process to the ground is likely to have serious fallout. But, that doesn't mean that you can't experiment (especially if the status quo feels like you're headed off a cliff.)

Certain projects have, by design, made the bar for contribution high for legitimate reasons. Debian's already the perfect example of a working gatekeeping mechanism that's high-demand. You need a sponsor, you find a mentor, you meet in person with someone who can vouch for you—as Nadia Eghbal put it, "Debian's process is built on the need for trust."[2]

But Debian is one shape among several. Athan Reines pitched a taxonomy for this: not "how open is your project" on a slider, but "what shape of project are you actually running?" He described four archetypes: the walled castle, the clique, the university, and the hippie commune.

The walled castle (or black box). You get the code, but the drawbridge stays up. SQLite is the cleanest live example. Their copyright page has a section literally titled "Open-Source, not Open-Contribution," which says:

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution...the project does not accept patches from random people on the internet.

You can't misread that. It's on their homepage. This archetype fits when the maintainer has a firm boundary they don't want to soften—a totally legitimate choice. It also fits when there's an author who's just done. The question: Do you want contributors? The answer: No.

The clique. You need to know the right people to get the secret password. OpenBSD is the best not-pejoratively-clique example I could find. Their hackathons page says, plainly: "Hackathon attendees come by invitation only. Some new people in the community who show promise are sometimes invited to see if they have what it takes." Linux kernel subsystems run on the same social logic at scale: the kernel docs describe a "chain of trust" where pull requests from unknown developers are received warily by subsystem maintainers until they've earned their way in. This archetype fits when the cost of misplaced trust is high and the mechanism for establishing trust is "does someone I already trust vouch for you."

The university. If you do your homework and score high enough on your exams, we'll admit you. Debian's process, above, is the archetypal case: the sponsor and mentor are part of a longer sequence that includes an application manager, a Philosophy & Procedures exam, a Tasks & Skills exam, and then DAM approval (or not). Their own docs are unusually honest about the deal: "the whole NM process is very strict and thorough. This is not meant to discourage people... but it does explain why the New Member process takes so much time." Kubernetes runs the most numerically explicit ladder I've seen: Member (sponsored by two reviewers from different companies), Reviewer (primary on 5+ PRs, reviewed 20+ substantial ones), Approver (30+ merged, nominated by a subproject owner). If you want the stdlib-adjacent case, pyOpenSci has documented onboarding flows for reviewers and editors: guest-editor probation, editor-in-chief nominations, a peer-review process modeled on academic journals. This archetype fits infrastructure that's load-bearing enough that mistakes are expensive to unwind, and it works if the syllabus is real. (It fails, badly, if the syllabus is a rebrand of "vibes-based homework we won't tell you the rules of.")

The hippie commune. Do you have a pulse? Yes? You're in. freeCodeCamp basically checks for a pulse and hands you a first timers only label. Their whole cultural stance is "let us help you land your first PR." I've been part of projects like this, and it's actually onerous in its own way. But, they're where a lot of folks get started. Without these, the rest of the spectrum loses its future contributors and maintainers. MDN Web Docs runs the same posture on the docs side: their contributing guide is basically "there's a place for you here, even if your grammar isn't perfect." (Wikipedia is the mother of this archetype but isn't code-shaped, so treat that as a cultural reference, not a technical one.) This archetype fits projects where the marginal contribution has low blast radius, and the real bottleneck is reach or discoverability, not integration cost. It also fits projects whose goal is teaching people to contribute, where the code is almost a byproduct of the mentorship.

In reality, there is, of course, a spectrum—and shades of gray as well. A project doesn't necessarily have to operate in a single mode, either. SQLite runs some clique-shaped review practices under its walled-castle surface. Debian's university process has real clique-shaped social realities inside it. Any given project can occupy more than one archetype at once—a codebase that's walled-castle at the core and hippie commune at the docs layer, say. And most projects drift between shapes as they age.

I also want to be clear that you're ALLOWED TO MOVE where your project is at. Is hippie-commune mode failing you in the age of AI slop? Maybe you run an experiment with a more rigorous onboarding (or have folks who have already contributed to the project mentor newcomers through their first PR so that the onus doesn't always fall on the maintainer.)

There is no more a platonic form for a perfect CONTRIBUTING.md than there is for a universally "perfect" job. The fit is between your project and its contributors. What works for one can be exactly wrong for another.

But here's why the taxonomy belongs in a piece about what you actually want: it forces you to say the thing out loud. "I want a hippie commune" is a different maintainer future than "I want a university," and both are different from "I want to keep the code out here but the process in here." You can't dodge the question by writing a CONTRIBUTING.md that just describes issue templates. The people who read it (the ~7 who will) can tell which archetype you're aiming for even when you haven't named it. Might as well spell it out.

There are pros and cons to the types of friction you introduce—selectively inviting who can interact, permanently banning a suspected peddler of AI slop, toggling off the "Issues" section of a repository. But, if the relationship (that between a maintainer and contributors) is evolving in such a way that it feels like it cannot hold, that's its own type of failure. Neither the maintainer nor "the community" are to blame when things end in a silent resignation or a public crashout—but maybe they can be avoided by experimenting with things you hadn't previously considered as being "worth it."

Like my old FOSS-happy-place Venn diagram, the chart below doesn't capture the n-dimensional reality of working in open source. But I'd like to think it's an improvement. On the x-axis you have maintainer/project (dis)comfort. And the y-axis is something akin to ROI (return on investment)—demand from contributors/community/ecosystem.

A hand-drawn chart on graph paper. The vertical axis runs from "nobody asked" at the bottom to "the people demand it" at the top. The horizontal axis runs from "I would rather die" on the left to "was literally gonna do it anyway..." on the right. Three example ideas are plotted as loose, dashed-circle guesses—livestreamed PR review, AI as market research, and code review as the alignment step—with a handwritten note reading "you don't know where they land 'til you try them."

The catch is that you don't really know where an experiment lands on this chart until you try it—not how much it'll cost you (the x-axis), and not what you'll get back (the y-axis). That doesn't mean you have to try everything. But it's worth paying attention to where things actually fall, rather than where you assumed they would.

Here are some things that we're trying (or considering taking for a spin):

  • Code review as the alignment step. Ed Yang makes the case that code review is where humans do the alignment work now. As AI takes on more of the implementation, the reviewer's job shifts away from line-by-line mechanics and toward the big-picture questions—does this fit, should it exist, is this the shape we want?

  • Using AI as a market-research companion, not a PR-generation machine. Instead of AI writes the pull request, it's AI helps you see the landscape. Feed it the parallel projects—for us that's NumPy, SciPy, Math.js, and friends—let it aggregate the patterns everyone else has converged on, and then you decide what fits. Same tool, pointed at what should we build instead of let's crank out code.

  • Livestreamed PR review. Twitch, Discord, YouTube—pick your poison. Someone watches a maintainer work through a review in real time. The discomfort scales hard depending on who you are (some folks would genuinely rather chew glass than do their job on camera), but it puts other humans in the room at the moment you're deciding something. And it teaches in both directions: people watching learn what makes a good contribution and what being a maintainer actually takes. It's knowledge capture without the curation—which means it might surface insights you never knew people wanted.

None of this is guaranteed to work. Most of what gets written about open-source communities and contributor experience gets written after the fact—after something worked. That means there's a bottom drawer somewhere full of the things people tried that didn't (those posts mostly don't get written.) And even the experiments that did work worked in the specific conditions of that project—its size, its maintainers, its users, its moment. Different projects, different fits. This isn't Wills and Trusts. You can iterate. Your CONTRIBUTING.md can change. Your governance can change. Your mind can change. Whatever you want to do is okay—just own it. And if you're trying something (the thing that's working, or the thing that isn't) come tell us about it. We're figuring it out too.

Sources

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

  1. Linux Foundation, OpenSSF, and Harvard LISH. Census III of Free and Open Source Software. December 2024. https://www.linuxfoundation.org/hubfs/LF Research/lfr_censusiii_120424a.pdf?hsLang=en; GitHub. Octoverse 2025. https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/. ↩︎

  2. Nadia Eghbal. "The Rise of Few-Maintainer Projects." Increment, 2019. https://increment.com/open-source/the-rise-of-few-maintainer-projects/. ↩︎