Pressures for Substantially New Squeaks

Andrew C. Greenberg werdna at gate.net
Fri Feb 12 13:57:33 UTC 1999


I wrote:

> Look guys, this is OPEN SOURCE software -- whatever you want it to 
> be, make it so!  It is unreasonable for you to expect Squeak 
> Central (who has given us GOBS of stuff and is making more gobs at 
> enormous rates) to stop what they are doing to build an entirely 
> new and different system -- they have their own agenda, and you and 
> I have ours.  The point is that they have given us this grand GIFT 
> -- and it is up to us to make it great.  That's the theory of the 
> Bazaar. Enjoy the chaos!

In a recent cc-listserv thread, one author, discussing Apache and the 
relative benefits of BSD and GPL discussed how modularization can 
reduce fragmentation of open source projects:

> Is this a fluke?  I don't think it is.  I think it is happening neither
> "because of" the license, nor "in spite of" it either.  I think we've been
> able to resist fragmentation because we've sufficiently modularized the
> project.  We have the core HTTP server, the perl module, the java module,
> the GUI project, etc etc. When the code base of a single project is too
> large for a small core team to maintain competently, then the pressure to
> fork becomes greater than what the core developer team can accomodate.
>
> I think what it comes down to is the talent and willingness of the core
> team to accomodate and cooperate.  Whether it's GPL, BSD, MPL, or anything
> else, a project will die if it no longer can evolve or grow because of its
> core team of developers.  This is Darwinism in action. This doesn't mean
> the code will disappear, just as archeologists can find bones and
> perhaps even DNA of animals millions of years after they became extinct.

One of the fundamental difficulties of Squeak as an Open Source 
project in comparison is its somewhat monolithic nature.  In 
comparison, Python and Java comprise a host of tiny bite-sized 
"modules" capable of providing "safe" means for expanding and 
enhancing the product without making fundamental changes to the core. 
This is in large part facilitated by some modern encapsulation 
features in each language.  Groups can spin off, do things in chunks, 
share their work with others for further development, and Darwin 
helps to assure that only the good survives.

Named Pluggable Primitives go a long way toward helping people to 
extend Squeak in fundamental ways without requiring substantial 
fragmentation of the core machine.  I am presently putting fininshing 
touches on a PluginPlugin, which will permit the use and execution of 
non-Squeak external libraries from within Squeak, again all without 
recompiling the VM.  I hope this will be helpful to some.

[Other changes are certainly indicated.  I do not agree with those 
who call for the Java-izing of Smalltalk, insisting that Smalltalk 
must support true private names.  After all, Python doesn't really do 
that (the experiment with scrambling of variable calls to identifiers 
beginning with a "_" wasn't used that much in practice for namespace 
preservation -- not to Guido's surprise) and Python supports an 
extraordinary library pool.  I am not opposed to modern 
encapsulation, and believe many aspects CAN, perhaps should, be added 
to Squeak without changing Smalltalk per se -- I just note that the 
lack of real private variables did not cripple Python.]

I think what is called for, at least, is a better set of documents. 
Few people understand (I'm sure I do not completely grasp) the 
purpose and function of changes editors -- this can be fixed with a 
reasonably straightforward, but complete, "how-to" documents. 
However, it is time for the COMMUNITY to get involved.  Documenting a 
project the size of Squeak is an extraordinarily large project, and 
we users owe it to the Squeak Central to pitch in.  If we produce 
even basic documents, they will in time be able to refine and polish 
it to get it right.

We are reasonably many at this point, and if we all took it upon 
ourselves just to document one or two Classes, or to write portions 
of a relevant FAQ, squeakland would be a far nicer place to live.  I, 
for one, volunteer to help.

Can anyone at SC think of ways to help coordinate such an effort?





More information about the Squeak-dev mailing list