4. HOW RELIABLE IS THE COMMUNITY?

(See part 1.)

None of the previous matters if the software isn't useful, or if we are not allowed to use the software. The former is what we're working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.

3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)

It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There's simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network. [Read More!]

2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user's computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe's law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed's 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed's discussion for a surprisingly accessible treatment of value, saturation, and other issues.)
[Read More!]

Croquet is built on some well-used, but not mainstream technologies. A colleague has asked “Why should we believe that Squeak scales to the enterprise?” I'd like to share my answer, to solicit comment.

It is good to ask this, and there are several aspects to the answer:
1. How reliable is the underlying software?
2. How much use can the software support?
3. How will applications be developed?
4. How reliable is the community.

Part 1 of 4.

[Read More!]

In working on Brie, I had been vaguely aware that the 'Self' language was similarly based on copying prototypes rather than instantiating classes. So I kind of went 'yeah, whatever' when Rick McGeer and others told me to check up on this '80's Xerox PARC project.

Wow. I hadn't realized that Self was so close in both the domain and the solution spaces. If there's interest I'll try to produce a comparison later, but for now, check out the Self site and, in particular, this paper.

In What Is It About Immersive 3D?, I claim that being immersed in among the application components allows and encourages us to mix and match among bits and pieces of different applications. That is, we're getting rid of the idea of having separate “applications” on a computer.

I forgot to mention the other aspect of immersive 3d: that we want to get rid of the computer. Well, actually, that we want to make using each application object feel like a real world object, not a computer thingie. The direct manipulation feel makes it easier to work with stuff, and the lack of indirect abstractions and symbols makes it easier to understand.

A few examples below the fold.
[Read More!]

Internal problems in Brie. Some nasty, some trivial, all annoying. We'll work 'em out, but time to think of something else for a while. How about huge cultural paradigm shifts?

Clearly, something's going on in the area of intellectual property. The old models are not serving. Everybody's got something to say. (Here and there are some current MIT community examples.) On the one hand, Apple tries to sue companies for using a Windows-Icons-Menus-Pointer (WIMP) look-and-feel that they themselves didn't invent, and they won't let me rip the songs I legally bought from them. On the other hand, they want to use the name “Apple” despite clearly being in competition with Apple Records in the music business, and they produce a variety of devices in the new-cultural rip-mix-and-burn chain. Are they schizo, or is it just opportunistic business? I think it's another data point towards the conclusion that we're waiting for Thomas Kuhn (in a broad sense) to point the new way.

How can we understand intellectual property rights in a digital age? I propose that we try to get at what we really mean in terms of some established axioms.
[Read More!]

When something new comes along, we tend to describe what it is. If it's something important, it takes a while to figure out why it's important – what it is that is really different. The description of what something is tends to be somewhat dry and technical and it misses the point. For example, a telegraph is an encoder and a decoder in an electric circuit. But couriers and semaphores involve coders and decoders, and other stuff has had electric circuits. What was important about the telegraph was that it provided instantaneous long-distance communication. This is also what was important about its successors like the telephone and radio, even though the descriptions of what each is are quite different than that of the telegraph. It's not as simple as describing what a new invention does for people. Quite often we don't know how it will be used.

Since I first heard about Croquet, I've been trying to figure out what is really important about the immersive 3D that everyone first notices about it. I think I now have an idea. It turns out that the “immersive” part is key.
[Read More!]

I don't know why software projects need meaningless codename, but they do. Maybe that's how this ethereal stuff becomes “real.”

I can't say that all our U.Wisconsin projects for Croquet will be named after cheese, but I wouldn't be surprised. Not sure why Wisconsin means cheese, yet we start with a French cheese. But Brie is cool. My wife lived there for a while. The have big parties when the new cheeses come out, but you can also buy this old wrinkled stuff that you can't get here, which my wife calls “fromage morte.”

So, what is Brie? [Read More!]

My wife is getting frustrated with the medium as she constantly checks for the latest in the raging debate in her favorite mailing-list. Meanwhile, writers and researchers lament the loss of the art and practice of writing letters.

There's no spec for Croquet. Although the architects have mature experience and good taste in evaluating technologies for what does and doesn't work, I don't think they set out to achieve a particular set of characteristics. Yet one of the things that appeals to me about Croquet is the characteristic that it is agnostic about what mode of communication works best: Synchronous like face-to-face conversation and chat, or asynchronous like email or a handwritten letter; Seemingly anonymous like most of the Web and multi-player games, or full of social cues like voice and video communication. Croquet is equally facile at all.(*)

But what works best? When? In what ways? My boss, Julian, has been bringing together a very interesting group of educators and scientists as initial users of a Croquet Collaboratory that we are building. Although they come at it from perspectives that range as far as art, public health, and games, I think they are all vitally interested in this issue. By having a single medium that provides all – a meta-medium – they can study group interactions and observe how different communication techniques affect outcomes.

(*) I'm not quite sure what it says that I'm comfortable saying this, even though the effectiveness of both persistence and naturalistic voice and video have only been suggested in demonstrations, rather than proven in practice. Is it vision, confidence, or faith among the developers, or naiveté and the academic environment?