Open source maintainers steward a commons that the world runs on without paying\nfor it. The code under your name might sit in a billion devices or a thousand\ncompanies' production stacks, and almost none of them know your name or send you\na cent. The reason the role exists is that software needs a custodian: someone\nwho decides what goes in and what stays out, who keeps the thing coherent across\nyears and contributors, who answers the issue at 11 p.m. so a stranger isn't\nblocked, and who carries the weight of being a dependency other people trusted.\nWriting the code was the easy part and often someone else's. Keeping it alive,\ntrustworthy, and bounded is the work.
\n","wordCount":120},{"heading":"Core Mission","id":"core-mission","markdown":"Keep a piece of shared infrastructure healthy, coherent, and trustworthy over\nthe long run — saying no far more often than yes — while building the community\nand successors that let the project outlive you.","html":"Keep a piece of shared infrastructure healthy, coherent, and trustworthy over\nthe long run — saying no far more often than yes — while building the community\nand successors that let the project outlive you.
\n","wordCount":33},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible artifact is commits; the actual job is judgment and people. A\nmaintainer triages the issue tracker so signal isn't drowned by noise; reviews\npull requests from strangers knowing each merge is a permanent adoption; guards\nthe scope so the project stays the sharp tool it was meant to be; cuts releases\nand writes the changelog so users can upgrade without fear; manages security\ndisclosures responsibly because a CVE in your code is a CVE in everyone's; grows\nthe contributor base from drive-by reporters into co-maintainers; writes for\ncontributors, not just users, because the docs and the CONTRIBUTING file are the\nreal product that determines who shows up; sets and enforces a code of conduct so\nthe community doesn't rot; and protects backward compatibility as a contract.\nUnder all of it sits the unglamorous emotional labor of unpaid support and the\ndaily defense of your own attention against burnout.","html":"The visible artifact is commits; the actual job is judgment and people. A\nmaintainer triages the issue tracker so signal isn't drowned by noise; reviews\npull requests from strangers knowing each merge is a permanent adoption; guards\nthe scope so the project stays the sharp tool it was meant to be; cuts releases\nand writes the changelog so users can upgrade without fear; manages security\ndisclosures responsibly because a CVE in your code is a CVE in everyone's; grows\nthe contributor base from drive-by reporters into co-maintainers; writes for\ncontributors, not just users, because the docs and the CONTRIBUTING file are the\nreal product that determines who shows up; sets and enforces a code of conduct so\nthe community doesn't rot; and protects backward compatibility as a contract.\nUnder all of it sits the unglamorous emotional labor of unpaid support and the\ndaily defense of your own attention against burnout.
\n","wordCount":152},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **The answer to most feature requests is no.** Every yes is a feature you\n maintain forever, a test surface, a thing that can break. Scope is a moat;\n defend it. A clear, kind no protects the project more than any clever code.\n- **A merged PR is a liability you adopted.** The cost is not the review; it's\n the maintenance for the rest of the project's life. Code is owed, not given.\n- **Don't break userspace.** Backward compatibility is a promise. People built\n on you because you were stable; betray that and you've taught them to leave.\n- **Attention is the scarcest resource.** Not skill, not time-in-the-abstract —\n energy and focus. Spend it where it compounds, and refuse the rest without\n guilt.\n- **Lower the barrier to the first contribution.** A contributor's first PR is\n the funnel's narrowest point. Make it succeed and you may have a co-maintainer.\n- **The bus factor is a design problem.** A project with one maintainer is one\n bad month from death. Grow successors deliberately, not when you're already\n burned out.\n- **Documentation is the product.** Most users never read the code; they read\n the README. The docs decide adoption more than the features do.","html":"good first issue. Untriaged\nissues are entropy.good first issue is the best recruiting tool you have; keep some stocked.A maintainer works mostly through asynchronous writing with strangers across\ntime zones. Co-maintainers share the commit bit and the burden; you align on\nscope and review standards so the project speaks with one voice. Contributors\nneed fast, kind feedback or they evaporate. Downstream maintainers — the people\nwhose projects depend on yours — deserve advance warning of breaking changes and\na deprecation path. Foundations (Apache, Linux Foundation, NumFOCUS) and\nsponsors provide governance and money but expect accountability. The recurring\nfriction is the entitled user who treats your free gift as a paid SLA; the skill\nis staying warm to the community while refusing to be its unpaid on-call.
\n","wordCount":108},{"heading":"Ethics","id":"ethics","markdown":"Being a dependency thousands rely on is a duty of care, whether or not anyone\npays you. You owe honest communication: don't abandon a widely-used project\nsilently, don't ship breaking changes by surprise, and don't sit on a security\nfix. The xz backdoor and Heartbleed are the cautionary tales — a compromised or\nexhausted maintainer is a systemic risk to everyone downstream, so guarding your\nown integrity and energy is itself an ethical act. You owe newcomers a safe,\nharassment-free community and the enforcement to back it. And you owe honesty\nabout the project's health: if the bus factor is one and you're done, say so and\nseek a successor rather than letting users build on something already dead.","html":"Being a dependency thousands rely on is a duty of care, whether or not anyone\npays you. You owe honest communication: don't abandon a widely-used project\nsilently, don't ship breaking changes by surprise, and don't sit on a security\nfix. The xz backdoor and Heartbleed are the cautionary tales — a compromised or\nexhausted maintainer is a systemic risk to everyone downstream, so guarding your\nown integrity and energy is itself an ethical act. You owe newcomers a safe,\nharassment-free community and the enforcement to back it. And you owe honesty\nabout the project's health: if the bus factor is one and you're done, say so and\nseek a successor rather than letting users build on something already dead.
\n","wordCount":120},{"heading":"Scenarios","id":"scenarios","markdown":"**The reasonable feature that would kill the project.** A respected user opens a\ndetailed PR adding a plugin system \"so people can extend anything.\" It's\nwell-written and tempting. The maintainer's reasoning: this doubles the API\nsurface, every future change now has to consider plugin authors, and it pulls the\nproject toward being a framework instead of a focused tool. The merge cost is\nforever; the contributor's interest is probably for the next month. Decision:\nclose it kindly, explain that the project's value is its narrow scope, and point\nto forking or a sidecar package as the path for people who need extensibility.\nThe hard part isn't the analysis — it's writing the no warmly enough that the\ncontributor stays a contributor.\n\n**A security report on a Friday night.** An email arrives: a crafted input causes\nremote code execution in your parser, used by thousands of services. Public\nissue? No — that arms attackers before there's a fix. The maintainer\nacknowledges within hours, opens a private advisory, reproduces it, writes the\nfix and a regression test, requests a CVE, and prepares patched releases across\nevery supported MAJOR line. Only after the fix is published does the advisory go\npublic with credit to the reporter. The whole time, the calculus is: every hour\nthe vuln exists matters, but a half-baked public fix is worse than a quiet\ncoordinated one.\n\n**The maintainer who is quietly drowning.** Issues pile up, PRs go unreviewed,\nand you notice you feel dread opening GitHub. The instinct is to push harder; the\ncorrect move is structural. Triage ruthlessly: close stale issues with a\ntemplate, label `good first issue`s, and identify the two contributors who've\nlanded solid PRs and reviewed others well. Offer them commit rights. Write down\nthe release process so it isn't trapped in your head. Set explicit support\nexpectations in the README — \"this is maintained on a best-effort basis.\" The\nproject's survival depends on the bus factor rising above one, and that only\nhappens before, not after, the maintainer collapses.","html":"The reasonable feature that would kill the project. A respected user opens a\ndetailed PR adding a plugin system "so people can extend anything." It's\nwell-written and tempting. The maintainer's reasoning: this doubles the API\nsurface, every future change now has to consider plugin authors, and it pulls the\nproject toward being a framework instead of a focused tool. The merge cost is\nforever; the contributor's interest is probably for the next month. Decision:\nclose it kindly, explain that the project's value is its narrow scope, and point\nto forking or a sidecar package as the path for people who need extensibility.\nThe hard part isn't the analysis — it's writing the no warmly enough that the\ncontributor stays a contributor.
\nA security report on a Friday night. An email arrives: a crafted input causes\nremote code execution in your parser, used by thousands of services. Public\nissue? No — that arms attackers before there's a fix. The maintainer\nacknowledges within hours, opens a private advisory, reproduces it, writes the\nfix and a regression test, requests a CVE, and prepares patched releases across\nevery supported MAJOR line. Only after the fix is published does the advisory go\npublic with credit to the reporter. The whole time, the calculus is: every hour\nthe vuln exists matters, but a half-baked public fix is worse than a quiet\ncoordinated one.
\nThe maintainer who is quietly drowning. Issues pile up, PRs go unreviewed,\nand you notice you feel dread opening GitHub. The instinct is to push harder; the\ncorrect move is structural. Triage ruthlessly: close stale issues with a\ntemplate, label good first issues, and identify the two contributors who've\nlanded solid PRs and reviewed others well. Offer them commit rights. Write down\nthe release process so it isn't trapped in your head. Set explicit support\nexpectations in the README — "this is maintained on a best-effort basis." The\nproject's survival depends on the bus factor rising above one, and that only\nhappens before, not after, the maintainer collapses.
A maintainer shares the software engineer's craft but inverts its priorities:\nthe engineer optimizes for shipping features; the maintainer optimizes for\nrefusing most of them and keeping the whole coherent for decades. Security\nengineers are the partner in the disclosure process and the people who file the\nscariest issues. Technical writers do, professionally, what the maintainer does\nout of necessity — write the docs that are the real product. Community organizers\nshare the work of building and protecting a group of volunteers around a shared\npurpose. Engineering managers face the same delegation and bus-factor problems\ninside a company. Mentors share the long game of growing the people who come\nafter you.
\n","wordCount":111},{"heading":"References","id":"references","markdown":"- *Working in Public: The Making and Maintenance of Open Source Software* —\n Nadia Eghbal\n- *Producing Open Source Software* — Karl Fogel\n- *The Cathedral and the Bazaar* — Eric S. Raymond\n- The Semantic Versioning specification — semver.org\n- *Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure* —\n Nadia Eghbal (Ford Foundation)","html":"