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