Software for programmers vs software for normal people

I *also* think that maintainers, in general, don't get enough thanks for the work they do, in general. It's tough, usually underfunded, and unappreciated work. And decisions need to be made.

But the better projects encourage their users to learn to be participants, empowered.

I feel like it’s a corollary of Conway’s law: if you build an autocratic or a corporate structure around your software project, it may be free, but it won’t encourage user participation, possibly not even in the form of allowing for customization, “unofficial builds”, and so on.

It also looks like there’s a discourse by “professional developers” that we should do away with that utopia of putting users in control, when we professional know users don’t understand a damn thing and are going to break our product.

I haven’t read it but I think this is what they meant by “the cathedral versus the bazaar”, right?

I feel this even as an experienced programmer sometimes, most often when it comes to asking questions about build process. "just use our prebuilt package" "why would you want to do that?"

FKB projects also tend to become closed or semi-closed (open core).

I like where you are going with this and am curious if you could unpack more by giving specific examples of each and how things play out from the user's perspective.

"Participatory Software" is a great phrase. So much of what I'm doing right now is predicated on this idea that participation is the only path forward for culture, just generally.

Creative Commons has variants which prohibit derivative works and commercial usage. Playing devils advocate for a moment, one could make a partially open license for those who wish to freely distribute their source code without allowing the user to tinker with it. I'm not saying I'd ever use a piece of software with such licensing. It's more that at least that way it would be more clear that this is a project to stay clear of.

I agree. It doesn't start and end at programming languages, but that's a very visible area... especially as a programmer. Sadly what Emacs has lacked is getting itself out there and being something users today can really embrace and use, and that's just as important. I'd really like to see more work go into Mousemacs and Guile Studio, the way Spacemacs has.

Blender is an interesting example of software which is extremely extensible and at one point was considered really "hard" to pick up but... those complaints don't exist as much any more, partly because things *have* gotten better, more familiar, without a real loss for experienced users. Geometry nodes are also a great example of something empowering that's accessible to people.

The only compalint I'd make about Blender these days is that dropping the colors on icons was a real loss. But that's hardly just Blender, they're reacting to the times of design.

Wait, how is C more free than Python.
Also, this is old news, but Lisps letting the developers create entirely new languages for each project is not necessarily a good thing.
As a practical example: I could write and test a patch for Yggrasil in about 2-3 hours that added an extra CLI argument, with practically 0 experience with Go or the libs it uses.
If new users can't make sense of the code, then it's not "user participatory".

I've understood more code in Guix than I've understood in any other project in my life.

The whole "lisp isn't possible for users to understand" is a myth.

I should say, any other project I didn't start :)

Guix does restrict what parts of Scheme it uses, like functional purity being somewhat enforced.
To clarify, I do think lispy syntax and most of the semantics are pretty good, but it's not true that a completely unrestricted language is optimal for users. Also if the language is too dynamic, the compiler suffers and users with cheap machines suffer.