Solving the Open Source Design Problem.

Any work a designer does usually means more work for somebody else.

from a recent conversation on why open source has trouble integrating designers.

I’m a designer who has been learning how to code. In the past year I dove into switching all my personal cloud services over to self hosted FOSS alternatives like Nextcloud. In getting more involved in these communities I sometimes found that when I logged a story saying “Hey this thing could be better, respectfully here’s my thoughts” the response was sometimes rather disappointing. “It’s fine the way it is” …“I don’t see the difference”.

I think there may in fact be no easy solution to this problem, but I think this might point to a solution nonetheless.

I am a designer learning to code. I only do web stuff though. Web is a field of development which has a fairly integrated history between dev and design though, as a web designer and web developer were often the same person back in the day.

Just as I am a designer learning to code many developers are learning design. The gap between web stack and native has shortened with the advent of technologies like Electron and React Native etc. The advent of Design Systems and the focus on componentization of UI in frameworks like Vue/React has also lead to growth in design skills in the web development community.

I think in some ways the only way this will be solved is through some convergence of the two. This is one reason why as a designer one of my focuses in discussing development and design with other designers is encouraging a higher level of technical development knowledge. On the other hand when I am in open source circles I try to advocate for good design not just in presentation of the “product” but in improving the experience of using code itself.

An example of this latter “improving the experience of code itself” is through the dotfiles community: 1

Dotfiles are configuration files for unix apps. It starts with something as simple as writing some easy aliases for your bash command line interface to make things easier to do. THAT IS UX! That UX via kaizen process.

Related to web based technologies you can see this same instinct playing out in how vscode


and hyper

have evolved rapidly in their design space largely due to the relative ease of writing extensions or plugins with only basic web stack knowledge. (plug-in plug wink wink)

And speaking of hyper above which is a command line interface app that is built using web stack technologies and runs on Windows, Linux, and Mac: UX isn’t limited to just visual presentation, it also is a part of text too. In the command line there have been several rather well designed command line interfaces developed in the last couple of years such as:



or zsh.


(zsh is actually much older but there’s been an explosion in its use lately due to things like “oh-my-zsh” project. )

Or the extremely fascinating xsh project which sadly is currently not being developed anymore (which I’ll cover in more detail in my next post).

Now all these things are examples of improvement in design in code presentation, therefore text, so I still think there is some gap in translating the gains of the developer focused design to open source design as a whole, since there are hard technologically defined distinctions between text data and visual imagery data.

But at least in one way it has made the user experience of learning to code a lot easier for me!

I think it’s also worth considering the ways in which innovations in CLI UX design is itself also comparable to the ideas that have been floating around in the world of “conversational UI”. I will expand this idea more next focusing on the subject of CLI shell UX and how I think designers who often don’t know anything about CLI can take some cues from innovations developers have been messing with in that space.