On Jan 30, 2005, at 9:20 AM, Peter Crowther wrote:

>> From: [...] Cees de Groot
>> On Sun, 30 Jan 2005 10:20:55 -0000, Peter Crowther
>> <Peter at ozzard.org>
>> wrote:
>>
>>> -- another way --
>>
>> Hear, hear! (mostly. There are quite a number of nits in your
>> story I'd
>> like to pick, but I'm not going to do that at this moment)
>
> Well, quite.  You didn't expect me to spoil a one-sided email like that
> by weakening my case, did you? ;-)
>
>> BTW - I'm thinking that we could decide to "just do it".
>
> I think Craig already has.  Like most prophets and visionaries, he has
> confused a lot of folks in the process.
>
>> it is a whole lot better than what we've got now
>> and could be done immediately, just by deciding to do it.
>
> And that, I would argue, is a key point.  As Craig has found, one 
> person
> 'just doing' works for that person.  As we have found on this list, a
> large group delegating a few people to go away and debate something 
> then
> maybe do it sometime... doesn't work either, as the frictional costs 
> are
> too high and nobody in the small group wants the results enough.
>
> This is actually a third problem with Squeak as an OS project... It's
> too big, and does too many things, none well enough to be 
> best-of-breed.
> So there's always a better tool to use for any particular problem.  Who
> would rally round the new, slimmer image?  Certainly not the
> Croquet/Teatime crowd.  Not the UI folks.  It wouldn't do multimedia...
> Really, it's a bit difficult to know who would take it and use it.

I strongly agree with the need for a small core and packaged extensions 
above that, and that Squeak is trying to do too much.  I would stress 
that my perception of squeak is that it is trying to do far too much 
for the resources available.  It shows all the signs of a project that 
is barely keeping its head above water.  There are major parts of the 
system with no documentation, no class comments, no way for anyone but 
the author to have a clue about what the code is SUPPOSED to do.  This 
means it is unmaintainable in the long run.  There are an equal number 
of areas where the code is unfinished to a large degree.  Much of the 
code is just barely good enough for what it is currently used for, 
while having pretensions of being more general.  This lack of quality 
in the design and implementation is understandable for research 
projects that are more interested in trying out an idea than producing 
a solid product, but the effort required to use Squeak in a product 
appears huge at present.  There is a lot of code that would need 
serious maintenance effort on code that is going to be hard to 
maintain, and hard to get changes accepted into.  Money is never going 
to flow into a project that is in this state.  And money in the form of 
services or development dollars is what it is going to take to get 
enough resources on this project to produce a clean product.  The 
successful open source projects are those that are used commercially, 
because they get resources from vendors, and employers using the 
software.  Unfortunately too much of Squeak has been built for research 
or hobby motivations.

Nothing of the above is critical of any individual or group.  There are 
pockets of people putting a lot of effort into this system, and it has 
some huge architectural advantages.  But to be successful the community 
is going to need to take itself more seriously and hold itself 
accountable to a higher standard of what goes into the product.  To do 
that the core must be smaller so it can retain its quality while 
supporting packages that can have any focus and quality they want.

People like open source projects because they can fix issues that 
arise, but that does not mean they want to fix them.  In general the 
level of bugs and quality of implementation is more important to 
adoption than the level of features.

>
> This shouldn't stop somebody doing it, however, and publishing the
> result; that way, people might pick it up and use it.  But that
> 'somebody' should need/want it *for themselves*, so that they'll put 
> the
> effort in.
>
>> But by Just Doing It, we could actually attempt to tackle
>> these issues instead of constantly debating them.
>
> Quite.
>
>> (re breakage - I just realized that it should be possible to
>> use the RB
>> rewriting stuff with thisContext sender to actually rewrite
>> methods that
>> call obsolete stuff and send the maintainer of the package an
>> auto-generated patch. Now that'd be an elegant tool for
>> dealing with bit rot ;)).
>
> Quick, find an academic and publish a paper :-).
>
> 		- Peter
>