💭 Difficulties of design in open source

I’ve been taking notes for a list or presentation highlighting major and minor difficulties that designers as well as design as a whole faces when it comes to open source processes.

Yesterday @devonzuegel posted on Twitter:

Why are designers relatively rare contributors to open source?

Which includes a lot of great replies to be added to the list. It also prompted me to open up the notes and make it a collaborative list! :slight_smile: So this post is a wiki, you can edit it! Click on the ‘:memo: Edit’ icon at the end of the post.

Right now it’s still a very rough state since it’s literally just the notes I wrote down so far, it will be shaped into categories and points ideally should have solutions added to them.

What do you think @dmichl @jdittrich @victoria-bondarchuk @belenbarrospena @ei8fdb @elioqoshi @Incabell @evalica @cameralibre @lama_89 everyone?

Reasons design in open source is difficult, or why open source has bad design

… and how to fix it

Why it’s hard to be a designer in open source:

  • documentation
    • Projects do not have contribution docs for designers
    • Contribution pages are focused on developing code → Design contribute pagr
  • assets
    • Projects do not have their website source code available
    • Projects do not make it easy to find source files
  • tooling:
    • git is very hard, even with the best interface. It’s not automatic and the language (commit, push, pull) is confusing. → SparkleShare
    • even with Github desktop it’s still difficult to use: push/pull/fetch/commit wording, not automatic, Not possible to drag & drop files into Githib desktop, big description field
    • There’s complicated tools necessary to get involved in it. Git for starters, terminology already too confusing, and not automatic → Sparkleshare, (Github desktop, Git-it, lennerd version tutorial)
    • “Tools of the trade” are Sketch, Illustrator, Figma etc. Some of them are only available on macOS (like Sketch) and usually they don’t work with easily accessible or shareable formats like SVG
    • universities teach “indistry standard” Illustrator, Sketch, etc → Education
    • Tools are difficult to use → OSD job board
  • Skills
    • As a result of using proprietary tools, designers often don’t know about SVG
  • Nature of design
    • People think design has to be done holistically and can not be broken up like software → You can use design systems, styleguides and have a big team
  • Legal
    • Licenses are confusing. Most are focused on code only and there’s too many. → Creative Commons
  • Smaller
    • There are more developers in open source than designers, so any vote is going to result in issues. → Don’t do voting, do educated decisions based on research, what others do, and usability testing.#
  • Cultural assumptions
    • “Linux is about choice”, leading to many settings and unclear target group (in doubt: Power users who want choice)
    • People think settings and options are great.
    • Design work is not valued so much.
    • Copyright is seen as positive in design circles → Everything is a remix
    • The culture can be toxic. → Code of conduct
  • Words
    • CI/CD mean two totally different things in design (Corporate Identity / Design) and development (Continuous Integration / Deployment)
    • PR means two different things in design (public relations) and open source (pull request)
    • “So you do database design?”
  • Communication
    • Everyone has an opinion on design.
    • “README.md” is not exactly a welcoming file name
    • Github says “Built for developers”
  • Limitations of current technology
    • Github offers to set a license, but you can’t choose Creative Commons, only code licenses
    • Github has a file size limit of 100 MB.
    • Github offers to set a .gitignore, but there’s no simple default to exclude .DS_Store and the like, only for languages
    • Github does not count comments (design discussion in issues) towards the log
    • GitLab offers to set CI, or add Kubernetes cluster, etc
    • Markdown files, which are the standard for readmes, can not be opened by default on Windows and macOS
  • Money
    • People think that open source means you are not getting paid. → Open Source Design job board


  • Integration testing is valued, usability testing is not.

  • The .git folder is visible?

  • The word “free software” adds to this confusion

What’s better for designers in open source

  • SVGs can be diffed
  • No problem with using resources because of unclear licensing.
  • Open source and distributed teams encourage documentation and validating your design

