Resources | Open Source Design

How to Join

Mon, 01 Jan 0001 00:00:00 +0000

Participating in the open source design community can mean engaging in discussions about design in open source, joining our community calls or organizing events.

Often, people who join the community are designers working on open source software, developers interested in design or people from other professional backgrounds.

There are no formal requirements to take part in the community other than following the code of conduct.

Communicating well

In order to keep the Open Source Design community a warm, welcoming, and safe place we ask that all participants read and adhere to the Code of Conduct.

Participation channels

Our account on Mastodon is @opensourcedesign@mastodon.social. The account is run by core members. If you want to join discussions or want to be found, use the #opensourcedesign hashtag.

Community call

Our community call happens once per month on the first Wednesday of the month at 7pm CET (please check for when daylight savings happens in your timezone) and we meet via Jitsi: https://meet.jit.si/opensourcedesign (an open source video, chat and audio service). Jitsi sometimes asks for you to ‘login’ but this should not be required to attend a community call.

Usually, we do a short introduction round, give updates on what is going on in the Open Source Design community and anything in the world of open source design and then chat about a few topics more in depth. New people are always welcome!

Discourse forum

Discourse is used for discussions around open source design. The account creation is not restricted - feel free to join.

GitHub

GitHub is used for working on the website and the job board. The content is written in markdown, the website’s theme is implemented in HTML and Hugo templates. You can file issues and make pull requests. Before submitting a pull request, it is best to open an issue first to describe the suggestion and to get feedback (except it is a fix for obvious bugs or spelling mistakes). Please do not submit AI-generated code changes, issues, documentation or code reviews.

Ways to contribute

Contribute design work

Open source projects post design requests on our job board. Some are paid, many are volunteer. If you have a project that needs a designer, you can post a job there too.

Come to events

We run and attend events throughout the year - meetups, conference devrooms, and design sprints. Browse upcoming events or help organise one.

Support us financially

We accept contributions through Open Collective - one-off or recurring, whatever works for you.

What membership looks like

There’s no membership card or formal sign-up. You’re part of the community when you participate - whether that means posting in the forum, helping someone on GitHub, attending events, or contributing financially. If you’re consistently active over time and start taking on responsibility for some aspect of OSD, you may naturally become a core contributor. There’s no formal process for that either - it just happens through sustained engagement.

Read more on opensourcedesign.net →

Links

Mon, 01 Jan 0001 00:00:00 +0000

This is a showcase of the many websites and platforms where you can find openly licensed icons, fonts, images, tools, and other resources. You can use them for any purpose, also commercial (some works have specific licenses, so always make sure it’s fine to use).

133 resources

Projects 20

Open source projects with active design teams, blogs, and processes: good places to see open design in practice or to start contributing.

Mozilla Makers of the Firefox browser. · UX blog
GNOME Desktop environment. · Design blog · Design team · Human Interface Guidelines
GitLab Git hosting and code collaboration. · UX team
Nextcloud Data sync and sharing. · Design page
Fedora Linux distribution. · Design blog · Design team wiki
Canonical (Ubuntu) · Design blog
WordPress · Design discussion · Handbook
Drupal · Usability group · UI standards
Diaspora Decentralized social network. · UI issues on GitHub
MediaGoblin Media platform.
BeWelcome Hospitality platform.
Mailpile Mail interface. · Issues on GitHub
Ghost Simple blogging platform.
Terms of Service; Didn't Read Contract rating.
LibreOffice · Design team wiki
Trustroots Hospitality platform.
Automattic The company behind WordPress.com, WooCommerce, and Jetpack. · Design blog
XWiki Development platform. · Design wiki
elementary OS Linux distribution. · Human Interface Guidelines · Design blog
Plasma Desktop environment by KDE. · KDE · Design page · Human Interface Guidelines

Icons 16

Bitcoin Icons Open source icons made for Bitcoin applications, free to use. MIT licensed.
Circum Icons Consistent open source icons as SVG for React, Vue, and Svelte.
Font Awesome The iconic font and CSS toolkit with a large free tier. · GitHub
Font Fabulous A fabulous icon set packaged as a font, free to use. · GitHub
IcoMoon CC icons and free-to-use icon-font creation software.
IconMonstr A large collection of glyph icons, free to use and modify without attribution.
Iconoir SVG icons, MIT licensed.
Inkscape Open Symbols Open source icon sets to use as Inkscape symbols.
Mono Icons A simple, consistent open source icon set for a wide variety of digital products. MIT licensed.
Pictogramas Open source free icons.
Remix Icons Huge repository of consistent, neutrally styled icons. · GitHub
React Icons SVG React icons from popular icon packs. · GitHub
Feather Icons Simply beautiful open source icons. MIT licensed. · React version
Styled Icons Icon packs like Font Awesome, Material Design, and Octicons as React styled-components. · GitHub
The Noun Project CC and purchasable icons for personal and commercial purposes.
Tabler Icons Open source SVG icons in a visually consistent style. MIT licensed. · GitHub

