is the Dynabook still a vision for Squeak ?

Avi Bryant avi.bryant at gmail.com
Tue Dec 21 14:19:19 UTC 2004


On Tue, 21 Dec 2004 14:34:46 +0100, Stéphane Rollandin
<lecteur at zogotounga.net> wrote:

> I use the word "vision" (with the Dynabook as an example of what is a
> vision) so that it is clear that I am not asking for strong directions,
> nor strict rules, nor enforcements of any kind, but simply for a
> satisfying and generally agreed response to the question "what is
> Squeak, today ?". maybe there is no answer to this question and multiple
> forks (and/or Universes) are the way to go, I don't know. but I believe
> some context should be provided both for newcomers and for developpers
> about Squeak purpose and future.

I think that multiple forks is already the reality: Tweak is a fork,
Croquet is a fork, Squeakland is a fork, Smallland is a fork.  So far,
from my point of view, these have been perfectly healthy forks: the
people involved in maintaining them are still active in the greater
Squeak community, there's a lot of dialog and code exchanged between
the forks and the "mainstream" Squeak image, and there's some real
effort on the part of the forks to stay current with newly released
versions of Squeak.

I think we would do well to acknowledge that Squeak is rapidly
becoming a community of forks rather than a single project with a
single vision.  And I think this would, and should, inform what we do
with the "base" Squeak: rather than thinking of the base as something
people actually use on its own, think of it as an optimal starting
point for the collection of forks.  That is, a change should only go
into the base if the effort to duplicate it across all of the forks
that want it is greater than the effort to revert or remove it across
all of the forks that don't.

This assumes that these are what Colin and I have been calling
"recurring forks": forks that take off from the latest stable release
of Squeak, but when a new stable release comes out, they re-fork again
from that base.  So the version graph ends up looking like a tall
narrow tree with stubby branches coming off it at every level, rather
than infinite diverging lines.

In this model, the main force operating on the base is the desire of
all of the forks to make their job of re-forking on the next release
as easy as possible, and thus want to integrate any fixes and
enhancements that aren't simple loadable packages - but also to
prevent any modifications that they would have to undo.

It, would, of course, be perfectly ok for someone to create a complete
fork rather than a recurring fork - like Scratch did, starting from
2.x and never looking back.  But it would naturally only be the forks
that had made a commitment to reintegrate that would have any
political influence on the base.  My guess and hope is that the
ability to leverage improvements from other forks would, in most
cases, make the hassle of periodic reintegration worthwhile.

Avi



More information about the Squeak-dev mailing list