Why is open source software so badly designed?

“It could have been so great, but why is it so ugly and difficult to use?” people trying open source software wonder. “Why aren’t designers contributing more?” developers complain. “Why don’t developers include us more?” designers lament.

Okay, actually that’s all me. As somebody who uses, designs and develops software, these questions bothered me. But I now believe that asking these questions frames the topic in an unproductive way. Instead, I’d like to ask:

How can volunteer-driven projects become successful?

What’s this clickbait? Did I just completely change the topic? Stay with me to see why this is a better why of looking at it—especially if you have an idea for a (sidenote: I’ll be using the abbreviation ‘FOSS’ a lot. It refers to free, open source software. Most of that is actually free in the sense that you don’t have to pay to use it. But it usually refers to that license under which the source code of the software is published: free to modify and share. I find the abbreviation isn’t pretty and that it’s a bit pedantic to make a distinction between FOSS and open source software without a free license, but as you’ll see, open source comes in so many shapes and forms, that it makes sense for this post. ) project and want it to be really, really good.

What FOSS are we talking about

When we ask why FOSS software is badly designed, it’s easy to dismiss that question, as the premise is wrong. After all, well-designed, successful FOSS projects exist.

Git for instance. Oh but wait, that’s a command-line interface and I guess we’re talking about software with graphical user interface. Okay, what about Visual Studio Code? Well, that’s not really for end-users! Then what about Firefox? There’s a big, professional organisation behind that.

So I guess when people ask why FOSS is badly designed, they mean software that:

  • Is free to use
  • Has open source code
  • Has a user base that doesn’t primarily consist of software developers
  • Has a GUI
  • Is mainly developed by volunteers

I think it’s important to be precise here, because FOSS isn’t some second-tier, ugly alternative for people who can’t afford any better. In fact, there are lots of great FOSS projects that don’t meet the criteria above. Many of them are so essential that without it, your computer wouldn’t work like it does. And you couldn’t have gotten this text on it via the internet either.

Idealist FOSS, the movement

The ‘free’ part of free, open source software refers to its licensing: something that has nothing to do with software in particular. FOSS started as a social philosophy. Here’s how the GNU Project summarizes their view on computing as follows:

Fee software means users have the four essential freedoms:

  1. to run the program
  2. to study and change the program in source code form
  3. to redistribute exact copies
  4. to distribute modified versions.

Software differs from material objects—such as chairs, sandwiches, and gasoline—in that it can be copied and changed much more easily. These facilities are why software is useful; we believe a program’s users should be free to take advantage of them, not solely its developer.

The important thing is that nowadays, many projects are open sourced for other reasons. But some people still have the expectation that FOSS makers live that original philosophy, leading to disappointment and incomprehension about what then look like strange development decisions.

There still are people who only want to use FOSS, because they strongly believe in the free software movement. They consider it unethical to support or even use proprietary software. They run Linux on their laptop, refuse to watch Netflix, as it requires them to install a tiny piece of closed source digital rights management software. They love that they have the option to run their own versions of their everything and never have to worry about losing access to their data. I find that laudable, but also very impractical:

  • Really being strict would mean not using online services or the software embedded in hardware like cameras, elevators, cars, etc.
  • Nobody has the time and skills to customize and perfect all the software to their desires and benefit from the openness
  • A lot of data I create or use is throw-away—I don’t care whether I can still access it in twenty years or not.

In the 1980s, when only few people had a computer in their homes, FOSS people were an important force behind software development. They were a big cultural influence. Today, it’s very common to use computers all day, everywhere. But it’s somewhat ridiculous to even consider banning closed source software from your life. With all that zeal and influence, how did we get to the current situation?

From open to closed

It’s not like users no longer care about the benefits of open software. But they also value other things. Like usability.

Venkatesh Rao (pay wall) wrote recently:

For structural reasons (SaaS), a significant diminishing in the political power, if not the technological value, of open source.

That sounds reasonable, because:

  • Asking users for money to use your software became easy after online payment became easy to implement. Payment providers (also SaaS) let software publishers skip the part where they had to set up connections with all kinds of financial organizations.
  • Before the web was mature enough to offer anything as a web service, users built and used FOSS on their own computers. Running SaaS at scale is costly, both in money and labor. It requires much more expertise on top of the expertise needed to write a straightforward computer program for one platform.
  • In the 90s it was common to download someone’s .exe and run it. Sometimes you got malware, but that wasn’t a big deal. We didn’t run our lives from our computers. Now it’s different. Giving an application access to your files possibly means giving it access to all your communication, photos, payment data and livelihood. And granting it the power to copy, delete or encrypt it for ransom. SaaS allows people to use software from publishers they don’t know with less risk.
  • Nobody becomes a stockbroker because they believe it’s their calling to bring balance to capitalist markets. And with all the money being made with software, the FOSS movement became marginalized.

The iPhone and App Store introduced a new security paradigm for software, but for very similar reasons, those too worked against FOSS:

  • Payment for software use became even easier to set up
  • Getting an app approved by Apple requires quite a bit of effort on top of building the basic application (albeit much less than setting up SaaS at scale)
  • Because the Apple doesn’t allow sideloading apps and on Android that’s too difficult for most users. So it’s not exactly attractive for developers to publish anything outside the app stores.

