💭 Difficulties of design in open source


(Jan-Christoph Borchardt) #1

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:

  • Projects do not have contribution docs for designers
  • Projects do not have their website source code available
  • Projects do not make it easy to find source files
  • git is very hard, even with the best interface. It’s not automatic and the language (commit, push, pull) is confusing. → SparkleShare
  • “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, designers often don’t know about SVG
  • 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
  • Licenses are confusing. Most are focused on code only and there’s too many. → Creative Commons
  • 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.
  • 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?”
  • “Linux is about choice”
  • Copyright is seen as positive in design circles → Everything is a remix
  • Design is not highlighted → Open Source Design, design tag in repo
  • Tools are difficult to use → OSD job board
  • universities teach “indistry standard” Illustrator, Sketch, etc → Education
  • 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)
  • Contribution pages are focused on developing code → Design contribute pagr
  • The culture can be toxic. → Code of conduct
  • Design work is not valued so much.
  • Everyone has an opinion on design.
  • People think settings and options are great.
  • Integration testing is valued, usability testing is not.
  • The .git folder is visible?
  • Github says “Built for developers”
  • 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
  • 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
  • “README.md” is not exactly a welcoming file name
  • People think that open source means you are not getting paid. → Open Source Design job board
  • 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

FOSDEM: OSD Panel
(evalica) #2

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.

(Jdittrich) #3

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.

Seperation 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”. 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.


(Belen) #4

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:


(Gilli) #5

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.


(Dina Michl) #6

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.


(Dina Michl) #7

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


(Jdittrich) #8

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.


(Dina Michl) #10

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?


(Jdittrich) #11

“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.


(Dina Michl) #12

i agree with you about this


(Jdittrich) #13

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.


(Belen) #14

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!