everything wrong with free software
"obedience breeds foolishness"
*originally posted:* jul 2021
*updated:* aug 2021
along with (and even towards the goals of) socialised computing, i think it is worth striving for "super-free" software.
how can we do that? free software has a distinct definition, and super-free software does not yet. but the idea is a subset of free software (super-free software must AT LEAST be free software) that better ensures we have MORE of the freedom that free software is meant to give us.
there are also some things that have made free software "less free"-- and rather than a solution looking for a problem, super-free software tries to address a number of problems that free software has suffered from over the past few years:
1. "open source": open source is a corporate scam, and super-free software can recognise it as such. it may not be possible to avoid open source 100% of the time, but super-free software can do more to speak out against open source and its efforts to destroy our freedom on the installment plan.
"youre destroying our freedom"
"no we arent! we havent done that, have we?"
"no, but you keep trying!"
"i didnt murder him, hes still alive"
"yes but you tried to shoot him"
"hes still alive though, isnt he?"
^ these people are not our friends! theyre saboteurs, we dont have to trust their bullshit.
why start with addressing the bullshit that is open source? because this isnt a fucking game anymore, and its time people stood up to these liars.
standing up for free software means standing up to a corporate coup-- the coup is not a takeover of "open source", that happened ages ago. the coup is a takeover of free software itself-- of the real thing, not the fake "controlled opposition" version. as open source takes over free software, free software goes from being a real movement to a controlled opposition version of itself. anybody who truly cares about your freedom will fight this. fake people will pretend to, because thats how it works.
2. no free speech, no free software
super-free software CANNOT abide a code of conduct. i know that things SIMILAR to a code of conduct have existed forever, and it seems clear that the gnu "kind guidelines" are an effort to avoid a coc by putting something vaguely similar (yet different) in its place.
codes of conduct are more like zero-tolerance policies, which are leveraged against good people in bad faith and add to the censorship and corporate control of a project. theres no reason NOT to draw a line in the sand about this. super-free software isnt a standard, its a goal to strive for, and some projects are (unfortunately) going to have a coc. but just because it has one doesnt mean its a good thing.
the crusade to put a code of conduct on everything along with the idea that older terms of service and things like "forum rules" are the same thing are two things that really dont add up. the fact that there was a crusade to get a coc into every project adequately demonstrates that this is a change, and NOT "business as usual" for free software.
3. gratuituous interdependency is a bug
one straw man of people defending gratuitous interdependency is to explain what a dependency is. but the people who are complaining and protesting already understand dependencies, and the people making the straw man are deliberately missing the point.
consolidating every little thing into a blob with literally millions of lines of code is not "modularity", it is a takeover. it creates lock-in, and thats the goal. when big companies do this, they get more control over free software. there are two very unfortunate truths, but people need to understand these two truths (theyre not smears, theyre factual) about richard stallman:
a. he doesnt care about unix design principles-- he doesnt care about unix at all.
people might think because he chose the unix design for gnu that he cared about the design principles behind it. thats not true. unix was extremely portable because of its design, and that may have made it an obvious choice, but stallman has made clear (through words, not only actions) that these design principles dont matter to him. i think the actual phrase he was discussing was the "unix philosophy" but he is quite welcome to correct this regardless.
b. this includes systemd-- he doesnt have a problem with systemd, and he has stated this on his website, as well as in email.
people might think because systemd is a problem that stallman recognises it as one. roy lied about this on more than one occasion, fabricating things stallman never said on the subject. since then he has looked to present evidence for why his fabrication is not entirely inaccurate-- but it WAS entirely dishonest. it was simply made up. i verified that personally, and it is a fact that roy fabricated it, speaking for stallman.
i have spent years hoping stallman would speak out against this, but making it up doesnt make it so, and putting words in his mouth is unethical (and dishonest). people need to understand, when they fight takeover-by-design like systemd, theyre doing it WITHOUT the help of the fsf. the fsf (and stallman) DONT CARE about this. they never have cared-- ON THE CONTRARY, they have consistently shown a complete lack of understanding about it.
stallman INVENTED free software, and is the reason the tools taken over by red hat, debian and ibm exist in the first place. he deserves a great deal of credit, respect, admiration and gratitude. the smear campaigns against him were moral crimes. but we are still "on our own" if we want to protect free software from the sort of threat that systemd (and similar or related software) poses as a takeover (or corporate coup).
regardless of whether its always the best thing to do, freedom means you can fork-- everything that is getting farther and farther away from being forkable (or even reasonably easy to compile) is getting farther away from freedom. systemd is just one VERY prominent example. a distro that DOESNT stand up to systemd is barely free, if it can even be called free. but there are (and will be) other things like it.
you can rate them not by the code, but by the effect they have on users. your little project that isnt designed well and doesnt have to be compiled, and barely has any dependencies could probably become easier to fork, but thats not the point. there are big projects out there, going out of their way to gain and maintain control in a direction that is profoundly difficult to reverse. people tend to know which projects fit this description. either way, its a discussion that needs to be had among people that care about your freedom.
there are things that can be done to avoid this problem, and move towards super-freedom.
4. we need to teach people how to create software, not just how to use it
people that know how to create software can teach themselves how to use software. we should focus on the fundamentals of computing, not training people in fad-driven application usage like schools do to keep people using corporate solutions.
if teaching fundamentals is not enough, we should start there then move on to more specialised training.
5. corporations are not going to stop trying to take over free software-- we need to get further away from them
free software was a grassroots movement, we need it to be a grassroots movement again. whatever we build, it must not be dependent on corporate sponsors. theyre not our allies-- thats open source. for many, many years, i thought corporate sponsors and free software could co-exist. super-free software has to be grassroots, shutting corporations out the way that national elections used to.
of course, that makes it harder to do things. but with corporate sponsorship, those things that are hard to accomplish become easier in the short term, and impossible the long term. we need to see that equation for what it is, and realise that sponsors are willing to play the long game-- and not play with them.
this also means that "big projects" wont happen as often. that means we need smaller projects. its doable, but we are up against the tech press constantly telling the public (including us) that it isnt doable. it was always doable, and it still is. most of the most important innovation is done by small teams. at best, sponsors make it so those people dont have to go work on something mundane and can work "full time" on their projects. but so often, that promise is like ibm saying it wouldnt interfere with red hat. who actually believed them?
6. free software should encourage sharing by example (and direct but diplomatic advocacy)
modern copyright is excessive, and poses a threat to culture, free speech and free software. the freedom to use software and the lack of freedom to use other works freely are so often at odds, that by encouraging the right to use other works freely we can reinforce the lessons of free software. that was the idea lawrence lessig had, but the organisation he started (creative commons) doesnt stand for freedom of any kind. that isnt what he wanted.
the easiest way (by far) to have a robust culture of sharing is to encourage free licenses on other works, not just software. this should be done with diplomacy and understanding, because everyone is encouraged by a very corporate society to hoard the "rights" on their works, not to make them free. simply put, we should encourage that other works include the freedom to use, remix and share them-- and preferably in a way that is compatible with the gpl and agpl.
technically, the free software movement does not require this, and sometimes even discourages it. we can move in the direction of a culture that is more free, without getting permission to move in this direction. as with systemd, we are on our own with this.
7. communities should try to "own" (control) software less
while this does not (at all) discourage efforts to keep software free (copyleft is recommended for projects that people rely on, at least-- the fsf recommends copyleft for all programs with more than 300 loc and makes very few other exceptions) communities should work to create software that is easy to fork, with all necessary documentation and build instructions.
this is a major shortfall (sometimes even in violation of the license required) of many projects. if you want to fork debian for example, you pretty much have to invent a way to fork debian. that information is as important as the sources, but its difficult (and not necessarily desirable) to enforce this with a license. the gpl requires build instructions to be available (this is a good thing) and thats a requirement often not met. the broader issue of providing instructions on how to fork a project (ideally including anything specific to the project itself-- each project neednt tell you how to use tools like git, create websites, etc) should be something we strive for as a movement. not everyone is capable of doing a great job of this, so we can be understanding about it. right now there is too much apathy, and communities do tend to hoard or obscure (or leave out) too much information.
this is not just a moral ideal. we WANT software to be free, and ideally we would make it so that if we gave up on a piece of software, someone else could just come along and pick up where we left off. communities vary widely in the help theyre willing to give people-- this isnt about making it a requirement (thats too large a promise) but about setting a higher goal for the movement. this applies as much to smaller projects as it does to gnu/linux distros or flavours of bsd. schools are never going to teach how to do things the way we do them, so its up to us to help more people get started if we want more people to understand all of this. and the more people understand this, the more people will support our movement.
8. software needs to be more modular
#3 is about not being too monolithic, and thats about a threshold of absurdity (with systemd as an example). this is basically the same issue, but from the other side-- take debian for example.
the way debian is put together is more monolithic than it needs to be. the whole concept of a distribution (in monolithic terms) is absurd when we have so much free software available.
in other words, it shouldnt be so difficult to just create an image, add a bootloader, add an installer, add a package manager, and start compiling things. usually this is done as a "distro", but today we are seeing more installers and package managers that arent distro specific-- and if installation and package management can be non-distro-specific, why shouldnt the entire distro be? this is something ive been saying for years, and ive manipulated enough distros to be confident in saying its possible. its not like this yet, because distros were made the way they still are due to constraints that no longer exist, but people would rather just create a distro and not make it so easy for someone else to come along and do it a bit differently.
a distro is a great way to install a bunch of software at once, and share it with other people, but while it provided an essential level of convenience when both bandwidth and processors were more modest, today it is providing a level of lock-in that users dont need. we can do essentially the same thing, minus the lock-in, by following ideas outlined here.
you can already fork a distro, remaster, but we dont make distros as modular as they could be.
ive even said before that instead of making distros at all, we should create applications (i think they should be text-based, but im not against people making guis-- especially add-on guis-- its just that guis tend to have more dependencies that drift in terms of compatibility more often, which means more work to maintain the program) that build distros for us.
the only time i ever created a distro, i decided that i never wanted to do ANY of it manually. i created automated remasters, so that whenever i wanted to change something i just added it to the program-- imagine if every distro was a program you could fork as easily as an application. theres simply no reason this isnt possible. but as a result, we would have more people who can maintain these things for us.
when a distro starts out, and especially when it gets sponsors, people want more control, not less. but eventually this tendency makes the distro so enormous that it becomes expensive to maintain, hard to find enough people to work on it, and increasingly vulnerable to manipulation and exploitation by sponsors.
if we made distributions and software so that we could just walk away and someone else could pick it up, if we kept these processes simple (and modular) enough, we wouldnt have to worry about "debian" at all. we could just say "how is foo installer doing?" and if it was doing poorly, maybe we could swap it out with another one.
a paint program could simply be a framework (a graphical shell) that provides a canvas, menu and toolbox for manipulating the canvas. if the interface between components was something very basic (numbers or strings) then you could write plugins for it in any language that could give the program that very basic stuff to work with. you could write a shell program to manipulate the canvas, or a plugin in python, or maybe even swap out the toolkit itself (switch from tk to qt, for example).
i write code, i know this is a very ambitious concept in practical terms, but it is NOT impossible. if more software was designed this way, we could get away from not only distros, but even applications, and simply have anything capable of doing anything.
please note, i use openbsd-- the idea of pledge in many ways, is the very opposite of this. though it is not a complete contradiction. while pledge locks down an application in terms of what part of the os it can access, python exists in openbsd. python can interface with the shell. what im talking about is not any crazier than writing a paint program in python, really. its more than that, but its not crazier than that. also pledge does not stop programs from being piped together.
distros and applications can be designed in a way that:
1. if we dont like a feature, we can just delete the component, and the program will ignore that its gone (because its basically a plugin).
2. if we want a feature, we can just add it-- by learning how to add a feature, which there are instructions for, which follow the basic guidelines of how the "application" works. this is not fundamentally different from plugins for mozilla or a paint program. but we can make it easier for more people, because we want every user (within reason) to be able to do this. a user that is inexperienced wont write a great script, but they can still write one. a user that is inexperienced probably wont write a great plugin, but we can make it as possible as writing a basic shell script (within reason).
3. if we want to change a program, we can simply edit the component instead. this doesnt mean nobody will ever write an application again, but it means that applications are much easier to edit.
i know that in a way, programs are already like this. i mean i know that modules and libraries exist even in programs that dont have plugins. the difference is that plugins (when done well) facilitate people working with things on a component level-- if you are using plugins, you dont have to recompile your browser to install a plugin, right? you dont need to know how the entire browser works to make a plugin for it. its a much simpler way to get started developing or improving a tool.
and we can indeed do distros this way as well.
im not saying we can perfect this, im only saying that if we moved in this direction, users would be more free. if your os was bloated you could just start deleting features you dont use. pocket? delete. all filters in the paint program i dont use? gone. recompiling isnt needed. you just have to know the right file to delete.
what would this do to repositories? not necessarily much. if you upgraded or reinstalled an entire application, you would get all your deleted / default plugins back. then you would just run the script you made to delete the unwanted ones. or maybe someone would write a plugin to do just that, and create a backup config in your home folder (or /etc, whatever).
we tend to think of an application as something the authors maintain. but as long as we do that, we are missing an opportunity to really create a future where a community is never lost without its founders. thats not because we want the founders themselves to be expendable (they already are, too much, already). its because we want the software to be that free, we want the user to have that much control over their computing.
but as a bonus, it makes it harder for an entity to take over a project by doing some harm to the founder or their reputation. it means nobody needs permission to work on it, and anybody can become a "developer" in a week. not the sort of developer that makes entire applications or giant projects, no. a developer of components.
maybe if we didnt go around convincing people that the best thing in the world was to make a huge project like libreoffice, but just a plugin that made a program work the way they wanted, they would find it less of a stretch to go work on something less glamourous (but more vital) like a writing a driver or fixing some buggy subroutine. i dont think we are doing free software a lot of favours by teaching people the industry bullshit that everything good is big, and monolithic.
there is a culture of development that requires people to work together in certain ways, and it has certain benefits and drawbacks.
if we can attack these (often unintentional, at least in the beginning) formations of lock-in, we can make computing more free than ever.
this is meant as a starting place, its not quite a manifesto (yet?) but for example with the paint program basically we just need to give the program a "virtual port" (metaphorically, not necessarily in terms of sockets) where you can communicate some metadata (program name, preferred location, maybe a filepath to the executable) and the program will outsource the processing of some kind of standard information to the plugin. this doesnt have to be done in a "dbus" kind of way, it could even be done in a simple, gms kind of way:
you could have a plugin that told a paint program (per the design of the paint program) "heres my name, heres a description of what i do, id like 1-100 priority in the toolbox and id like to be in this part of the menu" and the paint program would expose the canvas DATA (not the canvas itself! that would require more compatibility and decrease the number of tools you could create plugins with) to the plugin program. when you ran the plugin it would work on the canvas.
certain plugins could also get mouse information from the program, so you could write a different paintbrush or whatever.
instead of creating a paint program with many tools, you could create a paint program with just a basic paintbrush and an interface like this, and let other people create all the tools for it they wanted. eventually someone would write a better paint program-- but heres the thing. if the whole program includes all the instructions you need to compile it, how it works, etc, then if someone made a "better" paint program and it started taking over in a way people didnt like (when is systemd going to get a rich text editor and html renderer?), they could just go grab your version and create a "saner" paint program.
if systemd was made this way, you could just delete... all of it. or rewrite just the parts you wanted, because programs that "need" systemd would just be looking for certain very standard data that isnt hard to produce-- in any language, even a shell script.
gnu never tried to do this as a project. it never tried to have the level of modularity that unix did. it was simply blessed with it from the beginning, because of conscious decisions by unix developers.
we can make decisions like those, to take software freedom to another level entirely-- software freedom NOT dictated (for the most part) by corporations or bribed non-profits.
free software by users, not corporations.
true grassroots software development-- but more than ever before.
but again, this is just meant as a starting place.