“Who would've thought…it figures”

John Sundman, friend, founder of Wetmachine and my colleague at Curl, wrote some reflections on what went wrong at the two Rich Internet Application startups he worked for. (One was Curl.) I think his comments are spot-on. Here are some concurring reminisces, and one additional hindsight: we engineers were wrong not realize the deep structural flaw in our position.

As John says, we did burn a lot of money. Something more than $50M over several rounds. Them were the days. I think there are two good uses for that kind of money in a startup, and Curl didn’t do either one:

  • For companies that have a great marketing idea, which can be accomplished with a dedicated application of any appropriate existing technology, the money goes towards execution. Get big fast. Be number one. Own it. This is the realm of the folks with a really cool Web-site concept, not a cool compiler. It’s about market operations, not technology, and the oft-demonstrated business concept is that is very hard to displace an entrenched leader in an established market. The payoff to the Venture Capitalists comes from the revenue earned from that market, or from an acquisition by someone who needs to own that market. It isn’t necessarily expected that the company will ever do anything more than that.
  • But Curl was about new technology that enabled what we came to call Rich Internet Applications. We didn’t have the slightest idea what to actually do with it. For tech platform companies like this, the VC money is to enable a successful crossing of the Chasm to establish a beachhead in some niche market. Once that market takes hold and the technology transitions to the Tornado, even larger sums of money are required to handle hugely expanded operations. Even the biggest VCs can’t front that kind of money, so an IPO (or acquisition) is required. The IPO is the payoffs for the VCs, and owning the much larger post-Tornado mainstream market is the payoff for the folks who invested in the IPO. So while the IPO money goes toward operations, the VC money goes toward creating a whole product that can dominate a small key market in which the technology can prove itself.

As John says, Curl’s VP Engineering was all about operations. He didn’t seem to have any vision for the product. Just execution. That’s the right thing for the Tornado/IPO phase, but is simply not enough for an early-market innovation.

In one example of a misplaced sense of “executing” on operations, it was decreed (even before the VP Engineering was hired), that we were going to get product quality right, even if we didn’t know what the technology was for. I didn’t understand tech strategy enough then to see then that this was wrong, but given that direction, I convinced management – – that’s what we engineers did; we “convinced management” – – that if we were to have our language taken seriously, we needed a proper language specification. Despite personal appeals by the Rock Star founders, Guy Steele, Jr. and Kent Pitman had enough sense not to touch it, so management put me in charge of the spec. Ugh. After about a year of language lawyering with the compiler team, I had produced a very good language specification for a language that no one cared about. What a waste!

I should have realized in my interview that no one was at the wheel. I had flown out from Wisconsin to meet with 10 of the 12 founders. (Everyone but Tim Berners-Lee and Mike Dertouzous.) I asked everyone how they planned to make money. Every single person told me to talk to the VP Marketing, who wasn’t actually in for those two days. She wasn’t there when I started either. She had quit before I moved family to Boston.

Here are two more mis-cues where I was just as much a part of the problem as anyone:

  • At some point I got tired of explaining yet again what our technology did, so I wrote up a short tour. In five years of development by MIT’s best and brightest, no one had come up with a 10 minute non-jargon tech explanation. (Although the original paper was pretty damn good.) Two minutes would have been better, but I’m not a good enough writer. John grocked why this was important, and he fixed the worst of my attempt. But we couldn’t get the PR manager to have it published. Or her replacement. Or her replacement. I ended up getting it published by Dr. Dobbs on a CD myself, but by then it was long past too late. We had lost the opportunity to define what RIA was and what it was for.
  • We steadfastly refused to come up with our own application to show what it was for. That was what the millions of developer customers were going to do on their own. I came up with, spec’d, and prototyped a dynamic Web page framework in which users could actually change the page they were reading, and save it to be shared with others. It could be viewed in multiple formats, with more or less or different content visible, and changeable in the push of a button without a round-trip to the sever. I called it “infospace”, but today that concept is called a “wiki”. Wiki technology is different, and older. But the usage is similar in effect and time period. Anyway, management wasn’t interested. “Why would our customers want to let their viewers change the page?” I failed to make the case.

The CTO went out of his way to save my butt more than once during successive rounds of layoffs. John points out that he didn’t use the Internet, but the guy did use Curl on an intranet. He believed in what he had created, and he was right. But when the suits took the product in a different direction than what he needed, he moved his office back to campus and went back to the lab version of the system. We had lost our only real user, and our only exec who understood the vision.

Any new technology by itself is neither inherently disruptive nor sustaining to the existing order. Without visionary direction of what could be accomplished with fat clients, RIA has become a sustaining technology for the asynchronous Internet, not a disruptive innovation that changes the game. In an established market, the established players win.

It is extraordinary that Curl and Laszlo were even on the map to a pundit at Adobe. It is testimony to how good the products and the people were. But “better” counts for squat in an established market unless it is a near completely compatible improvement to what everyone is already making money and budgeted for. Curl and Laszlo are not compatible. They disrupt the process and the supply chain, but not in a positive way. And the result is simply a better way to deliver the same old kinds of things. Everything out of Macromedia delivers this but without the mess. Incompatibly better is only meaningful in a new market that doesn’t have an established way of doing things, in which the new technology is enabling a customer activity that just could not have been done before. Curl and Laszlo never established any compelling such thing in general. For Laszlo, having more money wouldn’t have changed that, per se. Having a bunch of existing customers wanting a more-of-the-same-but-better product would.

About Stearns

Howard Stearns works at High Fidelity, Inc., creating the metaverse. Mr. Stearns has a quarter century experience in systems engineering, applications consulting, and management of advanced software technologies. He was the technical lead of University of Wisconsin's Croquet project, an ambitious project convened by computing pioneer Alan Kay to transform collaboration through 3D graphics and real-time, persistent shared spaces. The CAD integration products Mr. Stearns created for expert system pioneer ICAD set the market standard through IPO and acquisition by Oracle. The embedded systems he wrote helped transform the industrial diamond market. In the early 2000s, Mr. Stearns was named Technology Strategist for Curl, the only startup founded by WWW pioneer Tim Berners-Lee. An expert on programming languages and operating systems, Mr. Stearns created the Eclipse commercial Common Lisp programming implementation. Mr. Stearns has two degrees from M.I.T., and has directed family businesses in early childhood education and publishing.

One Comment

  1. Having gone thru 2 start ups myself your observations are apt. I would add another requirement for a good tech success — a good CFO type. Skinflinty enough to tell the Prez no to the twice weekly massages but wise enough to open up the purse where it counts. And that kind of person is hard to find.

    On the development side there has been more than one company that has spent a great deal of time saying how great their software was. But they lacked one thing — code examples. It assists tremendously in the learning curve and permits the developer to quickly assess a fit.

Comments are closed