Us board folks have been discussing where to go from here and I
personally would like to see a lot of discussion on this on
squeak-dev, so I am going to completely unofficially kick off this
discussion :-).

I'll present this as a set of bullets, I think it would be nice if we
could have a round of brainstorming first to complete these lists
before becoming opiniative.

Pressures:
- Squeak 3.x is so far quite succesful in resisting us applying
software engineering efforts to it. The reasons are manifold, but two
major reasons are manpower and available tools, neither is going to
change any time soon;
- It looks like squeak-dev is on its own, with the two main projects
that are using it (SqueakLand and Croquet, of course) effectively
having forked. There always has been a perceived need to be stable to
support these projects, but in howfar that is necessary at present is
open for debate;
- There is an awful amount of ideas, and an awful amount of talk about
what hasn't been done to Smalltalk since Smalltalk-80. Some of these
ideas were bad, a lot were good but haven't been implemented, and some
have been implemented. I think the number one reason for not
implementing good ideas is inertia due to having to support a large
codebase (see the point about SqueakLand and Croquet).

Possible solutions (given in "who is General Failure and what is he
doing on my drive?" style):
- Abort. Go back to the SqC model and live with a monolithic image (do
not scale);
- Retry. Declare Spoon to be Squeak 4.0, declare that that is all that
is going to be "officially" supported for the time being, and refuse
to support anything additional that doesn't have a proven team backing
it (scale up).
- Ignore. Keep on following the (distributed) software engineering
trail, but realize that it may take 5 years before we have a
modularized, manageable Squeak (scale down).

I have a clear preference, but I am not giving it until after a bit of
brainstorming here on the list. I hope that the rest of you will be
able to show the same restraint :)