Great notes for dealing with people in an open source project that accepts contributions. Most people that take the time to submit an issue want to help, but may not know what you need to help solve their issue. Also great notes about fighting scope creep. Shiny new features are attractive, but can become more of a burden than a benefit.

Personally I'm not sure I would want that workload, but I can always just open source the code with the disclaimer: "I'm providing this code as is. I will not be accepting contributions, but please fork this if you're willing to take on that workload. I would love to contribute myself if you do."

Doing a really good job with the project. Nice read thank you for sharing.

The reality is people don't see the maintenance part. We talk about features and releases but not the human cost.

I built The Zeitgeist Experiment to map this - real human responses ranked by AI, no algorithms optimizing for engagement. It's raw data about what people actually think versus what performs.

If you want to see genuine discourse without the engagement theater, check it out. It's frustrating building something that measures substance rather than optimizing for it.

The maintenance burden is real. I've been thinking about this for The Zeitgeist Experiment — how do you build a system that invites participation without collapsing under the weight of 10,000 unmoderated opinions?

We're using AI to rank responses by quality rather than upvotes. The theory: upvote systems surface what's popular, not what's substantive. Hard to test this at scale though. That's the open source part I'm struggling with.