I proposed we discuss this subject in our FOSDEM panel session, more details on that in FOSDEM: OSD Panel

Some notes on the subject from MY experience:

  • Some organizations don’t monitor the design issues. They value more the development issues, so some designers don’t feel appreciated enough and it’s hard to quantify the work they do. There is a cloud of mysticism if a designer’s contributions are //really// valuable for the project.
  • The target of some applications / platforms is very generic, so it’s very hard to know who the software is address to. Even if you, as a designer, know the target, the decision makers are the developers, not the users, not the designer. This process can create some discrepancies between what should be developed and what actually is implemented. Also lots of politics.
  • OS users are more concerned with bugs than with usability or design improvements. If your organization is using a forum for example, as a designer you publish a design and ask feedback on it, there is a limited number of users that will actually provide feedback on it. So the decision again comes down to the people that participate more in the product, and those are usually the developers. Without having a clear validation that your work is productive and useful, as a designer, you might feel frustrated because of lack of feedback.
  • Very high level of technical terms and technical problems to solve. There is a lack of interested in making a designer feel welcomed inside an OS community. If the designer can survive, than “good for him/her”.
  • Loneliness: there are very few cases when multiple designers are working on the same project. That’s why I felt the need to be part of OSD community. I had no peers that shared the same concerns regarding the OS project, someone to talk to, someone to give ideas that are focused on user, not on performance and easiness of development.
  • As a designer, you mostly fight for your opinions. When you provide a design, you need to educate the developers why that design is good, why it will work, how fast it will work, etc. Instead of designing more, you need more to convince that what you produce will work. If someone from the community doesn’t like what you propose OR it’s HARD to implement, there are few chances that will get implemented.
  • OS projects are for mature (highly experienced), independent (proactive), opinionated designers that play the long-term game. Designers can’t play the hit-and-run approach in OS, since the committers need to gain trust in them. Few people have and agree to invest a lot of their time in OS projects, since they don’t see the benefit.
  • You need to share the OS values. You cannot think that you will make money out of OS. You need to have the same views in case you want to produce quality stuff that will be accepted.

I see four large topics here: infrastructure and separation, autochecks and scratching own itches


Most infrastructure in open source has code as its core “type” of thing. This is not surprising given that most code is text and given the status of text media in western culture.
Everything else is modeled after or around text: Communication media, storage of content, collaboration systems. Thus, doing non-text things in the existing infrastructure is hard.

Separation of parts

Design is hard to split up in parts which you patch together. For code, you can relatively easy define input and desired output and then it can be developed and if it adheres to the spec it will work. There are more elaborate versions of this to standardize this connectability. I guess “pipes” in unix are very well known, and this directs us also to where open tools seem to shine: Small tools, text interfaces, standards.

At least according to best UX practices, what the user sees should be coherent and it is hard to distribute.


A lot of coding infrastructure has “decisions” build in: Unit tests, coding style checkers, compiler errors and warnings etc. Designs are checked manually. We might have been closer to it in the 90s when Human Interface Guidelines were very strong, but they seem to have less strength today (maybe still at Apple?)

Scratching own itches

Scratching our own itch in code is seen as a core motivation in open source (see cathedral and the baazar). It is also easy to do this in code. You can easily start by writing the code that scratches your itch. A commonly named best practice in UX is “you are not your user” (Source). This gives less agency to the designer as you need somehow find out what other people’s itches are (hard, time consuming) and you do not have the motivation of doing away a problem which is yours and thus where graspable.

Addition to Scratching own itches: A source on this is “Scratching Someone Else’s Itch (Why Open Source can’t do Usability)” (also in ACM/Interactions, January 2004)

Addition to separation of parts: Limits of self–organization: Peer production and “laws of quality” argues that a lot of web collaboration projects assume that the modularity of small parts in much software does often not work for non-software.


Thanks @jan for starting this thread, @evalica for submitting a panel about it for the FOSDEM devroom, and @jdittrich also for the contributions. I can recognise and agree with all the reasons listed!

