Very bad about Squeak in blogosfere

 From Anonymous on
http://factor-language.blogspot.com/2007/08/smalltalk-is-dying.html:

"Anyone who says Squeak is production ready has never used Squeak in
production. Recently quite a prominent member of the Squeak community
seriously considered moving to Java because he could not get uptimes
bigger than a two days. It turned out Delays and Semaphores (!!!) were
broken all time along. There are dozens of issues like this. One example
is that the settings of the GC are tuned for memory sizes of about 1 MB.
Don't even get me started about the 1 GB and 120 MB memory issues which
tend to crash the image. Or the bugs in ClassBuilder,
InterpreterSimulator, Decompiler, .... You need to have several Squeak
images per CPU because there is a limit to the amount of punishment a
single Squeak image can take. Squeak itself is heavily forked (Squeak,
Croquet, Sophie, SqueakLand, SmallLand, ... ). All the code in the image
in unmaintained. There are teams but most of the time they don't even
integrate submitted fixes for bugs. Development of these packages has
stopped. The same situation for the VM. The only VM that is maintened is
the Mac VM. The Windows VM will only get new builds if the maintainer
needs some fixes for himself. The Unix VM is unmainted. The maintainer
of the main VM code publically stated he will do shit unless someone
pays him. Squeak is fully of ugly shit code that has just been hacked in
for abandoned experiments. That http server Seaside uses on Squeak?
Unmaintained and has bugs with HTTP 1.1. That really is just a small
list of issues Squeak has."




--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

That's right.  And all the other platforms are completely bug free.  
Why I've never decompiled an entire java application server to work  
around a fatal bug or anything.  I mean, there would be no need.  And  
it would be illegal besides.

Oh - except I have.

FWIW, the internet's largest retailer survived the x-mas buying  
season a couple years ago with a newish app server written in C++  
that had an uptime during peak load of something less than 15 minutes  
due to memory exhaustion.  So there's one definition of "production  
ready" for you.

-Todd Blanchard

On Aug 11, 2007, at 3:15 PM, Janko Mivšek wrote:

Hi Janko,

all problems are challenges, this was always the case, and I wonder  
<sarcasm>why people are using Croquet (Ubuntu) and bulding Sophie on top  
of Tweak and whatsmore on top of Seaside and software researchers rely on  
Squeak</sarcasm> instead of on J# and other static typers. Perhaps because  
J# has already passed its limits and so now Squeak is evaluated and  
thereby found too good to be true :) even if parts of it look crappy to  
the uninitiated :)

The message in blogosfere is a good enough plan for where to start doing  
something exiting with Squeak :) I understand the problem(s) description  
as, hey here's something todo for you hackers (professional developers).  
Sort of marketing; big vendors get mentioned when they face d%!ed big bugs  
and the headline makes it in the public sphere :)

/Klaus

On Sun, 12 Aug 2007 00:15:13 +0200, Janko Mivšek wrote:

On Aug 11, 2007, at 3:15 PM, Janko Mivšek wrote:

It's stated a bit harshly, but yeah, that sounds basically accurate.  
The amazing thing is that, in spite of all that, Squeak is still such  
a wonderful platform to work with. I do use Squeak in production, and  
there are very few things I would trade it for.

Colin

I'm just a newbie, but for what it's worth, 'production readyness'  
and commercial value are only one way to measure something, and I  
don't think they were the yardsticks that Squeak was built by.

