Convincing Designers to embrace OS methods

Design Lounge Communication and collaboration
1

Here is the initial documentation of the Analog Open Source Collaboration workshop from day 1 of the Open Design summit.
jan-andreas

We focused on the barriers preventing designers from becoming involved with F/LOSS design, or using open source collaborative methods.
What I would like discuss from this point is, well, obviously we can’t change all of these things at once… but which issues are worthwhile for OSD to work on solving? what kind of activities or resources can we as a group provide to help lower barriers, allay fears and increase understanding?

This is how the process worked:

First we did a couple of tests to understand the commit process:

#102 - smiley CC-BY Sam “drew a face”

#103 - smiley CC-BY Julian “add beard”, builds on #102

smiley

Then participants were then asked to list bullet-point answers to the following question:

“What are the existing barriers for non-open source designers to adopt OS collaboration methods?”

#104 - opaque CC-BY @simonv3 “initial problems”

  • opaque code repositories
  • lingo
  • lack of infrastructure
  • for-profit industry and motif

#105 - myfile.page, CC-BY @victoria-bondarchuk “first ideas for problems”

  • Ego
  • Art is not a team work
  • Art vs Design

#106 - what.txt WTFPL, @jan “first thoughts”

  • No knowledge of the concept of open source
  • Status quo is protecting ideas

#107 - stuff WTFPL, @andreasn “initial commit”

  • Hard to build software
  • Hard to share source files (or unused to doing that)
  • Hard to know what needs to be done

#108 - text.txt CC0, @Incabell “first draft”

  • scared of their work being stolen -> someone makes money with it
  • not getting credit
  • they don’t even know of the possibility
  • other people messing up their hard work
  • abusing their work for bad things -> it being connected to their name

