Web-Based Software or Customer-Built Software?

Adam Bosworth writes some interesting thoughts about the difference betwen waiting around for the IT guy to write your software for you, versus using some kind of existing general-purpose environment and building your own, or at least customizing them:

...the problem IT faces isn't sloppy languages. It is irrelevance. For much (although certainly not all) of the work IT does, IT is like children building sand castles on the beach and watching the tide roll in. That tide is highly customizable web based solutions, Salesforce.com today, perhaps Talaris tomorrow. Ask the average Salesforce.com customer (meaning a salesrep) if he is happier with the solution he has now or the one he had back when IT was building a customer CRM for him.

Maybe I'm missing the thrust of this, but I think what he's saying is that lightweight solutions like Salesforce.com win out over custom-built solutions by IT departments because they already exist and are flexible enough to be adapted to the individual's needs.

Over the past couple of decades of building and using software I've seen a lot of things go by, including scripting languages, Visual Basic, and many, many, many attempts to empower "regular people" to program things up for themselves, the way they like it. The best so far has to be HyperCard, from Apple Computer. It's dead now, though my brother Harvey doesn't think so. The scripting language is intuitive, forgiving, and like English. But it's still incredibly hard to get "what you want".

The problem is that customization isn't particularl easy, and most people don't bother. People don't pick Preferences or Settings from the menu. They don't change the garish blue menu bars of Windows XP (okay, they do all set background wallpaper images). Which means that people are still using programmer-built tools as the programmer intended, and the fact that a few of them are more flexible than others doesn't argue pro or con web-based software.

Consider FileMaker or DBase, totally flexible, open-ended databases. Do whatever you want. They have not taken over the world. More point-specific databases are what people actually want. Salesforce.com is tailored to a specific problem, has contact information and tracking as its focus. Would you really want to build that yourself with an open-ended database construction kit? Not me.

So I guess I don't see a trend here at all; it's just evolution. It's the usual flurry of exploratory software, new ideas, attempts to find the Holy Grail. Maybe a better analogy is a sports analogy, though I try to avoid them. Each new bit of software, web-based or not, is like a play in a football game. The play is sketched out on a whiteboard before the game (the business plan), it's taught to the players, then it's called on the field. Some plays move the ball forward, some do not. It's not inherently the play itself, but the execution of it, and the quality of the defense (competition) and the weather (business climate, evolution of technology, etc) that decide whether or not your pass is completed for a touchdown, or intercepted (large competitor) and used against you.

Web software hits the wall

I have been thinking a lot about web-based software versus rich-client software recently, fueled by thoughts by Adam Rifkin and visions by Marc Canter and a bunch of other stuff besides.

We are staking our company on client software, but not traditional "applications", but true network-based applications. I think that web software has hit the wall, and is becoming marginalized because of inherent limitations in what is possible.

The world wide web is a bit like cable TV: it's a downstream thing. A web site dispenses content to lots of clients, but the clients struggle interacting in an upstream capacity (like cable). If you've ever uploaded photos to a web site, you know that it's inherently a downstream activity, this web surfing thing. Uploading is like swimming upstream, salmon jumping out of the river, making little progress, struggling....

But that's not even the biggest limitation. It's not a coincidence that Napster, Kazaa, and instant messenger clients are all native applications: they simply could not work over a web-based platform. They call it peer to peer but what it really means is that the applications can use the network any way they want, rather than being forced to talk only to the server from which they were spawned, as web software must do.

Consider also that so-called "web software" wouldn't work at all without the native application called the browser. And it is not a trivial piece of software, no matter whether you look at IE, FireFox, Safari, or whatever. They are complete operating systems unto themselves, and they still do a lousy job of running application software.

That's because they're web browsers. Not application platforms. Java notwithstanding. There's no support for good UI (Laszlo notwithstanding). And they're limited in terms of what they can do on the network, for security reasons.

So we're watching blogs and wikis and social networking and web-based services grow on the web platform, with the conspicuous absence of messaging, collaboration, and file sharing, because they're basically not possible.

We think that many of these useful network paradigms can still be combined, but it requires an entirely new application that itself is kind of a platform, like the browser was before it, but which enables a richer kind of communication-based work to be done. We have that, although today it looks a bit more like instant messaging than it does a web browser. Or does it look like Kazaa? Or sort of like an email client? Hmmmm....

The chief value of web-based software is that the data stays on the web site, centralized. This is undeniably powerful. But it's quite possible to do without using a browser as your dashboard. We think that combining centralized data with an inherently powerful communications tool you get the best of both worlds.

Software: Like Coats of Paint

The software industry has diverged into radically different categories in the past 5-8 years. It used to be that there were very few programming languages that "mattered", and everything was written in "C". Along came Java, and changed everything.

Java is an interpreted language, which means nothing to most people, but it's a synonym for slow. Java is a convenient, addictive, easy-to-use, but ultimately lightweight programming language. It is not used at all for "desktop software". It's rarely used (any more) for "applets" which download and run through your browser. It's very heavily used for server-side software. In fact, essentially all modern web-based "services" are written in Java, or worse, in a scripting language like Perl or Python or PHP. Hmmmm. If it starts with P, maybe it actually is.

But interpreted languages require another program to interpret them, Java requires a runtime, and for server-side software usually an application server like "TomCat" or "JBoss". All this stuff runs on top of a web server, usually "Apache". So your friendly neighborhood web site like, say, Friendster, is a bunch of layers of software running on top of an app server on top of Apache on top of the core OS.

Layers of paint.

When you paint furniture, or your car, after 2 or 3 layers, you're supposed to scrape it all off, down to the bare metal, and start over. In the software industry we use that phrase "down to the metal" to mean going down to the operating system level that everything else sits on top of anyway. It's faster. Better. Simpler. But usually much more difficult. So people don't usually bother. Or they hurt themselves trying.

Programming in C on UNIX or Windows systems is like welding. By contrast, I call Java the hot glue of the internet. A couple of college kids can quickly put a compelling demo together by painting over something else, like making a stage set, and that demo can often attract funding, and then real users, and then it all bogs down and gets slow and sticky or it falls apart. If you've ever hot-glued anything together, a month later you know what I mean.

At Five Across, we started from scratch and wrote our own technology, in C, which runs lightning fast on the bare metal operating system. We think this will become a significant competitive advantage. It also means that our application software is under a megabyte in size, compared with, say, our competitor Groove, which is 50 times larger.

Some say layers and abstractions are good, but although they make things easy, they also limit what is possible because everybody's building on top of the same layers, and they constrain functionality to what the layers make possible (example: you can't do peer-to-peer conversations in a web-based piece of software. At all.)

I say scrape off all that paint and build some real software.