When Croquet is a success, what will it be? Really? Forget about the applications, what will Croquet itself actually do?
The other day I was sitting on my back porch. Resting comfortably on my lap was all the resources I needed to do my high-tech computer work. The box also played my favorite music, and when my wife asked about the lyrics, I was able to look them up in the greatest library the world has ever known. We checked our calendar, and printed a custom map to the next day’s event. And so forth.
Not so very long ago, it would have been very hard to imagine this, despite having had it all spelled out for us by Vannevar Bush or by Douglas Englebart on specific dates in 1945 and 1968. For any given technology, it seems to be very hard for most of us to fully imagine our future with it. I think the reason for this is that when the future comes, it’s all about the applications. The music player. The information index and specific song lyric libraries. Calendars, directions, and the tools for my work. We live in applications. We buy applications. Applications make or break a technology. But these applications don’t just happen because they are good ideas. They happen only (and not always) when there is a suitable enabling technology. It is rare that we think about what the enabling technology really is, fundamentally.
In the case of the World Wide Web, we have the unification of three concepts:
- A means of indicating any participating computer resource resource, worldwide –URL.
- A means of accessing that resource – HTTP.
- A means of expressing content to be accessed –HTML.
In addition to the fundamental technology, we had a useable reference implementation. Being asymmetric, the early Web had a large number of, e.g., Mosaic browser users, and a smaller number of servers.
No applications. No vendors. No products. No official distributions of software. If you wanted something, you built it.
The W3C was founded in 1994, about three years after the first available reference implementation and public description of the technology, and about a year after the Mosaic browser. This consolidated the idea that the core technology was open. You could build your own applications and even other implementations of the core technology, and you could sell them. You could cooperate with others though the W3C or other organizations, or you could choose not to.
I’m going to be lazy here and just assert that the combination of application-independent core technology, open reference implementation, and open organization, were all key to the success of the Web. I’m going to further just assert that given the pure aptness of the ideas, these three were sufficient for success. Well, OK, that’s sort of tautological. But the point is that the applications came without Uncle Tim having to write them. The people who wanted the applications wrote them. The people who wanted support got it.
Now, I want to be very clear here: I do not intend to merely build a cool conferencing app or some such and be done with it. I intend for Croquet to be the basis of a phenomenon with as great an impact as the WWW. I think the model for it to be successful is quite similar:
- Fundamental technologies for:
- indicating collaborations (e.g., to join them directly or though a proxy, and both for obvious access as when you visit a WWW page, and internally as when that page embeds a separate resource)
- accessing (e.g., using) them collaboratively
- expressing the content of the collaboration so that it can squeezed though a wire when you join, and persisted when the last person leaves and turns off the light
- An open reference implementation.
- A consortium to reinforce these ideas, guide their development, and facilitate cooperation among those who choose to get involved in this particular way.
Each of these is quite a complex subject by itself and worthy of separate discussion. My point here is to frame that discussion in terms of these high-level success factors, rather than as having folks look to U.W. or anyone else as a vendor supplying a particular application distribution.
heh, heh. Speaking for myself, of course, and not intending to represent the views of others.
See, also, http://wetmachine.com/i…
I should contrast the above with something that can seem similar, but isn’t. A platform like Unix or Java has a leading implementation, which the vendor might cloak in “open” terminology as a “reference” implementation. There might be an open organization available to support the community. And, of course, there’s a set of features claimable by the underlying technology. The features might even be unique individually or in combination.
I think the reason that this looks similar is that the general approach works. To the extent that it does, we don’t care whether something is a vendor(s)-supplied platform or an open, paradigm-shifting, enabling technology. It can be screwed up, either way. But I think there’s a reason that vendor platforms tend to get screwed up and stray from the model more often. When someone wants to “own” the platform, rather than making money from applications and services, the enabling technology model tends to fall apart. The open community organization breaks down. Deliberately incompatible clones start to compete with the reference implementation. Microsoft steps in. “If you design it so that it can be owned and controlled, it will be, but not by you.”
Of course, the platform model does work quite often. I do NOT think that we ultimately get to choose whether we are a platform or a fundamental enabling technology. Pretending can only work for so long. Rather, we are more likely to succeed if we recognize what it is we’ve got and follow the model that is most appropriate. How do we tell the difference? That’s another subject, and one which has been sitting unfinished in my drafts folder for a long time. But the short of it is this:
* When the math of what you are doing is truly different, such that it fundamentally supports a new way to do things for a new (and much larger) group of users, then you have a paradigm-shifting enabling technology, like the WWW. Produce a reference implementation. Describe the fundamental technology in an open, incremental and developable way, and create a community organization to share in the development. (And then, if you like, make money on applications and services.)
* If your feature set is merely a much better way of doing the same old thing – 10 or 100 times or any linear factor better – then you merely have a good platform that stands a chance of incrementally improving the status quo. Here the implementation is a product. Be prepared to make it do exactly what your constituency wants it to: work with partners as necessary to make sure that, out of the box, your software distribution handles the complete work-flow required by your users.
I’m asserting that Croquet is the former, and I’d like folks to think in these terms.