Pressures for Substantially New Squeaks
Andrew C. Greenberg
werdna at gate.net
Fri Feb 12 13:57:33 UTC 1999
> 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