@riverpunk I've been thinking about this from a slightly different angle for a while:

It seems to me that the principal way the *vision* behind the OG free software movement failed was that it didn't conceive of there being people who *would not be interested* in becoming hackers if given the opportunity.

So, when the original movement achieved its original goal (this happened circa 1997) they didn't know what to do for a follow-up.

@riverpunk cease the means of prediction.

I can grasp how one is anti regarding the big labs but pretending like this tech is not useful is where I desync.

@riverpunk Improve open source gender equality by making it a welcoming place for everyone instead of a welcoming place only if you're willing to tolerate a ton of harassment.

@riverpunk developers should be more visible, and I'll break down what exactly I mean by that.

I've worked as a developer and more recently as an artist. When developing software, outside of a few "celebrity" personalities which users probably at best only know by name, users primarily just use the software.

This is not how indie art scenes work. In many art scenes, watchers know the artists working on the art they consume. Not as celebrities! They know there is a human/critter making it.

@riverpunk Do more of "user driven development", because what the users think is the only thing that really matters in the end.

I am not a huge fan of the "X–driven development", as they are unfairely used to increase control (of users and/or developpers), and to maximize profit. But I do think the idea of always prioritizing end-users is an essential concept for an app in order to be nice, easy, and enjoyable.

Mostly, I think many OSS fails at the very first step: "identifying the users".

(edit: that being said, dev should also enjoy developing the software, I understand it can collide with users' expectations sometimes – not sure it applies to big projects though)

@riverpunk write software with the explicit intent of freeing the people. this requires a lot of things itself:

• documentation. don't document just the code, document the while architecture, write guides about how you work on the project, do walkthroughs of your thought process when you fix a bug or add a feature. obviously, don't push away people who are asking something that's in the documentation, as it could mean it us either hard to find, or hard to navigate.
• if support for a platform that doesn't free its users comes at little cost on your side, prefer supporting it, as that means people stuck there can still be partly freed, rather than well and truly stuck
• use tools with compatible ethics where possible, otherwise your entire project could be gobbled up, or at least crippled

special awards section for folks who can talk about projects that ought to exist but don't (or they do exist, but they aren't properly serving the need that exists because of some design failure or similar).

Here, I'll start with something (perhaps I may share more later, too):

Developers need to listen to their users, especially when it comes to UX.

There was a tendency in the old school of open source in which programmers kind of had this attitude that "if you don't wanna learn how to be a terminal wizard, you deserve to be spied on by Facebook" because you don't know what PGP is. Or that if a user thinks Linux apps are hard, the response was often to scoff and tell them to "git gud", instead of actually just making the program easier to use.

I'd like to see developers more and more accepting the idea that in order to make a real impact, we're going to need to develop things that can actually be used by a general audience.

@riverpunk
I'd really like them to work a hell of a lot more closely with domain experts, I think. Librarians, social workers, union activists, journalists... the people who are important in maintaining a robust civil society.