1) try to lift the technical burden from the designer. If the designer sends a file as a mail attachment, just add it to a branch of your repo yourself (with permission, hopefully)

2) when programmers see a small bug in a piece of code, they often fix it. Don't assume you can and should do the same with designs. Talk to the designer.

Having communication barriers like this absolutely would stop me from participating. I have no problem with being asked to redesign a logo over and again. I would love to feel like I belonged to a community and that I mattered. But having a developer jack my work and screw it up because it was easier than asking me to do it would completely scare me away from open source projects.

This might be not as crazy as it sounds, as I recently learned:

A few weeks ago, there was a short presentation about Git, targeted at non-programmers such as graphics and web designers. After the presentation, one of the designers (who apparently already knew about Git) stood up and criticized the presenter for not going deeper into branches and auto-branching.

Of course, the presenter intentionally left that topic out, in order to not confuse all those Git newbies.

However, the designer argued that this is what would make Git interesting for designers. He said that all this diff/commit/push/pull stuff was boring for designers where a "diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway. But branching has the power to reflect the natural work-flow of a designer who permanently goes back to previous versions in order to try different variants. Reflecting this via "Save as ..." (and naming files accordingly) is very cumbersome.

Although I personally think this guy overrated the power of branches, this might change once the Git user interfaces becomes simpler to use, more targeted to designers (rather than just software developers) and better integrated into graphical tools like Gimp, Inkscape or even Photoshop.

I'd love to see the OSS community develop better source control software targeted towards designers. :)

That's what the commit comments are for.

BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)

I use Git, and its a wonderful piece of software craft indeed, but it does not have Windows/Mac clients, that designers often use, as their base OS.

A decent usable frontend for Git, on platforms other than Linux too, needs to be developed, for it to be usable by designers.

Edit - I meant to say officially supported frontend and support for other oses by git.

GitX is available at https://github.com/brotherbard/gitx/downloads (Get the experimental branch)

Git Tower is available at http://www.git-tower.com/

Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers).

