Thanks to Enrico, Hannes and David for your kind words.

Enrico Spinielli wrote:

> If you will organize your projects to be open and you will be willing to get some help,
> I would be very interested to help with your vision of a system projected in the future
> without forgetting the past! 

The project was fully Open Source between 1997 and 2008 (though so
poorly documented that it might as well have been closed), but now is
partly Open Source and we still have to figure out which parts will be
what given the large overlap between the commercial venture and my PhD
project. Curiously, while it was Open Source it couldn't be considered
Free Software since in the 1990s I came up with a concept similar to
Apple's App Store but with "pay per use" as in Brad Cox's
"Superdistribution" instead of "pay to own".

http://www.wired.com/wired/archive/2.09/superdis.html

Having to pay to run software violates freedom 0, though not 1, 2 and 3:

http://www.gnu.org/philosophy/free-sw.html

It does not, however, violate any of the 10 terms of the Open Source
Defintion:

http://www.opensource.org/osd.html

Basically, it would be great if people could make their living by
working on Smalltalk. I am trying to figure out a way to achieve this
without secrets and restrictions. Back in the 1980s and early 1990s I
gave the DRM issue a lot of thought and decided against trying to find a
technical solution for an ethical problem.

Hannes Hirzel wrote:

> You say:
> 
> " I you can't add simplicity, only complexity."
> 
> So to have something simple you have to start from scratch.

Exactly. If you take Unix and add X11 and then QT and the KDE you might
get something that looks simple, but it really isn't and once in a while
the underlying complexity will show through. Contrast this with BeOS,
for example. And I think that they limited how simply they could make it
by basing their work on C++.

Even while playing with Little Smalltalk 3 (100KB image, 40KB VM and
Smalltalk-76 class model) or 4 (92KB image, 89KB VM and Smalltalk-80
model) I like to think about how much we have learned since these
systems were created and how much smaller and simpler they could be.

Just a simple example to make this discussion more concrete: in the
Squeak VM we have the "push literal" bytecode that will take an object
reference stored in the method object and save that on the stack. That
reference can be to *any* object in the whole image, but the compiler
will only allow us to generate code that points to a small set of
objects that have a literal syntax defined for them: arrays, numbers,
strings, characters, booleans and nil. What if we could just drag any
object and drop it into the source code? The compiler could be far
simpler - all it would need to do would be to copy the reference from
the source text to the method object instead of knowing how to parse
half a dozen text notations. Of course, the complexity would have just
moved elsewhere instead of being eliminated because if the compiler
doesn't know how to make numbers then some other part of the system has
to be able to do it.

The point is that doing it from scratch allows us to explore
alternatives that are not available while just adding to the current
system.

> I am looking forward to your work on a
> "a very simple Smalltalk to run side by side with Squeak in the second
> half of 2012"

For that we have to define a standard way to communicate between
different images (TeaTime is a way to keep identical images in sync, and
so doesn't count). That could be rST, Spoon's Other or something similar
(Colin Putney has proposed a specialized one for remote
debugging/development). With a little care, it would be possible to have
an application that would run half in Squeak 1.6 and half in Squeak 4.3
or else half in Spoon and half in Newspeak.

-- Jecel