4 ms·
> about barely breaking changes in Open Source software. I get the sentiment, but I'm immediately recalling times users have been spurned by projects that just
by git-pull 9y ago
> about barely breaking changes in Open Source software.
I get the sentiment, but I'm immediately recalling times users have been spurned by projects that just didn't listen. In that light, this feels like a subjective statement.
I can tell you I'm racking my brain right now trying to invoke custom sphinx-doc builders programatically. And I get absolutely zero consideration in the issue tracker. Why? Because 99% of the cases of sphinx are invocation through ReadTheDocs and the project's Makefile. They don't care whether their internals are intuitive or not.
To most, it looks incredibly trivial. But I have a legitimate case to use sphinx this way, and they flip when I suggest adding an argument to insert a custom Builder. No, I have to create a side effect by inserting an extension, which registers the builder as a string, and then figure out why I'm not printing even basic debug statements.
I seriously only have the intention of making life easier for others. The internals of docutils and sphinx are no simple feat to understand.
Eh, other than my own personal problems, which I at least made patches for, there's gnome's spatial fiasco (https://www.osnews.com/story/7344 https://www.osnews.com/story/7344). So, every time I did a gnome install I'd go into preferences to 'fix' it. Untold others did too.
I have sympathy toward open source projects not being able to change internals due to fear of introducing regressions and keeping code maintainable and (to a point) pragmatic. My point is, while there is people who pick small gripes over edge cases, there are simple little things that can cause headaches to users.