[squeak-dev] Re: Meeting Report for 8/18/2010

Hannes Hirzel hannes.hirzel at gmail.com
Wed Aug 25 05:40:59 UTC 2010


Andreas

Sure. I am happy that you like the analysis.
And I propose that you redraw the diagram to include Cobalt and other
maintained forks of Squeak if known to you. I have just used MSPaint
to do it. Why didn't I use Squeak?
Is SqueakLight or FunSqueak of Edgard maintained? Probably yes, though
on a more occasional basis. Edgar tries to preserve the original
Squeak flavor.

Cheers

--Hannes

On 8/25/10, Andreas Raab <andreas.raab at gmx.de> wrote:
> Hi Hannes -
>
> I think that's a very insightful analysis. I hadn't heard the term
> coopetition before and I've not seen the concept applied to open source
> projects. A very interesting set of thoughts.
>
> Would you mind if I quote this memo in full on my blog to preserve it?
>
> Cheers,
>    - Andreas
>
> On 8/24/2010 9:50 PM, Hannes Hirzel wrote:
>> Hi
>>
>> I would like to comment on the trigger word "competition" which Pavel
>> has brought up in connection with Squeak / Etoys / Pharo and Cuis.
>> Andreas is advocating a discussion which actually promotes the work
>> and I support this.
>>
>> 1) There is competition - sure - but as a whole it is just a sign of a
>> healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis
>> around. I have written this earlier this year when we were asked to
>> fill in a questionnaire. In fact as a user of a Squeak based Smalltalk
>> "distribution" or "fork" I am happy that there are alternatives. The
>> use of these alternatives may vary though.
>>
>> 2) It is probably more precise to speak of coopetition.
>> 'http://en.wikipedia.org/wiki/Coopetition
>> <citation>Coopetition or Co-opetition (sometimes spelled
>> "coopertition"  or "co-opertition") is a neologism  coined to describe
>> cooperative competition. Coopetition occurs when companies work
>> together for parts of their business where they do not believe they
>> have competitive advantage and where they believe they can share
>> common costs.</citation>
>>
>> Or maybe we should speak of a 'distributed' development approach or
>> just having different distributions which share ideas / concepts/
>> strategies / code snippets and packages. This is reuse on all levels
>> (analysis, design, implementation, package, methods). A recent example
>> is the WebClient and the release announcment of Pharo 1.1 for example
>> states (http://www.pharo-project.org/pharo-download/release-1-1).
>>
>> <citation>StandardFilestream now performs read-buffering, dramatically
>> speading up some operations like "Object compileAll" (2x improvement)
>> as well as various other operations (scanning change lists etc). This
>> change was taken from Squeak."</citation>
>>
>> and further down
>> <citation>
>> A new general cleanup protocol has been added. The cleanUp protocol
>> takes an optional argument to indicate whether we're doing an
>> aggressive cleanup (which involves deleting projects, change sets, and
>> possibly other destructive actions) or a more gentle cleanup that's
>> only supposed to clean out transient caches. This change was taken
>> from Squeak.
>> </citation>
>>
>> 3) Squeak, Etoys, Pharo, Scratch and Cuis have different "missions" so
>> to say. Or we could say "different customer groups".
>>
>> As a reminder for the goals of Squeak I would like to mention the
>> article "Personal Dynamic Media" written in 1977 which is to be found
>> on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is
>> amazing what was there at that time.
>>
>> The problem in the past was that Squeak development did not scale in
>> terms of developers working together and going for forks was the only
>> reasonable thing to do at that time. But this does not mean that new
>> approaches are not feasible. Scratch so to say was 'silent' fork. And
>> at the same time a very successful one. It did not create much noise
>> on this list. Maybe we should call it an application. In the area of
>> Squeak these borders are blurred (intentionally) and this might be
>> part of the causes for these kinds of discussions.
>>
>> 4) Going for a minimal kernel with loadable packages maintained by
>> various people is actually meant to stimulate "competition". People
>> will be encouraged to take the minimal kernel and load all kinds of
>> things on it and distribute the result and create communities around
>> it.
>>
>> 5) For this to work the kernel has to be minimal in a sense that it
>> can be managed by a small team. This is the aspect Cuis strongly
>> promotes and we want to adapt for Squeak. Actually this is not new at
>> all.  It has been a long standing goal. But for many reasons about
>> which  we have pondered many times it had not been achieved so far.
>> Juan has given the real-life proof that it is possible to maintain his
>> own fork as a single person while at the same time adapting important
>> changes from elsewhere. In addition he has contributed back to the
>> main-line Squeak development. From this point of view we should really
>> de-emphasise the negative aspects of competition.
>>
>> 6) This time we have Andreas, Pavel and Juan for the core, Eliot on
>> the VM side and Bert for the Etoys link working together. Others are
>> working on various aspects improving the system. I think this is an
>> opportunity and there is a real chance of success.
>>
>> 7) As an illustration I did a sketch. (see attached PNG file). I think
>> the overlap of the distributions is considerable. As a follow up it
>> would be nice to have some simple statistics like no. of classes per
>> distribution. Number of classes with identical names across
>> distributions. As the picture is very rough somebody might post a more
>> accurate one.
>>
>> Cheers
>>
>> Hannes
>>
>>
>> P.S.
>>
>> Please note that in the meeting report this thread is about Randal
>> says that he wants to contact the other Squeak based projects to talk
>> about a minimal core.
>>
>>
>>
>>
>
>
>



More information about the Squeak-dev mailing list