Against wastefull forks (Re: Taking Ownership of Squeak (WAS Re: Python at Disney))

Paul Fernhout pdfernhout at kurtz-fernhout.com
Sun Mar 11 14:03:52 UTC 2001


Bob Hartwig wrote:
> Why are we discussing a hypothetical fork, when the Stable Squeak fork
> already exists?  Peoples' concerns about modularity and stability are both
> important driving factors for Stable Squeak, and progress is already being
> made.
> 
> If you are contemplating a fork, check out Stable Squeak and see if you can
> join forces.  If you are against a fork, you're too late; it's already
> happened.  Start arguing against a second fork, which probably *would* be
> wasteful.

Bob-

I totally agree with the sentiment that forking is wasteful and should
be avoided. I also agree that if one is going to do something, it makes
sense when possible to do it with others, and the Stable Squeak project
is a great place to start with a group that has great goals:
   http://wiki.cs.uiuc.edu/CampSmalltalk/Squeak+World+Tour
   http://wiki.cs.uiuc.edu/CampSmalltalk/Squeak+World+Tour+Results

However, my point (and I think it has unfortunately been born out in
practice as demonstrated by the Stable Suqeak fork) is that (lack of)
modularity is so interwoven with the basic design of the system that it
would be best if this was a priority of SqueakC as to avoid a fork. 

Look at http://c2.com/ppr/envy/ for ideas on thinking about Smalltalk in
terms of layers and sections (effectively modules).  The basic issue
there is that classes are nice modules in a way (in that sense the
original Smalltak-80 was very modular, more so than many contemporay
prodecural systems), but classes also need to work together in larger
units (layers and sections) which themselves are effectively modules,
and all of these can have multiple versions that need to be matched up
to build a sensible image.

If Squeak was more modular, the Stable Squeak project would not have to
be based on a fork as it could improve Squeak module by module,
returning each module back to the community as soon as it was stabilized
or improved, and thus reducing confusion and minimze divergence from
time code spends out of the main line while it is enhanced. Also, the
Stable Squeak effort could contribute new business-oriented modules
(like alternate GUIs) that would easily "play nice" with the rest of the
modules being moved along by SqueakC. Likewise other developers not in
the Stable Squeak project would be able to still work on other modules
without being as likely to create dependencies which would effect Stable
Squeak.

What it comes down to is the feeling on my part (which SqueakC is free
to ignore of course) that modularity is so important to the survival and
growth of Squeak that if SqueakC are to advance Squeak's leadership
position, they have to take some action in this area, even at a great
short term cost. Obviously SqueakC's management may have other
priorities, but my other point is that in two recent cases related to
core Disney capabilities (networked games and animation) Disney has
chosen Python over Squeak -- so it would seem SqueakC's own interests
would be served by this focus on modularity (and stability).

Complementarily, it is to (sadly) say that an effort like Stable Squeak
(as it relates to modularity, not neccessarily other improvements) will
get quickly left behind unless it is a major fork which acquires its own
support community. In practice, for the short term that probably means
splitting the Squeak community which is a bad thing, or having massive
outside funding (which eventualy will also either split the community or
force everyone to use the new fork). The only other possiblity is that
Stable Squeak would attract a totally new pool of developers (business
type users) and I think that would happen -- but not at the start
(basically, not until it has more or less already succeeded).

So to summarize, IMHO:
1) Nobody wants a fork because it might fragment the community
2) Modularity is so interwoven and big a task that will take months and
be difficult to integrate with an ongoing development stream, so it
can't be done by anyone else but SqueakC without a fork
3) If SqueakC doesn't make modularity a priority, forks will happen
(Stable Squeak for example) because modularity is so essential for
stability and sanity and Squeak's long term growth and success
4) Lack of modularity is limiting Squeak's use at Disney
5) Therefore, SqueakC should make modularity a short-term priority

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list