Fonts 11

Some of these platforms also take submissions, so if you designed a font with an open license, submit it there!

The League of Moveable Type
Font Library
Google Web Fonts
Libre Fonts by Womxn
Open Foundry
Open Source Publishing Foundry
Velvetyne
Use & Modify
FontForge Font editor.
Metaflop Parametric font editor.
Type:Bits Collaborative type design workshop.

Images 11

Pixabay
Flickr Creative Commons
Gratisography
The Stocks
StockSnap
NYPL Public Domain Images Public-domain digital collections of the New York Public Library.
unDraw Open source illustrations.
Interfacer
Open Doodles Free sketchy illustrations.
Unsplash
Pexels

Creative Commons media 4

Media from big platforms published under Creative Commons licenses.

Openverse Search over 800 million openly licensed images and audio files (formerly CC Search).
Wikimedia Commons
YouTube Creative Commons licensed videos on YouTube.
SoundCloud Creative Commons licensed sounds and music.

Design tools 18

Design discussion also happens right on a project’s issue tracker, for example at GitHub: get an account, identify design issues, participate, and open new ones. A »Design« label groups them, like in the Nextcloud issues.

Pen & paper Mockups and prototypes without hi-fi Photoshop work.
draw.io Diagrams, mockups.
Pencil Mockups.
Penpot Mockups.
Quant UX Mockups, UX testing, heatmaps.
Krita Art, digital painting.
Blender 3D rendering, animation, textures.
darktable Photo workflow.
RawTherapee Photo workflow.
digiKam Photo management.
GIMP Image manipulation, compositing.
Inkscape Vector elements, print export.
Synfig Animation.
Natron Compositing, VFX, motion graphics.
Scribus Page layout, desktop publishing.
DisplayCAL Color calibration.
Kdenlive Video editing.
Figma UI design, wireframes, prototypes.

Color 6

Blend CSS gradient generator.
Leonardo by Adobe Color contrast generator.
Tanaguru Contrast-Finder For finding complementary colors.
colors.lol Overly descriptive color palettes.
Color Hunt Color palettes for designers and artists.
Nof Complementary Color Palette Generator.

CSS frameworks 8

Bootstrap Fully featured, mature HTML, CSS (LESS), and JavaScript.
Foundation Fully featured, mature HTML, CSS (Sass), and JavaScript.
Basscss Lightning-fast, modular CSS for designers.
Bourbon A simple and lightweight mixin library for Sass.
Kickoff A lightweight front-end framework for scalable, responsive sites.
Space Base A Sass-based responsive CSS framework.
Rebar Simple, lightweight HTML and CSS (LESS).
PatternFly A community of designers and developers building a UI framework for enterprise web applications.

Design reads 11

First Rule of Usability? Don't Listen to Users Jakob Nielsen, 2001.
10 Heuristics for User Interface Design Jakob Nielsen, 1995.
Principles of User Interface Design Joshua Porter.
Ten Principles for Good Design Dieter Rams, 1970s.
A Beginner's Guide to Finding User Needs
Don't Make Me Think Steve Krug's usability classic (book).
The Design of Everyday Things Don Norman's design classic (book).
Humane by Design
Human Flourishing Design Guide
Designing for Trust Data trust by design, principles, patterns, and best practices.
Inclusive Design: Cards for Humanity

Open source design reads 6

Free Software UI Havoc Pennington, 2002.
How Not To Design a Portfolio
Open Design Now Book.
Coordinating usability & testing in Free Software Thesis, 2011.
Barriers Faced by Newcomers to Open Source Projects A systematic review by Steinmacher, Silva, and Gerosa, 2014 (research paper).
An Exploration of Fedora's Online Open Source Development Community Ethnographic study by Diana Harrelson, 2010 (research paper).

Community & inspiration 10

Other nice stuff in the design and open source space.

Libre Graphics magazine Print magazine.
Libre Projects Collection of nice open source web apps.
Libre Arts News for creative professionals using free software (formerly Libre Graphics World).
Libre Graphics Meeting Conference.
Beautiful Open Beautiful sites for open source projects.
Open Design and Hardware Group OKFN open design and hardware group.
PIXLS.US Free and open source photography. · Software list
Photos of Design Research On Wikimedia Commons.
Checklist Design A collection of UX and UI best practices.
Untools Tools for better thinking.

