Coopetition in Squeak

An excellent article by Hannes Hirzel. Quoted with permission.

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.

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.

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

StandardFilestream now performs read-buffering, dramatically speeding up some operations like “Object compileAll” (2x improvement) as well as various other operations (scanning change lists etc). This change was taken from Squeak.

and further down

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.

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.

Squeak, Etroys, Pharo, Cuis

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.

Advertisements

%d bloggers like this: