El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribió:
> Dear All,
> 
> As far as I see it the only sensible way ahead for squeak 3.11 is to
> adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to
> begin a series of initiatives to promote compatibility with squeak
> pieces that pharo doesn't support.
> 
> The previous squeak 3.11 vision accepted, and now rejected, by the
> squeak board was to develop a process that would allow squeak to harvest
> the contributions of all the other forks, or other major initiatives,
> and for significant contributions to be shared by all the forks.
> 
> All of a sudden there was an "oh no pharo is ahead of us" panic that
> ensued last month as a result of new squeak-dev people that were not
> involved in, nor seemed aware of the goals of the 3.11 process. Within
> this process Pharo may simply be viewed as a research project carried
> out on behalf of the wider squeak community, that will be harvestable in
> good time.

I don't agree with you on this point. Pharo has its own merits to exists
and it didn't fork as a "research project" for the squeak community.
As its web page states, its goal is:

"to deliver a clean, innovative, open-source *Smalltalk*"

emphasis mine. Not a clean Squeak.
As the day pass the foundations grow stronger and itself gains more and
more identity and independence. This, if nothing really big happens on
Squeak, will attract more developers and new users. There is no date yet
to deliver a new version of Squeak, and this, together with the Pharo
1.0 release, will be less energy to try to maintain code for several
forks and several packages will choose to support the one with more
*apparent* users. 
What I want to say is, there is, as each day pass, less homesick for the
past and more joy for the future. 


> 
> However now that this idea is no longer going to be developed, we need
> to limit the number of diverging active forks as much as possible,
> rather than creating new ones ("trunk" makes the problem worse not
> better). 

This is a point that I have never accepted of your thesis. There is no
way to put all the "forks" in the same
process/mindshare/goals/repositories. It is impossible. Even if they do
it just for upsetting people. This isn't going to happen.

The forks, as the young people, want to be free, independents, of its
parents. They don't want to be like their parents project but a little
different. They WANT to be better (whatever this means to the fork) and
independent. They want to learn their own lessons.

If for accident they happen to be compatible good, but if not, well, as
the Linux community can show, there can not be a single distro neither a
single code base that runs in every distro. How they solved it, by
assinging mainteiner of each package that tracks the upstream project
and adapt it to the specific distro. Something like this will happen
with squeak/pharo/cuis. The upstream developers will have its
development platform but someone else will adapt it to other platforms.



> Once the output of "trunk" is released in whatever form we will
> then have yet another base image to manage code for, and I don't think
> that that is an acceptable outcome.
> 
> When it comes to the elections next year, if there is anyone who would
> like to run on the "Squeak to adopt Pharo" ticket, then I will vote for
> them.
> 

If this happen, then good for both of the communities. But until this
happen, most new users will learn by the lists about pharo and when
trying and comparing it to squeak, will make its choice. Some of them
will stay with squeak, some of them will try again squeak when a new
release is made and some of them will stay with pharo for ever.

One (at least me) can't be jumping or using several smalltalk versions
(the same way that I don't like to administer linux of several flavors,
it add unnecessary complexity and work).

> best regards
> 
> Keith
> 
> p.p.s. Bob is not going to be released as open source, if you would like
> the ability to build your images daily, and run the test suites against
> your deliverables, then please do email me for licensing terms.
> 

This is really a sad thing to read. Of course it is your decision, bad
for us as it sound as Bob was a very good piece of software. On the
other side, this sounds also like a emotional response more than a
rational one. But if the community can't use your code, well, like the
BitKeeper on the Linux kernel code case, someone will have to think
something.


-- 
Miguel Cobá
http://miguel.leugim.com.mx