Why are open source apps usually ugly?

Open source software is fantastic. The open source community's years of dedication and experience have helped build a rich software ecosystem capable of everything from completely replacing expensive, for-profit alternatives to supporting niche use cases that are impossible to be profitable as a standalone product would be. Online you can find everything from millions of small scripts to huge legacy projects that support the entire Internet, like Linux, Git or OpenSSL.

However, open source apps often have a downside for consumers. Consider some of the most popular and widely used open source software. Think of OpenOffice, LibreOffice, GIMP, VLC Media Player, Audacity and other such programs. These are great, feature-rich, free applications that can easily compete with their proprietary alternatives. However, they are a bit ugly. Not particularly ugly. Not an unbearable eyesore. But not exactly…fancy.

But why is that? Are open source apps simply doomed to have poor user interfaces? Or is there something else at play? We'll look at why open source apps are often just a bit ugly.

We are generally talking about FOSS projects that are entirely or largely managed by the community. There are open source projects with corporate sponsors, product managers, etc. Something like Bitwarden or Chromium would be an example of this.

Not all open source apps are ugly

Modern UI frameworks have improved things

Now we should be clear. Not all open source apps are ugly. There are many examples of great, clean, well-designed open source software. It's not a fair generalization to say that all open source software is ugly, but it would be quite accurate to say that established, feature-rich open source apps are often uglier than their proprietary alternatives.

There are some great looking open source apps, but they are mostly in earlier versions. The rise of modern, cross-platform UI frameworks like Electron is supporting a new wave of great-looking open source apps, but they often lack the rich features of more established projects.

Why are open source apps ugly?

Projects can lack a coherent vision

There are a few things we can point out when talking about why open source apps might not look good. First, open source apps, especially larger projects like GIMP or OpenOffice, are often worked on by larger teams over longer periods of time.

This contrasts with how proprietary apps are sometimes developed within a company, where teams of designers may set the visual language and product managers set the direction for the overall project while prioritizing features. Design in open source and community projects is often led by developers themselves, and the natural inclination of many developers is to prioritize features and functionality over design.

Instead of design and careful product oversight within a company, the direction of community projects is often set by a single maintainer or a team of maintainers who are responsible for enforcing standards in the project, approving changes, and managing contributions from the community are. Good maintainers are essential for leading a serious UI redesign of a large project, assigning work, and managing progress. However, maintainers often have more “important” concerns, including less glamorous features such as maintaining backwards compatibility, security, and stability. Poor maintainers can fail to provide direction to the project, and a lack of a coherent vision slows development.

Disagreements between the community and maintainers over the direction of a project can also lead to forks, where a separate group of developers takes existing code and begins developing their own version as a new version.

Forks aren't a bad thing – legacy projects often need to prioritize backward compatibility over new features. However, many forks can reduce the development effort for the original version.

It is difficult to redesign large projects

With a large code base, refactoring a large portion is an incredibly difficult challenge. This is arguably one of the bigger challenges in the software development lifecycle – often leading to companies starting from scratch in some cases rather than refactoring old or low-quality code.

This problem exists with large projects and is often exacerbated in the open source world. Transforming a large project like GIMP or OpenOffice into a new graphics library can take years. While a company looking to redesign this software could hire a team of developers full-time to redesign it, a community-led project might find it difficult to generate the same momentum and development effort.

This may not seem like the end of the world, but the larger the codebase of large projects gets, the more difficult it becomes for a true community refactor of a project. However, there are some success stories here too. The developers of Audacity, a popular and long-running open source app, are currently in the process of a major interface redesign that looks promising (albeit with some corporate support).

This one is a little more controversial, but not all community-led open source projects try to be pretty. These projects often focus on expandability, comprehensive support, and functionality, and are willing to sacrifice a certain amount of aesthetics in favor of ease of maintenance.

Some projects may value a great user interface, others may value a command line interface that can be easily scripted or automated. Some developers may highly value cross-platform support in a project, while others are happy to give up all Windows support in exchange for blazing-fast performance on Linux, for example.

This is another example where a project can be forked when a group of developers re-releases a modified version with changes they want to see that were not included in the main version. This new group of developers may be willing to sacrifice backwards compatibility, extensibility, or features in favor of aesthetics or new features that the major release does not support.

Open source apps prioritize features

At their core, these programs value features and compatibility over aesthetics. Community-led projects often start small, with the simple goal of solving an existing problem, and then slowly grow over time. They have limited resources, and developers usually choose to use those resources on adding new features or fixing bugs rather than redesigning UI elements. These projects also do not need to be marketed or sold to anyone, so there is less need for sophisticated, interactive design and more emphasis on meeting requirements pragmatically.