<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>adding some to the list (plus annotations):</div><div><br></div><div>- <b>anthropomorphic approach</b>. Very human-like way to program makes easier to install an interesting company culture</div><div>- <b>"extreme short development and deployment cycles"</b> &lt;--&nbsp;(often a week, depending on the feature a couple of days) this is extremely valuable to test business plans tweaks and&nbsp;<a href="http://venturehacks.com/articles/traction">getting</a>&nbsp;<a href="http://www.readwriteweb.com/start/2010/08/traction-how-to-get-it-how-muc.php">more</a>&nbsp;<a href="http://www.quora.com/Startup-Traction">traction</a>&nbsp;and&nbsp;<a href="http://en.wikipedia.org/wiki/Social_proof">social proof</a>&nbsp;faster</div><div>- <b>extremely productive &amp; small teams</b> &lt;-- a 'pizza' team (a team you can feed using only one pizza) can run a whole startup.</div><div><br></div><div>"...</div><div>- small time-to-market;</div><div>- complex functionality;<br>- extreme short development and deployment cycles.<br><br></div><div>It is not optimal for startups having:<br>- extreme scalability or (real time) performance requirements; &nbsp;<font class="Apple-style-span" color="#FF2617">&lt;-- <b>unacceptable</b> (deal breaker)&nbsp;</font><br>- existing libraries already covering most needed functionality.</div><div>For those startups Seaside can be suitable for proof of concepts.&nbsp;&lt;-- kind of nice but... (opportunity here <font class="Apple-style-span" color="#FF2617">if you <b>fix</b> the previous issue</font>)"</div><div><br></div><div><b>Notes about scalability:</b></div><div>Investors&nbsp;<b>will not</b>&nbsp;tell you no, they will tell you that they will think about it. So, anything that isn't a&nbsp;<b>hell yeah</b>&nbsp;is a no. So we better have that point addressed in a smarter way.</div><div><br></div><div>Said so, I'd add:</div><div><br></div><div>1 dabbledb found a way to make it work for them, nothing is written in stone saying they had to be the only ones (and if so lets break that stone)</div><div>2 if twitter runs on ruby, arguably slower than smalltalk VM's, then I feel that the can't scale judgment focused on theory and details and assumptions too soon</div><div>3 the wrong architecture (one that allows points of contention) will make even assembler to have scalability problems (reinforcing point 2)</div><div><br></div><div>I feel we can think bigger guys, is just addressing one issue at the time</div><div><br></div><div><div><a href="http://twitter.com/#!/sebastianconcpt">sebastian</a></div><div><br></div><div>o/</div></div><div><br></div><div><br></div><br><div><div>On Feb 28, 2011, at 9:41 PM, Stephan Eggermont wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Sebastian wrote:<br><blockquote type="cite">that list needs the profile that makes the whole difference:<br></blockquote><blockquote type="cite">- as investor<br></blockquote><br>Yes of course. Something like:<br><br>The Seaside framework allows small teams to build (complex) web applications fast.<br>It is interesting for startups needing:<br>- small time-to-market;<br>- complex functionality;<br>- extreme short development and deployment cycles.<br>It is not optimal for startups having:<br>- extreme scalability or (real time) performance requirements;<br>- existing libraries already covering most needed functionality.<br>For those startups Seaside can be suitable for proof of concepts.<br><br>Stephan_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br></div></blockquote></div><br></body></html>