[Squeakfoundation]Notes on a NYC SqF-related meeting (Cees, Paul)

[Paul Fernhout]

Cees de Groot was in New York for an IBM Linux tour (mentioned
previously on the list) and he and I had a chance to meet in person and
talk for a couple of hours on Squeak Foundation related topics. 

Cees (pronounced "Case") has been involved with Linux since 1993. I was
fascinated by his insights stemming from that experience related to open
source community success. While he cautions that every development group
is different with different needs for their particular system, there may
be much in the Linux model we can learn from for use as appropriate for
Squeak. Here are some (incomplete) notes from that conversation. Some of
this has been discussed before on the Squeak list, but I think it will
be nice to have it in one place. Cees, please correct me if I got
anything substantially wrong. 

=== squeak on a mainframe? ===

At the beginning we talked some about the IBM Linux tour Cees had been
on, which included discussing Linux on IBM mainframes. Cees suggested
that by looking at the lowermost Linux interface to the IBM zSeries, it
might be possible to make a port of Squeak running more-or-less native
on an IBM mainframe. Wow! For anyone interested, I just discovered this
article which discusses how you can get free access to Linux on an IBM
Mainframe, which might get one started:        
http://linuxtoday.com/news_story.php3?ltsn=2001-05-23-002-20-PS 

=== bless you :-) ===

Linux divides roughly into kernel, libraries, and configurations. A
benevolent dictator "blesses" kernel releases at some point. Others can
create and maintain specific libraries and packages they are interested
in, and bless those (with ones being close to the kernel perhaps
requiring delegated authority from the benevolent dictator). Then,
special interests can create their own configurations by choosing from
versions of the kernel and libraries/packages to meet specific needs
(business, research, gaming, embedded, etc.) and bless those
configurations (like, say, RedHat does). 

Putting this in a Squeak framework, we might have a VM blessed by, say,
Tim Rowlege (as benevolent dictator for life), various base classes or
applications handled by others interested in them (some key ones
delegated by Tim), and then configuration maps (maybe like ENVY)
maintained by the business Squeak interests, the research Squeak
interests, the embedded interests, the PDA interests, the protoype-based
Squeak interests, the education interests, and so on. We discussed ENVY
some, and my hypothesis that the people who like ENVY used it without
security turned on, and the people who hate ENVY used it with security
enabled.

The Linux process involves development, testing, and then "blessing" by
a recognized authority (possibly a benevolent dictator). If the blessed
code has problems, the authorities status and credibility declines
(perhaps eventually to the point where such blessing means nothing). If
the blessed code is solid, the authorities credibility is maintained or
increases. What is going on here is in part using somewhat informal
social processes to create some sort of engineering discipline. The
blessing process creates confidence. 

Cees pointed to some examples where  code still existed and might be
developed, but without and active "blessing" authority, the code was not
picked up. (Unfortunately, this has happened with some private Squeak
code or small projects developed in various ways which never get
"blessed"). 

Obviously, the current authority for "blessing" Squeak code is SqueakC.
So, it might make sense for SqueakC to "bless" an image for the Squeak
Foundation to use as a starting point, passing on some of the flame as
it were.

=== even and odd ===

In Linux, odd numbered releases are experimental, even numbered releases
are supposed to be stable. Almost anything can be added to an odd
numbered release for the first 70% or so of its time span. After that
point, the release becomes more conservative. Even numbered releases get
primarily only bug fixes (and occasionally backports of new features,
but this is controversial because of testing and stability issues). The
idea is that even numbered releases have a high friction for changes;
odd numbered releases for most of the time have low resistance to change
(although in the last 30% of the process they will start removing
unstable features).

=== marketing to IT decision makers ===

An important aspect of the Squeak foundation should be marketing Squeak.
Cees gave me a copy of LinuxUser magazine: http://www.linuxuser.co.uk 
What is interesting about this is that unlike your typical linux
magazine designed to be fun to read for techies, this magazine is
designed to be for managers (IT decision makers). So, it focuses on how
Linux is being used, how it will save money, what options are available.
For example, on the cover there is a picture of a burning five pounds
note with the text "Money to burn? Can you afford not to deploy Linux?"
It would nice to see someday: "Money to burn? Can you afford not to have
your programmers work in Squeak?"

