These are important points- as we move forward, I am hoping that we will be
moving towards a model in which individual pieces of code are liberated as
much as possible from unneccessary constraints on their usage.  That is
going to require a rather significant change in a lot of Squeak's
infrastructure, but I am rather impressed with how much progess is being
made by a lot of people in terms of understanding those issues, or at least
recognizing them.  The days of the monolithic image ( and the inherent
weaknesses and roadblocks to progress that it represents ) are, hopefully,
numbered.

- les

----- Original Message -----
From: <danielv at netvision.net.il>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, October 24, 2002 3:41 PM
Subject: Re: An uncomfortable question


> Well, I think something interesting is happening in SqueakMap. The count
> is now up to 16 packages, by 8 different authors. These range from small
> framework additions like SharedStreams to large projects that would be
> unlikely to ever become available through the Squeak base image, like
> Seaside.
>
> This opens up directly possibilities to maintain other projects outside
> the image too, like Celeste, Scamper and others.
>
> All this should reduce the maintainance effort required of SqC, and let
> the community do experiments in various directions without actually
> requiring a fork.
>
> A case in point - if Henrik's code was first debuted as a SM package, it
> would have gotten earlier feedback, it could have been more modular, it
> would have been easier for people to try out and it would have been
> optional, orthogonal to the harvesting work done on 3.3a.
>
> This would have saved us at least one uncomfortable question.
>
> So I think one important thing to consider is how we take full advantage
> of this new option we have as a community, and how we change our process
> to fit it in.