Learn to code 9

Focused on HTML, CSS, and JavaScript. Ideally to implement your own suggestions, but also to better discuss with developers and understand why and how certain things work and don’t work.

Mozilla Developer Network Great web dev documentation.
Transitional Interfaces, Coded For good animations.
Codecademy Interactive tutorials.
Git basics GitHub's guide to getting started with Git.
code.org
Egghead Video courses on web development.
tota11y A bookmarklet to check that your website is accessibility compliant.
Open Source Guide: How to Contribute to Open Source
Course: How to Contribute to an Open Source Project on GitHub

Learn to design 3

Hack Design Free design lessons by inspirational designers.
Designlab Design courses with mentorship and projects.
Voice and Tone Mailchimp's guide to writing good copy.

Read more on opensourcedesign.net →

Bibliography

Mon, 01 Jan 0001 00:00:00 +0000

Unsustaining the Commodity-Machine – Commoning Practices in Postcapitalist Design
Selçuk Balamir · Amsterdam School for Cultural Analysis

article 2021
How Nextcloud simplified the signup process for decentralization
Jan C. Borchardt · Opensource.com

article 2020
Use your artistic skills to help open source
Jeff Macharyas · Opensource.com

article 2020
Open Design, Libre Graphics: Why terminology matters
Ana Isabel Carvalho, Ricardo Lafuente · Libre Graphics Meeting Saarbrücken

talk 2019
Designing with not for - an observational report on the Wikimedia Movement
Hanna Petruschat · IxDA Berlin

talk 2019
Copy This Book. An Artist's Guide to Copyright
Eric Schrijver

book 2018
Open-source identity design for Simple
Daniel Burka

article 2018
State of Open Source Design in 2018
Victoria Bondarchuk · FOSSASIA

talk 2018
A Beginner's Guide to Finding User Needs
Jan Dittrich

book 2018
The Least You Can Do About Usability in Open Source
Victoria Bondarchuk · FOSSASIA

talk 2017
Connecting design, culture, art, and technology across the archipelago
Kathleen Azali · FOSSASIA

talk 2017
Expectations from Open Source Designers
Ecaterina Moraru · FOSSASIA

talk 2017
Authorship alternatives, free / open source
Loraine Furter, Eric Schrijver

article 2016
Design, meet Open
Dan Makoski

article 2016
Everything is a Remix Remastered
Kirby Ferguson

video 2015
Non-response, Social Exclusion, and False Acceptance: Gatekeeping Tactics and Usability Work in Free-Libre Open Source Software Development
Mikko Rajanen, Netta Iivari, Arto Lanamäki

paper 2015
How to get designers involved in your software project
Nicole C. Baratta · Opensource.com

article 2015
A Designer's Guide for Transitioning to Open-Source Software
Ryan Gorley

article 2015
Why You Should Design for Open Source
Jina Anne · 24 ways

article 2014
Open Source Design
Una Kravets

article 2014
No-one Starts From Scratch: Type Design and the Logic of the Fork
Eric Schrijver

article 2013
Designing In The Open
Brad Frost

article 2013
Open source graphic design
studio ponnuki

article 2011
Usability in Free Software
Jan C. Borchardt

paper 2011
Design in Open Source
Mark Boulton

article 2009
The Public Domain: Enclosing the Commons of the Mind
James Boyle

book 2008
The problem with open source design
Chris Messina

article 2008
Fundamental Issues with Open Source Software Development – User interface design
Michelle Levesque · First Monday

paper 2004
Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity
Lawrence Lessig

book 2004
The Usability of Open Source Software
David M. Nichols, Michael B. Twidale · First Monday

paper 2003
Choosing our Preferences
Havoc Pennington

article 2002

Read more on opensourcedesign.net →

Why one should be familiar with projects and their structure

Mon, 01 Jan 0001 00:00:00 +0000

How to start as a designer in an open source software project? It seems to be both very simple and very difficult: Simple because the formal barriers to participation are low: You do not need to be hired or show a certificate to contribute or participate in FOSS. Difficult because most projects do not have design projects that one can easily start with so involvement in FOSS as a designer can mean a lot of up-front clarification and effort to understand the needs of a FOSS project.

A common process is often described as one can just ‘pick up’ a task in an open source project, and do a task based on one’s professional competency or interest: Some dialog is confusing? Propose a better wording or layout! The software looks old-fashioned and dated? Create a new style or design system! A function is confusing to use? Create a design based on current simple/usable interface techniques, customized to the needs of the project!

