Designers, how do we get you guys to contribute to open source projects?

Hmm, there does seem to be a tortoisegit project at http://code.google.com/p/tortoisegit/ ..

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.

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...

For you and ErrantX, I think you're reading too much into my parallel: I was just replying to a statement made in the parent. Obviously I'll expect that someone making changes to my code is qualified to do so. It's presumably parallel for interactions between multiple designers on the same project – one can make reasoned changes to the other's work.

In the described event, there clearly wasn't communication but we don't really know anything more about it.

Here's a question, though: let's say you're designing something, say a logo, and there's been a fairly clear idea/requirements laid out, there's some sort of a feedback loop etc. Do you at some point settle on a finished work that you'll offer up and that's it? Or if the client keeps asking you to add more ninjas and make that T red &c., will you acquiesce whether or not it works for you?

Edit: or if there's a second designer who has a slightly different idea of how the finished work should look, how is that resolved?

That really sucks. I'm sorry that she had such a poor experience.

On our project, we've been working really hard to meet designers (and developers and users) where they are. Most of the time when someone asks how to contribute, we list the:

* Ideal way, easiest for us;

* Less ideal way, maybe a good middle ground;

* Difficult for us way, still possible, but likely to take longer to get incorporated;

It doesn't always work but it usually gives people a starting point. Also, on the plus side, it leaves little trails & tips all over the place on how they could contribute better.

My 0.02.