TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Notes from a tired maintainer

24 pointsby jgalvezover 1 year ago

1 comment

forbiddenvoidover 1 year ago
Empathy goes both ways.<p>I think &quot;tired maintainer&quot; is narrative device to elicit empathy, so I don&#x27;t necessarily believe this is true of the author, but if maintaining an open source project makes you tired, maybe don&#x27;t maintain an open source project. Maintainer is a different role than developer, and I think a lot of people who get burnt out on maintaining open source are burnt out because what they want to do is write code and build things, not manage projects.<p>My perception is that many (not all - people can be pushy) communication and overwhelming problems in OSS projects are the result of suboptimal upfront communication - as well as a pernicious, persistent mythos around how OSS development actually works in practice. Basically, a lot of maintainers feel like the problems in OSS are a result of users&#x2F;contributors not understanding what they need, but quite often, maintainers do not really understand what their users&#x2F;contributors need as well.<p>For example, the author mentions the following as the list of things people are often pinging about:<p>&gt; Want a feature to be landed &gt; Want a bug to be resolved &gt; Want your PR to be reviewed or released &gt; Want to have updates and followups for something &gt; Want to contribute and waiting for the maintainer’s update<p>I would expect most OSS projects of a reasonable size (where volume is an issue) to have a contributing guide that describes:<p>* How new features are decided, planned, assigned, implemented and shipped * How bugs are triaged, assigned, fixed and shipped * How PRs are reviewed and released * How and when updates and communication are provided * What contributions are desired, and how best to go about providing those contributions<p>Importantly, when these things are clearly documented (and that documentation accurately portrays the goals and working style of the project), the community will be able to help point out when someone isn&#x27;t playing along and help them toward the right path.<p>---<p>FWIW - the author appears to be a maintainer of nuxt and unjs, who actually do this very well. They&#x27;re contribution guide is worth emulating for other large OSS projects: <a href="https:&#x2F;&#x2F;nuxt.com&#x2F;docs&#x2F;community&#x2F;contribution" rel="nofollow">https:&#x2F;&#x2F;nuxt.com&#x2F;docs&#x2F;community&#x2F;contribution</a>