=== participants & infrastructure ===

We talked at length about group process related issues. These included
some issues already in the "Restless" and other threads. The chaordic
process can be a difficult one, but we feel we are making progress by
having a purpose and the start of some principles. We still need to
address participants, such as for example if groups like Cincom will
participate, and if they will donate technology (like StORE, which Cees
likes). We talked briefly about what might be sensible relationships
between a Squeak Foundation and Smalltalk vendors (such as growing the
pie, AIX vs. Linux in 1993 vs. now, upgrade paths, etc.). 

[Naturally, I tried to plug the Pointrel Data Repository System for
Squeak http://sourceforge.net/projects/pointrel/ as potentially filling
the StORE niche, although admittedly that code is not yet tested enough
to be given a high level of confidence, and it also is limited by
Squeak's ability to truncate files (and perhaps reliably flush/sync). I
also raised the issue of peer-to-peer Squeak distribution of the
codebase in addition to relying on a server.]

Cees said Squeak CVS has worked well for him. SourceForge (which implies
CVS right now) could be strongly considered as an initial starting point
for Squeak Foundation activity support because it is there, it is free,
and it has some credibility. It might make sense to have several
projects on SourceForge related to different interests -- and they might
even have different licenses depending on the participants in the
various projects. 

The fact that the image cannot be built from scratch from text files
(yet) is a difficulty in the SourceForge/CVS direction, although it can
be worked around somewhat by checking in binary files. Personally, I
would rate building the image from text as a very high priority for
complexity management. 

Cees pointed out that the much of the Linux community has a certain
expectation for how to, in a few shell commands, download a current
released set of files from CVS, build it, and then run it. There would
be great value in terms of leveraging the Linux community expertise if
the VM (and image) building process following that model.

=== thinking about things Java may do right and wrong ===

An interesting thing to think about is the Java model in the sense that
Java scales from a MicroEdition for embedded devices to an Enterprise
Edition, each managed more or less by distinct groups, but presumably
there is some common VM code in there. We chatted some about Alan Kay's
comment on the difference between standards as specifications (e.g.
Java) and standards as open-source implementations (e.g. CPython).

=== education and business motivations ===

We also discussed Alan Kay's comment that doing stuff to make kid's use
of computers better is an easy sell, compared to doing stuff to make
adult's computer experience easier, since adults are trained by school
and on-the-job to "keep a stiff upper lip" and accept distress and
discomfort, but it would be a rare person to say children's software
should be allowed to cause kids stress or discomfort.

Cees is interested in Squeak from two very different perspectives (which
I think have been mentioned before on the list). One is for use in
business related to web hosting (where he currently uses Python). The
other is as a parent wanting educational toys and tools for children.
This creates both business and charitable considerations for involvement
in Squeak. The two motivations, which each by itself may not always be
enough, can together sometimes produce some synergy leading to action.
This might be something to consider further from a Squeak marketing
point of view. 

=== the Squeak ecosystem ===

We discussed how the metaphor of the "Squeak ecosystem" as a set of
related projects and modules of multiple versions is a powerful one. We
both think it makes sense for the Squeak Foundation membership to work
in terms of strengthening this ecosystem of components, however they are
put together by the end user.

For one example, we discussed briefly the possibility of decoupling the
VM's lowest platform specific layer from a Smalltalk specific approach
to make a cross-platform base which could be available to other
languages (either through a VM or as just straight C calls). While such
a refactoring doesn't support Squeak Smalltalk directly, it might
indirectly expand the entire Squeak ecosystem -- if Python or Perl or
C/C++ developers were to use it and then help maintain it for their own
purposes.

For another example, relying on a configuration map to select a variety
of compatible component versions out of the larger ecosystem helps pink
plane and blue plane interest groups to more easily coexist (since they
just maintain different configuration files).

It might be nice at some point in the future to revisit the purpose
statement with the ecosystem metaphor in mind (although not now as we
don't want to slow things down). This ecosystem metaphor was one reason
behind Cees picking the NAMA principles (related to enhancing a natural
ecosystem) as a place to start from.

== conclusion ===

All in all, it was a pleasure and a great learning experience for me.

-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