[Squeakfoundation]Operating procedures for a "burn the diskpacks" list?

[Paul Fernhout]

Cees-

You raise an interesting set of issues I have had to pause to think
about. I do however want to generally keep the discussion more on the
concept of a list charter because that could be of use to anyone doing a
Squeak project (say, the next version of Celeste) rather than the issue
of whether this particular project was worth doing. But the details of
that charter don't seem to interest anyone yet. Hopefully it may serve
as a starting point should the issue of mailing list charters arise
again in the future.

=== clean rooms ===

IANAL, but I would think from what little I know of how "clean room"
work is done (i.e. give an API and functional spec to someone who has
never seen a related implementation) that probably no one seriously
participating on the Squeak list could participate in a true "clean
room" reimplementation of a Smalltalk system. Unlike using a C compiler,
using Smalltalk as a developer generally entails using a browser and
having access to system code -- so all Smalltalk developers are
"contaminated" by possibly having seen system level implementation code. 

However, I feel if a new Squeak-ish system is developed using a newer
approach (prototype-ish?), and all contributions are continually
scrutinized by asking questions like:
* "is this new?", 
* "is this grossly infringing?", 
* "is this feature present in all Smalltalks?",
* "is this feature from a well documented public reference document
(like ANSI or the blue book or a published paper)?", or 
* "is this feature from a compatibly license Smalltalk (perhaps
PocketSmalltalk or the public domain Smalltalk)?",
then perhaps something interesting and with a clearer title might
emerge. Hopefully, any questionable parts that somehow snuck in from
carelessness or ignorance could at least be identified, and then
replaced, reworked, or worked around. People have already added a lot to
Squeak on top of the core. I'm also hoping they might again make similar
contributions to a newer base, but with a clearer contribution license
this time if they had not licensed it clearly previously.

=== papers ===

It's an interesting idea to get formal papers signed (although that may
have been not meant seriously). However, the question is who to send
them to? Me? What if I get hit by a bus or lose interest? Who keeps
them? The community should not have a single point of failure. Perhaps
the Squeak Foundation could keep them (where? can they get lost or
burned?). And even then, what should the papers say?  With the charter
outlined, the record of the users contribution to the list is itself
proof of the validity of the contribution (assuming there is only one
way to subscribe to the list). Presumably a monthly FAQ would remind
list participants of their rights and responsibilities. Note, this does
assume the charter and the first click is legally binding, and I don't
know if it would apply worldwide (I think it would in the US with the
recent laws relating to click through licenses.) The paper approach
sounds like it would be more certain worldwide though.

However, printing, signing, and mailing a document raises the barrier to
participation so high that people might not be willing to try
participating at all. The "click here if you agree to join the list and
accept the charter" approach provides two easy choice points to control
how a participant contributes. One click signs up the potential
contributor (who is not really contributing anything yet, so there is no
immediate cost or risk, and yet that click provides an immediate benefit
of now getting an email stream of interest). A second click by the
contributor in an email program later on brings the previously agreed on
charter into play by making a "gift" of a license to the community of
some aspects of the person's copyright rights in the emailed item.
People could always send mail privately or to another list to avoid
making contributions covered under the list's charter. I'm assuming here
anyone can read the list archives or use them under the license, so
there is no other incentive to sign than to contribute code or otherwise
participate in the ongoing dialogue. To avoid worry, one might want to
specify a short grace period in the charter (perhaps one to three days)
during which submissions to the list made in error or otherwise
immediately regretted could be canceled or nullified as far as
licensing. The issue isn't to force people to contribute -- it is to
make it easy to do so in a manner that automatically provides a
reasonable amount of "due diligence".

=== GNU Smalltalk ===

GNU Smalltalk has a lot to recommend it. Frankly, working with the GNU
Smalltalk platform is something I've seriously considered -- although if
I was not going to work with Squeak, Python (or some form of Lisp or
Scheme) would probably come in second because of the size of the user
communities and the crossover to immediate business value. GNU Smalltalk
(based on reading about it) sounds very impressive -- especially
considering the small number of maintainers compared to Squeak. It
seemingly effortlessly deals with things -- exceptions, events, and
modules -- that have long been fought over on the Squeak list as far as
even convincing people they are worthwhile. And it does seem to have a
clearer title in terms of handling contributions and attempts to avoid
infringement (for example it has a more flexible event system added to
avoid seeming to infringe an existing Smalltalk). Without having tried
it, I think (probably showing my ignorance :-) that GnuSt shows better
software engineering than Squeak but perhaps shows to date less broad a
vision and less user enthusiasm (in part probably simply for being a
smaller community, but also for lack of Alan Kay & co.). Still, what
some may call less vision, others might call practicality or a different
vision. However, I'm looking for something somewhat beyond Smalltalk, so
GNU Smalltalk as is wouldn't quite fit either. Still, perhaps some
Squeak "vision" features in a Morphic direction or even ported code
(Celeste?) added to GNU Smalltalk might be an interesting hybrid for
people willing to live with the GNU Smalltalk license. 

== why rebuild something at all ===

I also hope this rebuilding process might be easier in some ways (or
possibly just more fun or educational) than refactoring what exists or
using a subtractive approach (as sensible as those may be to do in a
different context, with different objectives, as in StSq). And after
all, I am just trying to uphold Alan Kay's vision of using Squeak to
build the next great thing, and avoid "Squeak eating her young".

We never know as much about something as if we help build it from the
ground up. Thus, there may be great personal value in helping with a
"Squeak raising" after we "burn the disk packs", much like people learn
something about barns and carpentry at an old fashioned "barn raising",
perhaps after one burned down from lightning. 

[By the way, thanks go to Benjamin Franklin for inventing the lighting
rod and avoiding many barn burnings, even though the lightning rod was
very controversial at first for what now may seem surprising reasons.
  http://www.santafe.edu/~shalizi/White/air/rod.html 
Maybe Squeak needs a "crazy, paranoid developer" rod :-) ]

-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

Cees de Groot wrote:
> If you really want to have a sort of clean-room, infringement-free
> variant of Squeak, I think you should go all the way and only 
> allow people on the mailing list after they've signed papers. 
> Before you know, it looks an awful lot like GNU Smalltalk...