[squeak-dev] Squeak vision
Colin Putney
cputney at wiresong.ca
Wed Jul 1 10:45:42 UTC 2009
Hi all,
I've been reading this thread with interest, and more than a little
cynicism. It seems like we've had this discussion about once a year or
so ever since I've been part of the community, and probably longer
than that. Eventually they fizzle out without resolution and life goes
on. I'm starting to think, though, that the stars are aligning so that
Squeak can move forward again. Consider:
1. We finally have a replacement for Squeak Central. Part of the
reason Squeak has been drifting is lack of leadership. Squeak Central
used to provide that, but all the folks that were part of it have
moved on, and can't devote much time to the administrivia that
leadership inevitably involves. We went through several rounds of
other people attempting to fill that void, without a whole lot of
success. But I think the Squeak Oversite Board is finally in a
position to provide a centre to the community. After several rounds of
elections, terms serve by the board members, and succession by new
board members, I think it's clear to all that as a system of
governance that the SOB is working. The board are legitimately chosen
representatives of the community, they are accountable and responsive
to all the factions within the community, and they can provide the
continuity we need to sustain forward motion.
2. The license has been fixed. With the APSL and now MIT relicensing
effort, we're finally in a position to relate to the rest of the world
in well-understood ways. The Squeak-L wasn't a complete show-stopper,
but it *was* holding us back. Under the MIT licence, it's obvious to
everybody that Squeak is safe for business use and we can easily play
well with the rest of the open source world. Those things are crucial
if we want to grow the community and have an impact on the world.
Being able to join the Software Freedom Conservancy is the icing on
that cake; it gives us a legal entity to hang Squeak on, rather than
just a mob of individuals.
3. We've made some technical progress, albeit outside the umbrella of
"Squeak". A lot of work has been done for Pharo, Cuis, Squeakland,
Croquet and Sophie, and all of it (AFAIK) is available to the larger
community. Newspeak gave us a shiny new FFI, Cog has produced the
Closure VM. It'll be quite a bit of gunt work to sift out the gold
there and get it all in one place, but there's a lot of really good
stuff there.
4. Squeak is becoming more and more important within the larger
Smalltalk community. I notice this because of my involvement in cross-
platform projects - Seaside, Monticello, OmniBrowser. It's getting
easier and easier to write cross-platform code, because Squeak
provides a compatibility layer. When porting something like Seaside to
other platforms, the big issue is compatibility between lower level
image code in the different dialects. The easiest way to overcome that
is to provide an interface that looks like Squeak, because Squeak's
licensing lets you use the actual Squeak code to implement it. If we
wanted, say, a package that makes Squeak more compatible with VW, it
would be more work to implement because we couldn't use any VW code.
As a result, Squeak is the lingua franca of Smalltalk dialects, and
folks from those other dialects have an interest in the quality of the
code in Squeak.
5. Squeak has made an impact in the larger world recently. Seaside is
getting attention in the web-dev community. Etoys has hundreds of
thousands of users, and has begun to make inroads in to the linux
distributions. Dabble DB and Croquet make people take Smalltalk
seriously.
What I'd really like to see is a linux-like model for Squeak. The SOB
should be responsible for maintaining the VM, a minimal bootstrapping
image, and a set of core libraries. These, in turn, should be made
available to "distributions" like Pharo, Cuis, Squeakland. There would
probably also be "invisible" distributions used by comercial entities.
A lot of development work would happen in the distributions and get
pushed back upstream, but significant projects like compiler changes,
closure support, Spoon etc. could be organized by the SOB.
This isn't a new vision, of course, we've supposedly being trying to
achieve this for a number of years. But we've been stymied by two
things, I think. One is resistance to modularization. There are still
folks who like the way things worked under Squeak Central and the
would like to see a return to the monolithic image driven by the
update stream. I think the Squeak universe is too big for that model
to work anymore, but it's certainly possible that tightly focused
distributions could be created that work that way.
The other is backwards compatibility, which we've been discussing
extensively on this thread. I'm particularly heartened by this comment
by Bert Freudenberg:
> Being an environment for professionals and learners alike has always
> been a strong point of Squeak. There is no unresolvable tension
> there that I can see. For example, the Etoys team started 2 years
> ago to develop a product that got shipped to 500 thousand users by
> now, soon it will be a million. They did that with only a handful of
> developers working part-time. Sticking to the base system version
> they started out with was the only option (as everybody who ever did
> serious product development can relate to). Now that the hot
> development phase is over, the changes can be folded back into
> Squeak proper.
Perhaps the way forward is to excise Etoys from Squeak, Pharo-style,
then port back the Squeakland version of Etoys along with some of
their patches to the base image. However it's accomplished, I'd really
like to see this happen. Despite the coolness of Seaside, Etoys is
still Squeak's killer app, and I'd really like to see the whole
community benefit from its success.
Like Bert, I believe that there's no fundamental conflict between the
needs of educational and professional users of Squeak. Etoys is an
application that runs on Squeak, and would benefit as much as any
other from improvements to the VM and core libraries.
Colin
More information about the Squeak-dev
mailing list
|