I should clarify and say the issue that I am refering to specifically relates to UI/design. There are very few people that are good at it, so when those "good" people are not in absolute control and overly influnenced by committees, the design suffers. The good news about most open source products that have been successful is that they are more often API driven. Linux, the apache stuff, languages, etc, etc. Honestly, I havent yet seen an open source product whose UI I really like except firefox which is darned near commercial in the way that it is run.
<br><br>Graphics programs, Interface shells, video programs... I am not going to name names because then someone will either get upset or start misinterpreting. But I have yet to see something that I thought lived up to the best proprietary interface/UI designs. I cant say I have seen everything, but I have seen a lot. I think Open Source kills when it comes to creating high quality maintainable code. But I personally dont think the community process works as well for design and UI. I know people will disagree, and I really dont want to get into a back and forth with people getting upset and trying to prove me wrong. Its just my opinion. And of course there are always exceptions.
<br><br>Oh and by the way, I am not saying OpenMoko will have this problem. It specifically relates to the community process of development. But satisfying everyone's requests/demands in a UI is a sure sign of trouble and is much more prevalent in a more democratic process. Depending on how they manage the process and the form of the leadership it may not be an issue at all. They just have to be good designers themselves, and be willing to say "no" when warranted.
<br><br>Regards,<br>Hank<br><br>p.s. These are just my opinions. I have said it before, but many people have different perspectives on what it takes to make great products. I am not sure why anyone would care about my views on this subject.
<br><br><div><span class="gmail_quote">On 1/18/07, <b class="gmail_sendername">Richard Franks</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 1/18/07, hank williams <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<br>> I believe too many cooks spoil the stew, which is often a<br>> problem in open source, in my opinion. Its also often also a problem inside
<br>> corporate development efforts. When there is no clear and absolute<br>> leadership, product design suffers. This is of course my opinion, based on<br>> my 30 years of software development. It is, nevertheless an opinion. Your
<br>> mileage may vary.<br><br>I see this being true for monolithic projects such as a kernel, or an<br>office productivity suite.. I would say that it's debatable whether<br>the same holds true for the types of micro-application which are going
<br>to be created using the OpenMoko API (which as a foundation does<br>appear to have clear leadership).<br><br>Monolithic product design I believe arose from distribution and OS<br>layer limitations - when you simply couldn't download weekly updates
<br>or patches, the product had to get it right the first time. It didn't<br>always happen that way of course, but there was no real alternative as<br>the network infrastructure hadn't been built up yet.<br><br>Communication accelerates standardisation, and standardisation paves
<br>the way for smaller tighter applications. Given the diversity of<br>interests shown on this list, I don't think we'll run into the<br>too-many-cooks issue any time soon.<br><br>Out of interest, which Open Source projects have fallen victim to the
<br>too-many-cooks problem?<br><br>Richard<br><br>_______________________________________________<br>OpenMoko community mailing list<br><a href="mailto:firstname.lastname@example.org">email@example.com</a><br><a href="https://lists.openmoko.org/mailman/listinfo/community">