--- "Andrew C. Greenberg" <werdna at mucow.com> wrote:
> At 12:22 PM -0800 3/9/01, Dan Shafer wrote:
> >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.
> 
> True of Perl and Python.  Now distinguish GNU/Linux, E, X, Gnome, etc.

I'm sorry I don't know enough about all of these things to make a meaningful
comparison. I know Linux is an OS, which (unless I'm completely befuzzled) has
no built-in programming language. It is therefore not a development
environment. I have no clue about E. X is a windowing framework which (again,
as far as I know) has no built-in programming language. It's more like a UI
toolkit than a development platform or environment. Gnome _feels_ like the same
thing as X, with a lot more bells and whistles but, again, no built-in
programming language.

I think that's the point I'm trying to make (albeit perhaps not so cogently or
persuasively): Smalltalk is _both_ a language and a development environment as
well as a database of sorts that is or can be home to applications, all in one
big magilla. I really believe that makes it radically different from anything
else I know about. And therefore I think we have to reassess the "rules" we
have in our minds about how you deal with Open Sourcing.

> 
> >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.)
> 
> In several years, I have yet to see them say no to a meaningful 
> contribution.  Certainly some goodies didn't make them into the 
> standard release, at least not initially (STP has had remarkable 
> patience concerning some of his work), but that content was always 
> readily available.

I agree. I am not trying to portray SqueakC as resistant, just busy and
otherwise-occupied. My question isn't "Would they accept this changeset or
project?" it's "Do we have a right to _expect_ them -- and by direct
implication their employer -- to be able and willing to take the time to deal
with what is hopefully a rising tide of submissions?" I think the answer has to
be no.

> >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.
> 
> Patches, changesets, or whatever contribution you may care to make 
> are welcome.  Under the license, you are also free to fork whatever 
> you like, subject to some limitations.  I just don't see the need to 
> fork.  BTW, haven't you been watching the project/namespace/etc work? 
> One no longer needs to be "potentially disruptive of the entire code 
> base.  And if you can do better structurally, by all means do so.

In my group, we have seen a number of instances where we've done things relying
on the way something at the core of Squeak is done in one version only to find
that breaking in the next release. And we don't have a large, full-time
commitment to Squeak. I _have_ been watching the modularization work (though
not in great depth; most of it is beyond my ken) and I applaud it. I think it
paves the way for what we need: a more modularized Squeak with a highly stable
core augmented by projects or changesets that are dynamically added as needed.

> I just don't see any compelling, or even interesting need for a fork.
> 
> >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.
> 
> I feel very secure in suggesting that Eric would not find any of 
> these arguments a compelling case for a fork.
> 
Well, I can't argue with that position since I don't know how well you might
know Eric and what he would say about this situation. Perhaps someone should
ask him?


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/