Those that have great code content will say “design is for sissies”

And artsy sissies like us cannot tolerate continuous vitriol for weeks. It’s only in opensource software that new users are laughed at and insulted.

Hear, hear!

@Chrissie, interesting article but I think the point was a little laboured. Most open source projects would highly benefit from designer interaction and usually know it, I think actions definitely speak louder than words here so I’d love to hear how your collaboration gets on. It’s fantastic that you’re doing it!

We’re putting a lot of design resources into *some* of our open source projects but there are so many that are just “code only”. I think the fact a lot of the default open source hosting sites are literally just “Hello, welcome, here’s how to get the code” doesn’t help; it’s offputting to say the least. Maybe a new site that can put a friendlier face on open source projects could help… if landing page design is a big factor. There’s a ton of research that could be done in this area too. Nom.

Those that have great code content will say “design is for sissies”
Those that have great design are busy making more money or seek inputs only if it adds significant promotion. deviantart-style “community” behavior is very little.

And artsy sissies like us cannot tolerate continuous vitriol for weeks. It’s only in opensource software that new users are laughed at and insulted. In commercial product communities or even art communities, people talk to each, not yell, curse and swear. Even on the street, computer illiterate people *talk* rather than swear and insult strangers.

Given this state of affairs, your call to disarm is quite courageous and admirable. To say it with a popular slashdot meme – I, for one, welcome our new designer overlords! :-) (or overladies …)

A small note to the possessive coders out there:
If you don’t like people forking your code, why release it as opensource? The bunch who yell “Get Off My Lawn” are already old, in being over-protective of their code.

I researched the article pretty well, but there’s also a ton of information I have yet to stumble upon and learn from.

One of the things I was trying to be clear about is that there is a difference between heavily funded open source software projects specific to UI development (e.g. Mozilla & WordPress) and organic projects like Lithium, where the work truly comes from a corps of unpaid volunteers, who are contributing back to the community out of a sheer passion for open source.

Also, what we’re attempting to do is document a set of best practices (if we can find them) and create a system that can be adapted by similar OSS projects either sans funding or low on funding, who are open to partnering with volunteer designers.

It sounds like you’ve got great experience in this area, and I’d love to hear more and get any advice you can offer! Please hit me up @ chrissie AT jjomedia DOT com to talk more, if you can!

Also, excellent use of Typekit on your site! Hope to talk more!

Best,
CB

Another thing that makes it difficult is that design isn’t as matter-of-factly measurable as code is. With code changes, if it performs faster, is less lines, is more abstracted etc, then it’s not that hard to get community buy-in on making the change.

With design (visual, ux, even copy writing) it gets a lot harder and too often discussions turn into “yes but *I* think…” arguments. Usability testing is the best way to get ‘hard’ data that can convince developers.

Mark Boulton was hired last year to contribute design and interaction for the Drupal administrative user interface. He’s written about his experiences here: http://www.markboulton.co.uk/journal/comments/design-in-open-source#more-768

Yes, it’s not easy, be prepared to explain and defend your vision ad nauseam across multiple bug reports :) It takes time to build your karma in an open source community. But I’ve found that especially the senior developers within a project fully realize the importance of good design and ux. Both parties have to invest in finding a shared vocabulary for discussing design that steers clear of ‘bike shed’ discussions.

Famously Automattic contracted with Happy Cog to help with the design of the interface for WordPress, as well as the website. My project, Habari, was founded on the principle that everyone has something to bring to the table.

We had Michael Heilemann and Khaled Abou Alfa design our admin UI and create a HIG for the developers to follow. That was over 3 years ago.

Is it easy to be a designer working with an open source community? No. Of course it isn’t easy being a newcomer of any persuasion when it comes to OSS. Being a designer and a developer myself I have found most designers find it difficult to deal with the critical nature of open source development, as well as the “everyone in the pool” angle to producing work product.

