Sorry that I am late to this discussion - I was away for a week showing
off Squeak at an international free software conference [1]. Even
exchanged some ideas with Richard Stallman about the Squeak licensing
issues (he would be happier if we used GPL, of course).

My first comment is that there are two sources for all the energy that
we can now see in Pharo. One is improved processes, which is certainly
something we should have in Squeak (and is *the* goal for 3.11) and the
other is the "start up" glee that new projects tend to have. The latter
will eventually wear off, but I am sure that the former is strong enough
for it to keep going for a very long time.

I watched people and energy move from Self to Squeak, from Squeak to
Slate, from Squeak to IDST and many other similar cases. It is a great
thing that Pharo exists and anyone who really would like to have Squeak
be an Open Source Smalltalk-80 with a professional look now has that
option available. The question that was asked was if this should be the
only option?

My understanding of the Etoys situation leads me to think that it can't
survive as a fork. Who will continue to work on it now that ViewPoints
has transferred responsibility to the new Squeakland Foundation? I would
like Bert and Yoshiki to comment on this if possible. In the past we
have had forks between squeakland and squeak which were later merged
back and I want to see that happen again. I feel a moral responsibility
for all the students and teachers that have been convinced to adopt
Etoys (and I talked to quite a few this week). If Alan's suggestion of a
Python version of Etoys had been followed and that was what the children
were using then I wouldn't mind a "Squeak become: Pharo" situation, but
it didn't happen.

So my priorities are:
1) keep Etoys going and improving
2) Croquet
3) Seaside and Aida
4) Pharo

About what Dan wrote, I agree 100%. It might seem like a contradiction,
that I want as little change as possible. But that is not true at all -
I accepted that relicensing was the number one priority for the
community (I have always been happy with the SqueakL myself) and that
doing this right would mean 6 months to a year of additional time with
no progress. I actually proposed a technical solution that would both
allow us to have more backwards compatibility and radical progress at
the same time [2] but since nobody was convinced I am willing to push
forward with more conventional development.

On the last slide of my talk last week, I mentioned "Squeak and Cloud
Computing" and gave some details about a project for next year with 16
thousand Squeak processors on a 6 inch wafer. Though nothing is being
done in secret, I don't think most on this list are aware of just how
much work is being done on Squeak right now and how many are considering
joining over the next few months.

-- Jecel
[1] http://fisl.softwarelivre.org/10/www/en
[2] http://wiki.squeak.org/squeak/584