I use Ruby to make money with, but I don't have a lot of fun with it.  
For a long time (I've been programming for going on 30 years  
(assembler to C to C++ to PHP to Ruby), building software was work  
(hey, that's why they call it work), but Squeak has revitalized the  
fun part of programming for me.

I'm working on a game I visualized many, many years ago, but never  
had the technology to implement it with. I'm not writing it to sell,  
just for myself. Squeak is perfect for that kind of fun and exploration.

Thanks to all those who have obviously put a lot of hard work into  
this great environment.

-- John


On Aug 11, 2007, at 10:32 PM, Colin Putney wrote:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marketing for On-line Collectible Dealers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Identry, LLC
John Almberg
(631) 546-5079
[hidden email]
www.identry.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Aug 11, 2007, at 3:15 PM
 From Anonymous on http://factor-language.blogspot.com/2007/08/ 
smalltalk-is-dying.html:

> One example is that the settings of the GC are tuned for memory  
> sizes of about 1 MB.

Yes, but you can change that, but sometimes I think people don't  
care, although I think the target size was 16MB  macintosh SE/30s not  
1MB.  To be fair VisualWorks had like a 20MB target in the mid/late  
90s, mind when those 500MB mission critical VW applications
crashed in a puddle in middle of the floor that always resulted in  
extraordinary billing, last minute airline tickets, and nice hotels.

Sadly Squeak applications don't seem to run in those circles. That or  
Squeak been sold as a zero cost environment so people think they  
don't have to pay anything to anyone to get serious and difficult to  
solve problems fixed in the VM or image.


> Don't even get me started about the 1 GB and 120 MB memory issues  
> which tend to crash the image.

Well that has been fixed, it was not trivial and took work from  
multiple people to fix. No-one paid for it either...
Which in some respects is the heart of the problem, how many people  
push that squeak foundation donation button anyway?
Although that would only fund infrastructure support, serious work  
requires funding I'm afraid, otherwise what you see will continue.


--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

From the writing style it's completely obvious who wrote this, so all
I can say to him is: do you think this helps brining people to
Smalltalk?  An external blog isn't the most effective place to get
*this* group moving, but it's a great place to get more people to go
"yep, Smalltalk sucks just like I thought".

The way to get these problems fixed is get more people in (since that
produces code fixes as well as potentially more donations).  Comments
like this do the exact opposite.

On 8/12/07, Janko Mivšek <[hidden email]> wrote:

Colin Putney wrote:
> It's stated a bit harshly, but yeah, that sounds basically accurate. The
> amazing thing is that, in spite of all that, Squeak is still such a
> wonderful platform to work with. I do use Squeak in production, and
> there are very few things I would trade it for.

Well, yes, but you can't deny that the guy's got a point. The
frustration he's expressing is something that everyone has felt over the
years. And while there are various plain invalid points in his post
(like the fact that Squeak has bugs - I'm *shocked* to hear that of
course and would have never started three products if I'd known that ;-)
the main emerging point is valid: The lack of quality and maintenance.
The problems he cites are all known, some of them even have fixes but
there isn't enough traction in the community to make this all come
together. And of course the forks don't exactly help because we still
haven't figured out how to share code across the forks and consequently
we have left numerous folks behind in the last versions (3.7: all those
people who don't want m17n; 3.8: all those people who don't want traits)
and absolutely no way (and interest) in re-integrating those forks. And
as a result, you'll have the effect that Croquet has tons of bugs fixed
but nobody knows it (because I don't care about peddling the goods). And
I'm pretty sure the same goes for Sophie or Seaside or OLPC or any other
serious project.

Leveraging those projects is what Squeak.org today is really, REALLY
terrible at. But it is where the majority of Squeak production code gets
written so if you want to get those fixes and enhancements that happen
in these projects you need to find a ways of integrating them.

Cheers,
   - Andreas

Hi Andreas,

You cannot say that there is no intention to harvest changes and  
reunite forks. Look at what we did in 3.9.
Now of course you can say what you want but you cannot expect the  
harvesters to look into croquet code
and bring that fixes into 3.xx. So please do not bend too much the  
reality. We harvested and integrated as much
as bug fixes as we can in 3.9 and I think that the result is good.

Now if you document the code that can be harvested I'm sure people  
will take care of that.
The problem is that in the past you were shouting when we touched (we  
are idiots anyway) packages you maintained
such as graphics, so this is why I never dare to include your fonts  
fixes in 3.9. I was fed up to be bashed on regular schedule.
I think that bashing people was not really productive at the end.

Now let us be positive.
        - I would be interested to find a way and contribute to help fixing  
the situation
        ie bringing more tests, bringing the community together.
        - May be building task forces to fix what can be fixed.
        - using the squeakfoundation to collect money to improve the situation.
       
But first if people like you do not care about mentioning what is  
fixed what can the other do?
I bet that if you would put a list of croquet fixes then people would  
look at them. May be this is a task for 3.11.

Stef

Gosh we must be such nasty people. I'm amazed anyone has anything to  
do with Squeak  under such awful circumstances. Clearly we must all  
give up earning a living in order to satisfy this nice persons demands.

It may have escaped the notice of some people out there that a  
significant proportion of the major contributors to Squeak actually  
earn their daily crust by working for the net benefit of the  
community. That tends to mean that said people have precious little  
time left over to work on giving away free stuff not related to their  
work. "Free Software" does not mean "free to tell me what to do with  
my time".

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MERCI RIEN - Thanks for nothin'.

tim wrote:

This deserves to be re-quoted in full.

There's nothing you can't give away for free that won't turn some people  
into greedy whiners.

Fortunately, I think in most cases we get stone soup.

Andreas Raab a écrit :

> Leveraging those projects is what Squeak.org today is really, REALLY
> terrible at. But it is where the majority of Squeak production code gets
> written so if you want to get those fixes and enhancements that happen
> in these projects you need to find a ways of integrating them.

As forks are concerned, reintegrating fixes in Squeak mainstream should
be a two way process, no?
Otherwise, yes, Squeak will get all fragmented to the loose of everyone,
because yes forking in free software are very community expensive and
are most of the time dead end for some branches.

Hilaire Fernandes wrote:
> Andreas Raab a écrit :
>
>> Leveraging those projects is what Squeak.org today is really, REALLY
>> terrible at. But it is where the majority of Squeak production code
>> gets written so if you want to get those fixes and enhancements that
>> happen in these projects you need to find a ways of integrating them.
>
> As forks are concerned, reintegrating fixes in Squeak mainstream should
> be a two way process, no?

Indeed, one would hope so. Although, I'm not sure if we agree on what
"two-way process" means here ;-) To me, it means that those projects
both contribute as well as benefit. As it stands, it appears that most
projects don't benefit at all from "mainstream" Squeak. I can't speak
for other projects (so I won't) but the situation for Croquet is clear:
There have been plenty of fixes brought back to Squeak.org but there
have been no improvements brought to Croquet from Squeak.org. So it's
been a uniquely one-way relationship so far and that is part of why
there is limited motivation to go through the hoops to get all the other
fixes into Squeak.org proper.

I had tried to change some of this by doing per-package maintenance (so
that we and other projects may be able to benefit from changes folded
into these packages). Unfortunately, that effort got torpedoed every
step of the way.

Cheers,
   - Andreas

Andreas Raab <[hidden email]> wrote:
> There have been plenty of fixes brought back to Squeak.org but there
> have been no improvements brought to Croquet from Squeak.org.

IIRC you integrated a bunch of fixes of which at least my
FastSocketStream rewrite is "from Squeak.org"? But sure, Squeak.org is
very slow these days so I agree in principle :) - will post a long post
soon with an idea I want to bounce around with all of you.

regards, Göran

Hi all!

(long post, sorry!)

Andreas Raab <[hidden email]> wrote: ...
> together. And of course the forks don't exactly help because we still
> haven't figured out how to share code across the forks and consequently

And Andreas continues to describe the problem that I have been thinking
a bit about during my vacation.

Last night I wrote it up and intended to bounce it around "privately"
first on selected people, but reading this thread it is so inviting to
share the idea so what the hell :) Forgive me if this post is long - but
I want to paint my picture as best I can.

IMO these are our major problems today (we have lots of minor ones too
and the problems intermix):

1. More or less anarchy when it comes to leadership of Squeak-dev. The
board is not taking charge, for a whole range of possible reasons. One
obvious reason is that the guys elected are really good developers who
tend to be very busy. Another reason may be that we have different
expectations on what they should/could be doing. IMPORTANT: I am *not*
placing any blame though - we are all in this together.

2. We are now "de facto" living in a highly forked world (Croquet,
Sophie, Squeak-dev, Spoon, Squeakland, OLPC, yaddayadda...) but we don't
have tools that support such a world!

3. The core Squeak is not evolving properly mainly due to the fact that
most of the core codebase is "abandoned" - or in other words, noone
feels responsible and/or authoritive to bring it forward.

In short we have "leadership paralysis", a "forked world" and a largely
"abandoned core". Other problems I missed? Of course! ...but lets ignore
those for this post.


Considering a few measures then:

- Make a new fork with a strong leadership? Hmmm, could help with #1 and
#3 above but does nothing to improve #2 and would probably be tons of
work to succeed, and I personally don't have the required time to spend.
Plus I am a hard core "squeak-dev" member - I don't *want* to fork. :)

- Reshape the organisation of Squeak-dev? Nah, I am sick and tired of
pulling such work, done just too much of that stuff already over the
years, and it would possibly help with #1 and #3 (strong leadership) but
again would not help at all with #2.

So ok, forking is out and reshaping the organisation from the inside is
out, even though I really would want much more initiative from the board
in the future - no doubt about that.


Hmmm. But what could be done then? Well, after seeing over and over
again how really good TOOLS can change the way we interact in our
community (Monticello, SqueakMap, SqueakSource, Universes etc) I tried
to imagine a new infrastructure that would help with the three problems
above, in a *natural* way.

Let's look at #1 - the anarchy problem. If we don't try to solve it but
instead try to *live with it* - what could that mean? The piece that
suffers mostly from the anarchy is of course the base image. All our
external packages prosper just fine anyway (kinda). So could we put some
kind of "supertool" in place to maintain the base image that could be
made to work *without* strong leadership? I think we can.

What about #2 - the forking problem? Well, imagine this "supertool"
being written in such a way that it can be used in all major forks - if
its good and easy to adapt/install it would most probably also *be*
used. Monticello has already showed this can be done.

So instead of trying *not* to fork, we try to make it very easy to fork
- or rather *easy to live* in a forked world of Squeak
images/communities.

But #3 - the rotting core problem? Again, if it was very easy to fix
stuff in the core, publish these changes without having to ask anyone
for permission and very easy to cherry-pick such fixes from other people
- then hopefully the core would again start moving forward. As Andreas
notes - fixes are sitting inside Croquet and my bet is that they are
mainly sitting there because it is a bit "too much work" to push them
out. I am aware of fixes sitting in Gjallar (at least a few) just
because I didn't feel I had time to fix/prepare them sufficiently etc.


So my "daft" idea is:

Let's pull together a good team and make a Supertool that is written to
be used in all forks that... well, what will it actually *do*? :)


1. Introduce a new kind of source unit - let's call it a Delta. The guys
working with MC2/Monticello may have lots of noteworthy stuff to share
about how this kind of thing could look, but I simply want a "changeset"
for the 21st century. A patch. But a smarter one! The philosophy here
being that changesets are nice given their simplicity and malleability -
but they are not so nice in many other respects. But the concept of
communicating with other developers using the natural "work unit" - a
"commit" - is quite nice. In MC at least I tend to make too large
snapshots because let's face it - MC is too slow for small commits -
given how it works. We just don't suffer because it is so darn slick at
merging :)