And Giggle (http://live.gnome.org/giggle).

Windows is the only OS lacking a good client, but I use GitX for Mac every day, as do the less technical "devs" at our Startup.

Git Extensions (http://sourceforge.net/projects/gitextensions/) is actually really, really, good. The UI is well-designed and fast. Wish more people knew about it.

I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.

I use TortoiseHG and I expected parity.

Given that git was created for hosting the Linux kernel, it should be obvious why it's not a first-class citizen.

And of course, the command line option through msysgit is great.

Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git. I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.

(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)

Both problems seem "hard but solvable" to me. Isn't there software doing that already?

Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.

What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?

And the most important thing: How to display that in a way to be easily understood by non-technical people?

For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.

"merge"

Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.

So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.

However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.

Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.

http://www.kaleidoscopeapp.com/

Too bad it's not Free Software ...

Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.

In other words the document have many states at once depending on what you make visible or not.

On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.

It would be great to have some type of easy non tech integration to git (github?) for designers to use.

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.

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.

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.

When you do design for applications there are functional and conceptual components to the design. If people are taking your work and buggering up your intent, that's a problem, just the same way it is when someone takes code and alters its behavior without consideration for the code's intent.

The experience the designer had, and this conversation just belies the remaining gulf between the two groups.

I won't speak to this particular anecdote; I've found making judgements on intents based on a vague second-hand retelling of a one-sided account isn't useful. It sounds like communication was a total failure, probably on both sides.

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.

If I had designed and submitted a nice new icon instead of code, my experience would have been roughly the same.

Bottom line is that I didn't need to have my work accepted by anyone to validate my efforts. What I needed was to have the code run 20% faster for a rare use case; mine. And thanks to the project's authors choosing to go open source, that's what I got. Then, the authors accepted my patch, further lessening my work load by saving me from re-patching future versions.

So, do designers really get what 'open' implies? Would they enjoy being able to modify the splash screen for their own Eclipse install, even if nobody else would ever see it (they can btw)? I think having a headless mode is a much better feature than anything design-related ever could be. But that's me - other people want different things, and that is kind of the idea...

Also, obviously better 'things' (code, design, whatever) will sometimes take forever for no reason at all. Like this, for instance (the couchdb-python the logo is terrible): http://code.google.com/p/couchdb-python/issues/detail?id=126

Just remember not to worry: things tend to work out OK.

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.

The problem with design is that it is something that is not easy, but it SEEMS easy, because everyone has an opinion, and they think it's just as valid as anyone else's, even a professional designer. This isn't true. The people who designed the first 15 years of Linux interfaces should have never been allowed to design anything.

It's like the other guy said - if you optimized code and a designer came in and ripped out everything you did, rewrote it to be more "aesthetically pleasing", you would be pissed. If it happened twice, you'd throw a fit, and if it happened again you'd be done.

There needs to be a distinct process in place for contributing that doesn't include a programmer redesigning things before they get put into place. If the developer was competent to design, there would have been no need for the designer in the first place.

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?

In this potentially dicey scenario the ability to communicate with credibility is key; Everything we humans create has inherent connotations that can be interpreted and explained, and a designer should be able to justify how every mark on the page contributes to the experience of the end user.

Otherwise the person will just keep draining you, because everyone thinks they can design, except they can't. So they dilute your work to the point that it's a terrible mess if you give them a chance.

No, the problem with design is that every designer has a different opinion, and believes that their opinion is 100% correct, and there is no sway room at all. It has to be done that way, or no one will come to the site, even though it is exactly opposite as every other designer, who also has such strong opinions.

Design is subjective, but designers really believe it is not, that is the most important thing ever, and do not listen to anyone else.

If contributed code to a project, I'd expect another coder who knew what they were doing to change it.

But what happened is more as if someone contributed code and then, say, a tech writer changed so it wouldn't compile and then checked the code in.

I suspect it's not so much that a designer want to have their design never change. Rather, they want someone reasonably competent change it. The programmer often doesn't even know that they've "broken" the design by changing a few pixels.

That's called 'Copyright assignment' assignment and is not the norm in FOSS. You usually have to release your work under a suitable open source copyright licence, but you still retain ownership of the code.

Most of the large corporate sponsors of open source require copyright assignment. Most small one-man-on-guthub projects don't.

A designer's portfolio is based on visuals, which, if changed by someone other than the designer, no longer follows their intent and may not be representative of their design capabilities. While it may be contributed to the project, there is a definite need for those visuals to remain in a stable state for an extended period of time.

A developer's portfolio is based on projects, which typically either continue or stagnate, but do not vary enough from intent that their contribution is not discernable. Or, the contribution is to the project as a whole and that itself is the portfolio item.

It may sound like an ego trip, but this is a very real thing in the design world. You have to show your work, in production. It's one of the reasons I can no longer get a job as a designer - I've been a developer for too long and my past visual works are no longer used in production and I have nothing to show that I was actually ever a designer.

TLDR: It's not enough for the designer to say "I contributed to the project". They have to show visual proof because they are being hired or retained for their viewable work. A change in that design means it is no longer "their" work.

Here we come to a fundamental problem of FOSS economics. There are three forces which protect the software from the work of well-meaning but clueless people:

A) Physical reality. The software has to work. If I take an ax to the internals of Apache it will quickly become apparent that I screwed up when the web pages don't load. There are automated tests. There are well-defined criteria for performance: specs, stopwatches, size of memory footprint, number of crashes in N hours.

B) Community. Patches don't get accepted without buy-in. If you make a mistake that is bad enough you won't get enough other hackers to sign on to your patch. It will get debated to death until you make the community happy.

C) Governance. In any FOSS community, all contributors are equal in the eyes of the gods, but in practice some contributors are more equal than others. If everyone but Linus Torvalds likes your patch, your patch still might not make it into Linux.

How do these map to design?

A) One problem with design is that, almost by definition, it is the part of development that can't be done by a machine. You can't write automated tests. You probably can't even define "wrong" in any objective manner. Trying to do so will drive your designers straight up a wall:

http://stopdesign.com/archive/2009/03/20/goodbye-google.html

So to answer the question "hey, did my nifty new color scheme screw up the design?" you really have no choice but to ask a design team member. But:

B) The problem with design is that it doesn't scale well; it depends on a consistent vision and a consistent sense of taste. It is very hard to get more than three people on the same page here, and that's if they are trying to cooperate; mix in a saboteur and you are in big trouble.

So the right size for a design team is small. Small, and select: You need to earn your way onto the team. Add more members, or more voluminous input from nonmembers, and the team quickly spends more time bickering than building; if half those members are volunteers who have no experience and haven't read the style guide you are doomed to perpetual gridlock.

The established way to break this logjam is:

C) from the top. What color is the Ubuntu default theme? Ultimately, it is what Mark Shuttleworth wants it to be. And Shuttleworth has some taste, thank god.

Unfortunately, very few project leaders have taste - not just in FOSS but anywhere; this is why every piece of gear I own is gradually being replaced by a box with a little Apple logo on it. And if you are one of the rare people with excellent taste and the ability to lead a big technical project you probably have much more lucrative things to do than FOSS. Unless you are an idealist and independently wealthy, like, ahem, Mark Shuttleworth. There are precious few such people. It's a problem.

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.