On 2/13/07, <b class="gmail_sendername">Samantha Atkins</b> <<a href="mailto:sjatkins@mac.com">sjatkins@mac.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Building something generally enough to have a sufficient market for a<br>decent ROI and yet sufficiently intuitive, efficient and useful to<br>precisely the project you are working on now without taking too long<br>out of the schedule to learn the tool is a real trick.    How many
<br>potential users willing to pay how much for what with what kind of<br>long term maintenance, support and enhancement costs?   It might be<br>better to do it with a consortium of interested parties under open<br>source.   More of a Cathedral than a Bazaar though.
</blockquote><div><br>I've been thinking along similar lines, and my reasoning is as follows:<br><br>Suppose you tell the program "sketch a model of a teapot". For this to work, it needs to know what a teapot actually is.
<br><br>The sum and total of the required knowledge base will be far beyond the resources of a single team to assemble. It'll need to be shared; in rough analogy to Google and Wikipedia, the system's effective smarts, its ability to solve problems, will be a function of what it knows by virtue of the input of a great many minds distributed around the world.
<br><br>As a matter of technical principle, a free/shared knowledge base isn't incompatible with a proprietary program, but as a matter of practical fact, it's far more likely to work if the program is also open source.
<br></div></div>