2 ms·
This is pretty much spot on. I believe that the lack of "strong-D" Design you refer to is because Linux's desktop is pretty much the ultimate committee-driven
by scrumper 14y ago
This is pretty much spot on.
I believe that the lack of "strong-D" Design you refer to is because Linux's desktop is pretty much the ultimate committee-driven project. It's very democratic: great for preventing abuse, but rather bad when it comes to vision.
Most of us here know how difficult it is for one person in a company to drive an idea through without it being diluted; countless product companies have gone bust over the years because of committee-induced paralysis. It's much worse when you have a distributed group of volunteers who rarely, if ever, get to meet.
Maybe collaborative development is incapable of producing something as complex and difficult as a clean, well-designed desktop environment and API? Forking, competing spinoffs, factionalism are all useful things in some ways, but they're death to this kind of project.
- mratzloff 14y agoMaybe collaborative development is incapable of producing something as complex and difficult as a clean, well-designed desktop environment and API? Forking, competing spinoffs, factionalism are all useful things in some ways, but they're death to this kind of project. The Rails community seems to manage.
- jmelloy 14y agoRails has a pretty strong leader in DHH.
- mratzloff 14y agoBut there are strong personalities in the Linux community as well.
- scrumper 14y agoWell, Rails is a web framework. It's not an end user desktop environment like Gnome, KDE, NeXTStep, Windows or what have you. Collaborative development does rather well with developer tools.
- mratzloff 14y agoSure... so why the culture difference?
- msbarnett 14y agoBecause developers understand what they want and need from their own tools. Now, they might have different wants, and disagree on how to meet their needs, and march off in 800 different directions, but ultimately with enough effort any one group is capable of meeting their own needs. UI/UX that works well for "normal people" is something that most developers don't understand; they know the UI/UX that meets their needs, but developer needs are quite rarified and abnormal compared to the typical user. Thus, when they respond to disagreement with a UI/UX engineer by marching off in 800 different directions to scratch their own itches, they end up with no solution that meets the "normal user"'s needs. There's no culture of shutting up and following orders for the greater good of the project. tl;dr you can't solve the problems of someone different from yourself if the only thing you do is scratch your own itches.
- mratzloff 14y agoNicely put. Seems reasonable.