
Designers, how do we get you guys to contribute to open source projects? - stephenson
http://forrst.com/posts/Designers_how_do_we_get_you_guys_to_contribute-gVn
======
pieter
My girlfriend tried to design an icon for an open-source app she uses, but the
experience hasn't been really great. I think the way developers in open-source
projects communicate doesn't really work with designers.

She sent the photoshop source file and a png to the mailing list, but was told
to send in a patch instead, which meant she had to learn how to use git to
check out the repository, add the icon to the repo, and then generate a git
patch. Only after that, she was told that they couldn't use the photoshop
source file because they didn't have photoshop. Finally, one of the developers
imported the file into the GIMP, changed some stuff on the icon without
discussion, botched the output and then added that to the project. That was
enough for her to not try doing something like this again.

~~~
beaumartinez
> _Finally, one of the developers imported the file into the GIMP, changed
> some stuff on the icon without discussion, botched the output and then added
> that to the project._

Isn't that part of the "contract" of FOSS? You relinquish copyright of your
contributions to the project as a whole. (I can see how this can bite
designers who don't know much about the FOSS movement.) I suppose in this
situation it's a _good_ thing they use a version control system for designer
contributions.

It certainly is bad practice to change something _major_ with no discussion,
but when you contribute something, expect it to be changed.

~~~
jacobolus
You’re missing the point. If an open-source project treated a programmer with
the same lack of respect, I wouldn’t expect any different a response. There’s
no “contract” that says I have to volunteer my time to someone who won’t even
appreciate the donation.

On the other hand, I’m not sure it’s fair to indict all open-source projects
based on one side of a single story. I’d be interested to hear more of the
details in this case; sometimes people walk away angry about simple
misunderstandings and mixups.

~~~
rue
I understand what you're saying…but as an open-source contributor I certainly
expect that my code can be modified for various reasons.

I guess a “work of art” would feel more personal, and (unless given a tight
spec of elements that must be included) is more of a candidate for either
rejection or admission as-is. For changes I'd certainly expect a request “can
you add a wizard hat on the ninja?” rather than someone modifying it
themselves.

That said, I don't think it's a one-way street (and good design is sorely
lacking). The designers should have or take an interest in the general
operating procedures just like they would for any paid work.

~~~
ErrantX
Yes, but.

Imagine you wrote a piece of code and then spent a couple of hours optimizing
it to remove various bottlenecks etc etc.

You submit the patch, it sits there for a couple of days, then a designer
(bear with me) comes along, takes a look, cuts out your optimisations to
"simplify the code" and applies the patch.

You'd feel pretty rejected.

~~~
reneherse
Indeed, it's also a matter of actual vs imagined competency. What is the point
of contributing to a project if someone with an outsized notion of their range
of skills can come in and botch up previous work?

The issue is whether the person modifying or reiterating a work is competent
to do so; We hear all about it with programming, but there is such a thing as
"cargo cult design" too.

Also, I don't see it as whether a specific design contribution is "a work of
art", with all its associated assumptions of involubility; in this context
design is ever changing according to the evolution of a project.

------
replicatorblog
1\. Ask for help - I'm a designer that reads HN everyday and I wouldn't know
where to look if I wanted to participate in an open source project. Is there a
list? The problem is most OS software aside from GIMP/Inkscape doesn't make
its way in front of designers often.

2\. Make it discrete - What needs to be designed? The entire UI and workflows?
The application icon? The internal navigation glyphs? Redesigning an entire
app that has tens or hundreds of contributors can be daunting, but getting
someone started with something small can be a gateway.

3\. Leave it alone - One of the other commenters mentioned how a designer
contributed something and then it was overwritten and ruined. Typically you
don't want to have dozens of designers all working on a project unless there
are fairly strict guidelines to work from. Have a working group at the
beginning that can set the UI tone and create guidelines from that. Also a
small review committee to review changes is smart, just as they do for code.

4\. Version Control for Dummies - Put together a short explanation of how to
use the version control system of choice, assuming no knowledge beyond
Photoshop. Or find someone on the technical side who can be an
intermediary/GIT trainer. The human part of this is very important.

Do those things and you should see prettier projects in the future. I know I'd
love to get involved, but have no idea where to get started!

~~~
Andrex
Funny you mention GIMP, that's one OSS program that needs a UI refresh badly.

~~~
nnutter
I have not really seen any evidence of GIMP being that poor of a UI. The
biggest complaint is the multi-window interface for which single-window mode
is currently in alpha and should be out in a few months or so.

~~~
mkr-hn
It's a little clumsy if you're working with two images on one screen
(especially when drawing/painting with references). A single-window interface
has a menu option that lets you tile them.

I'll be happy when the single-window version is released.

~~~
idonthack
most complaints about gimp's multi-window UI are really complaints about
window management.

window management should be handled by the window manager, not by each
application.

~~~
d5tryr
That may absolve the app of responsibility, doesn't make the UI any better
though.

------
lotides
Why I don't contribute to open-source projects:

I feel like a second-class citizen around developers. And I don't want to
venture in to the lions den. After all, I "just make things pretty", right?

I hate politics. Many open-source projects are a power-struggle with
entrenched developers guarding against change.

Design is all about visual relationships. Making a change to one small aspect
to the design effects everything else. This is very frustrating in an open-
source environment, where parts of the design can be changed by the masses
compromising the integrity of the whole.

Our industry doesn't appreciate it. Employers don't care what open-source
projects we've contributed to. It's all about paying clients.

~~~
tibbon
I think you've hit the nail on the head with your final point. As programmers,
you can point to your Github repo as your resume. In the design industry, they
don't care about your Github repo (or will even understand it), and they'll
bug you about some part of the program that you didn't even contribute to or
were responsible for.

~~~
lovskogen
Depends who you want to work with. 37signals keeps on emphasizing that they'll
look up possible new hires. Having a repo on Github is all positive.

~~~
AaronChampagne
I've just heard about 37 signals this past month or two and am thinking about
putting out a portfolio for them. Would they actually care about OS projects
as a designer?

~~~
v21
They'd love you for it.

------
jbk
I really wish I knew how to get great designers...

VLC is a product, that is widely used, usable (not the mac version, though),
but it is extremely ugly.

It is quite hard to get designers to help us (redesigning all the buttons for
example) for quite many reasons. The biggest reason is that we don't speak the
same language.

Many designers don't understand the criticism that usually comes around with
each modification in open source project. Many developers don't understand how
to speak to designers in a polite way (they think they speak normally, but it
isn't perceived as such).

Also, many (not all of them) designers don't understand the difficulties of
usability, and sometimes mistakes it with "shiny". Usability of a desktop
application is way more complex than a website, and the current trend of
"removing functionalities" is not always welcomed by developers...

However, I don't loose hope :D

~~~
zavulon
> usable (not the mac version, though)

Heh. Obviously as VLC's developer you know better, but FWIW I've been using
VLC on Mac OS X extensively, as my primary video player. I don't think it's
unusable, or ugly at all.. I can't be the only one, can I?

~~~
jbk
Well, to be honest, VLC on Mac has this 2 windows paradigm that is very
complex to understand those days...

I've been working with a designer to try to do this mockup:
<http://www.jbkempf.com/~jb/VLC_mac.png>

~~~
radley
I don't understand the move to one window. I don't think the confusion is due
to two windows, but rather because your library window looks like a player by
default.

There's a 90/10 rule - only put the stuff you use 90% of the time in the UI.
The other 10% goes in the drop menu.

In the case of your mockup, I doubt people are EQing every movie they watch.
They don't really use the library, so prev/next/loop/shuffle and lib are all
unnecessary in a player view. I expect in most cases people use VLC to play a
single video, something that a native player won't.

Further, your time display doesn't show total time - only position. Most
players show current position and a total time/countdown toggle. The best
include an end clock (i.e. your movie will finish @ 1:32am).

What new type of user are you trying to attract? Once you know that, it's
pretty obvious what to do. Ping me if you wish to discuss (radley@ cloud.tv /
vj.tv). I'm a big fan of VLC and build/design UI/UX & media players for a
living...

------
Mushon
Replicatorblog's response made very good points. Though I think the FLOSS
community should start by appreciating the huge differences between developing
code and developing design.

I am a designer and a FLOSS guy and I have actually researched this subject a
lot, both in practice, in writing and in teaching. The essay I written for
Smashing Magazine a few months ago might be relevant in this context, it is
called "The Case For Open-Source Design: Can Design By Committee Work?"
[http://www.smashingmagazine.com/2010/09/01/the-case-for-
open...](http://www.smashingmagazine.com/2010/09/01/the-case-for-open-source-
design-can-design-by-committee-work/)

I identified three major challenges: 1\. Scratching an Itch 2\. Granularity
3\. Encoding/Decoding

I go through a few interesting positive examples for collaborative design
processes and then try to propose some tips to making it work. Finally it's
about a mix between leadership and openness, but this leadership has to be
respected even if it does not translate to algorithmic metrics (like Google's
A/B Testing of 41 shades of blue, more:
<http://stopdesign.com/archive/2009/03/20/goodbye-google.html>)

If you prefer to go through this essay as a 20mins video presentation, you can
check it here: <http://vimeo.com/18761002>

I start at 00:27:50

I realize this is a pretty long and complex answer for what sounds like a
simple question, but in my experience this is really revealing the boundaries
of the Open Source collaborative process as we know it and it will not change
unless we help this model mature.

~~~
lovskogen
Good research work, the article looks interesting – I'll watch the video too.
Looks like you do alot of stuff, what are you working on now?

~~~
Mushon
Thanks :) I'm actually working with illustrator Galia Offri on another project
along the same line as this thread. It is called Wikipedia Illustrated
(<http://WikipediaIllustrated.org>) and is trying to address a similar
question: "Illustrators, how do we get you guys to contribute to Wikipedia?"

------
us
Open source works great for developers for many reasons. On the flipside,
rarely does it benefit a designer (although not always true).

1\. It exposes a programmer's code work for all to see. If it's bad, you get
more than just critique. Others can point out what is wrong with the code but
even better, they can correct the code or help you see what is wrong. If it's
good or great, it makes for an amazing addition to any developers resume for
hiring purposes.

The same can not be said of designers. Sure they can get feedback and people
can often point out what's wrong, but these feedback are often more vague.
Rarely do they get a walk through tutorial of how to do things better,
actually having someone go in and show them how to fix their design flaw
(something that happens a lot on the coding side). Pointing something out and
having someone help you solve your design problem are not the same thing.

2\. I don't know about others but to me, a designer benefits more from having
their own portfolio rather than something that they may have contribute bits
and pieces together for a project. As a designer, I don't see the value over
my own portfolio which I can get enough critiques on without having to
contribute to an open source project. As a developer, I see a need but think
in terms of what designers benefit out of this. Open source designs are not
the same as open source software in all cases. As an entrepreneur, I hire
designers base on independent skill sets which is extremely hard to measure
when people are co-designing small projects.

3\. Just a comment but it would seem this is geared towards a developer who
can't design and want open source designs but where is the benefit the
designer is getting out of this. Surely there is a better argument. For the
record, I'm not arguing that designers can't benefit at all. I just don't see
it outweighing the benefits a developer would get in the same scenario.

~~~
Sirupsen
It's definitely easier for developers to contribute to open source projects,
they can just dig into the code and easily contribute patches.

Designing for a project requires a lead to a greater extent to keep the design
consistent, whereas programming is more defined and concrete work: "This is
wrong, fix it." If the issue no longer occurs after the patch is applied, work
is done. Design work is more abstract in that sense.

The designer's benefit would defiantly be in having the project in their
portfolio. Additionally I don't think too many projects need an entire design
team, for most projects one would be sufficient increasing the portfolio value
you are talking about. Most people contribute to projects they use, adding
functionality they would like to have themselves. I'm sure that is something
that would motivate designers too.

~~~
us
I'm sorry but I strongly disagree (btw, I'm not the one that downvoted you; I
don't have that option).

Why should I contribute to an open source project when I can do something like
design a simple killer wordpress theme that may gain major adoption and use
that as reference for my work than a single open source project catered to a
single developers open source work that may or may not get used heavily. That
or is only used in parts. There are tons of free designs out there, how often
have you or anyone you know hiring designers reference how awesome or widely
adopted their one off icon kit has been or something similar? Not happening.

~~~
mnutt
By designing a killer Wordpress theme, you _are_ contributing to an open
source project...

~~~
sixtofour
And maybe this is the nail that should be hit on the head.

WordPress is _designed_ to _easily_ accept design products like themes.

------
sambeau
The biggest battle designers have when working with developers is getting
across the idea that design is not "how something looks", but, "how something
works".

This means that, ideally, the design process comes before the coding process.

It can be very dispiriting for a designer to come into a project somewhere in
the middle to find that major design decisions have been made and cannot be
overturned. It is common, for instance, to find open-source UI that mimics the
data structures of the code rather than the foibles of a human brain.

If a designer were to join an open source project they would be seen as
"trying to change everything", "dumbing down" and "trying to take over". Which
would, in a way, be true - and probably exactly what was needed.

I've often wondered if we designers could start open-source projects: start
designing, publish & document our designs, release our work to the open-source
community and wait to see if anyone bites.

I have seen this happen before and it was amazingly successful: Coverflow.
Andrew Coulter Enright, a designer and artist, published a design for "how
iTunes should work" on his website. Jonathan del Strother, a Mac developer,
bit and published an implementation. Cover Flow was purchased by Apple Inc. in
2006.

I'd love to see something similar happen with a larger open-source app. Any
designers out there want to join me in starting a site for exactly this kind
of workflow?

<http://en.wikipedia.org/wiki/Andrew_Coulter_Enright>
<http://en.wikipedia.org/wiki/Cover_Flow>

------
recurrie
Reframe the question: How would you get designers to _start_ open source
projects? The open source world is pretty much structured around serving the
needs of those who can code.

In the field I work in, designers and developers have equal standing, and need
to create a middle ground of shared workflow, technology and design processes
that balance development and design.

In most open source projects, there are too many barriers to entry (real or
perceived) for designers to see themselves as participants. Everything from
version control systems that don't provide any real benefit for visual
designers to project leaders that see design as "eye candy" all reduce the
appeal to designers.

Remember, too, that designers have loads of options if they want to work for
free. You know all those "Build a Facebook clone over the weekend, it will
look great on your resume" jobs on Craigslist? Designers get that kind of
pitch ("Design us something for free; it will look great in your portfolio")
constantly. Open source projects looking to recruit designers need convey some
tangible benefit to participating.

In the design world, peer recognition doesn't come out of working on open
source projects that their designer colleagues have never heard of. Every
designer I know of will jump at the opportunity to do really great work, for
free if necessary. Looking at the open source projects I'm familiar with, few
of these look like the kinds of places where a designer would expect to create
really great work.

~~~
flink
That's an interesting question. I also wonder how you would get designers to
start open source projects without getting the opposite of a "developer-
centric" project where developers are the second class citizens.

Can you (or others) elaborate a bit more on what a place where a designer
could expect to create really great work would look like? Is it more of a
personal aesthetic thing (something that is personally interesting)? Is it
related to some of the other points in this thread (unfriendly tools, gruff
face to the community, lack of control etc.)?

~~~
recurrie
That a tough one - it's always easier to identify a problem than craft a
solution. Here's a shot:

* Projects should include screenshots or other visuals (no matter what their state of completion) on project pages. Browsing the usual Github page shows no visuals at all. Not every project is going to be heavily visually oriented, but most of the project pages I see look like a giant "Designers not wanted" sign.

* An environment where design can happen collaboratively. The "design thinking" ethos requires understanding what the problem is before trying to solve it. To really involve designers, some sort of sandbox where ideas can be expressed as something other than code, feature requests, bug fixes or "64x64px.png goes here." Would be ideal - a way to say "I see this working like this..." in a way a visual designer can express. Lots of discussion happens via chat, etc, but pretty hard to access if you're already feeling excluded.

* Something recognizable as a team structure. If projects need a designer, a project page noting an unfilled slot on the team would be ideal, along with some details. Icon designer? UX specialist? Copywriter? What do you need?

* Integrating rapid prototyping tools for design exploration. One of the tough tasks I find in interaction design is to get a feel for how a complex system is going to work without building it. I've see everything from Flash to Filemaker Pro used to build working models, to then be built out in another tool. Photoshop comps are great, but not a great way to simulate a lot of complex interaction models. If designers and developers are going to speak the same language, it's probably not going to be code.

I teach at a university of the visual arts, and I've often wondered about
finding a way to engage students in open source projects, but to be honest,
I've always been to fearful of what the outcome might be to really push this.
My worry is that for a lot of developers, a logo and a few icons is all they
are looking for. Fair enough, but not terribly attractive to the types of
designers that projects really need.

Finally, designers need to understand what a big deal software is. You almost
never see application design (web, desktop or mobile) represented in the big
design award annuals, and the types of things that do get in tend to be
gimmicky, Flash-driven web sites for consumer products.

~~~
flink
Yeah, I know what you mean about solutions. Actually solving the problem at
hand is a whole different world than finding the problem.

I know that I've been guilty of not making/updating screenshots very
frequently - they tend to be a pain. Something to keep in mind for the future,
though.

A collaborative design environment is a hard one. I've found it really useful
for code in the past but as you said, that doesn't help a whole lot on the
design front. The only practical thing I can think of at the moment is sending
links to static images back and forth over chat, but that doesn't get over the
barrier to entry on chat.

The only other things I can think of there would be screencasting (which
usually costs money and tends to be a little more one-way) and VNC but that
requires a lot more trust than I have for strangers (or than I would expect
them to have for me).

Team structure might be a hard one. I can't speak for all developers but I
generally don't like having a formal team structure if it can be avoided. Do
you think that the role part is important or just discrete, specific tasks? If
you were thinking of more of a control thing, that might be even harder.
Unless I'm the only developer, I generally don't expect to have much control
over a specific area. Then again, I also wouldn't expect people to be jerks
and completely change something I did without at least talking about it first.

As far as rapid prototypes for web applications go, I LOVE wicket
(<http://wicket.apache.org/>) because your templates are pretty much CSS and
HTML (none of that pseudo-code in templates crap) and you have pretty much
complete control over your javascript. You can mock up an entire site in HTML
and only need minimal changes to get it working with backend code.

I don't have as much experience with desktop applications but I wonder if
rough HTML/CSS might also work for the interactive parts. I'd have to think
about that one and it might be an excuse to try mocking up a desktop app I've
been thinking about.

I don't know if you'd be interested or if it would work, but I'd be up for at
least talking about less uncertain ways to get your students involved in open
source.

I have a couple of ideas for projects that I'd love to get design help on as
long as I'm not completely left out of the design loop. Getting more people
(and especially non-coders) involved in open source and helping in education
would be bonuses.

------
jt2190
OK, I'll bite... The article states that the only way to improve the user
experience is to bring in a Designer (loosely defined as somebody who doesn't
code.) I'd argue the opposite: Having a programmer who really understands user
interfaces and user interaction is the critical, missing piece.

Now that I'm in deep, let me go further... A motivated programmer can learn
the basics of interaction design very quickly, and get the user interface to a
point where it at least doesn't suck.

------
ohkine
I guess the first thing to do is to actually _care_ about it to begin with. I
have tried submitting suggestions for improving UIs (and even more trivial bug
reports like some element is not centred properly or a text box is 1 px too
tall) and it seems like many developers simply don't want to hear about it.
They don't have an eye for it, they don't think about how other people might
approach the interface, so it just doesn't bother them. They consider your
criticisms and suggestions to be nit-picking or pedantry and they either get
defensive or they just dismiss them outright. Even if they don't resent them,
they often consider them to be so low-priority that they're not worth putting
much effort into.

The second thing would probably be, like others have said, just to ask -- and
part of asking for help is making sure that you are able to actually receive
the help. Perhaps partially because of the above, and also because i am not
really a programmer (yet!), i have come to be hesitant to even try submitting
anything. The process is too complex. I feel very uncomfortable with patches
and pull requests and test cases, so please don't make me deal with them.
Offer a 'dumbed down' way of submitting our contributions, or, perhaps, make
somebody a liaison between people like me and people like your developers.

Large open-source projects in particular -- Firefox, GNOME, KDE -- are ones
that i have the most interest in contributing to, but they have extremely high
barriers of entry for people like me. (To a relative outsider it kind of seems
like the design direction of these types of applications/suites is strictly
controlled by some high-up cabal of developers, though, so perhaps that is
intentional.)

edit: wording

------
patio11
The same way you get developers to work on OSS -- have their high paying
corporate job either order them to do it or ignore their participation in it
during work hours.

------
jrwoodruff
During my day job I play the lone designer in an organization built from day
one with only software engineers. I suspect the problems that I face there are
similar to the problems faced by designers in OSS.

1\. Communication. Developers use a completely different language than
designers. If I come in talking about alignment, developers are thinking
'right left or center justified?' When developers start talking about
recursion, I go to sleep.

2\. Attitude. Often developers seem to think of designers as 'artsy' types,
and design as 'nice-to-have,' which is to imply not necessary.

3\. Attitude. Designers often get emotionally attached to their work and get
discouraged or give up when someone disagrees, has a different idea or wants
to go another direction.

4\. I can do it myself. A LOT of developers - particularly less experienced
ones - think design is something they can, and are, successfully doing
themselves. After all, it's just pixels on a screen, who needs photoshop,
right?

5\. Small changes. Developers often make small changes to designs. 5px extra
padding here, no margin there. Blue is blue, right? We'll just use that 10x10
icon the designer did for that page for this 25x25 icon we need on this page.
This drives designers insane.

6\. Eyecandy. This goes to a lack of understanding of the design profession;
many think design is just slick icons and pretty colors. Developers who have
worked with talented designers know that designers can improve entire systems,
helping streamline work flows and adapt the system to actual users.

7\. Bad designers. Oh yea, there's -a few- of us out there that just picked up
GIMP yesterday and think a 600 x 600px favicon should be fine. Even designers
capable of really good work may not understand why a 2400x1600 image cannot be
used thumbnail-size on the page. This is sad, but I've seen it.

8\. Lack of trust. Developers may have worked with bad designers in the past.
Most likely they have, actually. They'll likely limit the designers
interaction to making icons and css rather than involving them in the system
design and planning. Designers may not give as much as they could because they
don't trust the developers to value their input or even understand and execute
their contributions well.

Of course, that's not to say all projects are this way, and in fact, when I've
been involved in projects from early-on, this is very much not the case.

However, I've run into the above issues in my professional career more than
once, working face-to-face with people. Trying to make the relationship work
online, in projects as distributed as OSS projects are, that's very difficult.

But I think it can be done. For distributed design to work, designers need to
be brought on board from the beginning, in the planning phases. The initial
designer or designers would have to be responsible for creating a clear
vision, clear guidelines, and a well-documented style for future contributors
to follow. All contributions would have to adhere to those guidelines, and
developers would have to be as adept at spotting violations as designers.

Part of the problem here is also making designers aware of projects to work
on. Designers generally join different message boards (if they join message
boards at all), read different blogs and generally don't run in the same
circles as developers, possibly with HN being one of the exceptions. I'm not
sure how to change that...

~~~
rorrr
Design IS optional and isn't as is important as you make it sound. Look at
craigslist, hacker news, reddit.

~~~
mgunes
All three are very deliberately designed the way they are, and function well
thanks to those designs. Good design is often "as little design as possible",
as Dieter Rams' final principle for good design goes; avoiding overdesign is a
merit, not a deficiency.

~~~
rimantas
One of may favorite sayings is "Good design is invisible".

------
wccrawford
Pay them.

Don't -ever- expect anyone to contribute for free. When they do, treat them
special instead of taking them for granted.

That seems like common sense, but that's what I see all the time when it comes
to programming projects, open source or not.

~~~
Charuru
Sounds unfair, developers don't get paid, why do designers do.

~~~
us
Because developers greatly benefit from participating in open source projects,
designers usually don't. That said, developers also make more money than
designers do and in a tech centric world, there are more needs for devs than
designers. That's why.

~~~
nir
For most OSS devs, the benefit is having a more interesting portfolio,
especially skills they don't get to use in their day job. Wouldn't this work
the same way for designers?

------
tzs
The same question could be asked about documentation writers. Most of the
reasons given here as to why it is hard to get designers apply to
documentation writers, too.

For open source games, the same question could also be asked for music
composers, and again most of the same answers apply.

It might better to ask why is it so easy to get coders to contribute.

~~~
FiddlerClamp
Yes - for example I'd love to keep up my tech writing and marcomm skills by
contributing to open source projects, but I have no idea where to start.

~~~
flink
I don't know if this is what you were looking for, but one option would be the
Fedora project.

General: <http://fedoraproject.org/en/join-fedora>

Specific Areas: <https://fedoraproject.org/wiki/Join#Content_Writer>
<https://fedoraproject.org/wiki/Join#Designer>

One of the proposed long term goals (still going through the approval process)
for the Fedora project is to lower the barrier of entry for new members (Not a
great link but one of the better ones that I could find:
[https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-12...](https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-12-13#GOAL_.234:_It_is_extraordinarily_easy_to_join_the_Fedora_community_and_quickly_find_a_project_to_work_on.))

DISCLOSURE: I do work for Red Hat on the Fedora project but my interest in
open source is also personal. I suggested this because it seemed appropriate
and I'm familiar with it.

~~~
FiddlerClamp
Thanks -- I'm going to apply! I have always had a Linux flavor on dual-boot on
my PC for learning and tinkering. I'm more about end-user and customization
documentation rather than admin/install, but hopefully they can use me!

------
VomisaCaasi
I am someone who has got a foot in both of these worlds. Though, I code slowly
and I can't really draw either.

IMHO, designers don't usually feel any importance of open-source projects
because most of them/us are used to things that are aesthetically pleasing,
and they would not want to burst their/our bubble. If they we're given a
choice between free Linux (assuming Adobe Suite works on it) or OSX, they
would be getting OSX because it suits to their world, they would be even
paying extra if it was to cost more. Also, they want something that just works
and don't really care whether they can see or edit the source, since their
coding experience usually ends with HTML and CSS, hence the apathy.

I've worked with quite a broad range of websites and the less control I had
over my work, the less I enjoyed it. Solution? If you're able to find a
designer for your project, make him feel special by taking him as an equal
member of the team and give him full control of the design side (aesthetics).
More so, let him start from the scratch. Although, arguing about functionality
(UI and UX), which has logic in it, should be encouraged, you don't want to
offend him by saying his designs look bad, because a criticism coming from a
programmer is as bad as it gets. Coder's blogs are usually coloured dark blue
or green, that tells a lot. That's also the reasons why most designers hate
working for Google. One hour meetings whether a line should be 1 or 2px thick?
If you don't really like what he is doing, ditch him.

~~~
jamesteow
I disagree with some of this. I think a designer should have the skin to take
some criticism, even from a programmer. When my programmer co-founder
critiques me, I sometimes think, "shit, I must've really screwed up for him to
mention something." And yes, I do think it results in better work as long as
there is justification. I think that generally, one cannot be too precious
about aesthetics unless there is a clear vision with core principles.

------
Nadienka
That is a great topic of conversation and potential source of something new
coming out. I am an interaction designer myself and wondered about this issue
more than once.

Designers are always seeking for some projects to do even with no money
return. There are several platforms that work based on this sharing skills
principles, but often money based. Usually seen as a contest platform where
the client requests and users (designers) responds buy uploading their work.
Examples of this are Crowdspring www.crowdspring.com and in a smaller scale
DesignRider www.designrider.com. Why not build a sharing platform like these
for open-sources projects?

For a best results return, the briefing (instructions, guidelines, rules,
project intention description, for instance) should be clear and precise. For
instance, by specifying the format in which you want your design work will
already scan designers skills and give you more to the point results. Of
course, conversation is always welcome, a mailing list /forum in such platform
to discuss and share knowledge between developers and designers cannot hurt
either.

"Designers are scared of developers. Developers speak a foreign language, they
are like aliens." Simon Hørup Eskildsen. I don't think is there such a big
barrier between designers and programmers or developers. It is time to drop
that assumption. A web based platform that gets both working on several open
sources projects is a solution to consider and that might bring more responses
that you can think of.

------
yangman
I'm surprised no one has brought up how _difficult_ it often is to incorporate
design changes into an existing project unless it has been developed with such
accommodations from day 1. Even a seemingly simple software project can be
monstrously complex under the hood, and something as innocent as "this button
should be larger than the rest" can mean weeks and months of proofing, coding,
and testing. (e.g. Firefox 3's back button)

Whether a change comes in the form of code fixes, documentation improvement,
refactoring, design changes, or infrastructural modifications, the burden of
understanding the potential scope of damage and doing the actual work is
always, always on the contributor. Convincing another to take on the work on
their behalf is always a possibility, but it should not be hard to see why
design changes proposed through such a channel will often be pushed to the
back of the queue, unless for some dire need.

Designer or coder, there is no excuse for not doing due diligence in making
sure a contribution is a good contribution.

Looking at the discussion so far, there appears to be at least some consensus
that non-trivial effort above and beyond the (hopefully) expected hand-holding
must be dedicated to designers in order for them to become good contributors.
And, in corollary, the natural conclusion is that it's unrealistic to expect
designers to put in the necessary effort to become good contributors on their
own.

Following from the above, the more crucial questions, I think, are "How do we
convince projects that they should go out of their way to attract designers",
and, "Do you really need designers? Really, really, need them?"

------
Stormbringer
It's a power thing. Developers will (grudgingly) share power with equal or
better programmers than themselves, but the gnu version of the open source
movement is explicitly designed to put all the power into the programmers
hands, and any non-programmers should "just learn to program".

The are two other things that programmers tend to do:

(1) we hate redundancy

(2) if something is obvious to a programmer, he thinks it is obvious to
everyone else that that is the way it should be done (despite a simple survey
of his peers revealing probably 4-6 different ways of achieving exactly the
same result).

Programmers believe that their way is better than everyone else's _and_ that
it is intuitive as well (well, it was 'intuitive' to one guy on the team (ie
me), and I'm 'smart' so that must be the best and most intuitive way of doing
it, right?)

Unfortunately, good UI design has enormous amounts of redundancy built into
it, and that if there is only one way of doing something, it is actually anti-
intuitive. A design where the user can try 3 things out and the third one
works will be hailed as a paragon of intuitiveness. One where it takes 10-20
tries to get the magic combination will be viewed as having a horrible UI.

There is also a relationship between how easy it is to do simple things and
how the user perceives the UI. Programs which make it hard (ie go read a
couple of hundred man pages in order to figure out the flags you need) even to
do simple things are viewed as bad, even if it turns out that the same amount
of difficulty can also achieve amazingly difficult things.

Basically what it boils down to is that in order to fix the design of an open
source project, you would essentially have to fork it. And having forked it
and fixed it, the high priests of the programmer cult will despise your
efforts because there is too much redundancy.

------
smag
Here's what it would take to get me to make bring my product
design/interaction design skills to open source software: * Easy way to and
keep track of 'what projects are underway now and which need HCI or UX
expertise'? * Way to speak with the team over email or IM about what UX
challenges there are, and learn the constraints * Confidence that designers
will be adequately recognized for their contributions

Reading the thread here makes me realize that we're all so specialized--and
this is a big part of the problem. UX designers need to learn to use a command
line, need to learn to do at least some coding. Likewise, software engineers
(including open source contributors) need to become more discerning about the
basic principles of human-computer interaction and user interface design (not
just visual styling). Once both roles start to become generalizing
specialists, better collaborations will just happen.

------
retlehs
Related article from last July by Kenny Meyers:

Where are the open source designers? copywriters? information architects?
interface designers?

[http://thenerdary.net/articles/entry/the_open_source_designe...](http://thenerdary.net/articles/entry/the_open_source_designers)

------
sgdesign
I think nobody has mentioned the most obvious reason: 90% of open-source
projects are used by other developers, not by designers.

Making it hard to contribute can be a barrier, but it's not the number one
reason. Designers redesign apps, icons, and sites all the time just for fun,
even if they know that their contributions have no chance whatsoever of being
used.

Designers want to contribute to something that they care about, and the simple
reality is that a majority of open source projects are made to appeal to
developers, not designers.

In other words, if you want designers to contribute to your open source
project, make it something that they will use and be passionate about.

------
armandososa
Back when I discovered CakePHP I was just a print designer trying to become a
web developer. I was so thankful for the work of the CakePHP foundation that I
felt really bad for not being able to contribute back (I had no money, and no
real programming skills).

So, when they called out for help to design their official website I jumped in
and they gave me the opportunity to contribute with my design.

As a happy side effect, that design gave me _a lot_ of exposition so I could
finally left my dayjob as a print designer and start my career as a freelance
web dev. It's fair to say that the link on CakePHP's footer brought food to my
table for 4+ years.

------
eagleal
Adding on others (lack of recognition/respect, very difficult to submit
changes if you're not a dev, etc).

One reason designers usually don't contribute to open source, is because
they're paid to improve UX/UI on their commercial competitors. If
GIMP/Inkscape had the same UX/UI as the Creative Suite, there wouldn't be
market for the latter (this is what designers are paid for, unlike
developers).

This allows more startup opportunities or companies like Canonical (parent
company of Ubuntu) to provide a free and open source product (Canonical
actually has dedicated designers).

------
adev
I'm seeing a lot of the replies here are only thinking about designers working
on the final visuals of a project. While, yes, a designer might make the icon
better than a developer, what about the actual interaction processes that
designers often define? Those can be system level changes that need developers
to do, which means the designers need to be working along side, or ahead of
developers, not after.

Too often when I try open source software I see just a default list of options
that really makes no sense, or I often see the developers trying to
accommodate every need that might exist, resulting in overly complex user
interfaces.

It takes someone (a designer usually) with knowledge of human interaction to
know when a toolbar with multiple tabs works or when to keep it simple.
Without doing this, designers are (in an overly simplistic description) just
applying colors to existing boxes.

To get involved, Designers need a clear place to find projects to help on, and
a clear way to help on projects -- as designers aren't about to open source
code, install it on their own system and then begin work on the project.

I consider myself to pretty knowledgeable in the tech community and work as a
full stack designer/developer, yet I have absolutely no clue where or how to
get involved design-wise with any open source project. There's no "design"
section on github or google code that I've ever seen :)

------
ary
Just as you expect that non-programmers have no clue about code, you must
accept that non-designers (you) have no clue about (user interface / user
interaction / graphic) design (keep reading).

Obviously this isn't an absolute, and there are exceptions to this rule. The
most important thing I can get across is this; _End users do not, and will
not, think like you do about your software_ (Read 10x). The reason you _must_
get perspective outside your own is because yours is tainted beyond repair
when looking at your own project.

So, what can you do to make your open source project more appealing to a
designer?

 _1) Let go of preconceived bias when it comes to your UI / look-and-feel._

Someone more interested in the visual appearance and usability of your
application is going to want to make changes to the workflow. Just as you test
your code, test your design to make sure the designer's assumptions hold up.
As a president once said, "Trust but verify."

 _2) Develop a clear understanding of where your designers implementation
responsibilities end and yours begin (and vice versa)._

Which is to say, know their limits, and know your own. If they don't know how
to integrate their work into your project then either help them or find a
third party that can. If you don't know how to integrate their work into your
project then have them help or find a third party that can. Focus on your
strengths. Nothing is more dissatisfying that seeing your work butchered.

 _3) Check the ego at the door/keyboard/whatever._

This applies to everyone involved in any way, shape, or form. Objectivity is
the ideal, but lets be realistic. Personally I know more people who have had
bad experiences volunteering / interacting with open sources projects than
good (including myself). While this is anecdotal I think it's still important.
Don't mistake popularity with success, and don't let popularity become
validation for your lack of social skills. The people at the other end of your
emails, IMs, IRC channels, etc are just that... people. The golden rule gets
turned up to 11 when someone decides to take some of their _free time_ and
donate it to your cause.

This is hardly comprehensive, but I think it touches on a few points in ways I
have yet to see in this thread. Keep doing your good work.

------
kayoone
Make the project appealing to designers. For instance let the application have
themes/skins and have a marketplace where designers can sell their themes on
their own. That way designers dont have do deal with the developers and can
work on a complete consistent design. Wordpress and others are doing similar
things.

If a designer has created multiple layouts he could also make one for free to
get people interested in the other "premium" ones, so its not that every
design has to be a payed one.

------
jiipee_2
Many reasons why this is hard. 1) UI design needs to be understood and
implemented as a whole. This does not sound good for most of developers. I
don't know why. 2) Of course, good UI designer (I wish I am) can create bite-
sized chunks - divide UI plan into small parts that are more manageable from
the development perspective. UI designer still has to be able to say what
parts need to be there before the overall improvement is justified - in other
words, when the resulting UI can be evaluated. 3) Developers have always an
opinion what is good UI. Many features that make something very good to use
for non-tech-people, or easy to learn, do not match into developer view of
good UI. 4) Development environment tools, vocabulary and tools are not UI-
designer friendly. 5) Dealing the above issues in daily work does not leave
energy to have the same problems at free time.

------
pontifexmaximus
This whole discussion just makes me as a designer want to go and help some
project.

As a developer, I've already helped a few opensource projects.

What's missing? A centralized location for designers to meet developers.
github is unfortunately designer-unfriendly. It's developer oriented, and
code-centric. Fixing github into having a design aspect will surely repair
this.

I once tried to help out interpals.net. The usability of the site is non-
existent, and the visual elements look like they were made by a four-year-old.
Thus, I've come up with sketches and UI elements and gave it to the founder.
He was amazed and seemed eager to work with me. At the end wanted someone more
experienced. By that, he meant someone who can code, not only design. He
wanted a developer. At the time I wasn't one.

Beggars can't be choosers. His site continues to be dead-ugly.

I really want to help anything because I need to exercise design as much as
coding.

------
mediamaker
Im a designer and I would be happy to contribute to open source projects.
contact johnatjohncozendotcom if interested.

------
tealtan
The best way to get designers involved is to ask them the question, "What
don't you like about this software? How would YOU change it?"

This shows that you respect their input and are inviting them as a peer to
think about the project both visually and on a systems planning level.

I'd also recommend having a design lead who can bring on other designers as
needed. The design lead should be responsible for making all design decisions
and ensuring consistency. He should also be regularly communicating his
decisions and reasoning to the community. (Mark Boulton did great working with
the Drupal community, for example.)

When you give feedback to designers, try not to say "Take this out." or "Make
this bigger. Or change this color." Tell them _why_ (this is very important)
you want something changed, and let the designer come up with a solution. And
trust them to make the right one.

~~~
tealtan
Asking them that question also gives you an idea of whether they understand
the project and if their ideas for the design align with your own.

But don't ask them to whip together a "quick" mockup, that's considered spec
work and is frowned upon in the design community. No design work is both
"quick" and good.

------
sfled
Seems like by "designers" it means you would like contributions from "graphic
designers", yeah?

Just my humble, but designers, like programmers, can grow as their knowledge
and experience encompasses more techniques. From drawing to composition to
color theory to typography to XHTML to CSS to Javascript to PHP to Perl to
ASP.NET/C# etc, et, al.

So what kind of designer were you looking for?

BTW, from a visual design point of view, the classic education is to first use
a monospace typeface at a single size, then use other typefaces and multiple
fonts and weights, then get to the fancy curves and Photoshop bullshit. But
honestly if the designer couldn't make it work in Courier, they may want to
consider another career.

So there you go. Did you want gratuitous eye candy or did you want a talented
and educated artist who also knew booleans, conditionals and how to hit up a
database?

------
johnthedebs
I think the root issue preventing more designers from working on open source
projects is that, unlike development, design doesn't improve when the work is
distributed.

Development is modular – pieces can be added, removed, or changed out for
other pieces. Several developers can work on the same project at the same time
and not step on each others' toes (esp. thanks to modern version control).
This works great with the open source model.

Design, on the other hand, benefits from being unified and consistent. The
best-designed projects have one designer, or a small group of designers
working together closely. This doesn't work well with open source at all.

This becomes pretty obvious when you compare Mac systems to Linux systems.

Until this issue is resolved (by, eg, open source projects bringing on
dedicated designers) the symptoms are unlikely to go away.

~~~
jamesteow
"The best-designed projects have one designer, or a small group of designers
working together closely. This doesn't work well with open source at all."

This is a pretty important point that gets overlooked. I think designers can
help make something more intuitive and generally more readible but if we're
talking about a cohesive person, it usually has to come from one person with a
vision for the project.

------
Entlin
It's all down to different cultures. Open Source projects, the way they
currently are, are driven by coders - version control, bugtrackers, IRC etc -
all geeky things.

Designers work in different environments: personal discussions, meetings,
illustrator, photoshop, other web communities (like dribble and obscure
sections at flickr).

If you ask a designer to add stuff to your repository, you're asking him to
adapt to your way. Most designers aren't going to learn git.

To embrace designers means that you include them in your processes and tools.
And let them in on strategic discussions - that's where good design is most
often lacking in OSS.

If you continue with a Codeocracy where only check-ins are valued and the guy
with 100k lines of written code is king, you're not going to convince many
designers to help you with their free time.

------
EnderMB
I'm a developer with decent design skills and I would love to work on an open-
source project in both roles, although I have looked on CodePlex a number of
times to see what I could join. I rarely ever see any design openings, and
more often than not a lot of solutions in project repositories don't even
compile.

It's easy to say that designers are needed, but anyone who has spent time in a
design community of any kind would know that there are loads of designers out
there that would love to get their stuff out there. I'd love to do design work
for a decent open-source project while I get used to the code base to help
with the development; I'm willing to bet that many others are in the same
boat.

------
englishVoodoo
Beyond the obvious difficulties in the very nature of git and stuff like that
to be very technical. Without knowing to much about open source projects it
really feels it's such a tremendous difference in scope.

As a developer, you can contribute small patches, bits here and there or step
in deeper and create new features or improvements within the current feature
set.

As a designer, the bits and pieces option really is no option. Design can't be
applied like that. It needs to be applied to the entire project in a
consistent manner. Both visuals and user experience thinking. This makes it a
far bigger commitment, something I imagine not everybody is willing to do.

------
joelrunyon
The hard part here is the nature of the craft.

Developers have rules. Code has syntax. Everyone follows the same rules and
code comes out the same. One developer can pick up where another left off.
It's very clean cut. Designers are different. There are "rules" of design, but
each designer is different and have their own styles. That's not a bad thing,
but when you get multiple (hundreds, even) of different developers with styles
and no "strict" rules of design, it can make for a very hodge-podge project
that...well...looks like 100 different people designed it

[Not a designer or developer but I work with both and serve as a "translator"
between the two]

~~~
joelrunyon
maybe the solution is a set of design rules for project/community/development
that everyone agrees to.

------
lwhi
I'd suggest it might be more worthwhile thinking in terms of development teams
and UX teams.

I think the appeal of working on an OSS is that a developer gets to hone their
skills and work collaboratively. It's a way to contribute (give back), to gain
experience and to gain kudos.

I don't think the same collaborative aspect works as easily for design -
because design problems are perhaps less easily worked on iteratively as a
group.

UX, as a discipline, involves problems which can be solved collaboratively -
and lends itself to team work. Design that's born from UX research tends to
solve problems which have been more clearly defined from the outset.

------
OzzyB
Easy, create a "Benevolent Designer For Life" title for your project, then
assign to one very talented person.

Designers are simply unable to work in committee as stated by others here...

~~~
jasonlynes
Agree with this one. Try to start the project with a designer. Design is
something best consulted from the get-go.

------
tomelders
I think a lot of designers would love to work on open source projects, but I'm
a designer and a developer myself and even I feel that the creative input
wouldn't be taken seriously.

If an OS project assigned a Creative Director, that may help lead the way for
other designer to join a project.

Also, Source Forge and GutHub and the like aren't going to cut the mustard for
Designers. There needs to be somewhere like them, but tailored for design.

------
EGreg
I would also like to point out that when the design is orthogonal to the
development, there's lots of beneficial open source design out there.

I often use icons with GNU or CC licenses, for example. If only I could find a
site with website designs like I can for icons (iconfinder.com, findicons.com)
that would be great! I'd get a professional designer to use the open source
design as a base and just tweak it.

------
EGreg
I think that in order to critique design objectively, you need a set of
standards and guidelines for design, like the Apple iOS Guidelines. These can
be open-sourced themselves, and forked for various projects.

Without these guidelines, it will be as tough to tell the designer what to do
as it would explaining an obscure C++ error without any reference to C++.

------
jarin
Maybe it would be a good idea to put some donations together and actually hire
designers on contract. That way, you are less likely to run into the problem
of developers overwriting design changes willy-nilly, and you get a higher
quality of design work that can last for several rounds of iterations.

------
endergen
I believe it's because open source projects are designed to be modular. Design
on the other hand is holistic. So it's hard to integrate design into an
existing project unless it's an open source project such as a CRM where
basically designers can make nice skins of the entire project.

~~~
AaronChampagne
Fuck that. Good design IS modular design. If your designer isn't following
best practices like modular design then they are NOT good designers. Learning
to work in non-destructive modular ways was one of the most important lessons
for me when I transitioned from art to design.

~~~
endergen
Hahaha. No....fuck.....you! :)

I agree with what you are saying, I don't think it contradicts what I intended
to articulate. I was trying to get across that dropping a modular piece of
code such as say a Database system(Like MySQL) into a project gives you a huge
chunk of functionality which you can then build on top of. I can't think of
the equivalent for Art, except for widget sets or something along those lines.
Or a grid/layout template that doesn't require you to then go and have to
update any existing art to mesh well with the new art.

Now to be fair: you can come up with the equivalent of the MySQL situation
where say you start the project with say a widget set and just match it's
style moving forward.

I could probably match all my concrete coding examples with a modular art
project but I think there are two issues that in general going to come up:

1) A lot Graphic Designers are not to strong at building modular art as it
requires a more rigid process. There are exceptions of course, but we are
talking about in general why there aren't as many Graphic Designers
contributing to Open Source projects. (Wordpress though is a good example of
where there are tonnes of Themes provided by Designers).

2) Reusing a popular Design can make your project look more derivate than
unique. Where as with code this is less the case. Though with popular Widget
sets such as the design by Sofa for Cappuccino
([http://ajaxian.com/archives/cappuccino-07-aristo-ui-theme-
en...](http://ajaxian.com/archives/cappuccino-07-aristo-ui-theme-engine-
nib2cib-and-more)) is a good example of Great design that maybe benefits from
this familiarity as it's easier to grasp what widgets do when you've used
other Apps using them.

------
cjm
They need control over the portion of the project they're working on, and
these portions should be larger rather then smaller. There shouldn't be a
committee trying to design something.

------
rimantas
There is a problem: for a meaningful contribution designers must be involved
from the very beginning (hence "designer" not "decorator").

~~~
wolfgke
Then the rational choice for designers would be to contribute to open source
projects that are in a very early state.

But as far as I know, they don't do so. So we have a contradiction.

------
gidea
Make something beautiful that we all believe in. Then people will support that
idea.