When you throw your work over the wall, everyone gets to pick at it and make suggestions/changes. That doesn’t sit well with most designers. It is a different mindset, a different way of approaching your work. The moment you throw it on the mailing list or in revision control it is the communities work.

Check it out at http://opensource.mit.edu/papers/commons_identity.pdf

From what I’ve seen there are two big barriers to entry for a designer that wants to contribute to an open source project.

** Not being able to actually implement the changes they suggest **

If a designer just wants to contribute image comps for someone else to implement, that’s fine, but it’s a lot of work and might not end up being the first thing on the project maintainer’s todo list.

“Sounds good, send a patch” is a common response when someone requests a feature, and it works well for the guts of most projects.

Some designers might know how to implement their changes (especially for web applications and project web sites — many designers know HTML/CSS). If they don’t it’s not necessarily a deal breaker though. They could find a developer that also wants to improve the design and work with them to implement the changes.

** Not knowing how to use version control **

Even if a designer has the ability to implement their changes, they still need to know how to work with version control if they want a decent shot at getting those changes into a project.

*Many* open source projects keep their sites/documentation/etc in a Mercurial or Git repository. If a designer comes along, improves a few things and sends a pull request (or even emails a patch) I think most developers would pull it in a heartbeat.

Without using version control there’s simply too much overhead.

Receiving a blob of CSS or HTML, for example, is painful to deal with compared to a real diff. You have to find out what the heck changed (especially if it’s a blob of HTML that was originally generated from a template), figure out the original version the designer was working from so you can merge other changes, and so on.

Version control is what keeps programmers from going crazy. A designer that wants to contribute to a project will get a lot further if they learn the tools and use them.

In short, we developers know we’re bad at design, we wish we were better, and we’d love to have help from designers. We just need to stay sane while doing it and have enough time to continue working on the non-design parts of the project.

Thank you so much. I just want to say I love PHP Women :-) As a non-dev, I’m definitely intimidated by oss projects, but the Lithium team, couldn’t be more welcoming, easy-going, and enthusiastic to give this a try.

Hope to meet you someday!

Cheers,
-CB

There are overarching feelings of “design doesn’t matter” and “my project should be good enough on its own”, but fundamentally all open source developers want to make their projects look better. We just don’t know any designers. I’ve tried to include designers in my open source projects with very little success. The only times I did succeed is when I already had a relationship with the designers.

One solution I’ve found was becoming a designer. All developers should become designers. All designers should become developers. At least a little bit. Otherwise you end up with developers who can’t make anything for humans and designers who can’t make anything.

There will always be a line between developers and designers, but we need to blur that line a little more. Open source developers need to get smarter about the way designers can help them and the designers need to help. Teach us what you can do for the project and we’ll love you for it.

Show us how to bring our projects to larger audiences and you’ll be welcome every time.

And now a shameless plug for my latest open source project. Check out the WordPress Editorial Calendar. This is what it looks like when designers and coders work together.

And, Ryan, you’re awesome!

To me, you present a succinct call to action and act as an example in this process. I truly believe the more we push this effort the more we improve the quality of open source software.

Looking forward to working with you Chrissie!

so i encourage all open source hackers and project initiators to think about design. and then *do* something about it. and your comment at the end of the post really gets to the heart of the issue, though perhaps unintentionally. you say maybe “most open source software projects function fine without the added layer of design.” how can design be “how it works” if it’s an “added layer”?

so the first step is to stop thinking this way. coders need to update their thinking, as well as designers. if your project has any kind of ui aside from the command line, and especially if it’s meant for people who are not experts in the domain, then start with design. don’t wait to add it.

finally, i think more designers should be *starting* open source projects. designers involved in technology, whether it’s web or application design, have ideas and understand problems that need to be solved, and working with coders could initiate great projects. i think a sense of ownership is key to making the design more than a come-in-and-make-it-pretty kind of thing.

anyway, great post.

(from a developer who is painfully aware of her own limitations outside her sphere of expertise!)