On Jan 9, 2006, at 2:06 AM, Avi Bryant wrote:
> A suggestion that I think I've made in the past is that we  
> explicitly acknowledge the forking by not privileging any of the  
> forks with the name "Squeak" or the front page of squeak.org.   
> Instead, squeak.org could direct people to the fork that is most  
> likely to be useful to them, whether that's Squeakland, Tweak,  
> Croquet, Spoon, SqueakLight, Traits (what we're now calling 3.9a),  
> Seaside (not really a fork yet but could be), or something else.   
> Work to make the basic infrastructure of websites, bug trackers,  
> FTP servers, SqueakMap, SqueakSource and so on "fork aware" and  
> equally available to any fork that has a following.  And if you're  
> worried about the negative connotations of "fork", call them  
> "distributions" instead...
>
> Avi

Allow me to throw in my two cents as someone completely new to the  
world of Smalltalk and Squeak.

Opening up a fresh 3.8 image and browsing around is a daunting task  
right now. I'm sure sorting out the "core" from the "rot" to identify  
the crux of Squeak will become easier as my experience grows, but  
should that be a necessary step in learning Squeak?

To me, the system described in this thread of a "Core Squeak" that is  
the essence of Squeak, and an easy system of loading in additional  
features as packages (with dependency support), seems like easiest  
system for a newcomer to pick up. One could get the core image, open  
it up, browse around a bit to get a feel for what's there, and then  
hit SqueakMap to load in other packages to experiment with.

A system of forks or "distributions" seems terribly confusing, and I  
fear that that way lies madness. How much is lost by the confusion of  
having to wade through a monolithic image, or by having to step  
through a wizard answering questions about how I intent to use Squeak  
in order to find the proper mix of packages in a distribution that  
interests me? How much is gained by having a prepackaged mass of  
packages in a distribution compared to having a single, common, image  
that one can load those packages into in a half an hour?

This approach seems to be the cleanest and easiest solution for  
everyone. It gets the "rot" out of the image, but makes it rather  
easy to load them back in if desired. It allows people to create a  
package that, once loaded, would effectively be one of these  
distributions, without having the confusion of sifting through a list  
of similar images to download.

I hope I have no stepped on any toes, misspoken here, or suggested  
something completely impossible because of my ignorance of Squeak. I  
just feel it's important to consider how approachable Squeak is to  
the newcomer. It's all too easy to forget what it it's like to stand  
at the bottom of the learning curve looking up after one has already  
reached the top.

-Dane