@SuricrasiaOnline I think there are some possibly not terrible ways to pile abstractions higher, like algebraic effects, or using advanced type systems and basically letting a constraint solver figure things out, but uuh, they aren't very mainstream. Weirdly enough, champions of simplicity like the Plan 9 community also produce some fragile code, like all the undocumented requirements on inputs. Basically everything breaks if you have spaces in file paths.
"The most important difference between a jail and a home is who controls the lock on the door. Most smartphone companies want you to believe that the gilded jail they’ve designed for you is the safest place to spend your time. Precursor takes a different approach. By giving you the keys to the lock, it gives you a home." https://www.crowdsupply.com/sutajio-kosagi/precursor
@hypolite@heluecht@z428@witchescauldron@cketti re: "Do what you can" That's pretty much what I said, just focused on the communication aspect. 🙃 Like you said, "do what you can" should also be taken to apply to non-code contributions, including writing docs, helping out on issue trackers, and keeping the community healthy. If it improves things, it's worth doing.
Like, you write a two sentence update every so often and maybe add a sentence to the readme, and it lifts the pressure from you. Worst case scenario you wasted 10 minutes writing it. 🤷
@cketti@z428 Also maybe I underestimate people, but I don't think developers have a clear perspective on how well regular folks understand how software projects are developed. Realistically, just complaining about their lack of understanding won't make most of them understand. The most effective way to make this information reach them is via the channels where they read about updates and docs.
@cketti@z428 Re: > that's on you I find that assigning blame is less useful than trying to figure out how to avoid the problem. 🤷 No one claimed anyone is being tricked, the point I was trying to make (maybe badly), is that it's possible to communicate issues in advance, before they pile up.
And yup, it's not specific to FOSS, all projects should be transparent about their sustainability. That only reinforces that issues should be communicated in advance, whatever their nature may be.
@cketti@z428 IMHO preventing contributor burnout is a more important problem than treating it after it already happened, simply because prevention is nearly always the better solution to any given problem. If the dev feels like they are expected to do free work, they can lessen the expectation by telling their users they can't work on the project, instead of working on the project until they burn out.
@cketti@z428 Adding a simple sentence to a readme is not a lot of effort. 🤷 Nor is writing a short "hey i'm having difficulties, don't expect a new release any time soon". And no, that's not why I'm asking. *I* understand software development. A random person who downloads [insert software name] from a repo (or even from an official project page) might not. I hoped that was clear. Devs and users alike are not exempt from societal norms or having to communicate and listen.
@z428@cketti The harsh reality is that people might depend on the software, so indeed in that case just saying "thanks" and moving on is not the best option. Someone has to pick up the mantle.
@cketti@z428 Well, it has a bit more layers than that. First, the user might not be aware of the risks. The license is not enough IMHO, after a certain adoption threshold, if the readme doesn't communicate the (lack of) support or stability, then the fault partially lies with the project lead(s).
It's like feeding birds. If they get used to it and then you take away the bird feeder on a whim, it's not the bird's fault. Obviously that's an exaggeration, but hopefully you get what I mean.
@cketti@z428 This isn't an all-or-nothing problem by the way. There are a lot more options than just "enterprise level support" and "project developed for the lulz and abandoned out of the blue".
Like, if the dev is burning out, they can communicate that before they completely give up on the project.
@cketti@z428 To clarify, the situation described in the OP is bad, I agree, having users shout insults at a burned out dev is bad and it should avoided. But there are multiple ways to avoid it.
#Agile class is really weird because there are a lot of ideas in it that really resonate with me and echo ideas from #anarchy , but it's always in the context of generating revenue for whatever megacorp is your employer, and by extension also to its shareholders. Like, we had a whole lecture about #Spotify agile, which basically boiled down to: "workers can get a bit of anarchy, as a treat, and only as long as they help us build our monopoly".
@schmittlauch Not sure if they have open positions, but Element employs a few folks with P2P backgrounds. At least one Yggdrasil dev is employed by them.
@opfez So I haven't had many chances of actually *using* knowledge from it, but Ezermester Magazin is amazing. It started in Hungary back in the 50s or 60s and has some great detailed tutorials for DIY things. I think they're still going. We have a few dozen physical copies at home but also their whole archive is freely available online. "Ezermester" literally means "thousand master", or "master of a thousand trades", but the less literal translation would be "handyman".
I wonder if Comradery would have these issues. They seem to be caused by Patreon being an overly complicated mess and not loading some things properly unless every privacy preserving addon is turned off, but possibly not even then. I gave up after the dozenth attempt.
@strypey My 2c: Personally, I would still choose "the West" / USA over Russia or China. It's good to criticize all of them, but it's pretty foolish to pretend they are all equally bad. Heck, Russian and Chinese citizens can't even criticize their own governments.