Open-source software is fantastic. Years of effort and experience from the open-source community have helped build a rich ecosystem of software, capable of everything from completely replacing expensive for-profit alternatives to supporting niche use cases that wouldn’t possibly be profitable as a standalone product. Online you can find everything from millions of tiny scripts to huge, legacy projects that underpin the entire internet, like Linux, Git, or OpenSSL.
For consumers, though, open-source apps often have a downside. Consider some of the most popular, widely used open-source software. Think OpenOffice, LibreOffice, GIMP, VLC media player, Audacity, and other such programs. These are great, feature-rich, free applications that compete comfortably with their proprietary alternatives. They are, however, a little ugly. Not terribly ugly. Not an unbearable eyesore. But not exactly… slick.
But why is this? Are open-source apps just doomed to have bad UI? Or is there something else at play? We’ll have a dig into why open-source apps are often just a lil’ ugly.
We’re generally talking about FOSS projects managed entirely or largely by the community here. 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
Source: mockup.photos
Now we should be clear. Not all open-source apps are ugly. There are plenty of examples of great, clean, and well-designed open-source software. It’s not a fair generalization to say that all open-source software is ugly, but it would be pretty accurate to say that established, feature-complete open-source apps are often uglier than their proprietary alternatives.
There are some great looking open-source apps, but they tend to be in their earlier iterations. The rise of modern, cross-platform UI frameworks like Electron is supporting a new wave of great-looking open-source apps, but these often lack the rich features of more established projects.
Why are open-source apps ugly?
Projects can lack a cohesive vision
Source: mockup.photos
There are a couple of things we can point to when talking about why open-source apps might not look great. Firstly, open-source apps, especially larger projects like GIMP or OpenOffice, are often worked on over long periods by extended teams of people.
This is in contrast to how proprietary apps are sometimes developed inside a business, where there may be teams of designers setting the visual language and product managers setting 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 slick product oversight in a business, direction on community projects is often set by a single maintainer or team of maintainers, responsible for enforcing standards in the project, approving changes, and managing submissions from the community. Good maintainers are essential for leading any serious UI redesign of a big project, for assigning work and managing progress. Maintainers often have “more important” concerns though, including less glamorous traits like preserving backwards compatibility, security, and stability. Bad maintainers can fail to set a direction for the project, with a lack of cohesive vision stalling development.
Disagreements between the community and maintainers about a project’s direction can also lead to forks, where a separate group of developers takes the existing code and starts developing their own version as a new release.
Forks aren’t a bad thing – often legacy projects need to prioritize backwards compatibility over new features. Many forks can decrease development efforts on the original version though.
It’s difficult to refactor large projects
With a large code base, refactoring a large chunk is an incredibly difficult challenge. Arguably, one of the bigger challenges in the software development lifecycle – often leading companies to start from scratch in some cases instead of refactoring old or poor quality code.
Related
How to install Windows 11 on almost any unsupported PC
Want Windows 11 but have an unsupported computer? Here’s how to install Windows 11 even if your PC doesn’t meet the minimum requirements.
This problem exists for large projects, and is often exacerbated in the open-source world. A large project like GIMP or OpenOffice could take years to refactor into a new graphics library. While a company looking to refactor this software could put a team of developers on the redesign full-time, a community-led project might struggle to generate the same momentum and development effort.
This might not seem like the end of the world, but as the codebase of large projects grows, it becomes harder and harder for a true community refactor of a project. There are some success stories here though. The developers of Audacity, a popular and long-lived open-source app, are currently in the process of a major UI redesign which is looking promising (albeit with a degree of corporate support).
This one is a bit more controversial, but not all open-source, community-led projects are trying to be beautiful. These projects are often focused on being extensible, widely supported, and feature-rich, and are willing to sacrifice some esthetics for easy maintenance.
Some projects may prioritize great UI, others will prioritize a command line interface that can easily be scripted around or automated. Some developers may really value cross-platform support in a project, whereas others might happily drop all Windows support in exchange for lightning fast performance on Linux, for example.
This is another example where a project may fork, when a group of developers will re-release a modified version with changes that they want to see that haven’t been accepted into the main version. This new group of developers might be willing to sacrifice some backwards compatibility, extensibility, or features for esthetics or some new set of features that the main version won’t support.
Open-source apps prioritize features
At the core, these programs prioritize features and compatibility over esthetics. Community-led projects often start small, with simple ambitions to solve an existing problem, then grow slowly over time. They’ve got limited resources, and developers typically choose to allocate these resources to adding new features or fixing bugs instead of redesigning UI elements. These projects also don’t need to be marketed or sold to anyone, so there’s less of a requirement for slick, interactive design and more of an emphasis on meeting needs pragmatically.
