# What Does It Mean to Be an Open-Source Project Maintainer?

DevFeed: [What Does It Mean to Be an Open-Source Project Maintainer?](<https://devfeed.tech/articles/what-does-it-mean-to-be-a-open-source-project-maintainer-40607.md>)

Original publisher: [Read original article](<https://www.nateberkopec.com/blog/what-does-it-mean-do-be-an-oss-maintainer/>)

Published: 2019-10-07T00:00:00Z

Content type: opinion

Language: en

Sources: [Nate Berkopec](<https://devfeed.tech/sources/nate-berkopec.md>)

Topics: [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [Code](<https://devfeed.tech/topics/code.md>), [releases](<https://devfeed.tech/topics/releases.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [releases](<https://devfeed.tech/tags/releases.md>)

## AI overview

The article examines what it means to maintain an open-source project. It argues that maintainership includes responsibilities such as coding, documentation, issue triage, code review, releases, quality control, project direction, and encouraging contributions, while only some responsibilities require commit or package-publishing privileges.

## Source excerpt

There are many different responsibilities for the maintenance of an open source project, and while some of them get called "maintainership", I'm not sure they should be. Let's zoom out for a moment. What labor must be performed, by someone, anyone - in any successful open source project? Writing code - fixing bugs, writing new features, refactoring old code. Writing documentation - explaining why things are the way they are. Recording intention and design, and how to use the APIs provided. Issue triage. Making bug reporters create reproducing examples. Closing issues that are stale or invalid. Providing feedback on feature requests. Code review. Looking at pull requests and providing feedback. Regular releases. Packaging up a release and pushing to the package namespace. "Green Button" control. Merging pull requests. Deciding what should be merged and what should not. This "quality control": is this PR good? Does it fit the goals of the project? Did someone review it? Vision/direction. What's our release schedule? What features will we not include? What approaches will we never take? Enlisting help. Encouraging more contributions and engaging more volunteers to do the above. What's interesting is that only a few of these responsibilities require what most people consider to be the mark of the maintainer: commit bit and rights to the package namespace on the appropriate package manager. In fact, it's really just one of the responsibilities that needs that all-important commit bit access ("Green Button" control), and pushing to the package repository needs a separate privilege. Everything else needs no privileges whatsoever. Unfortunately, the word "maintainer" has become something of a byword for a mythical cowboy-coder heroine, someone who spends 40 hours a week on their project writing new features, fixing reported bugs, spinning up VMs on cloud services to try to reproduce the more esoteric reports. As an maintainer of a popular OSS project, many people certainly