What does it take to buy in to Squeak (was RE: Stef's departure from the SqueakFoundation board)

Milan Zimmermann milan.zimmermann at sympatico.ca
Sat Aug 26 06:54:27 UTC 2006


On 2006 August 21 05:04, Lex Spoon wrote:
> Milan Zimmermann <milan.zimmermann at sympatico.ca> writes:
> > 	1) "The Board" would start with defining what Squeak is - "Squeak" as a
> > small "SqueakCore" plus "Packages"  - Unfortunately I can only be
> > intuitive here, not saying I know what should be in "SqueakCore", likely
> > it would be much smaller than current Squeak, without Morphic, MVC (UI
> > loadable, is that possible?)
> >
> > 	2) "The Board" would steer the community to achieve separating the
> > "SqueakCore", and promote _tools_ that help achieving the separation, and
> > "re-loadability" of some most important packages.
> >
> > 	3) Once the separation is done, "The Board" would be repsonsible for
> > steering "SqueakCore" _only_.
>
> Sounds good to me.  I would like to see a body organizing Squeakers
> more than anything else, and this is the way to do it.  I wouldn't put
> it so strongly, though: in addition to arbitrating the maintenance of
> the core part, there is a place for helping people exchange their
> Squeak addons.

Yes that makes sense. I felt uneasy commenting on this given I am barely a 
weekend squeaker, but got encouraged by the original question "what would it 
take for you[squeak-dev list member] to "buy in" to a central governance 
model for Squeak". 

>
> Also, Squeak would continue to evolve the Squeak we know.  Discussions
> about tossing it and starting from the ground up are interesting but
> off topic.  If you want to do that, then you are free, but Squeak's
> organization should take care of Squeak.

What I had intuitively in mind (by saying it would make sense to encourage 
alternative cores) would be their existence would show the API to the core is 
well-defined and hopefully stable. In a way similar to ability to run (a 
large set of) packages such as KDE on both Linux and FreeBSD shows there must 
be well-understood API to the cores (perhaps with different adapters but 
still defined).  Apart from that clarification I agree talking about 
alternatives was off-topic.

Milan

>
> -Lex



More information about the Squeak-dev mailing list