#109 - reasons CC-BY, @evalica “impediments”

  • Github commit flow (visual UI vs console; remembering commands -> fear of mistakes / revert
  • fear of showing something not final, being iterative
  • open source tools vs. commercial debate (Inkscape, GIMP, etc)
  • fear of criticism
  • lacking knowledge of the “developer” persona
  • -understanding / using the tools in OS environment (not being actual users of the tools)
  • not having the final decision on the acceptance

#110 - design_issues_v1_final_thistimereally_v2.md AGPLv3+ @bertob “initial commit”

  • they don’t know where to start
  • they don’t see the value because they don’t use it themselves
  • not a part of design culture
  • no ethical background in free software
  • proprietary tools / platforms

#111 - problems.docx CC-BY @hns “start of thoughts”

  • ugly existing examples
  • tech heavy conversations
  • used to closed source software
  • fear of copyright “loss”
  • concept of designer as artist i.e. has ideas, and gives shape to them as one author.
  • missing experience of remix, building on the idea of others.
  • perception of ‘design by committee’

#112 openstruggle.txt CC-BY @h4nna “first draft”

  • don’t see how to live off that / earn money
  • designer’s “ego”
  • only learned to design for proprietary products -> change of habits/thinking needed
  • lack of framework for designers.

#113 abstract_art CC-BY Julian “[init] start word collection”
abstract

This work does not appear to have been committed…

How to scare off a designer:

  • lack of likeminded contributors
  • lack of recognition
  • blurry and unclear ways on how to contribute
3 Likes
2

The participants were then asked to cut up their photocopied works into individual problems, and displayed them on the display desk. They were encouraged to take a problem written by somebody else and explain it/expand on it.

Hard to share source files (or unused to doing that)

#114 stuff-more.txt WTFPL @jan

Everyone uses different software and filetypes or workflows. Even if you do share it’s then hard to collaborate.

Art vs Design

#115 myfile.page CC-BY @simonv3 “details for myfile.page”, builds on #105

Design is a job and it is rigid and requires payment. This is pushed by famous designers like Mike Monteiro who have been working hard to legitimize design as an integral part of product design that stands and sets it aside from Art. Art is for passion, design is for work and paying the bills.

Not getting credit

#116 myfile2.page CC-BY @victoria-bondarchuk, builds on #108

  • Culture of Art Education
  • Open Source - triumph of a community over one mind.
  • Open source teaches you to lose your ego.

Tech-heavy conversations

#117 tech_conv CC-BY @evalica, builds on #111
When receiving feedback, contributors might reference:

  • technical constraints
  • other features inside the product that duplicate functions
  • discussions in general, but a beginner might not know if the discussion is about their proposal or about something else.

Ego

#118 myfile.page CC-BY @Incabell, builds on #105

People might be insecure in their work and the thought of “better” people coming in and “enhancing” their work makes them nervous. They might see it as a criticism or feel like they failed and thus would rather not expose themselves to peers and be vulnerable. It’s easier for them to pretend that their work is already perfect.

#119 smiley CC-BY @jan “fixed issue: ‘needs a nose’”, builds on #103
nose

Lack of infrastructure

#120 opaque CC-BY @andreasn “add more details”, builds on #104

Tools like bugzilla and github issue tracker are for code only. It’s super hard to cram design into them. I run into cases where I’m not sure whether to attach mockups, or how to do code review.

Hard to build software

#121 - stuff WTFPL @Julian “add comment about build tools”, builds on #107
Flatpak and meson simplifies building software. Flatpak uses a manifest to define a build environment. So software can be built on many different systems.

Proprietary tools/platforms

#122 design_issues_v1_final_thistimereally_v3.md @simonv3 “question about status of tools”, builds on #110]

Thought: proprietary tools and platforms seem more advanced than open source tools, but there is no real holistic solution anywhere yet?
Is open source advancing faster than proprietary tools?

3 Likes
3

Once they had committed their additions, participants were encourage to write “issues” on post-it notes which encouraged others to take their work further - by illustrating the problem, expanding upon it, giving an example, or suggesting a solution.They then added to the work of somebody else and committed their changes.
issues

Only learned to design for proprietary products -> change of habits/thinking needed

#123 openstruggle.txt CC-BY @bertob “add diagram”, builds on #112

The industry mostly uses proprietary software, therefore educators teach these tools, therefore students learn them, therefore the industry uses them.

diagram

Issue:

Which are the biggest opportunities to break this vicious cycle?

Hard to share source files (or unused to doing that)

#124 CC-BY @evalica, builds on #114 & #117

Potential solution:

  • Use open formats when sharing (eg. SVG)
  • Use Git to commit source files in order to have the full history and ownership.
    source-files

Art is not a team work!

#125 CC-BY @Julian “add question”, builds on #105

What is the definition of art???

Status quo is protecting ideas

#126 what.txt CC0 @hns “add example, details and suggestions”, builds on #106

Explaining the idea of creative commons licenses sounds too complicated already, because copyright isn’t fully understood in the first place, and/or it’s unclear to them hy to choose the one CC-option over the other.
Also, applying CC licenses in the appropriate way feels pretty complicated or ‘in the way’ of the design outcome.

  • How to attribute authors of that Noun Project icon within my application/website?
  • How to help a designer with deciding which license to take for his/her artwork?
  • Help understand how design elements might be useful to others: “this is so specific, it’s only useful for my project.”

Opaque code repositories

#127 - opaque CC-BY @andreasn “added ideas why”, builds on #104

Instead of sticking things into Git, because Git’s “UI” is shit, and Git is bad at binary files, people “invent” their own versioning system, but the tracking of different versions gets lost. (design-issues-v1-final-this-time-reallyv2.md)

#128 does not exist. database error? :upside_down_face:

Fear of Criticism

#129 reasons CC0 @h4nna “added explanation example” , builds on #109

  • from earliest schooldays people learn to compete and to be better than others rather than collaborate.
  • they grow up thinking that educational resources are limited and they need to fight for it - same with job - unfortunately this is often true.
  • long story short: “criticism is bad” because it seems to attack my right of the position I’m holding and therefore attacks me. [These are thoughts one could have].

How can we take away the fear and improve our communication?

#130 myfile2.page CC-BY @jan “try to solve 118”, builds on #118 & #105

Potential solution:

We need to emphasize friendly collaboration and be clear that all work is iterative and everyone is learning constantly.
As such, we should also be critical of our own work, open issues on it and encourage others to improve upon it.

Getting credit - is it a goal for a contributor?

#131 myfile2.page CC-BY @Incabell “solve 116”, builds on #116

We live in a society where it is all about having stuff to show for degrees, and grade, and portfolios, as well as reaching a certain standing.
The fear of missing out on credit is reasonable in this scenario because it could inhibit our ability to reach those goals, and even worse, someone else could reach them instead of us , based on our work.

It is hard to distance oneself from this desire, even when primarily the goal might be another. As soon as this is taken away from us, we do start desiring getting due credit. Should it be the main goal? I don’t think so. Is it realistic to expect a contributor to never desire credit for their work? I don’t think so either.

commit-log

5 Likes
4

Many thanks to all the participants, and thanks for your feedback on the workshop process too!

I will turn the content of our workshop into a short blogpost soon, and I have incorporated your feedback into a bunch of issues on the Cut, Copy & Paste repository. Other suggestions to help refine the process are very welcome.

3 Likes
5

I also think it is hard. Git is something I see not as a good solution, since it is made for programmers and hand-written code.

Not directed to art, but to design, the argument makes some sense. F. Brooks argues in “The Design of the Design” for making one or two people lead architects of solutions to ensure design coherence. He also discusses open source development models, but sees them more suitable for highly modular parts of Software, like libraries and less suitable for user facing products.

1 Like
6

Thanks Sam for gathering and writing the results on the forum.

7

This post is interesting but what do “myfile.page”, “what.txt”, “problems.docx”, etc. mean? Are these filenames meaningful? Don’t make me think. :slight_smile:

1 Like
8

yep, my thoughts too - I had thought that filenames would be important to trace the development of a work over multiple iterations, but in fact the commit numbers do a good enough job of that. Based on this workshop I have changed the process to not require a filename - it’s confusing and unnecessary.
commitlog

I’ll be running the next iteration of this workshop over two days at MozFest this weekend - the topics we work on will be different, but I will also be gathering feedback from designers/artists/non-coders along the way, asking about their experience & perspectives on the open source process. This way I hope to get an idea of how valid our assumptions above are.

4 Likes
9

Ok, so it’s like how git tracks content rather than files. Makes sense. Thanks!

10

Thanks for sharing the output. Very interesting.

11

OK, I’ve published some documentation of the updated workshop that we ran on the weekend:
Cut, Copy & Paste at MozFest

The workshop itself has developed quite nicely, but I’ve also been thinking about the topic we had been working on, of convincing designers to try/adopt OS practices.

In the post, I mention some of the negatives about the '‘drop-in installation’ configuration we had at MozFest, but one of the positives was being able to see one-on-one how different people react to the open source idea.
You would be surprised how many people at a Mozilla festival don’t know about open source, but that just shows what a broad array of people are involved in ensuring the welfare of he internet.

The festival takes place on the campus of Ravensbourne College, a design and digital media school - I spoke with a lot of their students who had come by to see what all the fuss was about, and handed out a bunch of Open Source Design cards. Each time I introduced the OSD network, the first question was “do you know if there are internships available?” which is not what I was expecting.

I did some remarkably unscientific testing of the visitors to our session - I was especially keen to talk to people who were designers/illustrators/artists - and asked them about some of the topics we discussed in this thread.

A clear pattern emerged:

GOOD NEWS!

it’s not about fear, or business models, specific software alternatives, or the lack of version control tools… at least not yet.

BAD NEWS!

Nobody has heard of open source as a concept, let alone open source design tools, let alone open source design processes.

sooooo… we’ve got a bit of work to do on that front :wink:

2 Likes
12

It’s a bit sad to hear that people going to a MozFest don’t know what open source is. I guess some of them very students. At least they found sessions at the MozFest that teached them about OS, so that’s great. Thanks Sam for your work.

Regarding the internship questions, I guess it’s normal since that’s what they were looking for and fits in their target. Unfortunately, besides the coolness and principles of Open Source, it’s kind of hard to motivate young people to invest time in OS. They need money, they need experience, they need someone to learn from. OS communities often lack founding and people are more solitary and individual there.

The Job board is interesting for them IMO since they could build some portfolio pieces on real life projects that can have an impact.

Thanks Sam for the follow ups and your dedication.

1 Like
13

On the topic of internships, we could possibly put together something like a grant or see if there’s something like rails girls summer of code or google summer of code? Maybe worth its own topic?

14

Hey @simonv3, this is a great idea. We are in the early, and humble beginnings of building an app platform focused on design education and this is an area we are interested in. We empower designers and future designers to grow in their careers by connecting them to industry-specific mentoring and design education resources.

One of the big reasons we formed as a 501( c )(3) non-profit is so that we can raise money from donations and form scholarship funds, grant funds, and more so that we can help create opportunities like you are speaking of. We are currently building out a number of areas in our online platform at designmentors.org, but in 2018, I would love to focus on starting these funds and using our platform to help spread the word.

3 Likes
15

I’m the one who put Open Source Design on David’s radar. I met him at a GitHub drinkup years ago and noticed he was tweeting about his new Design Mentors organization, which sounds fantastic. @designmentors please note that a couple of us are open to getting together in Boston or Cambridge. See the Boston, MA, USA local meetups discussion and thanks for joining this forum! @dicebourbon you’d make a great mentor! :slight_smile:

2 Likes