Design by committee will not save FLOSS

The opensource ecosystem is keen on its mantras. One of them is that being an opensource dev/maintainer is a thankless unpaid job. And while that may sound like a selfless act of benevolence, there is another way of reading it : a selfish way of avoiding professional responsibility, while still exerting some amount of power and decision over technical decisions. Which is the egg and which is the chicken then ? It may not matter, but the quasi-hagiographic founding myths of opensource need to stop.

Everybody is working an agenda, harmless or Machiavellian is not the point. Altruism hides a quest for recognition, validation, love, and finding purpose. “Doing something interesting” is already an agenda and can turn harmful if people want to do only the interesting bits of a project, because chores and janitorial stuff always come into the mix. In an environment running on these grounds, there is a basic amount of selfishness (call that self-respect) that everybody owes to themselves, out of sanity and common sense. Money actually makes all that clearer, more legible and somewhat saner : you do the job, get paid, go home, forget about your day, unwind. When money is out of the equation, you get to ask yourself and others what they are truly looking for. Not that it’s bad to have selfish motives, but those need to be expressed clearly.

The FLOSS applicative ecosystem is mostly moved by an ideology of freedom and privacy. But it also speaks a double language : luring new users in on political and ethical matters on one hand, dismissing any responsibility on technical and usability matters on the other. Of course, who would we be to expect unpaid workers to work for free and for us ? No money, no responsibility, it is the rule. You get the product for free, you don’t get to complain. Problem is, the selling pitch mentioned only freedom and data sovereignty, not forfeiting the right to give (possibly negative) feedback post-install. And the mere right to usability as well.

But FLOSS projects are rarely a one-man operation, even though there is usually only one or two guys doing most of the job. If responsibility towards non-clients users can be dismissed, what about responsibility towards other contributors ? Because they all pledged their time, work and skill into making the project “better”, so they all owe something to each other. This, of course, requires first to define who is considered a contributor, because that could include anyone submitting a pull request on Github, even off-topic and out of the project scope, which is neither realistic nor fair to the long-term contributors doing the actual daily maintenance.

That raises a lot of questions regarding FLOSS projects governance, which become increasingly hard to ignore. How are decisions supposed to be made ? Who gets the final say ? How to work with a team you didn’t choose made of people you can’t fire ? Who owns a FLOSS project ? Especially when the founder(s) have left the ship ?

The temptation here is to resort to democracy, within contributors and maybe even within users. And unfortunately, that doesn’t work.

See, engineering is the job of matching the best technical solution to a well-defined technical problem. The problem with problems, precisely, is that their optimal solution is intimately subjected to :

1. how you look at them,
2. what your budget is,
3. what your priorities are (including values and politics, and, no, it’s not a curse word),
4. who is supposed to use the solution,
5. what the expected life expectancy of the solution will be.

The actual problem being examined is rarely the real, root problem you have but just the visible end of a deeper, underlying problem. Looking at problems in a way that promotes realistic and actionable solutions is a real job for which methodologies have been devised : let’s call that engineering. Solving the root problem usually solves several branch problems at once, in simpler and more general ways than patching each branch problem individually. But that requires some time spent an investigating and abstracting branch problems to find their common denominator and their root cause.

To use a recent case, you may think that sorting files by conditions is only a problem of being able to define advanced file filters in a GUI. But your sorting issue is already too specific, if you zoom out, your real problem is to efficiently cull a possibly large list of files and to have a way to mark the chosen files for future reference. In which your filtering sub-problem may not be as important as you think, or may even be a distraction. It might even be possible to cull without filtering at all. You will never know, if you focus on the filtering part while missing the big picture. Problems need to be tackled from global to specific, being blinded by the specifics is bad and it’s unfortunately easy in technics. Because technics exist in layers, and every technician tends to be specialized in only one or two of these layers, and each of these layers can become overwhelmingly complicated if you stare at it long enough, so you need to zoom-out regularly to go back to the end goal.

