[Squeakfoundation]The Natives are Restless

[Paul Fernhout]

Dan Ingalls wrote:
> I have some concern for the pace of bringing SqF into existence.

=== why I've been quiet on this list ====

I am torn on the bigger picture of what efforts SqF should be
supporting, and that is one reason I have kept quiet the past couple of
weeks.

I just saw Alan Kay speak where I am currently contracting and he
mentioned in his talk that some people are more "religious" about Squeak
than SqueakC (which he says tries not to be "religious" about Squeak).
He sees Squeak as a platform to build the next great thing, and then
maybe use that as the foundation for the n+1 great thing. Certainly when
I look at Squeak, as great as it is, I see it could be something more --
more easily supporting prototypes, supporting other languages on a
common base, acting as a distributed digital library, supporting Doug
Englebart's 1968 Augment vision, and so on.

I am concerned that without some discussion of this vision issue (and
maybe we have done enough to get started, since we have at least a
purpose?) we will basically end up with a SqF which essentially is a
loosely run company with poorly paid workers supporting a slower
alternative to VisualWorks. That might not be a bad thing, and I think
such an goal may be what is indirectly driving some of the interest in
making donations. 

I've certainly considered paying Cincom perhaps $2000 annually. I would
prefer to have a cross-platform Smalltalk base not requiring me to
report each sale, and I have an immediate application in mind to port to
it, so I might consider that amount as a business expense towards SqF.
If I had confidence in the people and process I should then be willing
to pay $2000 towards such a thing as part of, say, 50 others doing the
same. However, a VisualWorks-lite isn't really the main Squeak vision
and then we're also talking commercial coding, trust, deliverables, etc.
which imply other things about how priorities are set and by whom. Also,
if Squeak rapidly evolves, to the next level, then that effort might be
be abandoned. Also, for me, if I feel the legal status of contributions
to Squeak is not clear in terms of licenses and statements of
originality, then the money may just be wasted as a business investment
if I decide not to use the end product. So, I am wary of such an
approach, as much as I would like a royalty-free VisualWorks-lite.

As Alan Kay said in that talk, Squeak shows that five talented and
knowledgeable people in their 50s and 60s could for about $5 million
dollars total over a few years take 1975 technology to its ultimate
limit and produce things way beyond other projects (like Java) with
hundreds or thousands of developers costing hundreds of millions of
dollars. [For reference, Linux is more like technology from 1970 taken
to its ultimate. Alan of course would never discount the community in
Squeak's success, but obviously that community wouldn't have gotten
rolling without the core effort.] Yet, in how he talks about this,
clearly Alan has a vision to go further, and doesn't want Squeak to "eat
her young" like he says Lisp did. He clearly sees the need for new
approaches transcending what Squeak is now.

Related to this, the issue I've mentioned before on the list of a lack
of clear licensing status for each contribution is to an extent one
symptom of what I see as a need for modularity and complexity
management. There are other symptoms that have been discussed at length
on the main list. And, not to be too critical, but I think the
management of complexity is by far the hardest part of programming at
this point, and as sparkling and useful as Squeak is now (and thanks for
it) it will be a rough to transition Squeak from a paradigm (and related
code) where the management of complexity has not been the primary issue
for several years to a new paradigm (and new code) related to more
explicitly managing that complexity. People like Les Tyrrell have been
working on such tools (Oasis) for years. It is a hard problem.

Squeak currently supports a culture of people comfortable with a certain
tool set and a certain level of complexity managed using those tools
(essentially the browser, project, and changeset). While Squeak itself
may have only 200K lines of code in the mainline distribution, the
community as a whole surely has tens or hundreds of times that much code
(and many times that in various intermediate versions) -- and taken as a
whole, that makes for a lot of complexity. 

In other words, and obviously it's not quite this bad, but, if the
complex house of cards is near to going crashing down in flames without
some major changes, why should it be the Squeak Foundation that takes
the heat? Perhaps instead a "burn the disk packs" approach might make
more sense (such as Jecel Assumpcao Jr is doing with a new VM approach).
That way a new system with a clear title for every contribution,
organized in a modular way, with additional complexity management tools,
could be built from the ground up in a distributed fashion by the Squeak
community. Obviously, though "burn the disk packs" doesn't build that
much on the existing Squeak community or knowledgebase, and so who would
the developers or users be? Still, let's assume complexity management
is, say, 1980 technology. How do we get it, and how should this fit into
the SqF agenda? 

What this will probably get translated to in practice is a question of
what version of Squeak is supported and how that integrates with
supporting all the other Squeak efforts that are based on the latest
version of Squeak (3.1). But will that be satisfying?

-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