Folks -

I've finally gotten some thoughts together for how to address the 
'package issues' in Squeak. This is going to take a while so I apologize 
beforehand for the length of this message :-)

First, let's talk about the goals. What I'm trying to achieve is 
basically to blur the line between what is 'in' the image and what is 
'out' of the image. What I'm trying to achieve is to enable people who 
write applications and libraries for Squeak to be seen as direct 
contributors to Squeak. What I'm trying to achieve is to drastically 
grow Squeak by being much more inclusive while at the same time 
drastically shrinking it by having many fewer packages 'preloaded'.

How can we do this? Over the last months I've spent some time looking at 
options for package management. I don't really like any of the available 
options but since I'm not going to write something new, I've 
concentrated on the one choice that appears to be actively supported - 
Metacello. It has its weaknesses but contrary to all the other options 
it's the one choice that is being supported and I appreciate that.

While looking into Metacello I also spent some time at the Pharo 
Metacello repository on Squeaksource. There are many interesting things 
to be said about it, both good and bad. Good things about it are that 
it's community maintained. Everyone can update everyone else's 
contributions and although that's not generally done, it offers a 
community approach to making sure things work. Something that for 
example both Universes and Squeakmap lack completely. What's problematic 
about the repository on the other hand is that for one thing one needs 
to unconditionally trust the code even before one has even decided to 
install it (this by far my biggest complaint about Metacello). Also, I 
don't think that a single repository is a feasible option in the long 
term - it seems to me that supporting the cross-product of image and 
package versions is going to be problematic before too long. And of 
course browsing repositories with several dozen of packages to find what 
you need isn't exactly fun either.

However, the problems can be turned on their head, and that's actually 
pretty insightful. Here's the basic idea: What if, instead of having a 
single repository for all image versions with separate packages for each 
config, we would instead have a single package simply called 
Configurations in the trunk?

That Configurations package would contain all the "supported" 
configurations for Squeak (I'll get to that in a minute). The package 
would be community-maintained, just like any other package in trunk 
development process. This addresses the trust issues with Metacello, 
since the package has the same level of trust that all the other 
packages in a Squeak release have; it has been developed using the same 
principles.

What that gives us is a mechanism by which we suddenly can include 
Omnibrowser, Seaside, Magma, FFI and anything else people can come up 
with in Squeak without having to preload it in the shipping image. What 
it also means is that we can start removing packages from the image, 
replacing them with the proper configurations for how to load them back. 
What it means is that somebody with a new application (be that 
Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask 
for the configuration to be part of the next Squeak release, thereby 
contributing *directly* to that Squeak version.

Most importantly, however, is that we as the community can decide what 
we feel we want to support and what not. By being explicit about the 
'house rules' we can make sure that the model is sustainable moving forward.

To do that, I'm proposing to create a status of "Community Supported 
Package" in Squeak. What is that? A community supported package is a 
piece of software where we feel this is an important/interesting/novel 
package that should ship with this Squeak version. A community supported 
package can be loaded in a 'one-click' process directly from within the 
image. A community supported package is a package where we provide 
assurance that the package has been tested for this release.

However, that status does not come for free. In return for achieving 
this status, the software needs follow the rules for community supported 
packages, which (at least) should include the following:

* No conflicts. Neither class names nor -override categories. The 
rationale is that all community supported packages can be loaded 
together without creating conflicts.

* Tests mandatory. A community supported package MUST have tests. The 
rationale is that since we provide the guarantee that the package has 
been tested, we need to ensure that testing can be automated to the 
maximum extent possible. It doesn't mean 100% coverage but *some* 
meaningful set of tests need to be provided or else we can't say if we 
broke it in the latest update.

There may be some other guidelines that we may want to establish but I'm 
trying to keep things simple and only the above two are truly crucial - 
what they allow is to ensure that during ongoing trunk development we 
will always be able to load all supported packages, run the tests and 
see if we broke something horribly.

So the goal of the process is that if we do this right, we should be 
able to tell how good (or how bad) a shape we're in regarding the 
supported packages when we get to ship date. We should be able to 
encourage people who write libraries or apps with, for, and in Squeak, 
to contribute directly to the next release by providing a configuration, 
their code, and the tests so that we can keep things running. In return, 
we'll help with porting, provide backwards compatibility as required etc.

Code that we want to move out of the default image would be moved into a 
configuration so people can load it if desired, and it remains a part of 
Squeak instead of rotting away. Since the Configuration package is small 
and has no dependencies, there's no problem to include that in 
core/basic images and allow people to tailor custom images from there.

Concretely, I'm seeing the following steps as necessary:

1. Establish the status and the rules for "Community Supported Packages".

2. Create the "Configurations" package and start populating it with some 
examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like.

3. Encourage people to bring their packages up to 'community standards' 
and include them in the Configurations.

 From here, there are a few more things that we should do before we can 
ship the next Squeak version:

4. Provide a better installer than these awful doIts for Metacallo.

5. Establish a test server to automatically verify the community 
standards for supported packages (i.e., load packages randomly, ensure 
no conflicts, run tests, report results).

At this point, there is another clearly defined way to contribute to 
Squeak even if you're not a core developer: Develop your software, 
provide a configuration, ensure your software adheres to the community 
standards. That's it. You've just made the next Squeak release a little 
better :-)

Cheers,
   - Andreas