dirkstoop

I'm sorry but the basic premise of GUIs being limited and CLIs not is just completely wrong.

The startup community there has been building up steam the past couple of years — and it has become more and more organized. I'll definitely miss hanging out with all the talented people back there.

Worth another visit imho. ;)

- Dirk (one of the Sofa founders who's now moving to Palo Alto)

They must have known this device was in the pipeline when they made the WP7 announcement. It really doesn't seem like they gave much thought to how that would impact this (otherwise easy to get excited about) product's launch…

http://yfrog.com/ki79jj

We won't be taking on any more contract work (haven't anyway since the end of 2009)

Cheers, - Dirk

Also remember that there's a lot a lawyer can do for you in a situation like this, way before a lawsuit is even on the horizon.

I worry more about shaking-to-undo on my iPad and faux leather buttons in my Calendar app than about other companies figuring out there is more than plastic to build with.

This is a disadvantage for startups, because big companies will play this game. And it's a game backed by IP law so you can decide not to file, but you can't opt out.

I started typing a really long reply yesterday, but you're right, there's not a lot we can share in public about our plans right now.

One thing I do want to share is that SVN merging and text merging are completely different problems. Both would be great features for either app, but there's not a lot they could share implementation-wise.

SVN merging means dealing with the pre-defined features and limitations of SVN (both a pro – it already works – and a con – it is really hard to make something within the contraints of SVN that's not too error-prone and easy enough to use).

For text merging, we'd get to work on a completely 'new' problem, the only systems we have to code against are the file system and the cocoa text system.. More work maybe, but 'easier' to create something excellent.

I vividly remember the Scherzo theme; who could erase that memory? ;)

We emailed Greg and Arlo (authors of the classic Kaleidoscope) to see if they were cool with us repurposing the name and they were, you'll find their names in our app's About window.

yum.

I make cocoa apps, and I'm pretty sure that the 'native' part of the app — the part of it that could be ditched by linking to WebKit instead – weighs in way under 10 megs

- less control over interaction

- less snappy animation

- approval of some bloggers

- easier ports to fictive multi-touch tablets on other platforms

(Yeah, I understand your question was retorical, but I couldn't resist)

None of the big players will want tech that doesn't give them enough control over minimum bandwidth/streaming performance.

For small players, putting some h264/ogg files up on Amazon cloudfront may cost some money, but it's extremely easy to set up right and offers extremely good and consistent performance for the money. P2P doesn't add much for distributors that don't get massive amounts of viewers.

Not saying it can't be a game changer somehow; a similar P2P strategy worked out pretty well for Skype. But given that it's all talk right now, I don't think it'll do much to slow down HTML5 adoption for a while.

Besides the ODBC stuff etc. that Zed comments on (never dived into the book that deeply) its biggest problem is that the writing style is extremely, annoyingly, time-wastingly redundant.

I remember it explaining the same stuff over and over, worded slightly differently, easily spanning a dozen pages for every simple thing. After the n-th "I got it the first time, move on!" feeling I stopped reading it.

Except for some dabling in basic, max/msp and some proprietary scripting stuff, Python was the first language I learned. It was certainly the first one I learned to program in.

If the contractor clause is not applicable to this work even releasing it under the GPL is questionable, because that's most decidedly not the same as releasing it to the public domain.

(I'm assuming here that - since the author emailed mostly males - this field is predominantly male; I have no facts to back up that assumption)

Would love to see a similar study into replies to emails from male/female aliases to professionals in a predominantly female field.

My point is that without completely agreeing with it, the post still has value.

Spending money you haven't earned yet (either through an investor, a bank loan, etc.) can be a very good way to accelerate growth, and sometimes the only way to allow any kind of growth or even continuity. But I do think there is some truth to the cost of debt in having to deal with your creditors one way or another.

Now there's always the risk that nobody wants what you made (see fendale's comment), but lets assume for a sec that that's hard either way. Here's a very dry analysis of the path to money for both:

Advertising model:

- Create something useful

- Find an audience

- Find advertisers

- Get advertisers to pay you

Product model:

- Create something useful

- Find an audience

- Get audience to pay you

That's at least one less step in the ‘product model’. You can even argue that to properly execute the advertising model you'll actually need one more step in between: “Create an ad placement strategy” (“Create” as in “design and implement” in all cases here).

Getting money from the people who experience the value of the “useful thing” sounds a lot more direct (and more efficient, which correlates to a better return) than getting the people who value the attention of the people who value the “useful thing” to pay you.

I don't have any first-hand experience with the ad-supported model, but I seriously question whether it's a/the sure-fire way of making money online.

Reconstruction/guessing line of thought: When profitable, you don't need to indebt yourself to stay afloat, hence less people/entities to account to, hence more freedom.

Running a company without debt is liberating; you have a dozen fewer things to worry about.