Against wastefull forks (Re: Taking Ownership of Squeak (WAS Re: Python at Disney))

Andrew C. Greenberg werdna at mucow.com
Sun Mar 11 00:45:32 UTC 2001


>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 was offering counterexamples to the suggestion that general 
principles of Open Source development culture are limited to "pure[] 
programming languages,".  As I recall, the colloquy went along these 
lines:

	(1) You posited the possibility of a fork;

	(2) Others dissented, arguing that a fork of an open source 
product is something generally to be frowned upon in the absence of a 
compelling reason having one;

	(3) You posited that Squeak was distinguishable from the open 
source projects mentioned in support of this principle (Perl and 
Python), in that they entailed "purely programming languages," 
presumably proffering the proposition that the open source culture 
principles relating to forks apply only to purely programming 
languages;  You noted that Perl and Python don't have Os-like traits, 
GUI-like traits and so forth.

	(4) As counterexamples, I identified a host of different 
kinds of open source projects clearly identified with open source 
culture (Linux, E, X, Gnome, there's also Sendmail, Bind, Tcl/Tk, 
indeed the whole open source portfolio, in fact) which are not 
"purely programming languages," which either are or have traits in 
common with operating systems, which either are or have GUI-related 
aspects, and so forth.

>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.

I understand the big magilla thing -- hey, its Purim!  Indeed, the 
big magilla problem is at the center of our issue with GPL.

Perhaps you have identified here the possibility of a compelling 
argument for a change in Squeak, or a fork.  But the 
argument-by-analogy thing must necessarily fail -- the panoply of 
analogous open source culture projects is simply too large -- there 
will always be counterexamples.

I suggest two thing: (1) proffer your reasons for the change, with a 
detailed proposal and solution; and (2) execute your plan.  It 
doesn't require a fork, I believe -- if it works on the merits, it 
will become part of Squeak.  If it does require a fork, you'll have 
made your case.

>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.

I think different -- but hey, I'm using a powerbook.

I have been contributing for years.  My better works have frequently 
been given due attention and incorporated, even when not centered on 
SqueakC's mission.  Once again, your argument addresses only the 
possibility that a fork might be beneficial, offering at most support 
for a hypothetical that is contrary to my direct experience.

>  > 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.

So what?  In my group, I have seen a number of instances where I've 
done things relying on the way something at the core of Microsoft 
Windows, the MacOS or FreeBSD API's are done, only to find that 
breaking in the next release.

>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.

If its what you need, make it.  But why do you think it is necessary 
to take a diversionary path?

>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?

I see him at Hackers every other year or so, and occasionally serve 
on panels with him.  I might suggest that the authority derives from 
the argument, and not the person.

I agree with him that a compelling case needs to be made AS A SOCIAL 
MATTER to divide a society of collaborating individuals thinly to 
accommodate minor differences as to direction or style.  Divide and 
conquer, while a great strategy for deriving good algorithms, is 
generally a terrible means to rally resources to carry an open source 
project to the future. To vary from the general case, which happens 
from time to time, there must be a compelling reason to do so.

Nobody disagrees that Squeak can be improved, and your contributions 
would be of general issue to the Squeak community.  But you seem to 
be misunderstanding those among us who are suggesting that a fork is 
probably not necessary; or we seem to be misunderstanding your 
arguments why it is.

My suggestion is that the argument by analogy, even to the extent it 
may be valid, will never lead you to a strong enough argument to 
justify a fork; for there will always be a counterexample.

Let's get to the merits, or move on.





More information about the Squeak-dev mailing list