These are all valid design tasks and valid design solutions. They are not wrong, but also, such solutions almost never get implemented for many reasons, each unique to the FOSS project.

The infrastructure with its focus on single issues suggests that one can solve single, self-contained issues and it also matches the culture’s assumption that »everyone can contribute«. A lot of that culture and infrastructure is geared towards code, not interface design or any kinds of design practices.

But even for code, such quick, self-contained contributions are rare. They might apply best to abstract tasks like changing to a more efficient algorithm that still gets the same data and returns the same data. But most code changes interact with other parts of the code and quickly introduce ripple effects. In well-maintained and well-structured codebases these ripple effects are contained, but even to know that they are contained and do not cause a mess usually requires knowledge of the codebase, or the to know the right person to ask. This means, to contribute you need knowledge of the context even when contributing in code, the medium that infrastructure and culture are tailored to. And this applies even more to design contributions that are not received graciously or as easily with the culture and infrastructure of open source projects.

This means that design contributions usually require knowledge about the project one contributes to.

What the technology (programming language or framework) that creates the user interface can do and what not.
What users want to do with the software
What other contributors think the software should do.

The last two points are not always the same; many users want a replacement for a commercial product, many contributors want them to see their software as independent from such assumptions. They say that they are not Photoshop or MS Office, even though a free version of that is exactly what many users would like to have, since what they know will be intuitive for them.

It’s important to observe, and to understand how the project and the communication work. This can often be best explored by making small suggestions or changes rather than general redesigns that assert how design should be done, which easily miss what project might want to do and what can be done with the available technology.

Read more on opensourcedesign.net →

Typical Tasks in open source design

Mon, 01 Jan 0001 00:00:00 +0000

Many of the below suggestions are accessible and non-invasive ways of getting involved in FOSS projects. This doesn’t mean you cannot attempt a large, ambitious project that attempts to ’re-design’ or change much of a FOSS project’s interface or experience but as first or early contributions those are often met with concern and caution. The FOSS project has to know that you will be there through the entire time for a large contribution project. It’s best to start small, actionable, visibly valuable and understandable for those not familiar with design terms, processes and practices.

Improve Labels

What is this?

Finding better, more concrete labels for buttons, menus and input fields.

How does it help?

Labels shape expectations—and these expectations should match what the software actually will do.

Example: Don’t use implementation langauge in labels

In this issue on the inkscape project (via @ltlnx) user Adam Belis suggests to replace lables like “Insert node at min X” with “Add node to Left”: Instead of terms referring to variable names (min X) the new lables use everyday concepts (to Left).

When and why does it work?

Adjusting labels is often easy, since they are commonly stored separately from the code and changing the labels usually does not mean that code needs to be changed. There are two risks when changing labels:

Existing users are familiar with the old label and that the change will be confusing to them.
The new label is longer than the available space, which is particularly relevant in languages like German, which typically have longer words than English.

Resources

The Grammar of Interactivity
10 Usability Heuristics, Match Between the System and the Real World.

Improve Icons

What is this?

Finding concrete and familiar icons for buttons, menus and input fields that match the style of the currently used icons.

How does it help?

Icons should be familiar to the user and signify the functionality they stand for. It is important that all icons follow a common style lest they make the interface look messy.

When and why does it work?

Like labels, icons are stored separately from code and can be easily changed. Risks of changing icons are:

Existing users are familiar with the old icon; the change will be confusing to them
Changes are good in theory but introduce unfamiliar elements
There is no easy to recognize standard icon for what is meant and thus a label might be better.

Resources

Myth: Icons enhance usability

Layout of existing dialogs

What is this?

Redesigning layout and widget choice for existing dialogs.

How does it help?

Choosing widgets that are more familiar and more appropriate to the task increases usability. A meaningful layout that matches the user’s idea of the system and the user’s tasks helps to understand what needs to be done.

Example: Use semantically correct widgets

”Interface standards violation, using checkboxes instead of radio buttons” points out that in a dialog in penpot, checkmarks are used for mutually exclusive options, which, following interface standards, is what radio buttons or dropdowns should be used for.

When and why does it work?

Improving the layout of existing dialogs is actionable, since the changes focus on the interface itself and thus do not cause ripple effects through the code but only change one place. This needs basic knowledge of the available widgets and how they can be laid out.

Risks:

Suggestions that can not be realized with the available technology
Not being familiar with the tasks users do might lead to suggestions that look visually more clean but do not match the user’s needs.

Suggesting new features

What is this?

Suggesting features based on user needs.

How does it help?

Suggesting features that are based on actual user needs helps to make applications more useful.

Example: Trash in Penpot

