zlacker

>>levlaz+(OP)
On the one side: Yes, truer words have never been spoken. You want a new feature added? Want to talk about how the project should change directions? Want to impose new rules? Do a little power play? Yeah, start working on the project, implementing changes/features you want to see.

On the other side: No. When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. Your software has become a corner stone in other people’s software stack/life and so those people and their issues with your software have become your problem, too. If you want it or not.

Hiding behind open source and not fixing bugs has become a deal breaker so many times over the last few decades, that I stopped counting. Not everybody knows the language needed to fix a bug and not everybody understands the dependencies within a project to being able to fix a bug. So “fixing” one bug can create ten new ones and make things much worse.

Not to mention what happens when you attempt to fix the bug but the source is not accepted upstream because it’s bad, which is understandable, but still leaves you with an upstream version of the software and your patched version that fixes said bug.

>>Grimet+ad
> When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation.

What you're saying here is that "give them an inch and they'll take a mile" is not just a description of an unfortunate reality, it's a moral imperative. Give them an inch and they have a right to that mile.

Do you not see how totally destructive this moral framework is? If giving away free work instantly entitles anyone who benefits from that free work to an arbitrary amount of additional free work, the only rational move for a would-be contributor is not to play the game at all. Is that really the world you want to live in?