Влияние организации процесса на продукт
Любопытное рассуждение тут нашел. В целом, согласен.
Linux has had almost 2 decades of annual "Linux on the Desktop" pushes that universally failed, and there's a reason for this. Open source development can't do good user interfaces for the same reason wikipedia can't write a novel with a coherent plot. The limitations of the development model do not allow for this. The old adage "too many cooks spoil the soup" is not a warning about lack of nutrition, it's a warning that aesthetic issues do not survive committees. Peer review does not produce blockbuster movies, hit songs, or masterpiece paintings. It finds scientific facts, not beauty.
Any time "shut up and show me the code" is not the correct response to the problem at hand, open source development melts down into one of three distinct failure modes:
1) Endless discussion that never results in actual code, because nobody can agree on a single course of action.
2) The project forks itself to death: everybody goes off and codes up their preferred solution, but it's no easier to agree on a single approach after the code exists so the forks never get merged.
3) Delegating the problem to nobody, either by A) separating engine from interface and focusing on the engine in hopes that some glorious day somebody will write an interface worth using, or B) making the interface so configurable that the fact it takes hours to figure out what your options are and still has no sane defaults is now somehow the end user's fault.
Open source development defeats Brooks' Law by leveraging empirical tests. Integrating the results of decoupled development efforts is made possible by the ability to unequivocally determine which approaches are best (trusted engineers break ties, but it has to be pretty close and the arguments go back and forth). Even changing the design and repeatedly ripping out existing implementations is doable if everyone can at least retroactively agree that what we have now is better that what we used to have, and we should stop fighting to go back to the old way.
In the absence of empirical tests, this doesn't work. By their nature, aesthetic issues do not have emprical tests for "better" or "worse". Chinese food is not "better" than mexican food. But if you can't decide what you're doing (if one chef insists on adding ketchup and another bacon and a third ice cream) the end result is an incoherent mess. (At best you get beige and the DMV. Navigable with enough effort, but not appealing.)
The way around this is to a have a single author with a clear vision in charge of the user interface, who can make aesthetic decisions that are coherent rather than "correct". Unfortunately when this does happen, the open source community pressures the developer of a successful project to give over control of the project to a committee. So the Gecko engine was buried in the unusable Mozilla browser, then Galleon forked off from that and Mozilla rebased itself on the Galleon fork. Then Firefox forked off of that and the Mozilla foundation took over Firefox...
Part of the success of Android is that its user experience is NOT community developed. (This isn't just desktop, this is "if the whole thing pauses for two seconds while somebody's typing in a phone number, that's unacceptable". All the way down to the bare metal, the OS serves the task of being a handheld interactive touch screen device running off of battery power first, being anything else it _could_ be doing second.)
Из проекта Aboriginal Linux ( http://www.landley.net/aboriginal/about.html )
(зачем мне это? это я копаю интернет в поисках того, из чего можно собрать Trusted Computing Base на коленке, а это означает минималистичную self-hosting OS)
This entry was originally posted at http://wizzard.dreamwidth.org/308429.html. It has
comments. Please comment there using OpenID.
Linux has had almost 2 decades of annual "Linux on the Desktop" pushes that universally failed, and there's a reason for this. Open source development can't do good user interfaces for the same reason wikipedia can't write a novel with a coherent plot. The limitations of the development model do not allow for this. The old adage "too many cooks spoil the soup" is not a warning about lack of nutrition, it's a warning that aesthetic issues do not survive committees. Peer review does not produce blockbuster movies, hit songs, or masterpiece paintings. It finds scientific facts, not beauty.
Any time "shut up and show me the code" is not the correct response to the problem at hand, open source development melts down into one of three distinct failure modes:
1) Endless discussion that never results in actual code, because nobody can agree on a single course of action.
2) The project forks itself to death: everybody goes off and codes up their preferred solution, but it's no easier to agree on a single approach after the code exists so the forks never get merged.
3) Delegating the problem to nobody, either by A) separating engine from interface and focusing on the engine in hopes that some glorious day somebody will write an interface worth using, or B) making the interface so configurable that the fact it takes hours to figure out what your options are and still has no sane defaults is now somehow the end user's fault.
Open source development defeats Brooks' Law by leveraging empirical tests. Integrating the results of decoupled development efforts is made possible by the ability to unequivocally determine which approaches are best (trusted engineers break ties, but it has to be pretty close and the arguments go back and forth). Even changing the design and repeatedly ripping out existing implementations is doable if everyone can at least retroactively agree that what we have now is better that what we used to have, and we should stop fighting to go back to the old way.
In the absence of empirical tests, this doesn't work. By their nature, aesthetic issues do not have emprical tests for "better" or "worse". Chinese food is not "better" than mexican food. But if you can't decide what you're doing (if one chef insists on adding ketchup and another bacon and a third ice cream) the end result is an incoherent mess. (At best you get beige and the DMV. Navigable with enough effort, but not appealing.)
The way around this is to a have a single author with a clear vision in charge of the user interface, who can make aesthetic decisions that are coherent rather than "correct". Unfortunately when this does happen, the open source community pressures the developer of a successful project to give over control of the project to a committee. So the Gecko engine was buried in the unusable Mozilla browser, then Galleon forked off from that and Mozilla rebased itself on the Galleon fork. Then Firefox forked off of that and the Mozilla foundation took over Firefox...
Part of the success of Android is that its user experience is NOT community developed. (This isn't just desktop, this is "if the whole thing pauses for two seconds while somebody's typing in a phone number, that's unacceptable". All the way down to the bare metal, the OS serves the task of being a handheld interactive touch screen device running off of battery power first, being anything else it _could_ be doing second.)
Из проекта Aboriginal Linux ( http://www.landley.net/aboriginal/about.html )
(зачем мне это? это я копаю интернет в поисках того, из чего можно собрать Trusted Computing Base на коленке, а это означает минималистичную self-hosting OS)
This entry was originally posted at http://wizzard.dreamwidth.org/308429.html. It has
comments. Please comment there using OpenID.