It is being reported that the guys at Smallthought have gotten some funding for their DabbleDB product. That’s cool.
I like the core capability: multiple-view, spreadsheet-like shared-Web access to arbitrary user-created databases. That is, server-side Web2.0 plus Group Forming Network math, as applied to databases. Built on Smalltalk.
I also think this is a nice example of building a small and simple downmarket application, and then using modest revenues to build features to head upmarket on top of your core capability. (Christensen, Moore, etc.) The eventual target presumably being Oracle’s PeopleSoft.
I’m surprised that they they took as much money as they did this early. I think this is good, but not a change-the-world killer app. Lots of folks can do this. (Laszlo (where John works) and Curl (where John and I used to work) should approach stuff this way rather than chasing the enterprise from the start.) Maybe Web-Winter is thawing?
Or at least, that’s what I said to John, who’d like to have the conversation here so he can jibe me in public (and have some more links to Lazlo).
Knowing in advance some of what he wants to say, let me counter with:
My impression (mistaken?) is that Laszlo, Curl, and Web2.0 in general have become essentially server-apps with rich UIs processed on the client. That’s cool, as it brings all the Paul Graham server arguments into play. Laszlo’s Pandora is a nice hybrid, in that some of the data is from the local net and processed locally. I don’t know whether it is entirely processed locally or whether it passes through the server first. The fact that I don’t know (probably means I’m just ignorant, but maybe …) tells us that if it is entirely client-side, there’s no fundamental advantage/breakthrough in having it be so. In any case, I think the way to view Pandora and Gliffy is that AS A SYSTEM, I think they are fundamentally based on a central server.
Gliffy (another Laszlo app) is very nice. It and Pandora both completely fit the stuff that I like about dableDB. One potential difference is whether they’re built by the folks that know that application/market or by the folks that know the underlying technology. It sounds like even Gliffy/Pandora are built by the technology vendor, just as is the case with dableDB.
This still leaves open the question of who markets/sells the application versus the technology. I’m not sure what the right answer is on that question. Moore’s “tornado” model and Christensen’s application of “resource dependency” both suggest that at some point, they have to be the same. E.g., If Pandora or Gliffy take off really big, they will buy Laszlo, even if they make the guts open source, form a consortium to promote engine-development, etc. But I do like your idea of sprinkling lots of seeds to grow something that will eat you.
My point in all this that the cool apps that really show the power of what you’re doing are all down-market, not enterprise oriented. Building stuff for Verizon may pay the bills in the short run, but you will NEVER win in this arena. (Read “The Innovator’s Dilemma.”) Curl has staved off complete destruction by following this path, but it cannot pay off in the long run. Curl and Lazlo must create new markets and new application areas in which the benefits really matter (as Laszlo is indeed doing with Pandora and Gliffy).
As to Smalltalk vs LZX: I don’t think it matters. On technical grounds, the guys that make dabbbleDB (smallthought.com) may well think that Graham’s secret weapon stuff applies, and I think so to. But I don’t think it matters. Making life better for professional programmers has zero to do with long-term success in the technology marketplace. In fact, there’s empirical evidence that it works against you, and I believe, nay, I know, the reason is that mainstream/enterprise development is far more dependent on predictability and repeatability than on productivity. If a handful of cowboys can built it in 1/10th the time as an army of drones, then your predictability is many times worse. If a two month project and a two day project both slip by two weeks, what’s the percentage slip for each? And with fewer, less interchangeable people on the project, the odds of the two week slip are actually higher for the smaller team. You said it yourself regarding “the limiting factor”, below. Not how much cool stuff can you turn out per drone.