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.