Comment by M95D

> If you make your project public, it means you want and expect people to use it.

This isn't true. For many people (myself included), making a project open source means "if you find it useful feel free to make use of it, if not I don't really mind". I don't care, at all, if one soul finds my code useful. It's a gift to the commons, not some kind of social obligation I'm agreeing to.

Yeah, I didn't like that attitude either.

> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

Sure, I'm not entitled to anything. At the same time, this text essentially says "you don't matter", which I personally don't like.

Years ago, I tried the hot new Linux distribution. I tried to install a couple of popular packages, but they failed, due to lacking a dependency. I installed that dependency and it worked.

It's natural to file a bug report for this type of problem. I told them the missing dependency and assumed they'd make a minor adjustment and push out a fix for the buggy package. Instead, they closed the bug with a rude message about how it was a waste of everyone's time to file a bug report without an exact error message, and the buggy package just sat there.

They probably went on to become a SO mod, closing questions because they were duplicates of unrelated questions, but that's speculation.

> This is the attitude that made me keep my patches to myself.

That's your choice. Now if you open source your patches (in a fork, or in PRs to the upstream repo), someone other than the maintainer could benefit from it. So it's still helpful.

> If you make your project public, it means you want and expect people to use it

No. I benefit from others open sourcing their code, so I open source mine when I can. Because if nobody does it, then I don't benefit from it. But I don't care if people use it or not.

> You could at least write some documentation, so I don't waste my time

No. You are responsible for your time. If it takes you days to realise that you struggle understanding what my project does, that's on you. I am not responsible for you wasting days.

> If you set up a bug tracker, then at least have the decency to answer bug reports.

No. If you report a bug there, it can be useful to someone other than the maintainer, so it's still worth it.

> but at least you could give

I gave you a whole project that you apparently find useful, and all you have to say about it is "at least I could give more"?

> If you open it up to pull requests, it means you want people to contribute

No! Again a PR is a way to share a patch. Even if the maintainer never even looks at it, it may be useful to someone else.

> If you can't do at least these things, just say it's abandoned on the front page and be done with it.

I added a licence that explains what you should expect. I don't know of a single popular open source licence that sets any of the expectations you have. All they say is that you can reuse the code under some conditions.

> - If you make your project public, it means you want and expect people to use it.

no, it doesn't, maybe I have a github project, I want to easily share it with ten of my friends for something, I don't particularly care if other people see it, so I make it public. That in no way implies I want random people to come along with bugs and PRs.

> You could at least write some documentation, so I don't waste my time and then find out, days later, i

if it doesnt have any documentation then that is a clear sign you should not expect anything from the author of that software. if reading some code and figuring out if it's useful to you or not is too much of a risk of your time, then assume it's not useful and move onto something else.

> If you set up a bug tracker, then at least have the decency to answer bug reports.

maybe the author had time and energy to answer bug reports a few years ago and maybe right now they don't. When bugs go unanswered (like, all the bugs, not just one in particular), that means the project is possibly in an unmaintained or semi-unmaintained status, might be time to move on. Or if it's just your bug, it usually means your bug is something the maintainers don't care about or dont have the cycles to spend effort on (again, could be time to move on).

certainly, if I'm an OSS author and I want people to use my project and stay with it, then yes, I'm certainly going to answer all bug reports. But I have no such obligation (indeed I have lots of projects and are in both categories and many in between).

> If you open it up to pull requests, it means you want people to contribute. Have the decency to review them. Someone took time away from their jobs, families or entertainment to write those PRs. Ignoring them because you don't need that feature, not affected by the bug, or simply because of code aesthetics is an insult to the one who wrote it.

counterpoint, people who barge in on your project with huge PRs for features or changes that were not discussed at all much less signed off on by the maintainers are incredibly rude and entitled, because they are using exactly your logic above "I starved my family to bring this to you!" to guilt you into taking your project into directions you may not have wanted, and beyond that, PRs are just as much work for maintainers as for the person contributing them. An unannounced PR to me is pretty much a bug report with a guilt trip attached, no thanks. I really wish Github would provide more options in this area.

- a maintainer

I agree. I would add a pet peeve of mine:

- Don't publish a code of conduct and then be an absolute asshole to contributors (pick a lane and stick to it)

I feel there is a lot of performative policy published, which at the end of the day is lip service. Actual users or contributors come along and follow the guidance, expectations, etc? They then find themselves treated like a hostile entity and there is a weird prevailing attitude here that's "fine".

> me keep my patches to myself.

Exactly.

Nobody is entitled to your patches.

I can't tell if this is satire or not. I fear that it's not.

"If you make your project public, it means you want and expect people to use it. You could at least write some documentation, so I don't waste my time and then find out, days later, it isn't capable of what I need or I simply don't know how to use it."

WTF? If I make it public it's because I think other people might like to see it. That runs the gamut from "this is a production-ready project that solves a major problem" to "this is useless but shows some interesting techniques you might like to learn from."

If you spent days fiddling with an undocumented project that turned out not to do what you need, I'm not the one who wasted your time. That would be you.

If you want to limit yourself to only looking at high-quality projects with documentations and active bug trackers and PR reviewers, go for it. That's probably a good move! But putting some source files on a web server does not imply any further obligation, in those areas or any other.