Andrew....

OK, I'll concede that my argument by analogy fails here. And I don't disagree
with the idea that I/we begin this process by implementing some things and
letting the issue of forking flow from an assessment of the results.

My objective in raising the issue was two-fold. First was to see what the core
Squeak community thought of the idea. It seems clear that the people who are
active on this list generally agree with your position. (I suspect that
community is a tiny minority of the people who will ultimately use Squeak
"stuff" and who are sufficiently comfortable with Squeak's internals to feel
safe in this position. I am not part of that group, which may explain a lot.)

Second was to suggest that a commercial venture -- or perhaps a
well-thought-out foundation -- needs to take ownership of the core so that
SqueakC can continue their great work without hand-holding and detailed
monitoring of add-ins. That issue seems to come down to how modular Squeak
might become, at least in large part.

On that point, I guess we'll have to see when the jury comes back.

Meanwhile, I think we've had a wonderfully spirited debate and I can say I've
learned a lot.

--- "Andrew C. Greenberg" <werdna at mucow.com> wrote:
> >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.
> 


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