Many of the reasons seem infrastructural (e.g the ones about tooling), others are cultural (how design is practised vs. how development is practised). I think there is a third very important category of reasons: motivational. It seems to me designers don’t have a good answer to the question: “why should I contribute to FOSS?”

This is because, in general, the design community knows very little about FOSS. Designers don’t know what FOSS is, how it’s developed, why it’s important, and what impact it has on technology and on society. In short: they are not familiar with the politics and ideologies of FOSS.

I think designers are an ethical bunch: there is a lot of talk about doing good through design, improving people’s lives through design, and the ethical responsibilities we have as designers. If there was a connection between those ethical concerns designers have and FOSS, I think many more designers would be motivated to contribute.

By the way, I also think that OSD can make a difference on this one. We have been very good at advocating the importance of design to the FOSS community, but I think we need to pay more attention to advocating the importance of FOSS to the design community!

Just my 2c :slight_smile:


I’ll add two more problems here that I don’t think I saw mentioned so far.

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

A designer can spend a lot of work that ends up being wasted because someone else has to do a lot of work as well to make that design a reality.

I think a lot of developers think a design might involve changing the color of something. Then when they realise it means they need to change how something functions they get discouraged from getting involved.

It can be harder to make design “patches” since often the projects need a complete rethink in how the interface and user experience work.

Changing something like a signup flow can mean refactoring a lot of code. I think most open source projects that work on a volunteer basis are not willing to prioritise that for “little gain”.


I once spent tens of hours working on a design that was encouraged and well received by everyone involved in a project. But ended up never being implemented because it needed someone with more of a backend experience to get involved since it wasn’t just a superficial design change, and I couldn’t do that myself.

This is never a problem when I work with clients who pay me because, after all, they are paying me a lot of money to fix their problems. So of course they will make sure someone works with me to change whatever needs to be changed. But in an open source project where people are volunteering most developers would rather work on new features or something more exciting.


Thank you for starting this @jan - You already touched on this but I would like to add that part of the struggle also comes from a pedagogical perspective. Most design schools/universities (In the US as far as I know) do not teach, nor are educated on open source. They only teach students via Adobe and a few other proprietary softwares. So the awareness or interest just isn’t there. When open source is mentioned, there is a lot of resistance about wanting to explore this area. Few understand the freedom and opportunities that are available - let alone from a financial standpoint.


adding this twitter thread that’s currently addressing how companies abuse FOSS and do not give back to the community. please read!! https://twitter.com/patio11/status/1067515893335257088


I made similar experiences. My approach was to highlight that a university should not depend on (monopolistic) companies for their teaching. We actually send letters, did educational events and listed software that we considered alternatives.

As for the awareness/interest, I think it is there. But in practice, “going open source” is as much a concern as “going vegan”: Many seem to get the reason or were unhappy with doing things in Photopshop, just as they were with mistreatment of animals or the philosophical problems of animal product consumption. However, open source (nor veganism) touched directly and generally designerly concerns: Expressiveness, communication with clients, efficiency of work… Worse: Using a non-familiar tool, using a tool with a not-so-well-designed UI, using a non standard tool is an impediment to these concerns.

Where I saw successful FOSS initiatives at universities were the ones that bridged coding and design (processing and PureData or 3D printing…stuff…). I can only think of Blender and FontForge as tools that were taught. The reasons for this were less FOSS – I guess because they were free and trustworthy and for skills which were somewhat special: everybody had the Adobe tools for very common tasks like DTP, illustrations etc., but font editing and 3D were offered in special workshops. This gave software which was easy to install (aka free) and used by enthusiasts an edge.


