Against wastefull forks (Re: Taking Ownership of Squeak
(WAS Re: Python at Disney))
Andrew C. Greenberg
werdna at mucow.com
Sun Mar 11 00:56:26 UTC 2001
>--- "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>
>> Nothing compels anyone to use the alpha development versions. There
>> has a been a stable squeak (2.8) for quite some time.
>
>Good point, Andrew. But -- and I allow for the possibility, even the
>probability that I'm missing something very central here -- it isn't clear to
>me that anyone is fixing bugs in 2.8 (assuming there are any) or that there's
>any obvious way to add the cool new 3.x stuff into a 2.8 image. This includes
>most if not all of the modularization stuff that I think we really
>need to have
>to make forward progress a seriously feasible undertaking for anyone
>other than
>SqueakC and a handful of other insiders.
Be patient. 2.8 is stable. Updates and patches WERE backpatched for
a brief time. Now direction is moving on to 3.X, which in time will
replace 2.8 as the stable version of Squeak.
I am reminded of the FreeBSD shift from 2.2.7 to 2.3.X and, then to
2.4. Many commercial products stuck with 2.2.7 during the 2.3
"development era," and migrated to 2.4 or a late 2.3 during that time.
The difference between commercial products and open source, is that
the unexpurgated output of interim versions and development are
constantly available. These developments unsurprisingly include
fixes that some "holdbacks" would like to see backpatched to earlier
versions. Guess what? THEY OFTEN CAN BE!
Having recently served as V.P./R&D for a public company that
developed from an open source platform, I know this strategy to be
quite common. I can attest that the precise problem with forking a
"stable" version for commercial purposes is that you render your
product incompatible with future developments. A narrow-minded view
toward stability reminds me of the proverb about "a simple
consistency being the hobgoblin" of a developer's mind.
I suggest that if you need to "get it out the door," you probably
should, as I have done, choose a stable version and abandon updates
and upgrades except those patches you yourself wish to support.
Then, as soon as possible, get your code back up to current. Build
yourself a framework to protect yourself from massive sea changes, so
that the framework need only be slightly modified to acommodate
underlying system changes, if you must.
In short, I simply don't see any problem with Squeak's stability that
would give pause to any serious developer. EVERY version that has
reached solid release status has bugs. Guess what? ALL SOFTWARE HAS
BUGS. But every version since I have been involved with Squeak has
been remarkably stable, or trivially patched where it has hiccupped.
Perhaps you ought to hang out for awhile longer, and at least try to
contribute your modifications, before proposing a fork. Forks should
be the result of irreconcilable differences, and never one of mere
convenience.
More information about the Squeak-dev
mailing list
|