But how, as a design idiot armed with a recently downloaded copy of Gimp, do I tell whether or not my fine edit has "botched" your design or not?
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:
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.
I can define "wrong": Wrong is using the square image stretched to fill a rectangular space, instead of using the rectangular image I provided. It's mis-aligning elements intended to be shown on a grid. Or attempting to convert that PNG with a complex alpha channel to a GIF.
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.