Wow, so many different kinds of questions! From my perspective,  
heading a Croquet group at U.Wisconsin:

* The current and the next versions of Croquet will be aimed at  
developers. This is the bleeding edge, and that cuts both ways: some  
APIs (and all of the doc) is evolving, but it lets you create stuff  
that is supportable and scalable in ways that, to my knowledge,  
simply cannot be done otherwise. Only you can decide whether this is  
what you need and want.

* So far, the core software and existing applications have been  
developed by a rather small, close group. However, there are, maybe,  
a few dozen institutions, with worldwide distribution, who are  
committed to and counting on this project.  These institutions and  
individuals have varying interests and abilities, and are forming a  
consortium to coordinate further work.

* The essence of Croquet is to use the processing power available on  
individual machines to run individual but identical simulations.  The  
only thing that goes across the wire are initial state when joining  
and external (e.g., user) inputs. The other extreme is to run  
everything on a server, including rendering, and send updated images  
at 30 odd frames per second to each user. You'll have to make your  
own engineering decisions about which approach (or combination) is  
appropriate for what you want to do.  Download size may enter it, but  
of course, you need to compare the right things. 100s of MB are a one- 
time current developer's download. That has nothing to do with what  
your application may choose to deploy. And then, of course, there is  
the usual misunderstandings about installation and size of  
"executables" and "libraries" and images and such. There is a wealth  
of discussion on this subject in any number of newsgroups. Please  
consult those and make your own informed opinion before repeating all  
that stuff here.

* Croquet is built on Squeak, and inherits Squeak's flexibility and  
breadth. You can think of it as a platform with several delivery  
options, including browser plugins. Similarly for various kinds of  
"access control." (A phrase that does not do the issue justice, but  
which I use here to be recognized by the broadest group of folks.)  
Many of these options, have only just begun to be explored.

* There is a lot of extra capability and flexibility of Croquet as  
compared with narrow point-solutions. (Someone mentioned not needing  
to modify the world as it is being played.) One might think that this  
makes development harder if you feel you don't need this stuff. In my  
opinion, this capability and flexibility actually makes development  
easier -- not just in the obvious case of adding additional  
capability later, but even in the initial development.  But you have  
to weigh this against maturity and the basic math of the problem  
you're trying to solve.

* In addition to the web site, there is a lot of further discussion  
on the blogs that the site points you to. (http://croquetproject.org/ 
links.html) And don't be mislead by dates. Every one of the folks  
listed is actively working stuff (sometimes at the expense of  
writing), except I think Orion, who is on "sabbatical" in Antarctica!


Howard Stearns
Croquet Lead Developer, http://croquetproject.org
DoIT Academic Technology, http://www.wisc.edu/academictech
University of Wisconsin-Madison, 1301 University Avenue, Madison, WI   
53715
  +1-608-262-3724