cross-posted from: https://slrpnk.net/post/27708324
The long-term effects of tech enshitification are becoming apparent in how people perceive software bug reports. A software defect that would have been easily regarded as a bug in the 1990s is now seen as software functioning normally and as expected. The rise of enshitification and fall of software quality has conditioned consumers to unwittingly lower their standards of quality.
In the case of millennials and gen-z, they are starting off with a baseline of low standards as they were immersed in enshitified tech from the beginning.
Observation ①: Software ignores user’s instructions. The enshitification-era perception→ “not a bug”
The Lemmy web client enables users to generally block whole instances in their settings. Users can also subscribe to specific communities. The web client supports user input to block a whole instance while simultaneously subscribing to a community on that blocked instance.
People with a history of exposure to well engineered software naturally expect treatment that simultaneously accommodates all user instructions. The only way to honor both of the user’s instructions in this scenario is to prioritise the specific instruction to subscribe to a particular Lemmy community above the general instruction to block the node that hosts it.
To invert that priority necessarily entails disregarding the user’s specific instruction to subscribe to the community. This is what Lemmy does today. A machine that silently disregards user instructions without even so much as any sort of notice to the user can only be regarded as a poorly designed application that disservices the user if your exposure to technology pre-dates the era of enshitification (pre-2000s).
Reaction to this bug report shows the result of a devolution in perceptions of software quality. To be clear, Lemmy is not enshitified because enshitification is more of a consequence of conflicts of interest. Lemmy devs most likely simply failed to be adequately meticulous, yielding an honest bug. However, enshitification has downgraded users’ standard of quality so they cannot identify a defect when they see it.
Google demonstrated a parallel analogue to this. I used to search using dejanews before Google bought it. The search engine honored my queries. In particular, negations were respected. That is, searching “foo -bar” would yield results that do not contain the token “bar”. Likewise in Google early on. Today Google generally scraps the negation. You negate a word and Google nannies you by not only showing results that the include the negated word but in fact Google internally rewrites the query to suit its business interest.
The population accepts it. Google is still the top search engine. People have become conditioned to accept machines that ignore their instructions.
Observation ②: Lemmy deceives senders on status of msg delivery. The enshitification-era perception→ “not a bug”
Gen-Xers have an expectation that non-defective software is truthful. When a machine lies to the human user, it’s a defect. It is a most obnoxious kind of defect in the context of communication from human to human because of the importance of knowing whether a message is delivered. A false message about delivery can cause embarrassment, outrage, or loss of respect toward another human -- when in fact the machine is to blame.
Example: Bob blocks the Lemmy.World instance. Alice@Lemmy.World DMs Bob. To Alice, the message appears to be delivered. Nothing signals to Alice to indicate non-delivery. And nothing signals Bob that an attempt was made. Alice is deceived about the delivery and Bob is deceived about what to expect because blocking an instance does not block everything from the instance (e.g. public comments from LW users are still presented to Bob). Bob would not naturally expect a DM directed specifically to him to be blocked when public comments from the same person are shown to him.
Yet in this enshitification era, a significant number of people regard the deception to Alice and the astonishingly baffling contradiction of behaviour as software functioning as expected.
People born before the 90s tended to be disgusted with the idea of email servers that silently blackhole email, which accepts an email for delivery but then throws it away without anyone knowing. Then Reddit comes along with their rampant practice of shadow banning, which is even more abusive than blackholing because the deception of false delivery is bolstered by showing the user their own msg where it was sent to proactively maintain the deception.
I believe Reddit did a lot of damage there by conditioning the younger generation to accept being lied to about the comms status of message delivery.
Just as smoking changes personalities, so does enshitification
A study found that cigarette smoking actually modifies the personality of the user to become more accepting of filth. This is because the filth of cigarettes is unavoidable. Ashes are very lightweight and get carried everywhere. Ashtrays catch a majority but there are always some ashes in sight as well as cigarette butts. A smoker would have to have an unlikely high level of OCD cleanliness to counter it. So their personality gives. Smokers just become accepting of filth.
Enshitification of technology has the same propensity to modify people’s personality to accept the burdens it brings. Those who solve CAPTCHA become increasingly more willing to solve them. The industry of all things enshitified is banking on this effect. The more willing people become, the better enablers they become which supports current and future manifestations of enshitification.
As an enshitification resister, I have the burden of writing paper letters instead of email or web. It’s comparable to resisting cigarettes to not be conditioned to accept a filthly environment, but with more effort.
The fix
I don’t see the onslaught of enshitification being fixed. Software quality is worse as Ada loses popularity. But I believe if more people would read Tim Wu’s Tyranny of Convenience essay it would perhaps get more people to loosen their grip on convenience and the addiction thereof. The grip on convenience is a death-like grip as enshitification enablers refuse to acknowledge their own role in it.
In any case, this needs to be studied. Enshitification will proliferate non-stop if we don’t gain understanding on why consumers accept it.
I don't think you know what enshitification is: the definition is very precise, and it's not the general worsening and increasing mediocrity of everything you're using it to mean. The latter is a consequence of the former though.
Everything they're complaining about with Lemmy seems like the opposite of enshitification. The developers made Lemmy, a massive project, and missed a few use cases that they can go fix. There's no worsening of anything, just a lack of development time.
The thing with enshitification is, it only happens when money and greed are involved. I'm not sure exactly how Lemmy elicits massive revenues or greed. So it simply makes no sense.
But since the OP means that it's getting worse - or it's not getting fixed because people are trained to not give a fuck, I can only say one thing: if you want to make it better, you're welcome to contribute to the project. That's the beauty of open-source 😉
I’ve noticed a recent phenomenon of (youth?) advocating for coding without design, implementing without discussion, to such a cavalier extent that they would interrupt a discussion about design and try to order people to go off and build it. It’s particularly bizarre in the context of bugs because if someone creates a patch without discussion, they are taking a rather foolish risk of wasting their time and having the patch refused. Then what? Rage fork? Over a simple patch?
As you can see, the bug is “not a bug” as people see it. So the patch would have had risky acceptance.
There is also a problem in the assumption that the tester has the skills to fix the bug they report. It’s quite bizarre that people assume that someone who can find bugs must be able to code in the language of the software under test.
Dude, I've been contributing to open-source projects for the better part of 40 years, and I'll tell you one thing: the kids who can't code learn how to code when they want something done. And if they can't code, there are other ways to contribute to a project. You can do testing, report bugs, artwork...
Encouraging people to contribute to an open-source project - or indeed any project - they would like to see get better is standard practice and is nothing new. It's not creepy and it's not cavalier, and it's not a way to shun discussion. Not everything has to be seen in a negative light you know.
So I'm telling you again: if you see a bug that should be fixed, clone the repo and get coding. Don't know how to code? Maybe you can try. Maybe it's not that hard. We all started out that way.
Or you can report the bug. Or you can add your voice to an existing bug report.
But if you wait for things to happen, you might wait for a long time, as those developing the software you enjoy also have a day job and other priorities.
They reported things, they're butthurt that nobody agrees with how they think it should work and are trying to blame it on enshitification making us dumb instead of acknowledging a fundamentally different view of how things should work.
LOL, exactly.
It is creepy to tell foss contributors what to do. It’s bizarre that in 40 yrs of FOSS you have not learned that each person decides for themself how to contribute and to what extent. You should read the Debian project guides.. you don’t impose or push work on people. It’s a core principle.
And I’m telling you, fuck off. I am up to my neck in FOSS projects in languages I am productive in. And you’re telling me to push aside my productive work, learn some shitty language that I find annoying and blow time getting familiar with a codebase I’ve never looked at. All at risk of creating a patch that NO ONE WANTS. What shitty misguided manager you have appointed yourself to. You’re fired. Go mismanage someone else.
Read the links. The bug has been reported. Don’t like where it was reported? Read the sidebar.
If you've ever used a piece of free or open-source software, that's exactly what the author(s) and the contributors did. If you don't want to do that, that's fine. You don't have to be nasty about it.
In fact, I'd argue that if you haven't paid a cent for the software someone wrote, or the service you're using - which is almost certainly your case with Lemmy - and you haven't contributed to the project, you kind of lose your right to complain this loudly about it. Don't you think?
People who ride a high horse really shouldn't ride somebody else's horse.
Testing and reporting bugs is contributing. Full stop. Absolutely asinine to frame bug reporting as a privilege exclusive to those who spend money on a project. It’s to advocate for bug suppression and reduced quality. Bug reporting is an important part of the QA process and it’s foolish to limit that in any way.
The underlying deficeit here is the mentality that a bug report is somehow someone demanding a personal service. A bug report & potential fix is not for the reporter. It’s for the community. Bug reports are community reports, for and by the community. If you fix a reported bug, the person who originally reported it often worked around the problem and moved on by the time the fix is released. The fix is for future users.
You didn’t read what you’re replying to. The post explicitly stated Lemmy is not an instance of enshitification. The user reaction to Lemmy bugs demonstrates how enshitification has conditioned people. The bugs are simply bugs.
Oh I read it. You state Lemmy isn't enshitified, but then spend hundreds of words trying to relate issues with Lemmy to enshitification. Whether it's your intent or not the body of your post ties parts of how Lemmy functions to enshitification.
It reads like you're upset people disagree with your thoughts on how things should work, and you're trying to say it's all enshitified.
Admit it. English is not your mother tongue. Reading it and comprehension thereof are two different things. Yet you still struggle with comprehension after being explicitly told there is no language or cause correlating Lemmy with an enshitified product.
Ah, good ol' ad hominem attacks. Yes, very well thought out rebuttal.
Counter: Maybe, based on the multiple people who have commented so far, your message isn't being communicated clearly and people disagree on what it communicates.
If you see ambiguity in this direct quote, I cannot see how you can simultaneously be fluent in English:
How could I have written that more clearly?
Sorry to say it’s not an ad hominem. Not everyone has English as a first language and when your display of lacking comprehension manifests it’s not an insult to have (or be regarded as having) a different 1st language.
I was born in the US to a family who's been here for generations. I have three years in debate. I have spent years developing data interface tools for customers and working with user feedback. I understand English.
Saying I must not understand because I don't understand English is a prime example of an Ad Hominem. You commented on me instead of what I'm saying.
I understand fully you stated "Lemmy is not enshitified". I also understand fully that the rest of your post reads like you disagree with your own statement.
Your post effectively reads like this:
The effects of enshitification are becoming apparent. Here's issues I have with Lemmy. I think all bad software these days is the result of enshitification and thus the term should apply to modern software issues. This means Lemmy is enshitified by transitive property. Enshitification is modifying what we accept as the norm.
You are free to make the claim but the mere claim doesn’t do much for you when you’ve demonstrated the contrary.
I’m not easily convinced that someone w/3 yrs in formal debate would improperly identify an ad homenem, build a strawman and then try to double down on it when called out.
You do not get to tell someone else what their position is. That’s their job (exclusively so). It’s broken logic and it’s inherently indefensible. At best, you can try to excuse your error as an honest mistake by explaining what exactly triggered your misunderstanding (you did not quote). So you’ve failed on that too. The blind vague claim of inconsistency is useless here. It’s a futile attempt because even if you can find an inconsistency, it’s still a strawman in the end.
Exceptionally, someone w/3 yrs in formal debate might falsely restate my stance if attempting intellectual dishonesty -- a deliberate use of broken logic on the gamble that others won’t spot the strawman.
You’ve been explicitly told in plain English (and re-told) that Lemmy is not enshitified. If you still cannot absorb that at this point, plz fuck off. You seem to have little hope of grasping how the Lemmy bugs support the thesis that enshitification alters perceptions of bugs.
And? This seems like an incomplete argument. Do users accept software that disregards user instructions? Do users accept software that misleads or misinforms them about execution success, such as message delivery? Do you regard s/w that disregards user instructions or s/w that misinforms users as having a defect?
Speculation about not having English as a 1st language is NOT an ad hominem. People are not inferior for having a non-English mother tongue and it’s despicable that you would take this position. It displays a superiority complex.
My statement “To be clear, Lemmy is not enshitified” was included in my original post to mitigate the potential for those who legitimately lack the ability to pick up on nuances of the points. Your failure to grasp how the Lemmy bugs relate to the thesis suggest a comprehension impairment, most particularly after it has been explained and re-explained to you.
You might try making this “understanding” coherent and comprehensible with supporting direct quotes.
(enumerations added)
Thanks for writing that. It exposes your comprehension malfunction.
① correct
② correct (Lemmy has issues but you don’t understand how the Lemmy issues relate to the thesis)
③ brain malfunction - I neither said nor implied that bullshit. I /would/ say that some s/w and a more significant portion of service is enshitified (but “result” is also the wrong word).
④ brain malfunction and crux of your failure to understand the role of Lemmy defects in the hypothesis, which have no relationship to enshitification. The perceptions of people exposed to rampant enshitification as they judge bugs is what you have missed.
⑤ brain malfunction, sequitur from brain malfunction ④
⑥ correct enough - but important to realise that having bugs is normal. My hypothesis more accurately stated: Enshitification is modifying what we consider a defect.
I don’t roll with Cory Docterow’s coining of the term. It was a good start but I see the term much more useful in broader application.
Fair enough, I can ro-ro with that.