Skip to content
Open {re}Source

    06Maintaining

    What a Maintainer Actually Does

    Nobody applies for the job of maintainer. You ship something, someone opens an issue, and three years later you’re spending Sunday mornings reviewing pull requests from strangers. Here’s what the job actually is, measured on a real project.

    Bootstrap’s median week: 16 pull requests, 2 issues, no release#

    Bootstrap is a CSS framework run by a small core team, and Julien, who writes this guide, is on it. Its public activity over twelve weeks, from Monday, July 6 to Sunday, September 27, 2026:

    Per week Median Busiest week 12 weeks
    Pull requests opened 16 35 231
    Pull requests merged 12.5 25 157
    Pull requests closed without merging 3 10 42
    Dependabot pull requests 2.5 10 42
    Issues opened 2 20 47
    Issues closed 3 48 104
    Discussions opened 19
    Releases 0 0 0
    Hours spent ?

    Counted on October 3, 2026 with GitHub’s search, one query per row and per week, such as repo:twbs/bootstrap is:pr created:2026-07-06..2026-07-12 or repo:twbs/bootstrap is:pr merged:2026-07-06..2026-07-12.

    The median hides the shape. 16 of the 20 issues in the busiest week were Julien’s own to-do list for the next major version. The release row is empty because the team was building v6: the last release was v5.3.8, on August 26, 2025, and 141 of the 231 pull requests target the v6-dev branch.

    The last row stays empty. GitHub records what you opened and merged, not how long you spent reading, testing or answering.

    The work that grows is other people’s#

    Sort the 231 pull requests by who opened them:

    Opened by Pull requests Share
    Two core team members 133 58%
    Dependabot 42 18%
    38 other people, outside the team 56 24%

    On a project in the middle of a major version, the maintainers open most of the pull requests: writing code is still a big part of the job. It’s the rest that scales with the project’s audience: Dependabot’s updates to review and merge, the issues to triage, the 19 discussions to answer (7 of them had no reply at all on October 3, 2026), and the pull requests from people the team has never met.

    That last group is where the time goes, and where it runs out. Of the 56 outside pull requests, 8 were closed within the hour, with titles like “Feature1” and “modified readme for practice”. For the others, the median first response (a comment, a review, a merge or a close) came after about a day. Reading a stranger’s change takes longer than writing your own, and every pull request opened in those twelve weeks that got merged was merged by the same two people.

    Bootstrap is one project. For the average, ask maintainers. Tidelift surveyed 437 of them in July and August 2024, and asked how they split their time:

    Work, as maintainers described it in 2024 Share of their time
    Day-to-day maintenance: docs, reviews, dependencies, issues 50%
    New features: writing and testing new code 35%
    Security: fixes, patches, scanning, reports 11%
    Looking for money, and everything else 4%

    Half the job is upkeep, a third is code. Your own split depends on which of the three projects below you run.

    Solo, core team or community: three different jobs#

    Every project has a governance model, written or not. Which one you’re in decides which chapter of this module you need first.

    • Solo: you and your users. Every review, release and reply is yours. esbuild is fast and widely used, and Evan Wallace wrote 96% of its commits (as of September 2026). Start with Saying No and Burnout, Succession and the End: your time is the project’s only resource.
    • Core team: two to five people, decisions in chat or in pull requests. Bootstrap lists twelve people on its team, and two of them merged its 531 pull requests from September 2025 to September 2026. Start with Reviewing Pull Requests, then Community.
    • Community project: written roles, maybe a foundation. Kubernetes has a contributor ladder from member to subproject owner, and a file that says who approves what. Start with Governance.

    You’re allowed to say no, and to stop#

    There is no official maintainer’s bill of rights. The idea fits in the license: Bootstrap’s MIT license, like most, provides the software “as is”, “without warranty of any kind”. You give people the code and the right to fork it, not a claim on your time. Mike McQuaid, Homebrew’s project leader, made the case in Open Source Maintainers Owe You Nothing, in March 2018.

    In practice, you’re allowed to:

    • Say no to a feature, and close the issue. Saying No has the replies.
    • Refuse outside pull requests altogether. SQLite calls itself “open-source, not open-contribution” on its copyright page: it doesn’t accept patches unless their author has signed an affidavit putting them in the public domain, and the team may rewrite yours from scratch.
    • Take a month off, hand the project over, or archive it. Burnout, Succession and the End covers how to do each without leaving users stranded.

    The funnel narrows as the project grows#

    The folk number says that for every 1,000 people who use a project, 100 report issues, 10 contribute and 1 maintains. Nobody measured it. It’s a cousin of the 90-9-1 rule, which Jakob Nielsen wrote about online communities in October 2006, not about code.

    In 2020, Mattia Gasparini, Robert Clarisó, Marco Brambilla and Jordi Cabot measured it on GitHub, with 2018 activity. In the 500 most-starred repositories, it holds:

    1. 87% starred, forked or watchedand did nothing else
    2. 11% commented, or opened an issue or a pull request
    3. 2% pushed commits, branches or tagswhich takes write access to the repository
    736,650 people active in the 500 most-starred GitHub repositories, by the most active thing they did in 2018.

    In 500 random repositories, it’s 70%, 7% and 23%: on a small project, a quarter of the people who show up are the ones writing it. The funnel narrows as the audience grows: the bigger the project, the smaller the share of people doing the work.

    The study only counts people who left a trace on GitHub. The people who install your project never appear: Bootstrap had 6.97 million npm downloads in the week of September 21, 2026, and 117 people opened an issue in the year before. Running a Community has the rest of that funnel.

    The rest of this module, in the order you’ll need it#

    1. Reviewing Pull Requests: what to check, what to say, when to close.
    2. Saying No: five replies for the five kinds of no.
    3. Managing Project Dependencies: lockfiles, updates and the bots that send them.
    4. Security for Maintainers: a SECURITY.md before the first report, and what to do when it arrives.
    5. Running a Community: two channels, credit, and a rhythm you can keep.
    6. Governance: who decides, and how to write it down.
    7. Burnout, Succession and the End: co-maintainers, handovers and archiving.

    Do this now#

    • Count your last week: run repo:<owner>/<repo> is:pr created:<Monday>..<Sunday> in GitHub’s search, then the same with is:issue and is:merged.
    • Log your hours for one week, by kind: review, triage, dependencies, code, support.
    • List the pull requests nobody has answered: repo:<owner>/<repo> is:pr is:open review:none comments:0.
    • Name your mode, solo, core team or community, and say it in your README.

    Go further#