When the original dark theme was introduced several years back, I complained mightily about various contrast bugs that made things unacceptably difficult to read at best, impossible to read at worst.
I volunteered to spend some time tweaking the CSS to improve the contrast ratios some while preserving the overall look (IOW not a specific “high contrast” theme so much as making it more generally readable). I was rebuffed with a comment along the lines of oh it’s just for aesthetics and accessibility isn’t a concern.
The dark theme has improved over the years but that whole interaction was very disappointing. It also made me decide I didn’t want to spend any free time contributing to Discourse. I’ve definitely noticed a trend of any feedback taken with extreme hostility.
10 Likes
That’s not at all uncommon with open source software. There’s definitely a big ego factor involved in open source.
One that I encountered today, not related to Discourse, but similar. There’s this module that automatically provides a JSON API that frontend code can call for data from the CMS backend. Some of the database queries it produces are pretty bad. The CMS has a system of query tags, so you can say $query->addTag('this_is_query_xyz'); and then that allows other code elsewhere to check if ($query->hasTag('this_is_query_xyz')) and alter the query to make it perform better with your data or whatever. There have been multiple requests for them to just add a tag to their queries, so that other people, when building a site, can then make use of that feature, but they refuse. Because “That one single line of code would have to be maintained and we don’t feel it’s necessary or worth the maintenance burden.” 
That’s just their ego. Nothing could ever be wrong with queries their code generates, so why would anyone ever want to alter them?
There’s another that annoys me. PHPCPD looks for copy-pasted duplicate code, and nags you to refactor it if you have duplicate code above a threshold. Pretty much every other code quality scanner tool has some kind of mechanism for adding an exception. So you can tell it “Yes, this method is really long, but that’s intentional, and it’s okay in this case because it’s test code.” and it’ll stop nagging you. Not CPD. The maintainer insists that no code should ever be duplicated and there should be no exceptions, even if you’re setting up two test cases that are very similar but have a few key differences, or dealing with standard boilerplate. There’ve been several requests for it, and he just closes all of them with a curt dismissal.
That’s just ego. If you don’t code everything exactly the way he wants, then why are you even coding?
I call those out because those are both cases of existing features widely-implemented in other code in the same systems, and trivial to add. But rather than add one line of code to help their users, the maintainers will write hundreds of lines of comments in the issue queue to declare that they refuse because they don’t want to and people who want it are wrong.
7 Likes
I get the DRY principle, but that’s just dogmatic enforcement. That you can’t override it and say, “yes there’s a good reason for this and it’s not worth the effort to do it differently” is just silly. Not everything has to be treated like NASA-quality code.
Ain’t that the damn truth. I remember spending time on the Discourse forums to complain about something and just getting railed on by the PTB essentially being told “I’m holding it wrong”, “why wouldn’t you want it this way”, and otherwise completely dismissing my experiences. Discourse, I love you, but some of your developers have shitty attitudes.
6 Likes
This happens everywhere and I used to call it the “academics vs reality” fight.
Before everyone settled on Ansible or saltstack (or terraform) for config management/IaC, there was a holy war between configs system that were prescriptive- (that is, you write how things should be, the tool makes reality match your definition, full stop), vs tools that can examine how the world is and then convert that into a definition.
Many of those tools that came from large university networks or early supercomputer teams were staunchly against examining the existing world at all - why would you ever let anyone deploy something outside the definition?
Of course outside of academia when something breaks you go fix it, and if that means kludging something together to get it working again and then coming back around to make your definition match reality afterwards, well, that’s what you do, because otherwise your infrastructure is down and people are pissed off at you. But if you’ve only run a fiefdom of a campus / research network and your users are more nuisances than customers or otherwise don’t get a say in reliability, well then, sure, spend an extra hour fixing your definition before you bring your infra back up.
Google even enshrined this in their cloud! “Preemptible” servers used to have a 24-hour restart timer (unlike competitors where preemptible workloads ran until that capacity was needed by a non-preemptible customer, often for weeks or months) - for no other reason than that Google thought that anyone running preemptible workloads “should build their systems to be tolerant of daily restarts as a good practice” - completely ignoring reality. There though, they have customers not serfs (unlike a lot of their other monopolistic business divisions) and were forced to change their offering.
So it’s not just the FLOSS community that is this way, it’s idealism vs pragmatism overall.
9 Likes
Someone wiser than me once said to me, “shipping is a feature”. This gave me a lot of perspective.
7 Likes
ego
Dear FSM I’ve run into this so much when trying to integrate open source libraries. I have a flat spot on my head from banging it into a wall so often.
6 Likes