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.
>
>
>
>