What they don't tell you about maintaining an open source project

Debate over AI‑written style

• Many commenters feel the blog post’s cadence, bullet‑point structure, “not X, but Y” tropes, comparison tables, and ultra‑terse “X → Y” lines strongly resemble LLM output.
• Others counter that humans can write like this, that specific phrases aren’t strong evidence, and that accusing every online writer of using AI is becoming tiresome.
• Some note the author’s heavy AI use in other parts of their work as circumstantial evidence; others argue that even if it’s AI‑assisted, it doesn’t inherently diminish the content.
• One reader describes feeling “violated” by the idea of AI on a personal dev blog, prompting reflection on trust and authenticity in technical writing.

What open source maintainers owe users

• One camp: open source is fundamentally “code + license.” Maintainers owe nothing beyond the terms of the license; community, docs, and support are optional.
• Another camp: the social contract and community are central; licenses exist to enable collaboration and shared improvement, not just individual freedom.
• Long subthread debates whether community or license is “primary” and how Stallman’s goals should be interpreted.
• A nuanced view splits projects into phases (toy → product → infrastructure) and argues maintainers should clearly state expectations (no SLAs, hobby project, sponsorship encouraged).

Support burden, boundaries, and user behavior

• Examples of rude, entitled issues (e.g., accusations of “greedy” free tiers) illustrate emotional and time costs.
• Advice ranges from “ignore trolls, close/delete issues” to “don’t help people who won’t help themselves.”
• Some insist it’s fine—and necessary—to say “no,” define scope, and refuse to chase down custom setups or forks.
• GitHub is seen as attracting the broadest, least filtered user base; alternative forges (codeberg, sourcehut) reportedly generate fewer low‑effort questions, partly due to higher friction.

Monetization and paid support

• Several argue that commercial users—especially enterprises—should pay (support contracts, hourly rates, “priority issue fixing”).
• Others describe real‑world frictions: universities and non‑US entities refusing to pay even small amounts; large companies imposing heavy procurement, legal, and security overhead for tiny contracts.
• There’s debate on how hard it really is to invoice without a company and how scary tax/regs should be; some say “just charge,” others highlight jurisdiction‑specific hassles.
• Multiple commenters recommend charging significantly more to be taken seriously and to make the burden worthwhile.

Documentation, scope, and contributions

• Strong agreement that “every feature is a feature you maintain forever,” including as future security risk.
• Advocated strategies: keep projects minimal and modular; maintain clear boundaries; be judicious about accepting PRs since merged code becomes maintainer responsibility.
• Docs are never finished but should target an assumed baseline; some support questions are better handled ad hoc.
• Public forums or discussion boards can offload support to the community and serve as living documentation.

Reward, burnout, and sustainability

• Some appreciate the article’s balanced tone, noting most discourse overemphasizes burnout and abuse.
• Others, including long‑time maintainers, say sustaining focus over years is extremely hard once the initial excitement fades.
• A recurring theme: maintenance is only sustainable when expectations, boundaries, and (often) compensation are aligned with the project’s actual usage and impact.