2. Create the notion of "delta streams". Yes, we had the update stream
earlier - a sequential flow of changesets. It was kinda nifty, but
imagine having tons of these streams originating both from larger
cooperative projects (Croquet, Sophie, Seaside, Gjallar etc) and from
individual developers ("Andreas Raab's kernel fixes", "Juan's
refactorings of Morphic" etc). A Delta could appear in several streams
so Croquet could have a single stream for each release AND multiple
streams for different kinds of Deltas, like "base image fixes for
Hedgehog" etc).

3. Make an efficient but simple storage model for deltas and delta
streams. Here I am thinking KISS. If a delta could be represented as a
single gzipped file (enabling dumb servers just like MC does) and a
stream can be represented by file naming conventions (by a number
suffix) - then a stream is just a directory or a zip of a bunch of delta
files. Yes, very similar to gzipped changesets and the update stream. :)
This enables us to use all "vanilla" tools available for dealing with
files (http servers, ftp, rsync, email etc).

4. Make a simple but efficient transport. Let's say we set up a public
server that syncs such directories of delta files (streams) from tons of
places. And then offers it to all of us as a simple rsync. Each
developer (or team) could then use rsync to mirror that mega tree of
delta files onto our laptops/servers and the tool inside Squeak would
just need to bother with reading the local filesystem - which makes it
much more portable across Squeak dialects (and possibly even Smalltalk
dialects - but let's not go there just yet). This also means we don't
suffer from servers being down.

4. Make a simple model of Delta and DeltaStream in Squeak and let it
mirror the filesystem. Add a simple API to the model á la Keith's
Installer. Or hey, just enable Installer work with this model.

5. Make a great Morphic tool to work with them. Perhaps we could even
rework the changesorter family of tools thus superceding changesets?


Ok, imagine this supertool in your image. Imagine that all public
streams are listed directly in the tool and new ones just "pop up" as
they are added. Imagine that you can add your own private streams just
like you can add repositories to sources.list in apt-get (you Debian
people know what I mean). You can have purely private local streams on
your harddrive or streams on a shared fileserver in your company/dev
group, etc.

Now you have this huge flood of Deltas in hundreds of streams at your
fingertips. How would you use it?

1. Subscribe to some major streams and configure it to automatically
load deltas whenever they appear when you press "update".

2. Set some rules that govern if the tool should just try to load - or
ask for confirmation based on characteristics of the delta.

3. Autosubscribe to categories of streams. For example, if a new bug-fix
stream appears for a package you use a lot - you might want to get it
autosusbcribed - or again, have the tool ask you.

4. Of course, easily publish your own streams. We are talking single
button, no getting permissions etc.

5. Push fixes to other people's packages as deltas onto a personal
public fixes-stream. This means it does not matter what package you are
bug fixing - you can *always* push the fix to your personal public
fixes-stream and don't need to bother with getting permissions on
SqueakSource or wherever it came from. This is a very IMPORTANT feature
and should hopefully put an end to "lost fixes" or "fixes sitting inside
images".

We have too many fixes out there that just never get published because
of the "hassle", and sure, someone says "it is very easy to upload to
Mantis!" - but fixes on Mantis sets expectations on quality,
documentation, follow up etc. A personal fixes stream like above sets no
such expectations - it is there for the taking - but that is all.

6. Pull deltas. Selective cherry picking etc.


Important features of Deltas:

- Atomic load of a Delta. Either it loads cleanly or it does not load at
all, and it ensures this by checking FIRST that everything is in place
for it to be able to apply cleanly. This should prevent "failed loads"
and broken images. The actual low level atomicity is another story but
SystemEditor from MC2 perhaps? I dunno.

- Revertable, if *possible*. A delta can be analyzed to see if it is
revertable. If it includes doits or class initializations it is in
theory not revertable, it may be in practice though! It can also be
marked as DefinitelyNonRevertable.

- A Delta is declarative. Another class should be responsible for
actually applying them.

- When a Delta is applied to an image we generate a reverse Delta which
(when applied) will reverse the effects. Since the image may be in
different states this reverse Delta needs to be constructed when the
Delta is applied!


A Delta contains:

- A Preamble similar to ChangeSets with info fields
        - Developer (name, id, signature etc whatever)
        - Original stream (URL)
        - UUID
        - DefinitelyNotRevertable flag
        - Test doit (a non destructive, non interactive doit that should throw
an exception in order to prevent loading!)
- An ordered sequence of Actions, see below.

An example list of different types of Actions are:

- Change method (class name, old method src, new method src)
- Add method (class name, method src, category name)
- Remove method (class name, method src, category name)
- Categorize method (class name, method name, old category name, new
category name)

- Create class (class name, super class name, definition, category)
- Delete class (class name)
- Change superclass of class (class name, old super class name, new
super class name)
- Rename class (old class name, new class name)
- Categorize class (class name, old category name, new category name)
- Change definition (class name, new definition, old definition)
- Class comment change (new comment, old comment)

- Class initialization
- Doit (marked as revertable or not by author!)

Note how these Actions contain "more" info than a ChangeSet - it
contains information about what it was "before" in the image it
originates from! The idea is to make Deltas "rich" with info so that we
can apply them with more smarts.

When applied to an image the Delta is copied to a directory with the
same name as the image followed by "-applied-deltas". It is also logged
in changesfile. If the Delta can not be cleanly reverted (based solely
on its own contents) we generate reverse Deltas and store them in the
same directory prefixed with "reverse-".

Applying a Delta:

1. Verify that it can be applied (or signal CanNotApplyException). Do
this by analyzing Actions and running any Test and see if it throws an
Exception.
        - It can not be applied *cleanly* if something is "different" from
expected.
        - It can be applied *dirty* if all changes can be applied in "some
fashion". For example, a delete operation and the thing to delete is
already deleted. The reverse Delta will then show this so that a revert
will not put the thing back in.
        - It can be applied *partially* if just a subset of Actions are applied
(by choice or since some just can't be applied). The reverse Delta will
then show what was applied or not.

2. Verify that it can be reverted cleanly (or signal
CanNotRevertCleanlyException). Do this by analyzing Actions.

3. Apply and generate the reverse Delta if needed.

4. Copy delta and any reverse delta to applied dir.

5. Log to changes file.

6. Report package touched (for running unit tests afterward!)


What about merging then? Well, the concept here is to be much more
"loose" when it comes to merging compared to say MC. It was inspired by
something I read about git (Linus' SCM tool) - it doesn't try to be
smart - it just tries to do the right thing when it is obvious. In other
situations it just asks the developer. I think I like this approach. The
Delta model should be easy enough for all developers to understand. It
is "just" a changeset/patch after all.

So if I am trying to apply a Delta (or several) and the "before state"
is not as the Delta expects - we can either cop out, or let it be
"smart", or just ask the user to decide what to do. BUT... I am not an
SCM implementor - the MC/MC2 guys can clearly explain to me why/how this
will not work or amend the idea so that it can work. I gladly admit my
ignorance. ;)


...ok, enough blabbering. :) Does this sound plausible, useful or just
plain dumb? Is MC2 already this and much more?

ciao, Göran

El 8/13/07 5:47 AM, "[hidden email]" <[hidden email]> escribió:

> Hi all!
>
> (long post, sorry!)

Gorän:
I cut you post for not doing more long.
I read and re-read carefully and you put very clear my own in the works
ideas about the problems you describe and give a possible solution.

Only I wish you know I ready for work with you or any masters joining to the
Supertool quest.

Awaiting orders !

Cheers.

Edgar

This 'uber' tool will require some centralized server to store and
exchange deltas.

Its also would nice to have some 'feedback' mechanism, like accompany
delta with tests and authomatically report delta authors on how well
his delta works with particular image.
The author of delta/package can choose a set of other packages to
receive their versions in test report, so he can have a clear view
what need to be done or where to look to fix bugs.

Also, we can add a special 'test' deltas, which can be written and
associated with some package. Since we don't need to have tests in
image on a regular basis, only at development/deploying stages a
common scenario can be to load test delta, run it, send report and
wipe it out.


--
Best regards,
Igor Stasenko AKA sig.

Hi!

"Igor Stasenko" <[hidden email]> wrote:
> This 'uber' tool will require some centralized server to store and
> exchange deltas.

The idea was to try and not reimplement these particular wheels.

We set up a server that syncs streams from all over the globe (probably
using rsync and possibly a slew of other transports) - and then we all
can just use rsync to mirror that server down onto our laptops.

Thus - the Smalltalk side of it just sees a file tree on localhost.
KISS.

> Its also would nice to have some 'feedback' mechanism, like accompany
> delta with tests and authomatically report delta authors on how well
> his delta works with particular image.

Yes, and we should not underestimate emails as feedback mechanism. :)
If each Delta and/or stream has an email address associated it will be
easy to send comments back.
And some streams would then use a mailinglist address.