Very interesting, I had the same experience at my university during my master’s program - I love the analogy you pulled with veganism, I think it summarizes it nicely honestly. I did not take the letter route, although I think that sounds more effective, I tried addressing it with the chair of our department, but ended up finding resistance among the rest of faculty that was already familiar with Adobe products and their argument was that “since it’s an industry standard why set them up to not be able to compete in the market”.
I also agree with you that my university was MUCH more accepting of processing/P5 and FontForge and since those are considered more “coding” the “crappy” UI is more tolerated.
So what does that mean, FOSS can’t compete in the design sector unless it’s completely polished?


“since it’s an industry standard why set them up to not be able to compete in the market”.

Yes, this I experienced, too. Thus, I did the move of criticizing closely binding academia and market together (Not that it did much).

addressing it with the chair of our department

I like this! I think some architecture professors where actually supportive of the argument and subsequently worked with us so this is also a good way, I think.

FOSS can’t compete in the design sector unless it’s completely polished?

No, I do not think so. Most Adobe applications do not look particularly beautiful. But they look OK, get design stuff done and they are standard, and I think most FOSS Software does not compete with it well. Blender and FontForge have no beautiful UI, get design stuff done and face no one single standard in their markets and I think thus they are acceptable. For p5 I agree: they are close to coding and thus where open source shines, usually.


i agree with you about this

I found this paper very interesting, https://arxiv.org/pdf/1507.01297.pdf which researched scratch projects and their perceived quality finding that

a) collaborative projects were of lower perceived quality
b) the losses were bigger for media intensive projects (graphics, sounds) than for coding intensive projects.

…which connects well to

Update 17.12.18: Similarly, Are Agile Methods good for design (Armitage) shows the problems of splitting a design problem in single pieces like it is often done with code.

Update: 19.01.19: “The Design of the Design” by “mythical-man-month”-F.Brooks also emphasizes the need for a coherent architecture, in his view ideally made by one or two people.

1 Like

This is a very important point. Being a PhD student in a design faculty in the UK, I can confirm the Adobe thing happens here too!

1 Like

