It's almost like watching lottery winners having their lives ruined.
It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like this? I know, I know. I'm taking my crazy pills again. Sorry.
Sounds like a whole lotta give to me...
It seems like you're trying to make it seem like there is always a legitimate exchange, and so they owe you something. Some projects want help, others don't. In the latter case, it's just a gift from the author, and they don't owe you anything.
Any open source maintainer will tell you that many PRs, even well-intentioned ones, end up being a net negative. Often they don't further the maintainers aims, they need detailed review, take sometimes a lot of effort to manage the communication tactfully, etc.
Yes, many PRs are a win and it can be really gratifying seeing your project become bigger and better than you could have made on its own.
But also, many PRs are just a chore and a hassle.
At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.
That doesn't mean I'm willing to accept your patch. As soon as I accept collaboration, I need to worry about copyright on the contributions, whether they follow my coding style, and whether I'm willing to accept additional complexity for features I don't care about.
- There exist open source licenses (with copyleft) that disallow making it closed source.
- There exist other reasons to publish the source code: for example allowing the user to study it.
Technically you could just post the .pyc bytecode as long as you didn't care about it working on anything but CPython and compatible implementations.
Consider CC0 instead.
As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices.
CC0 allows you to provide maximum benefit should you opt out of "social coding". People can go ahead and fork your stuff, or just use bits and pieces, without needing to deal with licensing or crediting headaches. (Significant consumers still have to track provenance, though.)
Certainly I would expect amyjess and anyone else reading to exercise due skepticism and perform their own research and I respect them enough to expect that they will "consider" my suggestion rather than "blindly" follow it.
PS: Why assume everyone is "ill-informed"? We're all learning together forever: you, me, amyjess, other readers...
People should decide if it's a big deal for them and if it is, fork the project to fix the issue or move to another library. I have had to do this many times myself, I kind of thought that's just how things worked with smaller projects. More than once I've found someone of a like mind has _already_ forked and made the change.
The level of entitlement in the discussion astonishes me. Someone has done a lot of work and offered it for free along with a license that lets people modify it and redistribute it and that is not enough. Instead of being grateful for it, people are demanding that the giver also make the changes that these people need and take on the burden of maintaining them.
To all those people: Why should he? Do it yourself or pay someone to do it. It need not be any more complicated than that.