Designer-friendly Open Source
Why Open Source is ugly (it isn’t), developers don’t like designers (they do), and we’ll never see a decent FOSS Figma alternative (we will).
We love attractive things. Not only do they look good, but they tend to work better as well. We buy clothes that look good on us, we surround ourselves with beautiful things. Is it safe to assume that we also select digital products that look better than their poor-looking competitors?
The answer is — yes, it is, and yes, we do. The first impression impacts the user so much that even those that fail to complete their job to be done tend to leave satisfied and have a good reflection on the product. We fall in love at first sight with the product that manages to catch our attention with its pleasing aesthetics and dismiss those that fail.
Ugly products don’t attract attention, so much so that some of us will never turn to a poorly designed alternative — even when it’s got more to offer and comes at a lower price. Even when it’s free.
Is Open Source really ugly?
Let’s begin by defining what “ugly” actually means. The choice of colour plays a crucial role in the perception of the product, and so does visual novelty: “beautiful” products are the ones that are capable of impacting the user’s initial perception of their usability, trigger a positive emotional response and behavioural intentions.
Following the logic, “ugly” products should cause the opposite emotional reaction. It’s important to set the framework: “ugly” products are not the ones using “old-fashioned icons” or “old-school fonts”, “ugly” products are the ones that fail to create a pleasant visual impression on the user — for instance, by using troublesome colour combinations or neglecting their own design rules.
Subjective judgement aside, from this standpoint open source products are considered “ugly” because of how little thinking is put into making an impression on the user. More than that, open source is “ugly” because it fails to surprise. If your product looks the child of the late 90s — and, most likely, it’s because it is just that — what “element of novelty” are we talking about?
Open source projects are not made to gain profit: that works both for and against them. On the one hand, they are completely independent of any corporation, company, and any other structure whatsoever, which means that revenue streams don’t play any role in defining the roadmap — the primary goal is to satisfy its user with the functionality it provides. On the other hand, open source doesn’t really care about the user.
Let me make it clear: open source software is built by its users for themselves. Often the software outgrows its creators’ initial ideas and starts living its own life. With some exceptions like Firefox and Blender that are created and supported by non-profit foundations and the community, most of the projects live without any help from the former, which means the resources are severely limited. Since the user base is not bringing any direct profit, monetary or otherwise, to the community, it’s essential for the developers to look for other developers, first and foremost, while growing the audience might actually bring more pain than gain.
Users might start thinking of themselves as of “customers”, demanding certain functionality or straight away attack the contributors for not paying enough attention to their problems — as if the software wasn’t provided for free by a group of enthusiasts who volunteered to maintain and develop it. Growing the customer base is terrific — but who will be supporting it, nurturing it, comforting it?
So, while not being particularly concerned with the growth of the product’s user base, community-backed open source solutions rarely have “engaging design” or “lovable experience” anywhere near their top priorities. Like Red Hat’s Brian Gracely pointed out,
They’ve always sort of gotten it to a good solid point that does 80% of what you want it to do, or it works well enough but there’s not great interfaces and things on it.
Are designers not ready to collaborate?
In her article “Open source design is ugly, here’s why”, Ginny Hamilton quotes Garth Braithwaite saying that design schools encourage competition among students which doesn’t lead to a collaborative mindset. Braithwaite goes further: designers are outnumbered and often overworked, which makes recruiting them for side projects exceptionally hard.
The design community, however, senses that designers are often underappreciated, which makes contributing to a project founded and led by developers even harder.
Pieter writes:
My girlfriend tried to design an icon for an open-source app she uses, but the experience hasn’t been really great. I think the way developers in open-source projects communicate doesn’t really work with designers. She sent the photoshop source file and a png to the mailing list, but was told to send in a patch instead, which meant she had to learn how to use git to check out the repository, add the icon to the repo, and then generate a git patch. Only after that, she was told that they couldn’t use the photoshop source file because they didn’t have photoshop. Finally, one of the developers imported the file into the GIMP, changed some stuff on the icon without discussion, botched the output and then added that to the project. That was enough for her to not try doing something like this again.
Lotides adds:
I feel like a second-class citizen around developers. And I don’t want to venture in to the lions den. After all, I “just make things pretty”, right?
Developers, when asking for more designers to contribute to open source, often tend to be quite, well, condescending, to say the least.
Another thing is that they don’t know about git, PRs, issues and other complex words like these. And when somebody goes to a GitHub repository looking for an issue, it’s all overwhelming.
The community often perceives designers as a group of creatives making “pretty” things and “refreshing” the interfaces, and the bias definitely impacts the collaboration — but even more so, the desire to collaborate with the community, albeit for the greater good.
Designers are expected to come in and solve some issues, but just as one bucket of water is not likely to save a house on fire from burning down, a lonely UX ranger is not likely to patch a hundred of things and save the day.
An experienced designer, however, knows pretty well that revamps and overhauls are not always the best solution. Yes, putting the small fires down one by one is not the best strategy, but nor is demolishing the entire block to rebuild one mansion. Of course, some Muse Group might want to consider redesigning Audacity after purchasing it, but most project require something different — and when a mature designer proposes to take care of that, who would dare to refuse?
Is the Future Open Source?
“Most developers have a very limited understanding of usability” — says the paper titled “Usability in Open Source Software Development”, published in 2006.
“You can do a lot in it, after you get past the awkward menus”, — the Linux Journal quotes an average user.
Luckily, the times they are a changin’, and we see more and more developers embracing design thinking and accepting the fact that “lack of trust” can no longer remain a valid constraint protecting their product from the curse of usability. How long will it take before a lonely designer who cares about privacy and stability joins the game after understanding that there is actually no good choice in the market?
Take Figma, for instance: a great design tool that took the market from Sketch in just a couple of years. A stable proprietary technology that lives in the cloud and claims that the data belongs to its creator, but also reserves the right to share you de-identified data with the third parties and sell it to the advertisers.
Cloud collaboration is what drove customers to Figma in the first place, but how reliable is the technology? Of course, one tiny server shutdown every couple of months is not a big issue, and surely no intern will be allowed to wipe out all Figma’s data clean, but just as Amazon is prone to human error, no other cloud-based platform is immune either.
Sketch is another proprietary product, but looks like its ship is sinking: using a combination of 3 tools (Sketch, Zeplin, Invision) to store, test, and ship design, sharing files via Dropbox or crying over Abstract is no longer an option for teams who want to work smoothly and fast. A mac-only former king is now desperate for new ideas, but its inevitable demise is near.
Open Source, on the other hand, has a great potential of solving both issues: keeping the data secure and software-independent, and allowing the community to expand functionality.
Those who remain sceptical about the potential of the open source software for designers are rightfully in doubt: many “open source alternatives” to popular tools have either died soon after emerging or froze in the eternal “early Alpha”. However, the recent rise of remote work that helped Figma grow tremendously and taught many to live and breathe online, collaborate and co-create virtually, gives a great hope for the future of Open Source for developers and designers alike.
As for searching for Figma/Sketch replacement, there are some decent players in the market that are ready to fight for their user. Just a few months back Kaleidos Open Source, rolled out an Alpha version of their web-based design and prototyping tool — Penpot.
Unlike Figma and Sketch, Penpot is using SVG as the default format, allows the designer to run a local instance of the app or use it online with the team. Unlike its proprietary competitors, Penpot is not sharing its users’ personal data with advertisers, keeping almost all activity on the platform private.
Penpot is in Alpha, so it might take a while before it becomes mature and wins over more users, but it serves well as a proof of concept: Open Source is capable of doing much more than being a toy for a couple of geeks. It’s becoming a future: a sustainable, accessible, open future that values collaboration and transparency over market share and capitalisation.
To sum up
Open Source offers a reliable, affordable, flexible, and more ethical alternative to proprietary software. It respects privacy and confidentiality, relies on open and free standards, allows for customisation.
It comes with a pinch of salt: when the enthusiasm dies out and the fun is over, contributors tend to disappear, so the most successful big Open Source projects are those that are backed by engineering companies, non-profit organisations, such as Mozilla, Blender Foundation, Canonical, and others that maintain a healthy balance between maintaining good products and keeping the community engaged.
Open Source products lack budgets to quickly reach ambitious goals, so changes and improvements may take plenty of time to be implemented. Moreover, the designers are rarely involved in the process, making the products less user-centric, less appealing, less lovable. Open Source software is not “ugly by design” because of outdated icons or bad font choices: what makes it “ugly” are the severe usability issues that have been overlooked for years.
Fortunately, the tides are turning: the developers are now recruiting designers more actively, realising clear usability issues with their products and paying attention to improving usability, and the designers are actually willing to contribute more.
As a result, we are likely to soon see more outstanding products in the free and open source market, including some built for designers.
