Lots of valid points here and I find myself agreeing with a lot of 'em. And the ones I don't, I do see that it's not objective, rather, it's things I find my experience to differ on.
The tags in the post image, do have stories to tell, as do the previous slights against Free Software that we've seen on Cohost - even if they're "shitting on" FOSS, it is critical feedback, and I have been taking a read at what people have to say. Some of it is, perhaps, just loudly complaining about things that can't - or shouldn't - be changed or fixed about how FOSS is. But there are common threads in the Discourse™ about FOSS. I'm a Free Software advocate, and I support and prefer Free Software when given the choice, and recommend it to others when it's applicable and suited for their needs, and having a place like Cohost - a place away from misguided "free-speech" zealots and "free software cultists" - a place which is run by a self-professed "anti-software" group, allows some of these threads to rise and be considered, rather than stricken down.
I'm specifically hoping to take on some of the challenges that sit between "hobby-level coders creating FOSS" and "commercial, full-scale operations supporting FOSS", by reaching out to people, and putting together teams of non-coders and coders alike, to support free software and its users. Rather than the corporate "Embrace, Extend, Extinguish" playbook, which time and again leads to corporate capture and undue influence on independent projects (AOSP vs Linux/OpenJDK being a recent example, but also Nokia/Trolltech/The Qt Company, and Qt) - we hope instead, to embrace the broader user and contributor community, extend an arm to the users and developers who need it, and empower the Linux desktop user, by making the experience better, and setting a good example for FOSS projects to follow. As a community of maintainers, we would sit in the middle there.
Perhaps my message was abrasive in the post (bottom of thread linked) you're probably referring to (judging by the words used). I'll be frank, I'm severely jaded by how abrasive the FOSS culture and OSS developer hierarchy have been to me and my coworkers, friends and acquaintances, that I don't feel it's off the mark to say there's a problem, and be loud about it. And I feel the same from your post, that you've seen how capitalism takes advantage of people in the FOSS community overall. That is not lost on me, either. I've seen people put through the Amazon skill-laundering defeat machine time and again. I live on Long Island, New York, and have been jobless here since the start of COVID; it's a runaway capitalist hellscape all around here.
What it comes down to, for me, is that, just as there are people who want to, or can, contribute their time, skill and resources into code, with no expectation of payment, only the guarantee that their contributions are open-source:
- there are also people who cannot contribute their time, or cannot afford to, especially if they are not expecting to be paid for it - they would prefer to pirate Windows, and deal with a system broken in "known" ways, than to troubleshoot a system broken in unknown ways, deal with a bug report, write a patch (if they can), talk to a developer who may be jaded against them for reporting, potentially deal with abuse or flamewars over it, and then either have their problem fixed by the end of it, or just deal with it - "as-is, no warranty," etc.
- there are people like me, who also want to - and do - contribute, for free, but in the non-code segment of a FOSS project. Graphics, documentation, people skills, management and moderation, triage and resolution of issues, direction and governance of projects, and leadership of teams. This isn't rare, it's more of an issue that the people who do all of these things, are usually not doing it for FOSS, and certainly not "for free", or in ways that don't show up as worked experience on a resume, or green squares on one's Github. And the ones who do it for free, are presumed to be doing it for power or control reasons, which is a whole nother can of worms.
Some projects, however, manage to balance these two competing factors, and provide a good middle-ground, where an active community welcomes new, non-technical people, rather than "expecting" them to open shell windows and obtain logfiles before their first post.
I take the example of Haiku, the operating system, and Haiku, Inc., its backing corporate (501(c)(3) NPO) entity. Haiku developers are by and large people who contribute small changes, file bug reports, and do their work for no payment from Haiku Inc. However, some folks, who contribute very forward-moving components or changes to the Haiku codebase, are compensated for their work. And the infrastructure (servers, hosting, services) is paid for primarily through that medium, as well. It is strictly capitalist - money goes into it, revenue is disbursed in a corporate budget - but communitarian in nature, and under the structure of a non-profit organization.
Another good example, perhaps, is the community around ArchLinux, in particular its documentation. The Wiki often has clearly laid-out, step-by-step instructions, despite the technical and fidgety nature of ArchLinux overall, for both common and mundane, as well as esoteric and novel usecases, hardware, diagnosis, and known issues.
What I'd like to do for styx, organizationally, is one step further than this - taking to heart your ideas on other posts on community-oriented self-hosting, and shoring together a collective governance structure which emphasizes improving the quality of one another's contributions, lowering the bar for entry, and making every change count.
I would like to see small groups within and around this project, to assemble, and be able to work together on bettering not just styx and its software, but Linux and FOSS at large, as a whole. Not in the invasive "systemd" way, but by providing developers with well-triaged testcases, bug reports and even patches with fixes, and - in the event the upstream developers are not cooperative, we'd maintain forks which fix these specific issues.
I'm going into this with the understanding that usually, one user, by themself, won't be very successful at making change happen in a software project unless they understand the codebase, or the developers' own motives. It usually takes at least a user and a developer, and others in the project, to work towards a resolution.
We hope to grow a substantial userbase, by maintaining and packaging software for styx, enabling others to do the same, and to overall be a good steward to the community, for finding, reporting, and measuring issues in software and software maintainership, and making the experiential basis of a Linux operating system feel a lot less hung-up in its own ways.
And what if we don't? We would've still made an OS, and at least some people may follow our example, if not lead by it, as many now-dead FOSS projects have done.
Anyway, I didn't expect to write so much, but here we are. 😅
Thank you for being critical, though. Your explanation of what exactly I missed out on, did help me understand a bit more about what it is that makes the FOSS community overall tick, and why sometimes that does fall short, both for users and for FOSS developers and others on the project. It is going to be hard work, and I sometimes do need grounding to realize that no, not absolutely everyone is on the same page, and the reasons for that are valid, and many of them addressible, too. I just know that I can expect it to be hard work, and that I should do better to take into account how that impacts people who do the work on software.
Not having to fight the computer? That's a software problem.
Not having to fight the software? That's a project problem.
Not having to fight the project? Well, that's going to need an umpire, or a referee, and nobody wants to be the referee - but sometimes we all have to step up - hell, sometimes I have to.
Because it's become a people problem, and nobody wants to fight the person.
