I'm saying you and other groups will be able to pursue "strategies" of
inclusion, including releasing (somewhat) tailored image, in a Squeak
world that supports sharing very well. 

IIUC, you're saying that if this were so you would be happy, but you
don't trust we'll get there. Right?

If so, I merely need to show why this strategy should work, and make
sharing less expensive than it is now.

What do *we* need to do to avoid our pool of packages from becoming
forks? as I said, we need for all images to share a "base". So the
derivative images should avoid patching that. We need our packages to
follow policies (which we'll need to invent). Part of which is that
packages are modules and it is very very bad manners for your package to
patch another's code. Especially those of base. Distro's should have
ZERO loose methods. It's all base + packages. That should mostly do the
trick. 

Why? because then the case you mention doesn't happen for distros - some
packages require other packages, some packages conflict, and tools
(we'll develop) help users avoid getting into that situation.

We also need to be careful about the contents of base itself. To avoid
giving people excuses to patch it, it needs to be clean, it needs to be
stable, it needs to include the critical stuff, and then include nothing
else (if it's not there, it won't be patched). People need to understand
that it won't be *precisely* what they want, because it is shared. If
they *need* to have a base that is not generally acceptable, that will
require a fork.

As long as the popular images don't fork (patch base), we'll be fine.

Any less nervous?

Daniel
PS. For the curious:
To continue the Linux analogy...

(simplifying...) At first, Linus made a kernel. People would get it,
compile it, compile all their GNU utilities they'd gotten by ftp from
various nether-sites, and have a system. Obviously, this was cool for
people that had never had unix on their PC, but for anyone that wanted
to actually *work* with a complete system, not spend time installing it,
it wasn't very good.

Then distributions came, some commercial. These were bundled sets with a
specific companies logo and ideas splashed all over the place. This
didn't make hard core users very happy, because they wanted to be free
from the ideas of this or that vendor.

But they wanted to share all that hard work of
cobbling/patching/installing/solving conflicts every package they like
to use, every time a new release comes out. They created automatic
installation infrastructure, with dependencies, and build-servers, and
policies that define rules about packages, and scripts that test the
validity of packages. They split the packages into categories like base
(which is pretty much shared by all), and development and net and so
forth. All that was shared, and the packages, of course. What stuff was
packaged? whatever people wanted (within the licensing policy, aka
DFSG). 

That's Debian. They pick a project leader. There's no question that the
DPL doesn't decide what packages are in - the Debian package maintainers
do that. What strategy do they have? I don't know, they have somewhere
over 8000 packages right now. They have various internal projects that
package for including educational projects, or projects for kids.

Does everyone use the same image? no they have nice UIs to download
stuff on demand, that automagically handle the dependencies.

Andreas Raab <andreas.raab at gmx.de> wrote:
> > We do intend to have multiple images, starting soon - with 3.6's
> > release. This will include the "full" image, which I think everyone
> > agrees should be a "media platform", among things, since cool demos
> > pretty much require media stuff. This image would be "base" + a set of
> > packages preloaded. To avoid becoming a fork, this image 
> > should try hard to include packages that are mostly modules.
> > It can apply patch packages, if it avoids patches to "base" stuff,
> > so that development done on this image is shareable with "base".
> > It would obviously need to be led by someone media oriented. 
> > 
> > Does this solve the part that bugs you specifically? if not, how?
> 
> If I would think that having multiple images that way would solve the
> problems I wouldn't even have started the discussion. In short, I don't
> trust this approach very far though it is hard for me to explain exactly
> why.
> Perhaps another analogy with the Linux world and its distros is
> appropriate. What you see is effectively a split of the community around the
> different distros and in the Squeak case this might be even more complex
> since it is likely that significant work will be done in the various
> versions. 
> 
> Consider a situation where we use a method in distro X which is not in
> distro Y (or implement a selector which is not in distro Y but defined by
> someone else in distro X). What's going to happen? Stuff breaks. Meaning
> that we'll soon have packages which work only for distro X, Y, or Z. Meaning
> that the overhead which is required to make "all around versions" for
> something triples (this is similar to changing versions but now we suddenly
> have a couple of versions which we need to test against). And I don't think
> the community can survive this split (it's too small for it) and people will
> see Squeak as a thing "where things just don't work" as a package loaded
> into one distro works perfectly fine and breaks in another one. And then,
> people will (merely to avoid this image) start thinking very hard about
> giving their distro a different name, setting up their own servers for the
> packages and you got a couple of forks ahead of you. I'll leave it up to
> your judgement if the Squeak community can afford this.
> 
> Cheers,
>   - Andreas