A lot of people say open-source software sucks, and that can feel unfair, or even be upsetting to those of us who are open-source enthusiasts, advocates, and contributors. After all, we often know better than most that the software we love is often exceptionally powerful, fully capable of producing high-level results, and built by people who deeply care about what they’re making.
But let’s pause for a second, zoom out, and look at this from the average end-user perspective. Most people choose software because they just want to get stuff done and get it done with the least friction possible. Beyond that, most people expect that software to be a pleasant experience to use. Granted, familiarity often plays a huge role in what we consider “user-friendly” and comfortable to use. Historically, if we’re being honest, many open-source applications haven’t met that standard. So, if we’re to be objectively fair, that reaction is often valid. Like it or not, the first experience for most users is visual, the “form” in “form follows function.” Between UI and UX, that often means that the initial user experience falls squarely into the “UI” camp, but here’s the thing: UI is a critical component of UX.
Speaking of which, let’s talk about UX. It’s an important concept that has become one of the largest aspects of the tech industry and one of the niches with some of the highest-paying roles, and yet it’s often been historically maligned by some of the very folks responsible for making it a reality. By that I mean, developers.
For many developers, the concept of a good user experience has simply been, “Does it function? Good enough.” For open-source, this has been our guiding light for many years. It’s the very reason that so many people have developed the belief that open-source software isn’t user-friendly and therefore isn’t for them. Thankfully, there’s a new generation of developers who understand why this can’t work: because people don’t experience software as a list of features. They experience it as a whole environment. They experience the menus, the wording, the defaults, the layout, the documentation, the friction, and the small moments where they either feel guided or abandoned.
Tech Insight: Presentation precedes purpose
Imagine you’ve been invited to dinner by a good friend. You know them well, and you’ve always gotten along great. They’re a great person to be around, kind-hearted, and they always make a good effort to show up.
At dinner, the food is excellent. Your friend is the same friend they’ve always been.
But from the time you showed up, the floor creaked; you noticed the table was messy, the lighting sucks, if you can call it that, and worst of all, you’re wondering, “What’s that smell?” It’s not the food. The table makes you sit at an awkward angle. By the time you finish eating, if you ever do, you may still appreciate the food and your friend who made it, but you’d still say that dinner with them sucked.
User experience in open-source software is often a lot like this.
We can have apps with great capability, but if that capability is locked behind an experience that feels like eating dinner in a cave, it doesn’t read as functionality. As a rule of thumb, we should remember that if functionality feels like pain and confusion, people won’t separate the function from its form.
To most users, form is function, and to be fair, they’re not wrong. A tool as simple as a knife that happens to be confusing to use makes it easier to get things wrong and cut off a finger rather than cutting your tomatoes and onions. The point isn’t that our software needs to be flashy, fancy, or frivolous. Not every app needs glass and glamour to be comfortable or fun to use. We don’t even need to follow every trend or copy every popular tool within a genre. That’s not the goal or the point. The point is that we should put users first, and to do that, we need to reduce friction, in whatever way that needs to happen.
Just because open-source software is often the work of volunteer effort doesn’t mean that end users will always excuse and understand a poor experience. This is why I, and surely many others in the community, are pushing so hard for better standards, sane defaults, and clear documentation, not just better aesthetics, though aesthetic appeal has its place, too.
We have the power to make it happen
Apart from the call to reduce friction, the biggest takeaway I want to leave us with is this: we can do this. The beauty of open-source is that we’re in control, and nobody can stop us or dictate our limits. So, if we want to build great software, we can make it happen. Even for those in the community who aren’t developers, designers, or even documenters, the power is still in your hands. Feedback and even feature requests help to shape the software we love and make the experience better for everyone else. You never know what the ones building and maintaining may have missed until you speak up.
In a nutshell, if we want better software overall, and we want open-source to win and be embraced by the world, we can see that through. The key is to put end users, people, first, reduce friction, and ensure that the experience of achieving the goal is as comfortable and meaningful as the experience of reaching it.
Practical Tip: Think like a user
This one is for developers, designers, and any other open-source contributors and builders. When we’re building, testing, or giving feedback on software, the question we should be asking isn’t just “Does this feature work?”
But rather:
“Could a regular user find it, understand it, and comfortably use it?”
Try walking through one common task from start to finish as if you’ve never used the app before. Sometimes it even helps to try doing the same task in another software within the same field, if possible. Finding their pain points and wins can help us to identify and implement our own solutions more strongly.
A feature that technically works but generates too much friction is a barrier that needs to be reduced or removed. By reducing that friction, we can make our software experience feel better without needing to redesign everything at once.
Try to catch where someone else might hesitate, or find something unclear, even through word choices. See if you can identify ways in which the defaults create extra work, and where the interface makes you stop and think too hard. All these small details constitute the whole. Knock these out the park, and you’ve got yourself a polished piece of software that will likely do well to promote itself.
If you want to stay in this lane
I’ve written some related articles in this series that you might find interesting if you liked this one:
The Myth of the Learning Curve - The Roll Out
A closer look at how people talk about software difficulty, and why “too hard to learn” is often more complicated than it sounds.The Bloat Tax: Big Downloads for a Thin Experience - The Roll Out
Why bigger software does not always mean a better experience, and how performance, footprint, and user expectations shape whether software feels worth using.The Social Side of Software Trust - The Roll Out
A look at how software trust is shaped by perception, social pressure, and the stories people repeat about open-source tools.Open on paper is not enough - The Roll Out
A look at why openness needs to work in practice, not just in principle, especially when real users and real workflows are involved.
Working with us
At RolandiXor Media Inc., we blend design and open-source thinking for our clients.
Elsewhere
- Mastodon: mastodon.social/@rolandixor
- Threads: @rolandixor
- X: @rolandixor
Support this work
If this writing has been useful and you’d like to help sustain it:
→ https://ko-fi.com/rolandixor
Catch you in the next Roll Out!
Comments