Exactly how we could use tests in this setup I have no specific opinion
about - but it would surely be an important part.

The whole thing is a simple idea really:

        Make it TRIVIAL to share code changes and to get them. No memberships,
permissions etc needed.

The Changesets and their tools did have a lot of nice attributes. Like
for example being able to work, work, work and then using a dual change
sorter easily pick out the work into different changesets (commits).

regards, Göran

This even can be simpler:
it can build dependency set automatically based on global symbols used in code.
For each global symbol (mostly class names) we can find corresponding
package. So all we need is to accompany delta with  version info  of
these packages.

On 13/08/07, [hidden email] <[hidden email]> wrote:
--
Best regards,
Igor Stasenko AKA sig.

Andreas Raab a écrit :

>
> Indeed, one would hope so. Although, I'm not sure if we agree on what
> "two-way process" means here ;-) To me, it means that those projects
> both contribute as well as benefit. As it stands, it appears that most
> projects don't benefit at all from "mainstream" Squeak. I can't speak

May be it will be easier to see Squeak.org not as a place of innovation
but as a place to gather fixes, improvements, innovations coming from
other places as Croquet, Sophie, Seaside,... I think nobody working in
mainstream Squeak is paid for that, so it is not possible to expect from
there direct huge improvement and fast reactivity you can get from
people working in corporate and dedicated to this task.
In the other it will be disappointing if improvement/fixes done in
Sophie or Seaside forks can not flow easily in Croquet and vis-versa.
Organising free software community is probably very difficult, but if
well organised the benefice is huge for everyone using the software.