I have a suspicion that one of the reasons why FOSS tends to be Like That (user-unfriendly, often command-line only, difficult to set up and use, very picky about the environment it runs in) is because there’s a misalignment between the features that are most helpful and the features that are most fun to work on. like you know what’s really unfun to work on in a codebase?

• UI stuff
• UX stuff
• making sure the default behaviors are sane and work well on most people’s computers
• addressing new user pain-points
• fixing environment-specific problems when “it works on my computer”
• writing documentation and tutorials
• finding ways to minimize the tinkering necessary to get the software to work

but you know what is fun?

• adding new features
• increasing the complexity and depth of the system
• devs optimizing their own workflows
• making the system more robust or flexible for highly technical users
• fragmenting the ecosystem in various ways

and in my experience that first list is all things that FOSS tends to be bad at, and the second list is all things that FOSS very often does

I’m glad that a lot of FOSS has gotten very accessible at this point (GIMP and LibreOffice are great examples), but we definitely have a long way to go before FOSS adoption reaches a critical mass (year of the Linux desktop blah blah) and this might be part of the reason why

I also just think that once you’re immersed in a FOSS project, it becomes hard to understand which parts are confusing or unclear to new users, or which parts of the documentation need clarification or rewriting, or even which jargon should be avoided for the sake of clarity. the illusion of transparency becomes a real problem

so I think it might be helpful to have new users do the software equivalent of playtesting where they record themselves setting everything up for the first time so that the devs can see which aspects of that first experience are smooth and which aspects are problematic