Classical Applications (was Re: 17 new updates)

Doug Way dway at
Fri Feb 19 06:48:44 UTC 1999

On Wed, 17 Feb 1999, Andrew C. Greenberg wrote:

> Doug writes:
> > I guess when considering adding features essential for a Squeak
> > application tool, there are 3 options:
> >
> > 1.  Add the feature to the main Squeak (supported by the Disney team).
> > 2.  If the feature is too complex/platform-specific or otherwise doesn't
> > fit in with the Squeak vision (i.e. is rejected by the Disney team), add
> > the feature to a special Squeak Pro fork (whatever it be called).
> > 3.  If the feature is too complex/platform-specific or otherwise doesn't
> > fit in with the Squeak vision (i.e. is rejected by the Disney team), and
> > there is no Squeak Pro fork, give up and don't add the feature, and let it
> > become one of many neglected, unsupported file-ins sitting off on a server
> > somewhere.
> While approximately correct, I dissent from the "them-or-us" approach.
> This is open source, guys.  Things happen decentrally, with nominal 
> guidance from "squeak central."  The good stuff tends to find its way 
> into the next rev.  Call it option one-and-a-half:
> When you build it yourself, you haven't created an orphan -- you have 
> created an opportunity.  Call it option one-and-a-half:
> Think up a project.  Talk about it on-line (to see if it isn't 
> already extant, in the works at Disney, or if someone else is doing 
> it already).  If not, build it, document it well, publish the 
> file-out and watch what happens!
> Now, here's what happens.  People use it and/or love it, or they 
> don't.  If they do, it is likely to get adopted and (the golden ring 
> for oss hackers) integrated "one way or another" into the "central" 
> distribution.  If they don't, it will be likely to fade out into 
> oblivion.
> The success or failure will lie in the merits of your own work -- not 
> the whimsy of some monolithic central organization.  Live the dream! 
> Make it great -- and they will come.
> The neat part is that while the product is being evaluated by the 
> community, others will do to your work, precisely what you did to 
> squeak.  They will give you good stuff and cruddy stuff.  In the end, 
> your work will be better, and the community will be the better for it.

Basically, I agree with what you're saying.  I probably exaggerated my
point #3 a bit... I certainly don't mean to imply that changes made by
individuals and put out on a server will be ignored.  (such as my
scrollbar changes. :) )  Your scenario describes most of the contributions
being made to Squeak.

My point was mainly just that, for the smaller subset of contributions
which don't make it into the main Squeak line because they're too
platform-specific (such as a native widget framework), it wouldn't hurt
for these contributions to coalesce into an alernate fork (or maybe just a
group of tools).

Hopefully, this will happen naturally once someone has built something
significant for native support.  So we probably don't need to argue about
it too much about it until then. :)  Marcel Weiher's SqueakEnvironment
sounds like a promising first step, though...  (Of course, there was also
Boris Shingarov's Cheese project for OS/2 native widgets, but something
more simple and general might be needed as a starting point...) 

- Doug Way
  EAI/Transom Technogies, Ann Arbor, MI
  dway at, dway at

  Smalltalk: Guaranteed Y10K Compliant

More information about the Squeak-dev mailing list