I agree with much said by both Ned and Lex. I've written an article on
SqP that talks about the network effects through which these
social/technical issues affect Squeak. It has an example on how Linux
kernel development solves some of the bottleneck problems we're seeing.

Daniel

lex at cc.gatech.edu wrote:
> This was a good read!  I completely agree that focussing on the
> social structures is the best way to move forward, and also that we
> should pay attention to what others are coming up with.  There are
> plenty of tools around, and we can make anything that we need anyway.
> 
> Along these lines, we should think hard about what our actual
> communities are doing and desire.  In particular, please notice that
> a lot of Squeak users are not tracking the "standard" Squeak
> release at this point, but have started with 3.0 (or earlier!) and
> gone on their own way.  THIS IS NOT BAD.  Or at least, we cannot
> afford to simply say all these guys suck and need to change pronto.
> We need to come up with a community structure that supports our
> current disparate members, even if we want to change this over time.
> 
> 
> One of your ideas I find particularly helpful is to consider that
> putting
> a package into any individual distribution requires some amount of
> extra work.  Each distribution will have its own standards, all of
> which are more than zero.
> 
> This does not mean, however, that people *must* be responsible.  It is
> simply that they must be responsible if they want their code to go into
> the particular distribution they are interested in.  There is no need to
> put guilt trips on people.  Instead, let us set up standards, and then
> rely on people's own interests about whether it is worthwhile meeting
> those standards or not.  Keep in mind that people *do* have pressure to
> get things into the centralized distribution(s) even if they are
> completely self-interested.  Anyone who has tried to maintain patches
> while the upstream source is being modified, can tell you all about how
> un-pleasant that is.
> 
> Another interesting aspect of having multiple distributions is that it
> removes some pressure from the gatekeepers in the "standard"
> distribution.  If they think of themselves as making "the" Squeak, then
> they are under a ton of pressure to make every decision right, and this
> inevitable slows down the acceptance rate of good-looking patches.  If
> they think of themselves as making *one* good Squeak distribution, then
> the standards are different.  It becomes easier to allow for mistakes,
> because users who cannot tolerate the mistakes will be using a different
> distribution anyway.
> 
> I picture this multiple distributions approach as being an excellent way
> to both support our current community and to support any efforts to
> migrate that community in desired directions.  It would be nice, by
> itself, to go to some Squeak site and then be able to tour around the
> various sub-communities.  And there are useful tools for migration being
> talked about: let packages be shared among communities, let them be
> added to distributions when they have met the distribution's policies,
> and do let distributions have policies attached to them.
> 
> 
> One aspect that bears some investigation is these "workflow" tools.  I
> would be ecstatic to have a good Squeaky bug tracker, but the ToxicFarms
> guys seem to think workflow tools are better than mere bug trackers.  I
> know nothing about them so cannot comment.
> 
> 
> 
> On a small matter, it seems reasonable to have more than one
> image per distribution, so let's not *quite* identify images and
> distributions
> one-to-one.  A classic example is 3.6 basic versus 3.6 full: these both
> should draw from the same set uf packages.
> 
> 
> Finally, your "distribution" seems exactly what I mean by a "package
> universe", but I'm not sure if it is exactly what Linux people use it
> as.  For whatever it's worth.  I'm perfectly fine with "distribution" so
> long as we keep it straight.
> 
> 
> Lex
> 
> 
> PS -- let's not forget to update the web sites with any updated
> community viewpoint we come up with after these discussions.  And of
> course, these thoughts should actually be run by some of the
> non-squeak-dev Squeakers at some point!!