How do you, or do you vet if a software will paywall features or "enshittify"?
-
I like to see companies design their software such that their main financial incentives are tied to the quality of their product. This usually involves being open source; if someone can fork it, your paywalled version better have extra features that open source people can't make easily. I also like to see them trying to avoid vendor lockin; if it's easy for you to switch, then they need to actively work on not letting that happen.
For example, Bluesky. They have an open protocol and (I think) you can easily transfer data between instances. If they start fucking people around, you can just jump to another ATProto app.
For Kagi, the only thing you're paying for is search... So if they fuck that up, you can just crawl back to DuckDuckGo.
Obsidian is an interesting case. It's not open source, but the files it works on are just markdown. If they go totally wild, I can just easily switch to VSCodium to edit my files.
-
For example, Bluesky. They have an open protocol and (I think) you can easily transfer data between instances. If they start fucking people around, you can just jump to another ATProto app.
I've never touched bluesky but everyone on Lemmy seems to be constantly saying that there are no other instances
-
it's basically the exact same thing as i've seen with IRC, people keep saying it's decentralized and then when asked to show an example they just go "yeah well uhh obviously it's not externally decentralized duhhh! It's
internally decentralized" which just means they protocol makes horizontal scaling easy.. -
You dont.
Obviously copyleft license and stuff that embraces FOSS is great, but open source licensing doesn't bar the key developers paywalling features. You just have to avoid building digital systems around a single point of failure where possible.
-
They took all the momentum from the community and put it behind a paywall. It used to be that you could use the whole thing for free and only needed to pay for support, but now you need to pay for subscriptions. Red Hat blocks access to the package repos entirely without a subscription (though it is free in certain cases) and Ubuntu pushes the Pro subscription at every opportunity and requires it for certain security updates.
-
Nobody seems to be putting the effort into making ATProto federated apps, sadly. The main people who would do it are also the type to stubbornly stick with ActivityPub.
-
Enshittification is built-in to Capitalism, the Tendency for the Rate of Profit to Fall forces it. FOSS and whatnot is safe.
-
I think i have 3 big criteria:
- Track record
- Structuring things to pre-emptively keep themselves (and more importantly, those who might take over later) honest and aligned with the collective good
- Good people involved and ideally in charge of the project
Other people have mentioned things like venture capital and that's certainly something to bear in mind (arguably part of the structure), but there are projects like Matrix where that feels quite marginal to me, the aforementioned aspects more than make up for it.
Like when the main figurehead of the project goes on stage and nerds out about the code, that's a pretty fucking good sign in my book. -
Ability to export data to a relevant, open standard. If I can jump ship at the drop of a hat, then I'll consider it. I won't buy if I don't have that power.
-
There are, but as long as 98% of the userbase is all on the main instance the decentralization provides little protection from the whims of corporate.
-
You can never be 100% sure, but there are protective factors that make it less likely, and they mostly boil down to incentive structure:
- Ownership - Is the project run by a non-profit? A for-profit company? A hobbyist? This is the best indicator of a project's long-term trajectory, because it generally indicates the purpose behind creating it.
- Business model - How does the project make money? Donations? Subscription? One time payment? Generally models where you can outright purchase a copy of a particular version is insulated against future updates you don't like. Donations protect against exploitation, but run the risk of the project being unsustainable and abandoned.
- Source - Open source code isn't a silver bullet, but (especially with good licensing) it can make enshittification less likely as it's a lot easier for dissenters to spin up a fork / competitor. It also makes it very difficult to hide sketchy stuff like data collection and back doors.
- Red flags - You should avoid anything that is SaaS, backed by an investment firm, or publicly traded. All of these involve incentive structures that encourage and reward exploitation of consumers and employees for increasing profit margins.
-
Google puts in more development power than anyone else. Any forks we’ve seen so far are only really soft forks, as in they only apply a few patches on top of what Google puts out, rather than taking the project in a new direction, because you’d be behind pretty quickly.
Ok, but what's stopping them other than a lack of desire?
Partially, it’s only financially viable for Google to develop these projects, because they have those Android ads or benefit from a web with less tracking protection. This makes it extremely unlikely for any other organization to be able to splurge a similar amount of money, which brings us back to a fork just being unlikely.
I'm kind of skeptical of this idea. FOSS has almost always been able to succeed in the long term despite having a small fraction of the development budget of proprietary software, often due to the passion of weekend devs essentially donating their time to the cause. Whether it's Linux, Blender, Gitlab, Godot, Krita, etc., I can't think of a single FOSS project that has funding anywhere near the same level as their corporate rivals.
-
I don't get it... What is Ubuntu doing to enshittify their operating system that you can't mitigate through source modifications or switching to another free OS?
Unlike Windows and Mac users, if my Linux distro does something that I disagree with, I feel that I have plenty of power to do things about it on multiple levels. I left Ubuntu years ago, but there are plenty of things the community can do to make things better without relying on Canonical to do anything at all.
-
I'm not familiar with either of those projects or what you mean by "that stage", but why can't you and the community around them just fork them and continue development in a way that you prefer? What's stopping you?
-
Just because you can work around it doesn't mean it's not enshittification.
-
You're avoiding the point: when you have the source code, the ability to build it yourself, and the right to continue community development in any direction you want, there is nothing that a company or any other entity can do to make your experience worse.
If I don't like the direction of Lemmy, for example, there's nothing that stops me from forking the last known good version and continuing to use/develop that myself for the rest of time. It's fundamentally different than if you're someone who uses Reddit, for example, and you're 100% beholden to the whims of what the developers decide. That's the point I'm making.
-
Yes, but that's no longer Ubuntu, and it takes a lot more time and effort on your part to maintain your fork. That's not sustainable, especially if it happens to multiple products.
-
Look for escape hatches. I run a self-hosted Cloudron server. The software I host on my home server is FOSS via Cloudron, but Cloudron itself is a service that keeps each of the FOSS apps up to date with security upgrades and data migrations when necessary. It's a huge boon to running a self-hosted server. But when it comes down to it, they could potentially close up somehow (new leadership, get bought out, shut down etc.) They've left an escape hatch though--you can bundle and build your own apps, with a CloudronManifest.json etc. This would allow me to continue to run and update software if I absolutely needed to, without their support.
-
There are various obstacles to "just forking" a project; it requires times to understand the frameworks / libraries used in the project, understand the code and its different parts and last but not least, have a interest to invest that time and energy (most often, that time could be spent developing your own solution that would fit your usecase better).
As for the stage I was referring to, both the theories of enshittification and rot-economy see software and services going through stages to attract new users, before going in for the profit maximizing.
-
This is absolutely the answer. If it isn't funneling money away from actual value creation and into their pockets, it's evil in the mind of the investors.