When one deleted a project in Penpot, one would get a warning, but upon confirmation the project would be gone. This is easy to habitually dismiss. A well-established mechanism that does not have the problem is implementing a trash-can, a temporary container from which deleted files can be retrieved again if one accidentally deleted them or changed one’s mind about them.

This feature was suggested by a user in the penpot community forum, jan transferred it to a github issue. One user commented “I’ve never needed this feature until today 😭”, implying that they indeed accidentally deleted projects. The feature request was picked up at some point, so that penpot now has a trashcan for deleted files.

The feature is relatively simple, since it uses an established metaphor and mechanism and was probably also not complex to implement, as it relies on similar components as other ways to organize projects.

When and why does it work?

The first question is: Is the feature actually useful?

A feature from another software that its users like and which you tried yourself and found to be helpful, too (relatively easy).
A feature based on observation and documentation of what you and/or other users do (relatively hard)

The other question is: How hard is this to implement? These are factors that usually lead to difficulties:

If the feature needs custom UI elements, it is usually harder to implement than a feature that can use existing widgets like input fields, menus or toolbars.
If the feature relies on complex, hard to define behavior: “If this happens, it does… but if that happens…”. Anything that “guesses” the wanted behavior is often impossible to get right.
If the feature needs a technology that is not part of the product at the moment. This is not easy to find out without knowing at least a bit about the code, but if developers mention that it would mean to introduce “command-pattern”, “real-time evaluation”, or “caching”, it hints that this is possible, but difficult. It might be worth it, but it needs a dedicated developer.

Read more on opensourcedesign.net →

Tools and Code

Mon, 01 Jan 0001 00:00:00 +0000

There are basic tools that most projects use. It is helpful to be familiar with them, since this is where most coordination and work is done. There are tools for designers, some of them open source, too, but these tools vary and, if you are a designer you are likely to know them already. This article is about the tools that developers use.

Issue trackers

An issue tracker allows to register problems with the software and discussions about how to solve them. Prototypically, this is a technical problem like the program crashing in a certain condition. However, issue trackers are often used to collect all sorts of problems with the software, including usability problems and feature requests.

It is helpful to first read some existing issues to understand how the issue tracker is used and what tone of communication is typical. Don’t forget that many (but not all) issue trackers allow the use of images, which can be helpful for clarification of problems and to make redesign suggestions.

Code

Just knowing how to program in general is helpful to follow some conversations of developers. However, to contribute code you need to know the specific programming language that is use on the project and often how to use other code (libraries) as well. You also need knowledge of the code of the project. Code of a non-trivial project can span hundreds of pages, and is usually not easy to understand. Usually, people learn how to contribute code by doing some small changes in particular parts of the code and then slowly expanding.

Git

Open source programs are created in one or several programming languages. Different programmers can contribute code. Combining code from several programmers is done via a version management system. The one used most widely is git.

Even if you do not code, you might get in contact with git, since git is often used to manage non-code contributions as well, so icons, translations or text for documentation might also be added through git despite it being a tool made to manage source code – so it more or less struggles with other kinds of content. A simple change or addition is usually not too difficult, though even that will get you in contact with the ideas of commiting changes and then pushing them to a central sever to share them. Git is sadly notoriously difficult to learn, so the use of a graphical git client or a platform like GitHub, GitLab or Gitea is helpful for beginners.

Mailing lists

Particularly older projects use mailing lists instead of web forums for their discussions. It is a way to send a mail to one address and have many people receive it, making to good for group discussions. To read and to post you need to “subscribe” to the list. Before you post, read along for a bit to see if the mailinglist is right for you and to know what tone is common on it.

Read more on opensourcedesign.net →

Resources | Open Source Design

How to Join

Communicating well

Participation channels

Social media

Community call

Discourse forum

GitHub

Ways to contribute

Contribute design work

Come to events

Support us financially

What membership looks like

Links

Resources directory

Projects 20

Icons 16

Fonts 11

Images 11

Creative Commons media 4

Design tools 18

Color 6

CSS frameworks 8

Design reads 11

Open source design reads 6

Community & inspiration 10

Learn to code 9

Learn to design 3

Bibliography

Why one should be familiar with projects and their structure

Typical Tasks in open source design

Improve Labels

What is this?

How does it help?

Example: Don’t use implementation langauge in labels

When and why does it work?

Resources

Improve Icons

What is this?

How does it help?

When and why does it work?

Resources

Layout of existing dialogs

What is this?

How does it help?

Example: Use semantically correct widgets

When and why does it work?

Suggesting new features

What is this?

How does it help?

Example: Trash in Penpot

When and why does it work?

Tools and Code

Issue trackers

Code

Git

Mailing lists