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! 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:
- Projects do not have contribution docs for designers
- Contribution pages are focused on developing code → Design contribute pagr
- 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
- 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
- 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
- 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.#
- 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
- 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?”
- Everyone has an opinion on design.
STILL TO SORT:
- 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