In engineering school, I was taught how to conduct design meeting, brainstorming sessions and prototyping. You might think that sitting 10, 20, 30 subjectivities into the same room might average to a sort of objectivity, but it does not. It sums up to 10, 20, 30 different personal preferences and likings, usually the solution that each individual has already worked with in the past. You got to be efficient, right ? But the effort you put into recycling your acquired knowledge, perhaps even to feel relevant again (emotional matters inside), may conceal its complete irrelevance to the current topic. Sometimes (often ?), it’s good to forget what you know and start fresh from intuition and research (using new sources). I still get caught in there myself, trying to reuse tools, techs and knowledge from an old project while newer ones are better suited for the task and makes it much easier.

Design meetings need preparation and a host. The more people in the room, the more preparation. Everyone needs to be aware of the modus operandum, which starts with everyone having read the specification book. Which means the specification book has to exist, and someone needs to have carefully broken down the problem into technical specifications.

Because, yes, design is only the middle of the process. There is a before and an after. A specification book essentially details the criteria that the solution will need to meet to be accepted, expressed as quantitative (or at least objective) metrics as much as possible. For an application, which is mostly a tool, there is a task to achieve. We can break down the number of steps required to achieve the task, the hourly or daily productivity targeted, the amount of training that the operator will need before being able to use the tool, the external pieces of technology to support and interface with, and then the ergonomics no-no, like the forbidden postures and motions. If software is not heavy machinery, keyboard and mouse still promote repetitive motions and stress that can cause wrist and arm injuries and need to be avoided when possible, and that starts in GUI design.

The specification book will try its best to not suggest or bias in favour of any particular technology or solution. Early biases are detrimental to rational design and lead to missing great opportunities entirely. Solutions will be the job of the design, and it’s very important to fully separate both. The design process is one where you need to think against your brain, because it’s lazy and falls back automatically to old habits.

So, with your specification book that everybody read, you can boot your brainstorming meeting, which consists in throwing any idea of a solution the attendance gets, no matter how ludicrous, and to take notes. Though you may want to keep in the room only people with relevant technical experience, so their ludicrous still has some realist in it, otherwise it’s just people loosing everybody’s time (outsiders may have value to that process too, but only if they are able to get remotely on-topic — it’s a dice toss). Every idea, no matter how shitty, will be noted on the board. The point is to unlock associations of ideas and ensure everyone contributes fairly. Once the board is filled, it’s time to associate possible benefits and drawbacks to each idea, and start culling them on their feasibility (there are plenty of methods to do so, mostly “abitrary objectivity” like decisions matrices and so on).

With the few remaining ideas, the next step is to start drawing mock-ups and to compare them. Then choose between the mock-ups which one(s) will have the privilege to become a prototype. Then build the prototype and submit it to the validation tests defined in the specification book. If all goes well, you move to production, otherwise you iterate to the next prototype. With enough resources, you can work more than one prototype at a time, to explore more options and compare at the end using A/B testing.

And so FLOSS goes down the drain: all this requires training that very few contributors have. Then there’s the time commitment, which no FLOSS contributor has because, remember, they all have other jobs and are doing this thanklessly and selflessly for free. It also requires a leader to organise and structure the design process (which is not the same as pulling rank to get one’s own way). Even if you invite more people to split and share the work to satisfy your flawed idea of democracy, that will actually create more management overhead to maintain a unified direction and structure. Design by committee ends up voting for the drawing with the most likes, because nobody knows how to move beyond individual subjectivity to find a viable general solution.

In fact, the whole concept of FLOSS design is flawed even before you get to the specification book. The specification book requires a client (or end user) from the outset, who can be asked about their needs, expectations and qualifications. Computers are no longer just used for computing; they are also used as interfaces to perform tasks outside of the computer. Programmers work with computers for computers and see the world through them. They need to get out of their comfort zone to understand someone else’s job before translating it into machine language. Good luck doing that without access to a non-programmer who can explain their job.

The typical answer is “programmers scratch their own itch”, but remind me how many programmers in FLOSS image processing are advanced pixel pushers (I don’t even dare blasting anything beginning with “pro”) ? No offense, but you might want to take input from people having actual experience with the task at hand. So how exactly is building good apps for well-definite tasks supposed to happen if we don’t have the workers at talking distance ?

There you have it, the proverbial mediocrity of FLOSS : people programming for tasks they don’t master, who are not even trained programmers for a large part, who have no training in design and engineering procedures, who have no more than a few hours a week to allow, while the FLOSS evangelists keep trying to convince everybody that next year gonna be the year of Linux on desktop.

