Open Source Maintenance Becomes Unpaid Second Job, Author Argues
An article published on Hacker News contends that platforms like GitHub have transformed voluntary contributions into roles filled with bureaucracy and stakeholder meetings, urging developers to reclaim control by limiting access and disabling public trackers.
A recent article titled "Open Source Does Not Imply Open Community" argues that the landscape of modern software development has fundamentally shifted from independent coding to an unpaid second job characterised by corporate bureaucracy. The author contends that what was once a simple pursuit of independent work has evolved into a role burdened by stakeholder meetings, performative community management, and the administrative overhead of large-scale platforms.
The piece contrasts this current state with earlier eras of development that relied on barebones webpages, FTP servers, and email for distribution and communication. In those earlier days, projects operated without formal structures such as Codes of Conduct, pull requests, or designated core teams. Communication occurred through unofficial IRC channels and mailing lists, allowing developers to engage without the political friction or rigid workflows that define the modern environment.
The transition to hosting sites like SourceForge and the subsequent dominance of GitHub is identified as the tipping point where open source maintenance began to mirror corporate employment structures. The author describes how these platforms introduced formalised workflows, including Agile methodologies and Key Performance Indicators, effectively turning voluntary contributions into a job complete with tickets, roadmaps, and the pressure of changing requirements.
Under this new model, maintainers find themselves managing a "community" they never signed up for, dealing with complaints and demands from people with little patience. The article suggests that this influx of strangers and AI bots has created an environment where developers must babysit users and manage chat groups, leading to significant burnout. The author notes that while some massive projects require teams to manage their complexity, this is presented as an exception rather than the rule for the broader open source ecosystem.
In response to these challenges, the article advocates for developers to reclaim control by limiting access to trusted circles and avoiding the influx of unmanageable users. Specific technical recommendations include deploying bare git servers, turning off public issue trackers, and disabling pull requests to prevent the distraction of rearchitecting software outside of its original scope. The author argues that software can remain "open source" without being developed openly, allowing creators to focus on writing code and making tools they like without the baggage of performative governance.
The piece concludes with a strong recommendation to stop allowing strangers to invade personal development spaces. Instead of running operations that function as half tech incubator and half daycare for inexperienced users, the author suggests developers should work alone or with a small group of trusted individuals, free to use any tools they want and release code drops on their own schedule.
