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

Andreas Raab andreas.raab at gmx.de
Wed Aug 25 06:11:28 UTC 2010


On 8/24/2010 10:40 PM, Hannes Hirzel wrote:
> 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?

I don't really think changing the diagram is necessary, as the point is 
crystal clear, and there are probably even more forks than we can think 
of right now. I've posted it here:

http://squeakingalong.wordpress.com/2010/08/25/coopetition-in-squeak/

This will be very interesting to look at a couple of years from now :-)

Cheers,
   - Andreas

> 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