"Web 3.0", or Why Mantissa is What the Web is Missing

PC programmers originally wrote programs for DOS. It was simple. It was direct. A program could do whatever it wanted. It could write directly to video memory, it controlled the whole screen.

Later PC programmers had to learn to write programs for Windows. At first, that was a big pain. The Windows API, even Win16, is hundreds of times more complex than the DOS "API", if you could even say it had one. Applications had to be changed so that their UIs behaved like Windows did, rather than what was "best" for their application domain. Most programs had to abandon their crazy key-bindings to make room for C-c and C-v to mean "copy" and "paste". (Even we geeks only have room in our hearts for one or two sets of crazy key bindings.)

Browsers are today's "video memory"; applications put information wherever they want, with no user-interface conventions that aren't enforced by the browser itself. There is no operating system for the web, no mechanism to make different applications play nicely together on a single server, let alone on a single page. The web is in need of a major shift.

Many would have you believe that "Web 2.0" - AJAX and such - is this shift. "Web 2.0", insofar as I can tell that it refers to anything concrete, is the idea that web applications should respond to the user interactively. This is something that applications have been doing even before DOS; it is not a new idea, and in a sense, it is only the web playing catch-up in an area where desktop applications have long been the clear winner.

What I want to know is, where is the integration paradigm? Where is the clipboard for the web?

I think that whatever answers this question will rightly deserve the moniker "Web 3.0". It will be providing a leap forward over non-web applications which will really be worth something, and hopefully won't be worthy of brutal derision at the hands of industry pundits.

Web 3.0 is going to come with a price, though. By way of an analogy: DOS developers didn't understand the value of Windows programming at first. They objected: Windows is slow. It's ugly. The UIs are boring and everything looks the same. It takes too much memory. Why couldn't they just use DOS like they used to?

Today's web frameworks are generally more like DOS than like Windows, in this respect. Don't get me wrong, I don't mean they're bad: DOS was a huge step up from its predecessor, which was, basically, "you have to write DOS yourself in every application". The "Web 2.0" frameworks I'm familiar with: Rails, Seaside, Subway, Django, and TurboGears are geared (no pun intended) towards providing those parts of your application that you'd have to write yourself, if they weren't provided. They are sometimes libraries, sometimes frameworks, but their purpose is to provide you with a quick path to development and make your application interactive. They aren't really geared towards providing a context in which your application can communicate with other applications.

The infrastructure Divmod is building, we hope, will provide some of the imposed structure that has thus far been lacking on the web. The first step, by way of Mantissa, and our recent work on the "Offering" system, is to provide a way for multiple installed applications to be easily installed on the same website, an idea that Zope, among others, pioneered with some success. That's the front-end, the Windows-1.0 phase. Later, we hope to build clustering and inter-application remote integration with Vertex, the "networking" and "multitasking" that came with Windows 95, following in that same metaphor.

Let's escape the metaphor for a second. The concrete features we want to provide will be things like: You want to write a social network application. Social networks implicitly use telephones and email. With Divmod's framework you can (in the future, when we have finished these systems) write an application as a set of plug-ins which will be activated by the Address Book page, the "Email Inbox" page, and the "Place Call" page from our VoIP application. You can automatically create To-Do items for the user's existing task-tracker. Similarly, if you provide appropriate plug-in interfaces (which the system does make pretty easy and idiomatic)

In the process of writing this essay, I discovered that wikipedia says others are already speculating about Web 3.0 and with similar ideas. It will be distributed, it will be decentralized, it will involve connections within and between web services.

So, how does this all relate to Divmod? What could we hope to gain by providing this kind of technology, especially by giving it all away for free? I'll explain the part of our business model that this impacts, because I am personally always suspicious of people telling me of great stuff they'll do for me without an idea of how it's helping them.

To start with, we have a lot of different ideas for applications, and we want to make sure they can all inter-operate. All the standard reasons for using open source apply - making bugs shallow with more eyeballs, etc - and we also want to make sure that as we're focusing on our first few uses we are preparing for a broader and broader use of our technology, and what better way to do that than by having other people with other use-cases take a look at it.

We have another reason too, though. Once we're done with all of our ideas for applications, (and by all that is good and holy in this world, one day we will be done!) we want to step back and allow the service to keep growing through the contributions of our users, and eventually compensate those contributors who provide us with useful code. Taking a page from Red Hat's book, rather than attempt to sell a commodity into a market, we want to define a market for "web 3.0" products, and then be the market leader and provide a marketplace for good products, rather than simply sell our own.

By providing a structure that will allow lots of different applications to be installed on the same site, we provide a way for independent developers to provide us with applications that can be run together on our site. We can then run all those applications through our account management system and make it easy for those developers to get compensated based on usage patterns and that sort of thing. Of course, any applications we're going to run on our cluster will have to be licensed as open source so that we can have the same expectation the developer does: we won't sue them for using our stuff, they won't sue us for using theirs.

In other words, we're trying to leverage this technology shift to make a way for hackers to get rich writing open source software, without going through the process of starting a startup.