I have been following the discussion as an observer.  While I have been 
working with Smalltalk for decades, I have yet to dive into Squeak, or 
Croquet, beyond playing with them.  In both cases, the issue is the 
size of the image, and the overall impression from the "product".  The 
Smalltalk of old was much less capable, but also less intimidating.  
The number of classes and categories was smaller, and what was there 
was both better documented, and had less redundancy.  In the Squeak 
image there are 2 UI systems, at least 3 graphics systems, etc.  
Croquet adds OpenGL bindings, which at least are well covered by many 
reference sources.

I would submit that Squeak is suffering from featuritis.  Like 
Microsoft Word, it keeps getting new features without rationalizing 
them with the existing features.  As a volunteer or noncommercial 
effort, this is totally understandable.  I am not being critical of 
anyone.  But, as a community I think you are reaching a cross-roads.  
Getting investment into Squeak, and Smalltalk in general, requires that 
the community of programmers grow, and the results be usable in 
commercial environments.  It may be time to take a break from adding 
features, and get a more minimal well thought out core.  For the sake 
of portability, and to allow tinkering with everything, it has often 
built everything itself.  This reduces the options for those that are 
trying to produce results that have commercial value, or want better 
performance.  (Native windows vs. a single window for example.)

I suspect that the current Squeak code base is serving too many 
masters.  Too many divergent interests are being served with one code 
base, one image, when innovation and progress would be better served by 
divergent images off a central core.  If we had a core that included 
the language, VM, compiler, and core runtime like collections, rich 
unicode multi-lingual text, and a method level packaging system, 
efforts could evolve independently of each other.  This core could be 
relatively static once it was stable.  The innovation would be on top 
of that.  This would also allow newbies to be introduced to the system 
in stages.  But, that would require tremendous effort, require top 
architects to have a prayer of getting it right, and be very 
disruptive, which would not serve other users.

I do not know how long the current status-quo will remain.  I suspect 
that just as the PARC work exploded into derivative works, Squeak will 
do the same.  I would expect that the number of derivative images will 
increase as various needs arise that can not be resolved in a single 
environment.  I hope that the community can retain some unity in 
working with this divergence.  This is more likely to produce small 
"elegant" subsets of the current image that is Squeak.  If someone 
produces a truly elegant core it should get attention and users, and in 
time it might replace the current image as dominant.  So, I expect 
evolution to win out over a controlled design effort.

Michael


On Dec 12, 2004, at 11:52 AM, stéphane ducasse wrote:

> hi mark
>
> Have you noticed that diego has to fork and work alone already. Don;t 
> you feel that this is somehow
> our failures as a community? Especially since diego was the guy 
> pushing the dynabook idea and complaining that not enough was done for 
> the multimedia in squeak. Where were the people to help him?
>
> Stef
>
>
>>> It shouldn't come to anyones surprise that if you leave a community 
>>> that this community will go into a different direction.
>>>
>>>      Marcus
>>
>> I think that Marcus is dead-on with this comment.  People shouldn't 
>> be surprised if parts of the system that they contribute get 
>> abandoned if they're not there actively promoting and maintaining 
>> them.  (And I disagree with Andres:  Andreas is actively promoting 
>> and maintaining his pieces of Squeak, and as an active developer, 
>> it's certainly part of that role to critique what others do and 
>> encourage what he wants to see.)
>>
>> But I think that Lex's point is also quite valid: What about the 
>> newcomers to Squeak?  What is their expectation about Squeak, and do 
>> we them (and the community) a disservice by not making some effort to 
>> meet that expectation?  Expectation failure doesn't encourage people 
>> to join a community.  The important question for the community, then, 
>> is to define: What is Squeak?  By answering that, we can more 
>> effectively promote that definition and encourage the appropriate 
>> expectation.
>>
>> I'm biased here, but I think that one of the ways that people 
>> discover Squeak is through the OOPSLA paper by Dan et al. and the 
>> White and NuBlue books.  We certainly don't want to let EVERYTHING in 
>> those publications define Squeak -- that would completely limit the 
>> community's ability to change.  But I do think that the NuBlue book's 
>> title, "Squeak: Open Personal Computing and Multimedia" is a pretty 
>> good definition, and one that the other publications agree with.  
>> Squeak is about open personal computing and multimedia.
>>
>> That's what concerns me about the current process in Squeak -- it's 
>> setting aside the personal computing and multimedia aspects (for now 
>> -- I do understand that) in favor of improving the underlying base.  
>> I understand that current members of the community consider those 
>> "goodies" (such as Wonderland and eToys) to be "hacks," but those 
>> "hacks" brought in many people to Squeak.
>>
>> I do appreciate what Stef and the Berne group have brought to Squeak, 
>> and I think that the environment that they propose for 3.9 sounds 
>> like an exciting one to work in.  But here's my suggestion: It's not 
>> Squeak, at least not as it has been defined and communicated in the 
>> past.  When the base is improved and the personal computing & 
>> multimedia "goodies" are ported back (if they are), then it might be 
>> Squeak again.  But as Marcus points out, that will only happen of the 
>> multimedia developers are still around then, and they might not be 
>> during the interim -- it's not clear that people interested mostly at 
>> the level of the base image are the same kind of people who want to 
>> build things like eToys and Wonderland.
>>
>> I make two concrete proposals -- they're alternatives:
>> A. Call the new thing something else.  Let "Squeak" end at Version 
>> 3.7 or 3.8, unless someone wants to continue it as a tool for 
>> personal computing and multimedia.  Don't let the expectations of 
>> "Squeak" limit where the current community wants to go.  Use the new 
>> name to attract new attention (maybe get Slashdot to notice?) and to 
>> signify a new set of emphases.
>> B. Or, call the 3.9 version "Squeak 4.0," and make it clear that 
>> there is no promise of compatibility or multimedia features across 
>> the boundary from 3.X->4.0.  Say that clearly on the Website, and 
>> make the final 3.x version forever available.  If people want 
>> "personal computing and multimedia," they can download the final 3.x. 
>>  If they want the coolest open source Smalltalk on the planet, with 
>> the base hooks to grow one's own personal computing and multimedia 
>> (like the really interesting eToy/Wonderland substitute whose URL 
>> Marcus sent around), then let them grab the latest 4.x version.
>>
>> If a day comes when the "goodies" get folded back in, maybe we can 
>> re-merge.  But nobody should hold their breath waiting for it.  The 
>> Georgia Tech group and Andreas' Croquet group can decide which 
>> version(s) they want to develop from, and perhaps fork if they want.  
>> (FYI, the "Scratch" project at the MIT Media Lab is building on 
>> Squeak 2.7 -- the forks are already happening, so we might as well be 
>> honest about it and stop battling over the name.)  But by making a 
>> clear break with the past, Stef and the Berne group have a freehand 
>> to take the base image in the directions that they want, and people 
>> who come to Squeak with the "personal computing and multimedia" 
>> expectation can make a choice.
>>
>> Mark
>> __________
>> Mark Guzdial : Georgia Tech : College of Computing/GVU
>> Atlanta, GA 30332-0280
>> Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
>> http://www.cc.gatech.edu/~mark.guzdial/
>>
>>
>
>