But where the FLOSS ecosystem shines is in wishful thinking : add more people, and collective intelligence will overcome any issue. In what world ? When you add more dancers to a dance hall, you only increase the probability of having someone stomping over your feet. It’s called increasing entropy  : more particles in random motion within a confined volume will only increase the number of collisions between particles. To increase efficiency while adding particles, you need to make sure those particules stop moving in random directions, which is all the more difficult than you have particles. Meaning collective intelligence is the sum (or more) of individual intelligences only if there is some structure to organize the work, meaning someone has to assume leadership to maintain that structure. Human beings are no ants or bees, they work with concepts and abstractions and communicate with words, drawings and graphs instead of dances and pheromones.

There is no secret : quality takes time. Computers, internet, electricity too, but mostly time. Doing research takes time, prototyping takes time, talking with end-users and trying to understand their problems takes time, and there is no shortcuts. It takes skills too, which ultimately means it takes the time of the right people.

Professionalize FLOSS, or else nothing. No buts, no ifs. Yes, admin and taxes gonna suck. In any case, the whole idea of “working for free” is unsustainable and even unfair competition for those who can’t afford to donate their time like that. The FLOSS contributor is also often a white middle-class middle-age man, except when it’s a freshly graduated guy polishing up his resume, and it would be interesting to study what makes the FLOSS contributor able to contribute and what prevents the rest of the world of doing the same, but open-source communities are not the cute little communist utopia driven by sharing that they pretend to be. Remember, before being a hand-burning capitalistic token, money was a measure of work that you could exchange against goods and services.

Putting more people on the matter will change nothing – more people induce more overhead, thus more work — and neither will launching deep cries into the night to the mythological figure of the UX designer.

And all that for what? Let’s not forget what computers are for. There are many jobs that could be done without computers in the 20st century. More and more tools have been digitised under the false promise of increasing productivity. Computers can improve productivity if you can process batches of uniform objects with a single command. Instead, users repeatedly click the same buttons in the same order in stupid GUIs, failing to benefit from automation or batch processing. The difference now, compared to the 20th century, is that users have no idea what they are doing: they have become alienated from their tools, from their job. There is another name for that: violence. We have subjected them to violence. We removed any control or understanding they could have had of their tools. We have placed them under the domination of software publishers.

It’s about time FLOSS stopped focusing solely on freedom and privacy and started considering the violence contained into forced digitalization, especially towards the least computer-litterate users. After all, FLOSS only caters for the most computer-literate users. For everyone else, it’s even more violent than proprietary software, given that it’s typically less user-friendly. But good luck trying to explain violence to someone who not only doesn’t experience it, but even belongs to the social class that inflicts it.

As the technical entry barrier to FLOSS is higher than for commercial software, FLOSS is actually less empowering. But if empowerment is ruled out, what remains to FLOSS is only how intellectual capital (source code) is shared. By definition, it will be shared among people who can read source code and who happen to be in majority white, educated, privileged and have time on their hands. So much for your communist utopia: it’s just another variation over the same old bullshit, capital being shared among a minority capitalists, and the rest of the world suffering from their choices.

The free software movement is right-wing leftism. In the countryside, in poorly-educated circles, among working-class people, we see an appetite for left-wing discourse only on the “wealth sharing” aspect,¹ including job preservation and the right to work, with an abysmal blind spot concerning all other aspects of social progress (sharing and protecting the environment, emancipating women and minorities, fighting against all forms of domination and oppression, including structural and medical). This partial leftism makes these populations extremely susceptible to far-right populism, whose intrinsic racism, misogyny and xenophobia are in no way incompatible with the truncated and reductive vision of social progress. It’s exactly the same thing that’s happening in the librist movements: it has theorized how intellectual capital should be shared, and completely lost sight of the emancipation of all those people who have found themselves held hostage by forced digitalization.

What makes FLOSS so toxic is its repeated inability to admit its own paradoxes, while developing an emancipatory discourse of pure facade, structured against the GAFAM rather than towards their victims. The only way to empower users is to replace software hacking with proper design, then start designing with them, for them, acknowledging their needs and limitations.