Assuming that open source has strong ties to engineering culture and that design is concerned with people and context, I found it quite interesting to read Faulkner’s [1] “The Technology Question in Feminism”, summarizing some interesting research (in the context of the question why there are few woman in engineering), pointing out:

  • Links of masculinity, engineering and capitalism and the idea of “dominating and controlling nature”
  • The impression of girls/woman of the dominant hacker image as being not concerned with people (Turkle, 1988)
  • Mathematical rationality as dominant idea of “how engineering should be done” (Hacker, 1989) even though practical work in engineering can be quite emotional and messy. (Bucciarelli 1994, Kidder 1981) [see also Schön, '83]
  • Ridicule of people without technology knowledge.

Not being concerned with people on one hand and mathematical rationality and ridicule on the other do not go well with designing for people, I think, and it might make it hard to combine the two cultures.

[1]: Faulkner, Wendy. 2001. “The Technology Question in Feminism: A View from Feminist Technology Studies.” In Women’s Studies International Forum , 24:79–95. Elsevier.

Loving this thread! Thanks to everybody!

The vegan/FOSS comparison was neat, I feel just the same about it. We had a joke in college that non-market-oriented design (FOSS included) was like the pandas: no one will be in favour of the panda extermination, but only a few will really take a move in order to stop it…

I also agree and noticed the same problems with FOSS in the university where I graduated. Even among a group I participated that studied and took action in a socialy-concerned/anti-capitalist design aproach, FOSS was this big tabu. I had some hard times moving files back-and-forth between inkscape and illustrator when collaborating in a project.

Some of the reasons of why designers stick with proprietary software I often hear are:

  • I don’t have the time to learn another software, I need to do my job and can’t depend in unknown tools
  • It is buggy
  • What is the point of using FOSS if you don’t know how to code to fix and improve stuff?

Apart from the software theme, I think that the word collaboration – so important in free/open source projects – in the design world is still associated with taking a lot of colorful post-its, and repeatedly reorganize them in a panel. This word is trapped in the planning phase of design, not really reaching the implementaion phase with file review, versioning, issue tracking and other practices that became second nature in the FOSS development world. Creating the tools and plataforms that allow that kind of collaboration may be a nice path in order to get a FOSD (Free/Opensource Design) beyond the sfotware/tool you choose.

1 Like

I think this is an excellent point. Actually, reviews have their equivalent in design critique at least in an education-context: Present your project to your peers! Answer questions! And this could be done more.

If design systems continue to be a thing, it might also offer nice ways for collaboration as they have the modularity needed for splitting tasks (Difficulties of modularity I did lament already above).

@jan mentioned testing not being valued. I agree, though I think there is an important difference between e.g. unit tests and usability tests. The former you can do yourself, the latter needs quite some preparation and people and dealing with uncertainties etc. I must admit, I do not usability-test my written-for-fun projects either.

However, I think there is an often overlooked alternative: Rule-based evaluation.

  • Heuristic Evaluation is rather simple to do and is based on checking for 10 simple rules.
  • PURE is based on assumed cognitive load ans possibly a bit more expert-y and generates a simple score and color code
  • KLM estimates best possible efficiency. So if you want to see what UI is (theoretically) more efficient… model it.

Sure, it is not the same as usability tests with the ideal target group and a larger sample size and… but at least heuristic analysis has been found to be efficient as well as a good supplement to usability testing. Nevertheless, I rarely see these methods applied in industry as well as in open source.

Thanks for pointing me to this thread @jdittrich!

I’m doing the research about Open Design, and compiling all my findings in one mindmap. This thread is a goldmine of information and I agree with things said here. I created a separate branch (orange) to the left of the mindmap and tried to structure all ideas from this thread there.


A lot of great things are being created by the open source movement, and as a designer, developer and entrepreneur I believe that open collaboration should become a thing in other fields too. I see this movement not as a part of open source, but something more general, so it could work with any kind of project, even a no-code one. Collaboration can be available not only to designers and developers, but to all sorts of other creatives from writers to musicians. So in order to find the solution that would make it possible, I am now trying to understand how it works currently, what problems are there with existing solutions and what they are lacking.

At the moment there are two major problems in my opinion: the lack of infrastructure (version control of creative assets, no open collaboration platforms for them) and community, especially the cultural differences between creatives and developers which have to be addressed in order to create an inclusive solution. Motivation is an important issue as well: it will not be the same for creatives as it is for developers in the open source.

This leaves us with three levels of the system that have to be addressed in order to create a solution for open creativity. Firstly, a level of an individual contributor: what their motives, expectations and attitude are, what they are feeling, what previous experience and knowledge and experience they have. Secondly, a level of a group of people — a community. How the collaboration is managed, the internal “climate” of the community, the decision making process. And lastly, an infrastructure level: what tools are used, their accessibility, and how they enable people to create, share their ideas and collaborate with each other.



@zyumbik you can also watch the panels we had at FOSDEM about this topic, see the recording from https://fosdem.org/2019/schedule/event/panel_more_designers/


I was pointed to Homesteading the Noosphere and its statement on FOSS as a gift-giving culture, which is also reflected in “The power of gifts: organizing social relationships in open source communities”, stating that “…the giver gets power from giving away.”

Now, it might be that “giving” to a project is hard, due to the difficulty of…

A gift probably should come with some investment from the giver and should be somewhat valuable for the project. This also implies that it should only create non- to few work (it is also fine to unwrap gifts or assemble them, the bits of work that are totally fine when receiving gifts in other contexts). Closely related: A gift should not demand an immediate giving back to the giver.

I have “given” icons or “please increase the contrast” to FLOSS projects several times. This was usually relatively easy: People could replace a color variable or an icon image with none or minimal code changes – great. But many design suggestions might need larger investments: restructuring several UIs, reconsidering a paradigm etc. Now, might feel less like a gift, but more like a burden.