I don't think the practices that have applied to previous languages and tools
in the Open Source movement apply as well here as they seem to at first glance.

Perl and Python are purely programming languages. Their audience is
programmers. They have very little if any application and GUI "baggage" (I put
that into quotation marks because I think this "baggage" is the really
essential part of Squeak for many purposes and users.) Taking a look around a
Squeak image, I find lots of things that are not programming tools and which
would ultimately be used by non-programmers and even non-techies like my wife.

The monolithic nature of the image -- which is what triggered this entire
discussion -- mitigates against expecting the current "owners" of that code
base, Disney and SqueakC, to expend the resources necessary to make Squeak
accommodate the needs of business programmers, personal productivity
application designers, and others who are less concerned with the educational
and multimedia aspects of the product that of necessity earn Disney's focus.
(Geez that's a long sentence! Sorry. No time to write a shorter one.)

That said, "forking" may not be the right term or quite embody the right
concept here. What I had in mind was simply this: unburdening SqueakC from the
necessity of incorporating, monitoring, and delivering "patches" to Squeak
since that is not their goal or their proper role. A "patch" in Perl or Python
is not likely to be potentially disruptive to the entire code base, nor is it
likely to be something so sizable that it creates the complexities of, e.g., a
PDAMorph in Squeak.

I am as opposed to unnecessary forking of Open Source projects as anyone. I've
read Raymond's work as well. But I don't think even Eric would suggest that
there is _never_ a reason to fork and that each particular
product/language/tool has its own gestalt. I am merely suggesting that given
Disney's overarching goals and interests and the broader interests of at least
some substantial part of the community, combined with the monolithic nature of
the image, some new approach is called for.

--- "Randal L. Schwartz" <merlyn at stonehenge.com> wrote:
> >>>>> "Andreas" == Andreas Kuckartz <a.kuckartz at dokom.net> writes:
> 
> Andreas> I do not see a "plea of dire necessity" to fork the Squeak
> Andreas> project. When did SqC object to submissions of Smalltalk code
> Andreas> or VM modifications which were necessary to make Squeak "an
> Andreas> industrial-strength, generic problem-solving system for all
> Andreas> of us" ? If they did not do that then new or improved code is
> Andreas> required instead of a probably wastefull project split.
> 
> Totally agreed.  In the Perl community, when someone complains about
> how Perl does something, we merely reply "patches welcome".  I think
> that applies here too.
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/