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. 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.
It is my experience that everybody is working an agenda, harmless or Machiavellian is not the point. “Doing something interesting” is already an agenda and can already be slightly harmful if people want to do only the interesting bits. In this context, there is a basic amount of selfishness that you owe to yourself, out of sanity and common sense. When money gets in the equation, it somehow makes it transactional, clearer and saner. When it does not, questioning motives is unavoidable.
The FLOSS applicative ecosystem is partly 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. Even though the selling pitch mentioned only freedom and data sovereignty, not STFU post-install.
But FLOSS projects are rarely a one-man operation. If responsibility towards not-clients users can be dismissed, how is it supposed to be shared between contributors ? More precisely, what is the responsibility of the contributors toward each other ? Because they all pledged their time, work and skill, the whole money joker doesn’t hold : they all owe each other something. And, to begin with, who is considered a contributor ? That could include anyone submitting a pull request on Github, even off-topic and out of the project scope.
That raises a whole question of FLOSS projects governance. 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 a job which consists in wiring technical problems to technical solutions. The problem with problems, precisely, is that their optimal solution is intimately linked to how you look at them, and the actual problem being examined is rarely the real, end, problem you have but just an avatar. Looking at problems in a way that promotes realistic and actionable solutions is a real job. Indeed, looking at the actual end-problem through the contextual one enables much simpler and more general solutions, often avoiding compromise (which is a lose-lose transaction often happening as a result of looking only at short-term and local interests).
To use a recent case, you may think that sorting files by conditions is only a problem of being able to define advanced filters in a GUI. But your sorting issue is already too specific, your real problem is to efficiently cull a possibly large list of files and to have a way to mark the choosen ones 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.
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 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).
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 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 criterions that the solution will need to meet to be accepted, expressed as quantitative 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.
Notice this 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.
So, with your specification book, 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 realism 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.
And there we go. All this requires a training that very few of FLOSS contributors have. Then it requires an amount of time that no FLOSS contributor has, because remember, they all have other jobs and are doing it thanklessly and selflessy for free. Then, it requires some leader to organize and structure the designing process (which is not the same as pulling rank to get his way). And even if, to satisfy whatever flawed idea of democracy you may have, you invite more people to split and share more work, that will actually create more management overhead to keep some unified overall direction and some structure in the herd. So, design by committee ends up voting for the most liked drawing, because nobody has the slightest idea of how to move past individual subjectivities in a way that brings a viable general solution.
In fact, the whole idea is flawed from even before the specification book. The specification book requires to have a client to begin with, whom you can ask questions about their needs and expectations. The whole problem of a programmer is… he is supposed to program for a task producing a result outside of the computer, so he need access to knowledge (practical and theoretical) about this task. 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 of experience. 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, trying to do a job for which other people get paid full-time in the non-FLOSS world, while the FLOSS evangelists keep trying to convince everybody that next year gonna be the year of Linux on desktop.
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, more overhead, more work — and neither will launching deep cries into the night to the mythological figure of the UX designer.
