I am drawn more and more towards simply "communal software". It is simple and to the point without needing to bring in a lot of loaded political baggage. Sure capitalists might fund some of it, but I think it would be significantly more difficult for capitalists to co-opt "communal software" than the nebulous "open source" which has had its meaning intentionally diluted and stretched to absurdity.
@be "Software of the Commons" to directly invoke the Tragedy of the Commons? Doesn't exactly roll off the tongue though.
@splatt9990 I think "commons software" would be too easy for corporations to co-opt for precisely that reason.
@lightweight @be @splatt9990 Yesterday, I went on a bit of a rant about this same topic (https://social.finkhaeuser.de/@jens/105943742804743427 if you want)
I'm all for "communal software". What I'm more concerned with, though, is how we define that.
Problem is, I *like* the four freedoms, I just don't think they are enough. The "communal" term suggests the right direction.
I struggle a bit to define the necessary other communal aspects in a similarly concise form.
@lightweight @be @splatt9990 I figure the UNIX approach of one tool, one job is closely related to the "toolkits over frameworks" kind of thinking. To me, both enable freedoms because they allow much more varied re-use, being less prescriptive to users.
But it's hard to put them into a license - not that I particularly want to - this would have to be more of a manifesto. And then it's still a fuzzy enough thing that people can interpret it differently.
If I start with the idea that engineering is political, then engineering has to aim for certain goals, in the context of our conversation here communal goals.
I do think that there are more exclusionary engineering practices that have nothing to do with unsound design; one is to subsume a lot of separate concerns into one system.
@jens @lightweight @splatt9990 I generally agree with you that our motivating principles and the real world impact we want to have on actual humans should inform the technical decisions we make. But I don't think any particular techniques of accomplishing those goals should be coupled to a political philosophy. So I think your point works better as an abstract principle rather than a specific prescription of "this is the best way to design software".
That's essentially the difference between toolkits and frameworks, which is leading in deciding how something is used: the user (toolkit!), or the software (framework!).
I think this discussion digresses a little bit, though, fun as it is. Communal software sounds good.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.