Pragmatic FOSS

FOSS was a prominent movement, then money-making closed source made that movement pretty marginal. But the FOSS movement wasn’t only pushed by ethics. Some of the reasons the movement considers software liberties important, is that they:

  • Reduce vendor lock-in
  • Reduce power abuse by software makers (the kind that leads to addictive, controlling and manipulative apps)
  • Help users retain control over their data

These reasons are still important for software users today. Most end users aren’t in a position to negotiate such liberties, but when software vendors creators look for solutions to their own problems, they’re very much aware of the benefits of open source.

So the demand for highly technical FOSS has only grown. And so has the supply. Many of the FOSS projects today are run by volunteers. Many of these are side projects run by professional developers with personal motivations like:

  • A desire to experiment and learn beyond the environment that their day job offers
  • Lack of opportunity in their day job to show what they’re good at
  • Better hiring perspectives

All things equal, employers prefer employees who contribute to FOSS projects. There are (sidenote: These are also the employers that ask 10x developers to be extremely hardcore and work 200%. Don’t fall into that trap. These are people who believe sleeping is the same as being dead, that enjoying food is a waste of time, just like sex and having fun with your family and friends. ) who require that candidates not only show an impressive professional resume, but also show involvement in side projects, like open source contributions. Now to me that looks unsustainable: you can’t expect people to have a full-time job, maintain that project outside of working hours, perform well in both areas and have a life away from the computer.

So here we are: FOSS is still around and perhaps more essential than ever. But now it’s mainly in service of companies who use it to produce well-designed, easy to use applications and make money off that.

Why is open source software so badly designed?

Again, I think a lot of FOSS is well-made. The kind of volunteer-driven FOSS for end-users, that’s supposed to have a user-friendly UI, not so much though. And I believe it’s because these applications are competing with the world’s biggest software makers, with the biggest budgets to get design right. The implementation of these designs heavily rely on FOSS projects. That means that much of the economic value added by software companies isn’t in software development. They identify problems that people have, design and test solutions. The implementation is often (sidenote: My former software engineering coworkers used to joke that they don’t really program anymore. That they’re more like plumbers piping together stuff that’s been made before them. ) than bundling a bunch of FOSS framework together with custom UI.

Software developers often divide up work into tiny problems. For each problem, they create a ticket. Often it doesn’t matter who picks up the ticket—it could be one of thousands of volunteers who just happens to look for a problem to fix on a Saturday afternoon. They write a test, write the code for it and submit it.

Great design isn’t done by picking up a tiny issue and creating a solution for it. It’s done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. It’s labor-intensive and requires people who are engaged with their users over long periods of time.

And once a designer has designed and tested a solution they believe in, they have to convince the people building it. In a professional environment, they typically report to someone who can decide when a design is well enough tested to be implemented. In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, ‘Yeah, but I like it the other way’, designers are shit out of luck.

Software developers use automated tests to proof that their code is good enough. Good enough usually means done. One problem, one solution. Designers usually create dozens or hundreds of solutions for the same problem. Except for the simplest of problems, they usually can’t automate the evaluation of their solutions. Although they methodologically and iteratively improve and evaluate solutions, they can’t proof that their proposed solution is better than the idea of a random bystander.

I’ve worked with developers who had so little trust in the design team, that they sometimes flat out refused to follow the spec. A designer can’t force a developer to implement their solution. All they can do is discuss the situation with the team lead and hope for the best. In most volunteer-driven projects, there isn’t even such a structure.

Compared to development, design deals with more (sidenote: Meaning there are many variables for which the outcome is uncertain. ) problems and requires more involvement, effort and stakeholder management. A designer can’t just spend a few hours and do a meaningful contribution to badly designed UI design. But a developer can identify a bug, fix it and do a pull request even within minutes.

So what do we do about it?

As you might have guessed from my introduction, when I first started to research the topic of open source and design, I was a little frustrated. I wanted to switch from Windows to Linux. But the open source photo editing software Darktable was (sidenote: I’m not saying Darktable is bad or anything—I couldn’t enjoy my hobby with it. ) to use compared to the closed source Lightroom, that I gave up. If only a few more designers had discovered Darktable, I thought. If only more designers would be in FOSS, we’d all have control over our data and be free from big tech.

But with the historical context above, I now accept the situation we’re in. It’s not a matter of developers acting just a little friendlier or designers acting a little less egoistically. We’d have a very different expectation of UI design today if it weren’t for all the money that was poured into software design. FOSS is great, but a well-designed UI can be the difference between a user base of a few hundred programmers and one of hundreds of millions of people.

Well-designed UIs don’t just emerge from spontaneous volunteer contributions. A designer could spend most of their working time volunteering and making a great design for a FOSS project. But then still there needs to be a structure and a collaboration process wherein that design is used.

I know—it’s time for me to suggest some solutions now. You’ll find them in How to make volunteer-driven open source projects successful!