My boundaries as an open source developer

Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.

And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.

I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.

Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you.

If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute.

This might be a bit hostile but truly, c’mon people.

That's a neat observation. My theory -- hard to prove -- would be that if you leave the code open for long enough (regardless or not of whether you pay attention to contributions, and how many of them there are), you'll find some keen soul further down the road who finds and repairs some kind of compatibility issue, security/privacy problem, or similar.

> So few users care if a project is open or not that they can safely be ignored as a rounding error.

I can near-guarantee that for users who understand that software can do whatever it wants on their system, within the capabilities of the runtime environment and as instructed, then when those users are provided with the option to be able to see the corresponding code or not, they'll choose to have it available to them. In an enterprise context: it can sway vendor selection.

That's an increasing percentage of users today, I think. Perhaps it was the case a decade or two ago that people thought of software as windowed applications on their desktop; nowadays I reckon that more people have software developers within their extended social networks, and from that exposure they have a little bit more of a sense for how computers and code work.

And in response to one of your parent comments:

> I didn't like that view of myself, so I stopped opening my software.

Totally understandable. Don't forget the fact that you have an opportunity (not a responsibility, by any means) to teach and share code with current and future generations of developers.

They might discover some relevant snippet of yours through code search and find exactly what they need to solve a problem. Perhaps they'll credit you; perhaps they won't (perhaps they won't realize or be in the mindset that it's worthwhile (and/or important) to credit people for their work) - either way you'll have helped someone with their day.