> From: ... stéphane ducasse
[...]
> But what we really need is a leadership which can be an organization 
> that for example
> can collect funds, have a decent web page, identify target, motivate 
> people, value enhancements...
> and not just a bunch of people working on projects without 
> communication.
[...]

Coming in late to the discussion - apologies.

Sorry, Stef, but I disagree.  What a successful open source project really needs are:

1. A small, close-knit bunch of people working on Squeak to achieve their own ends (these may not be 'leaders'), and distributing that product;

2. A way of allowing a larger group to modify and extend the products of that small group, and then to distribute those products.

I am going to argue that Squeak has *never* had that combination and, as a result, has never been a successful open source project.

-- the old way --

Squeak sort-of worked in the days of SqC.  It worked because there were a core bunch of people who could and would sort out the problems, sometimes *despite* the larger community.  The rest of us could argue, redesign, jabber away until we were blue in the face, but development continued despite all the noise.  There weren't 'working groups' and 'cleanup projects' and the like; there were people who trusted each other to fix the problems while working solo.  This works for a small group of Smalltalk developers, as our beloved "exquisite personal computing environment" can just-about deal with coders importing code from others in a small group.  It's hard to do this with even a few people working on the same project, however, and seems to get exponentially harder as the number of developers increases.

Some of us in the larger group didn't always like the way the development was going.  When a new image came out, we found that the extensions we had made didn't work any more, and we had to fix them or let them rot.  So we clamoured to get 'our' bit into the 'base' image, because then it was more likely that it would be maintained.  That didn't work, because the central maintainers couldn't maintain the extra bits and they rotted anyway.  But neither was it possible to keep reasonable external packages that could be added in, because those packages relied on too much of that highly-functional, extensible class hierarchy in the core.  Implementation inheritance is inherently fragile - as I think every package maintainer has found out when something minor changes in a base class and suddenly your code no longer works.

-- the new way --

SqC dispersed.  Image maintenance was taken over by the larger group - and, immediately, the problems started.  Our "exquisite personal computing environment" turned round and bit us, because it *sucks* as a system in which a large number of developers can work.  We're now in the position of having a small group of 'harvesters', whose job is to examine changes submitted by others and to perform a damage-limitation exercise on the amount of change going on in the core image.  It's a tough job; it burns people out.  But, because we have this monolithic image, we don't have the choice.

The larger group are still no better off; possibly worse off.  We still develop code.  We are still encouraged by the functionality in this huge code base, and we still choose to use implementation inheritance to extend the system as there is no other mechanism in Squeak for extension.  We still get ticked off when something modifies behaviour on which we depend; but now, we cannot even be sure that the modification is sensible, as the harvesters are having to pull in changes from many people and attempt to make them work together.  This situation will remain while we continue to use implementation inheritance from base classes that evolve.

-- another way --

1. Throw away the notion that you can depend on that big, juicy class library.  You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.

2. Decide on a very small, stable core.  Collection and number classes may be a good start.

3. Introduce a proper notion of interfaces for these.  Freeze the interfaces, either formally or by people avoiding modifying them.

4. Build up from this core.  In each package - for example, the MVC UI - define and freeze interfaces.  Document all the dependencies.  Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package.  Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.

We will then have a basis for a system that might begin to satisfy (2) above.  (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project.  The larger community cannot force it.

Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers.  We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive.  This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.

-- conclusion --

Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts.  Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core.  So the architecture of Smalltalk itself is against us.  Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version.  So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision.  And it takes them more effort to develop in that environment, but *much* less effort to maintain.

I admire Craig Latta's work on small images that do not contain a development system.  If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.

I'll leave you with one last puzzle: why does majorShrink exist?  Why isn't it majorGrow?

		- Peter