What's in it for a designer?

* It's not scratching an itch that they have.

* It's not great promotion (design has worked on a portfolio system for generations, so they have them already - showing someone what you've built is new and revolutionary for development in relative terms, but for design that's just how it is).

* It's probably not much fun (it's a skill to work with designers and to manage a project such that it comes out well - one that most OS projects do not possess if I had to guess).

* It's probably quite thankless (by no means a universal attitude, but plenty of developers think of design as an add-on, or a nice to have - not much of a situation to be in with your work).

So why would designers volunteer for this when they could do work for themselves and their portfolio that they may actually enjoy? How many projects will provide enough exposure to make this a good use of time?

• It's great for scratching an itch of 'I want to help other people'.

• It can be good promotion. The same way a good github account can help developers, stating and showing how you have participated on a open source project that is real is good for showing you can pull through on projects and deliver.

• It can be great fun to see something you designed being implemented and working. Even more fun if people praise you for your great solution to a problem. The thing with doing FOSS as a designer, you have to take alot of control - and push for developers to code your design. It's not just delivering a PSD, you have to work with the developers.

• If you solve a real problem, people will thank you.

It can easily go the other way and your contributions can be ignored and never used, you will be reacted to with hostility by developers who think that design is an "extra" feature, and that even if you do succeed and something you do does hit a release, the overwhelming majority (nearly all) of people who use the software won't know you exist.

