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.
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! So this post is a wiki, you can edit it! Click on the â 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.
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
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
STILL TO SORT:
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
Infrastructure
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.
Autochecks
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.
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!
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â.
Example:
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.
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.
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.
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.
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.
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.
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.
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.
So this post is a wiki, you can edit it! Click on the â
Editâ icon at the end of the post.
