Open source maintainer burnout: closing the contribution door
The Canario Terminal closing its source code generated a discussion about the costs of open source that goes beyond licensing. The maintainer cited the burden of contributions, issues, and community management as the reason for closing. Commenters pointed to the SQLite model, 'open source, not open contribution,' as a healthier middle ground: code is visible and forkable, but the maintainer controls direction without fielding PRs.
This connects to the Squeak 6.1 and Chicken Scheme 6.0 releases, both of which are mature open projects with small but dedicated maintainer communities. The recurring theme is that open source is easy to start and hard to sustain, especially when the project gets popular enough to attract users but not popular enough to attract reliable co-maintainers.
The GitHub-as-default-infrastructure assumption is also being questioned. Several comments noted that 'open source' predates GitHub, and that hosting source somewhere without issues or PRs is a perfectly valid model. The conflation of 'open source' with 'open contribution via GitHub' is a relatively recent and not necessarily healthy development.
So what?
If you're building on open source dependencies, pay attention to maintainer signals. A project closing contributions or going read-only is often a precursor to abandonment, not a sign of health. For founders considering open-sourcing their own code, the SQLite model is worth studying: it gives you community credibility without the support burden.