There are two sides to open-source development (at least, when it's not with people you know personally IRL) and one is, sad to say, generally not very pretty. Institutional hostility toward non-programmers still lives in a lot of open-source projects--usually the ones who need them the most!

(EDIT: Mind you, this isn't a reason to not at least try to contribute if you feel it's important to you, but the results are often not as rosy as your post suggests.)

That's contributing to other people's projects period.

OSS is about scratching an itch, releasing code your business does but does not need to protect, or about self-gratification. While it can be a showpiece, you never get much in the way of fame out of it, no matter what you do.

The software (at least in my perspective as both) is completely different and so the two problem spaces are rarely going to collide in exactly the right way.

They want people to make things pretty, and there's a big difference.

Bringing a competent designer on board means bringing a strong opinion on board.

Someone who'll probably decide to cut 90% of the features.

The problem with most open source projects is everyone involved has an opinion that they'll fight for, so you end up with 1000 features, designed by a committee of developers (see the Linux desktop)

I'm certainly not going to speak on behalf of every open source project. But the ones I work on? This couldn't be farther from the truth.

If you're a designer and want to contribute to Django PLEASE hop on django-developers or get in touch. I would love to have you.

[I think there's a kernel of truth in iamcalledrob's comment. Designers and developers often speak different languages, and I think this can often make designers feel unwelcome. I've neither the space nor the time to expand on this thought, however.]

EDIT: on re-reading my post, it looks like I'm saying Autocad didn't have designers, which is completely the opposite of how I feel. What I was trying to get it is that (IMO) Autocad is an amazingly approachable product with tons of features, just presented in a way that isn't terribly daunting to a new user.

I feel the same way about Photoshop. People spend time learning its quirks because it's worth it.

However, realistically 90% of the features could be cut and it'd be for the good of the product.

The problem in the software industry (and this is not limited to Open Source) is that people like long feature lists.

This is especially important if you're a Photoshop or an AutoCad. You need new things for the new version.

Firefox, the Linux kernel, Wordpress, Rails (and here I'm specifically mentioning infrastructure, as APIs need good design too).

The Linux desktop sucks for sure, but that's only because everybody, including designers, are only interested in the first 80% of the implementation which is the interesting stuff. The other 80% of the work is boring and people have to get paid to work on it - that's why projects with commercial interests do get polished (there are exceptions like Eclipse of course, which is over-engineered).

    Someone who'll probably decide to cut 90% of the 
    features

It's also not the job of the designer to cut features. His job is to create an interface to make those features easy to use.

Also the article mentions Eclipse versus Coda. Personally I hate Eclipse, but that's what you end up with when creating an IDE for a language with APIs designed for IDEs in the first place.

Of course, it could have a better design, as IntelliJ IDEA can show, but even IDEA is overkill for projects created in dynamic languages designed for simple text editors. See what I did there?

I can't speak for the Linux kernel, but Firefox isn't a shining example of great design. It was back in its early days, when it was incredibly simple, but now it's place is as the complex browser that's extendable in any way.

At the cost of ease of use.

Chrome is now the browser that has opinions and does it right.

> Personally I hate the Gnome desktop because it doesn't have the features I want. The OS X desktop has tons more features and attracts many more users.

The OS X desktop is fairly feature-light, and definitely opinionated. Notice the lack of support for themes or colour customisations in OS X. The dock is at the bottom, the menu bar is at the top. Because Apple say so. And I trust they know what they're doing.

That being said, Apple's shift in focus to iOS can be felt when you look at Lion.

Last time I made a serious attempt to use Gnome was a year or two back - and it was clear that there was a lack of decision making.

Nobody's got a strong enough vision to just decide what typeface the UI should be in, or how the menus should be structured, or whether running apps should be at the top or the bottom of the screen.

They defer these decisions to the poor users, saying "it's customisable, make it exactly how you want!", when in reality, you end up with an unpredictable and difficult to use product that nobody understands, and can be got into broken states easily.

"Oops, I removed the Applications menu". That kind of broken.

> It's also not the job of the designer to cut features. His job is to create an interface to make those features easy to use.

Not true. This is what I mean by open source doesn't want designers.

A good designer will almost certainly simplify your initial idea, cutting all the fluff that's not essential to the product. This is why you need to involve a designer at the very start of the project.

A designer who doesn't do this is probably not a good designer.

The dock is very customizable. I have never used it at the bottom for years of using a mac.

You are correct that people do not properly cost in the mental load of having a non-clean interface infront of them.

I love the SketchBookPro interface for instance in how it disappears. I also like the new "Giant Bubble" MS products much more than the prior un-ribboned versions.

I am a developer (although iOS, so perhaps have a higher love of design than some devs).

1) Most of the software I use is commercial or already well designed(OSX/iOS), so I don't really have a personal itch to fix something I use.

2) I'm familiar with web technologies, git and development environments but I think the problem is politics or communication. I imagine it's lot easier to pull a repo, refactor a bunch of code and get it patched, than it is to submit a remake of the UI and get it on the product. Somebody probably likes the old one more and feels the 128 menu options where there for a reason.

I already have enough politics on my day job, so arguing on with developers on open source projects doesn't sound that inviting. I might be wrong, but it just doesn't seem like that designer friendly environments and maybe lacks the process/tools to be that.

The mentors chose this joke of a buzzwords and a brainless copy of Facebook (Facebook has dashboard with 9 buttons therefore my app will have 9 functions and it is a good UX) instead: https://anirudhspider.wordpress.com/2011/04/01/version-2-wor...

The code of app was terrible - mashup of business and diplay logic organized as 1 screen = 1 class. I recognized that to decouple business logic from view and enable different screen flow, splitting into proper MVP layers would be needed - and offered to do the refactoring as well.

I tried - never will again. Open source my ass.

Designers like to design one product and expect developers to follow suit, not the other way around. This doesn't happen in the open source world.

I do professional iOS development all the time, and have had the pleasure of working with some really good design teams while working, who are there the entire process, but I've also had the occasion when a design is handed down by "god" and they won't do a damn thing to adjust to what's actually possible or doable.

The communication style of designers also irks the hell out of developers. There is argument by emotion, argument by reputation and argument by logical reasoning. Most devs do the latter as a default thing. Many (I'd probably not say most) designers shoot at repuational argument overly quickly, relying on inchoate notions of things they can't really verbalize well.

The fact one side is saying "Trust me, look at all the stuff I've done" and the other is saying "But this is that way and that is this way" leads to a horrid clash of communication style. This is only exacerbated via email, which is how much OSS gets done, as email is exceedingly logic based.

There needs to be a "Oh, pushback, let me listen then change things" that many people lack when they're not experts in the area.

That said, there are people who listen exceedingly well when they're not experts and are a pleasure to work with.

The comparison between Eclipse/NetBeans to Coda is problematic. The OP downplays the importance of who those apps were created for, when that is a fundamental part of the design process. Both Eclipse and NetBeans are just as designed as Coda, but not for web developers. Take the “Refactor” menu in Eclipse, for example: it feels like someone is saying “We know how miserable you feel that the code sucks right now and how hard it is to improve it. Here, have these amazing tools and fix it.” For a Java developer, having a refactor do in seconds what would take a whole day definitely has emotional implications in the visceral, behavioral and reflective levels. If that does not resonate with the OP, well, that’s because he doesn’t have the same sensibilities and issues a Java developer has, not a inherent fault of Eclipse.

[O]ver 80% of Linux kernel contributions are made by corporations, so it’s reasonable to infer that most open source software is built to feel an internal corporate need. Consequently, interaction design is underrepresented in open source.

While it’s certainly the case that open source has a lot of interaction design issues, the who-what-why-how of the kernel are not the cause. The Linux kernel is the least user-facing component of the typical OSS stack. As Linus points out in an excellent chat with Greg Kroah-Hartman¹, there is very little left the Kernel developers can do to help the typical user. The problem is in the “userland”.

Part of the problem is market. To be blunt, commercial software needs to sell, and usable interfaces are an integral part of that.

OSS needs to “sell,” too: it must be adopted by a community and, in some cases, it must find a corporate sponsor. One may argue that OSS projects are started to solve the problems of a single person, but the ones that become products must have seen wide adoption. Good interaction design is, just as for commercial software, another selling point. At the same time, terrible user experience is democratic. There are loads of unusable commercial and open source software available.

What open source really needs is not (just) designers, but design. Good design can only happen when people with a strong hand, a vision and any kind of design sensibility are in charge. And that’s true for any kind of software product, not just OSS.

¹. http://www.youtube.com/watch?v=__fALdvvcM0

A couple times I've talked to Eclipse committers in detail about UI problems and what I get is either denial that there's a problem or an answer like "Oh, yeah, I guess we should do a UI sweep sometime." I'm sure Eclipse seems fine to the people who make it, but that's true of almost any terrible UI. Most people stop at "looks good to me," rather than going for, "tested to work well with the target audience".

I never said Eclipse had better or worse UX than IntelliJ IDEA. This is not what the OP is about.

At most companies, a "designer" is a person who by definition doesn't make anything directly useful. They produce documents describing how they think other people should make things. Much of the time their designs only get executed because somebody with power over paychecks tells developers to obey. But most open source doesn't work like that. Nobody can order a volunteer to do things differently.

What open source needs is for developers to understand designing for people. For user-facing apps, the point isn't to write code, it's to make something that people use and love.

To aid in that, we could certainly use help from user researchers, so we get feedback on what's working and what isn't, and get enough data help us think about solutions. And maybe we can use help from consulting designers when we need help with a problem. But I don't think we need designers as such, any more than we need managers.

Are we really trying to, for random example, create a protocol for individually and consistently addressing nodes securely within an ad-hoc mesh network of inconsistent size which needs to route requests to one or more gateways to the larger internet, OR are we trying to help average people create their own neighborhood networks where they can share services?

I submit that we're doing the latter, and the hard problem in order for programmers to facilitate it is the former. As a programmer, I stumble across magnificent libraries bitrotting on various parts of the internet that sometimes do things that I wouldn't even have imagined possible, yet no one but hobbyist techs will ever use them until they are integrated onto the backend of something that designers somewhere created to scratch a person's itch, not a programmer's. The big problem: when will a designer ever be meandering around the depths of CPAN or an aside on some obsessed functional programmer's blog?

To be even more extreme, I'd like to see more projects primarily headed by designers or end user types, ones with little to no technical knowledge and a healthy respect for people who do. As a programmer, I pride myself on telling people the best way that things can be done with a computer, not what people should want a computer to do and how they would like the computer to do it.

Seriously, the less I have to think about ui, especially in the context of projecting myself into the mind of somebody who isn't clear on the difference between a directory and a file, the better. Background shit that automagically runs with no interaction? Love it. Something that helps grammar school kids collaboratively research their school projects in a transparently sourced way? Somebody please draw me a picture, tell me where to put the buttons, and tell me what they should do. And even though I've written an awesome algorithm to realtime index and classify the contributions of the individual students and make suggestions about who should be assigned to clarify a portion of the outline based on keywords and library proximity - tell me where to put it, or whether I've been wasting my time and that no one needs it. I don't have to have a big red button on the toolbar. I'm smart, I can certainly use the algorithm for something else.

Sorry for ranting:)

a. we developers don't make it easy for them to do so.

b. designers don't care about our projects.

For example, look at wordpress ... you can go in and create a theme ... today, if you'd like to, as a result there are tons of free themes out there, but how would a developer go about creating a Netbeans theme?

Also, most open source projects are created because a developer wanted to build something cool for themselves ... and it isn't often that designers find those sorts of things cool as well so of course they're not going to be designing cool ui for those things

The first is solvable ... devs need to make a concerted effort to reach out to designers, outline a design process (send us a psd of your design, we'll go over the details in basecamp/unfuddle/whatever and you can provide direction as we go) ... I can't see much being done about the second.

In fact I have a lot of developers asking for design help (and luckily vice versa)

The format I use is a little more free form and it's curated which I hear a lot of people say help a lot.

Plus projects are fresh.

I have also tried to involve myself in OSP over the years.

The problem at least from my experience was that while developers have a clear process on how to work together amongst themselves. While they have created their own lingo. It doesn't really include the design process (unless they like me want to learn how to use GitHub) and how that ties into development.

There is clearly a disconnect between the two disciplines and I have yet to find a tool to allow for easy transcendence. You can't in my experience use the github principles for versioning of design, since iteration works completely different for most designers.

I have a couple of ideas of how that could be done, maybe I should start a WH project :)

Git does work for the design files (however less well than with the text the programmers work with).

I'd say generally speaking, it works better if you do design and cutups for a programmer who then implements a fork. He then submits the fork to the project to be merged in to the main project if the rest of the implementors agree.

Gotta find a front end programmer who likes you and thinks you're doing the right thing for that to pan out well.

But my point is more about about design iterations within photoshop, fireworks etc.

Obvious problem is file size. It's going to be interesting to see whether LionOS will allow for some sort of integration with GitHub that allow for this.

i reckon we'll get to a point where early in a repo's life there'll be a concepts/design folder with process files - would also make sense to plan the architecture in the same fashion...hmmm the possiblilities

so that the dev planning the models/views can collaborate with a front-end designer as to the architecture of a site, but all within github etc etc etc. i can but hope.

That doesn't translate well in fireworks OR PSD if you want to collaborate well.

Or are you just referring to transit time (aka upload/download time)?

But also just a problem of state.

A lot of designers who use PS use layers and groups to show different scenarios within the same file.

But as I originally stated.

The reason why many designers don't joing these projects is because it doesn't take their way to work into account.

Yes you can learn to use Github or other versioning tools but that's not good enough if you ask me. Especially if you want to have more designers to participate.

I thought the reason many designers don't join the projects is because many technical people are surly when you try to tell them to put things here and here and here... etc.

It's not like you can't share a dropbox folder then occasionally check into the code base, or never check in the PSDs at all.

I am just saying that to many it IS coding.

Seriously, what was he using Eclipse and Netbeans for if Coda is a migration path. Stating the obvious: He clearly wasn't doing any heavy duty coding. Talk about using a sledgehammer instead of a fly swatter.

I don't see any portfolio links in the comments yet...