“The slow evaporation of the free/open source surplus”
https://www.baldurbjarnason.com/2024/the-slow-evaporation-of-the-foss-surplus/
Where I try to explain, as succinctly as I can (which isn’t that succinct), why I’m worried about where FOSS is heading
@baldur another factor I have observed is that COVID and lockdown changed people's attitudes toward how much nonsense they are willing to tolerate. this has an impact both on projects and the software itself.
projects previously got away with onerous procedures and odious personalities being involved in the contribution process. people won't slog through it now.
the change in user attitudes has, for the most part, not been matched by a deeper focus on QoL bugsquashing and low-friction UX.
@baldur the demographic who are deeply invested in FOSS as a philosophy are generally still willing to make that trade, as they always have done. in practice, however, the majority of users are more casual fans of FOSS, who will seek out alternatives more quickly when things frustrate them, and who will accept commercial alternatives that are more comfortable to use. when the bar for frustration shifts, but the design philosophy of the software does not move to match, those users leave.
@baldur there are examples of projects that have made a concerted effort to solve these problems (KiCAD comes to mind, running user surveys and then acting on them rapidly) but they are a minority.
my personal view is that this is an endemic cultural issue that has plagued FOSS for decades, but I don't have the energy to get into this because it inevitably leads to tedious reactionary defensive responses.
@gsuberland @baldur Don't know that it's worth much, but if it helps: I agree on all of this, and it has been frustrating me for over a decade.
(And I've experienced the same active resistance to changing that culture, too...)
@joepie91 @baldur the core problem, as I see it, is a culture of code being lauded as the be all and end all. writing code is directly equated with creating software. if you're good at writing code, you're smart, you're useful. if pushed to explain what else is involved, folks will mention documentation and maybe community management. if design is mentioned, it's exclusively about architecture, not about experience and usability. as a result, well-designed user experiences are vanishingly rare.
@gsuberland @joepie91 @baldur could I ask you what I as a contributor/developer for OSS projects can do to improve things (even if that change might only affect a tiny amount of people)?
@tsrberry @joepie91 @baldur the answer to that heavily depends on what kind of project it is, who the users are, and what scale it operates at. if it's a small CLI tool developed by one or two people and used by a handful of linux sysadmins you probably aren't running into many UX design pitfalls. having really good docs is nice, having error messages provide context and guidance helps, being welcoming towards contributors and not needling them with endless style changes is very helpful.
@tsrberry @joepie91 @baldur if you're operating at a larger scale (especially on gui tools) then running annual community feedback campaigns is a huge winner. make it a simple survey form - minimum friction, maximum response rate. people will tell you all the things that have been bugging them but never got around to opening an issue for. commonalities in responses will help you direct your efforts and make a lot of users happy with relatively low effort.
@tsrberry @joepie91 @baldur but ultimately at that scale you need input from actual designers - people who really know how to make a good UI/UX, and who can tell you what you can do better. that can be direct, by getting designers to come help with the project and help come up with better approaches and workflows, or it can be indirect feedback. and be humble. don't get defensive because you're attached to the project or it'll be work to fix the issues. it's hard work to do it right!
@gsuberland @tsrberry @baldur One thing I'd want to add to that is that if it's not feasible to find experienced designers (funding reasons, community politics, whatever reason), it *is* possible to just learn how to do this stuff yourself on-the-fly as a maintainer, but it makes the "be humble" part all the more important, and to make that work, you *need* to have an attitude of "if a user complains about something, that means there's a bug, even if it's not where the user thinks it is" (eg. it might sometimes be a documentation issue instead of a UX issue, but as long as people complain, there's *a* bug somewhere).
@joepie91 @gsuberland @baldur Thank you both, this helped a lot! :D
I'll note these down and try to do my part!
@gsuberland @tsrberry @baldur Also, related to the 'user surveys' point - it's surprisingly helpful to just enter your project name into a search engine every once in a while, and read every blog post, Reddit thread, and rant you come across. Those tend to be *full* of things that never made it into 'properly filed' issues, and give a good impression of the general atmosphere around your project, because people tend to speak more freely and directly.
Of course that does mean that you should refrain from responding to them unless you are absolutely 100% certain that you can do so non-confrontationally, because seeking out confrontation with people talking in their own spaces is (deservedly) a very quick trip to the trash pile. Better to just take notes and work on fixing their complaints in the background.
(Bonus points: you can do this one as an 'unaffiliated' contributor with no formal power within the project. Whereas a proper user survey, although it can have better coverage, tends to require speaking formally for the project.)