"Pink Squeak" as the new name for the version of Squeak targeted toward business/commercial use?  Hmm, "Squeak" by itself is already a bit whimsical sounding, but this might push it a bit too far.  Why not go all the way and just call it "Golden Twinkie" or "Frosty Cuddles"? :)

Okay, joking aside, I know you were referring to the blue-plane pink-plane thing.  And I agree that "Stable Squeak" is a pretty darn boring name.

I'm not really sure what a good alternative is.  I suppose you could call it SqueakPro or something like that, but that has a sort of marketing drone feel to it.  PowerSqueak?  PipSqueak?  I'm comin' up dry here... I got nothin'.

- Doug Way
  dway at riskmetrics.com


Stephen Pair wrote:
> 
> Since Stable Squeak is forking, maybe we should start distinquishing the two
> forks as:
> 
>    Blue-Squeak
>         and
>    Pink-Squeak
> 
> Just to be a little less boring than "Stable Squeak." (no offense to those
> that no doubt spent countless brainstorming hours to come up with that name)
> :)
> 
> - Stephen
> 
> > -----Original Message-----
> > From: Sarkela [mailto:sarkela at home.com]
> > Sent: Wednesday, April 18, 2001 4:32 PM
> > To: squeak at cs.uiuc.edu
> > Subject: Re: Stable Squeak?
> >
> >
> > Thanks for responding Michael. You may as well have read my mind.
> > I will, however, address the same points in roughly the same order.
> >
> > I must apologize for not being more communicative. I have had
> > other activities that demanded my attention. I am truly sorry.
> >
> > I recall a picture from my childhood of the "language tree". It
> > was gnarly and had funny shoots... like the Finno-Ugric languages.
> > I would hope that Squeak will develop its own branches. Perhaps a
> > foundation could help archive, explore and nourish this tree.
> > We can embrace variety and come away richer.
> >
> > Since this branch is favoring simplicity over features, it is
> > smaller and simpler. Mainline Squeak can benefit immediately
> > from the unit tests we have written. Over time SqC can incorporate
> > our base changes, or come up with better solutions that address
> > the same issues. In any event, the long term goal is to incorporate
> > more and more of the base image functionality in the Squeak world
> > tour environment as loadable source code. It will always lag
> > the base in feature set. It may even support other experimental
> > interface projects. Our points of view are the principle
> > limiting factors. The goals of the Squeak world tour and SqC
> > are different, but they are more complementary than conflicting.
> > There is an interesting dynamic tension between production coding
> > values and the values of experimental development. Both are crucial.
> > I expect the development of each to be a co-evolution.
> >
> > Why should you expect more openness in the future? Because,
> > the Squeak world tour has reached the stage of an initial release.
> > Every effort is being made to avoid licensing issues and I have
> > erred on the side of caution. This is in the final round of
> > validation.
> >
> > Hopefully it will spawn a flurry of forks when it is released.
> > We hope to facilitate moving functionality between forks in
> > the code base.
> >
> >
> > [|] John Sarkela
> >
> > Man ist vas er isst. ;-}> See you in Essen.
> >
> > > From: Michael Rueger <m.rueger at acm.org>
> > > Reply-To: squeak at cs.uiuc.edu
> > > Date: Wed, 18 Apr 2001 08:55:01 -0700
> > > To: Squeak <squeak at cs.uiuc.edu>
> > > Subject: Re: Stable Squeak?
> > > Resent-From: squeak at cs.uiuc.edu
> > > Resent-Date: 18 Apr 2001 15:55:57 -0000
> > >
> > >
> > >
> > > Andreas Kuckartz wrote:
> > >
> > >> I still do not see a need for a project fork which is not even prepared
> > >> openly.
> > > I agree with you that the work could have been more publicized, but...
> > > The whole idea of Squeak is to encourage everyone to do whatever they
> > > want. Interestingly both Alan Kay and Dave Thomas actually encouraged
> > > people to do this in their keynotes at SmalltalkSolutions.
> > > Standardization is stagnation, and we already have enough systems that
> > > are standardized, haven't we? ;-)
> > >
> > >> Which of these features are incompatible with the aims of SqC ?
> > > Actually none. And stable Squeak is not intended to be incompatible, the
> > > idea (John correct me if I put this wrong) is to take a breath, take a
> > > very close look at the system and work out some issues like modularity,
> > > refactoring, cleanup of historically "grown" code that later will
> > > benefit the "mainstream" Squeak tremendously.
> > >
> > >> Why should I expect more openness in the future?
> > > Be patient just a little while longer.
> > > And, the world tour is coming almost to your home town in August (ESUG
> > > in Essen), for LA that would be considered walking distance (except
> > > nobody would walk here ;-) ).
> > >
> > > Michael
> > >
> > >
> > > --
> > > "To improve is to change, to be perfect is to change often."
> > > Winston Churchill
> > > +------------------------------------------------------------+
> > > | Michael Rueger    m.rueger at acm.org      ++1 (310) 937 7196 |
> > > +------------------------------------------------------------+
> > >
> >