A few months ago, I wrote in essence that I'm a user of the Linux kernel, and I don't want to fix my shitty broken computer. I want my vendor to work with the Linux developer community to get fixes into the main stream kernel, so I don't have to fix my shitty broken computer.
I was reminded of this as I was reading Adam Hyde's book The Cabbage Tree Method. In his book, Adam makes the claim that free and open source is broken -- it works for developers, but has failed its users. When a developer has a problem, they have the necessary skills to fix that problem. Users don't have.
While we often claim that everyone can be involved in free and open source software without needing to code (and many are, in various roles), we've all too often fallen into the thinking that in order to contribute, you must possess the skill to develop software.
If you listen to some of the public discourse at the moment, well outside of our own bubble, there's a feeling in society that everyone needs to learn how to program a computer! Computer programming is introduced at ever younger ages in, and out, of school. Hacker dads and moms are putting on Coder Dojos to teach children about programming. Raspberry Pi's are all around us and in many children's rooms.
It's easy to think the future is one where programming has developed in a way so that everyone knows how to program, and everyone can contribute to fixing the software which runs our society. We can certainly make programming easier. And there's definitely a value in learning programming for everyone. But it doesn't mean everyone should be a programmer. It doesn't mean everyone should or will contribute to fixing our software.
When I wrote that I don't want to fix my shitty broken computer, I've actively made the decision I'm not going to do the work to fix it. I know how to code, that's not the problem. I just don't think that I should be the one doing it.
I make decisions like that every day, as I'm sure you do. I know how to bake bread, but oftentimes I choose to buy bread instead. I usually know how to repair my car if it breaks, but I often choose not to do it myself. I know how to fix the software on my computer, but I choose not to.
The freedoms which free and open source software gives me are still relevant, even if I don't exercise them, because they are important for someone else. And they're important for the company from whom I get the hardware and software I use. But they're only indirectly relevant to me.
So for as long as the only contribution one can make to free and open source software is to contribute with the ability to code, free and open source software will fail its users. I said before that there are plenty of people contributing skills to free and open source software which is not coding. That's true: there are designers, translators, writers, and a lot more.
But those tasks don't help me, as a user, get my problem fixed. I can't fix a broken device driver by writing better documentation or designing new icons for the software.
What we need are ways in which those of us who choose not to code can contribute to getting the bugs we encounter fixed. This requires a lot of changes, from the tools we use to interact (which are too technical) to the way we communicate about free and open source software contributions (where we tend to emphasize code contributions).
If we don't find a way to include even people like me in the process of fixing a bug, then free and open source software will remain a tool for developers only. If we want to make sure free and open source software gives freedom to the end user, we need to give the end user a chance to use their freedoms and be included in the work.
If we don't, if we don't manage to include users in the work of developing software, then I fear the freedoms we want for developers will never reach the users.