Shattering -- good or bad?
Russell Nelson
multiple revisions result, each with a different feature set. John
Gilmore coined the term ``shattering'' for this phenomenon. With
public domain software, the different fragments may have their own
copyrights, so there's no hope of merging back into a single
distribution. But with GPL software, you can always get the source.
So, is the competition resulting from shattering a good thing? Or is
it bad because people could have been cooperating? But cooperating
requires some compromising.
Emacs: Lucid Emacs, GNU Emacs, Epoch
Linux: SLS, MCC, Slackware, Yggdrasil
NCSA Telnet: CUTCP, QVT/Net
-russ <nel...@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
Jim Dodd
: We've all seen it. You distribute a system in source form, and
: multiple revisions result, each with a different feature set. John
: Gilmore coined the term ``shattering'' for this phenomenon. With
: public domain software, the different fragments may have their own
: copyrights, so there's no hope of merging back into a single
: distribution. But with GPL software, you can always get the source.
: So, is the competition resulting from shattering a good thing? Or is
: it bad because people could have been cooperating? But cooperating
: requires some compromising.
: Emacs: Lucid Emacs, GNU Emacs, Epoch
: Linux: SLS, MCC, Slackware, Yggdrasil
: NCSA Telnet: CUTCP, QVT/Net
I believe the critical issue is the intent. If your efforts are directed
toward a specific goal, ie very one is marching to the same mission
statement/drummer, then shattering is definitely going to hinder your
progress.
But, other than providing a wide variety of, hopefully, sophisticated
software to *ALL*, I don't believe there is a true "goal" with any of
the software you mentioned above. With this intent, the "competetion"
is not only supportive, but probably induces a great abundance of
the very software it is trying to promote.
Jimd Dodd
ji...@netcom.com
--
Jim Dodd email: ji...@netcom.com
Bill Heiser
>So, is the competition resulting from shattering a good thing? Or is
>it bad because people could have been cooperating? But cooperating
>requires some compromising.
I tend to think (as the name implies) it "shatters" the cohesiveness
of the product. For example, if one of the "subgroups" produces a
not-so-good product, it reflects badly on the main product name.
--
Bill Heiser bi...@bhhome.ci.net hei...@world.std.com
Joe Buck
>We've all seen it. You distribute a system in source form, and
>multiple revisions result, each with a different feature set. John
>Emacs: Lucid Emacs, GNU Emacs, Epoch
>Linux: SLS, MCC, Slackware, Yggdrasil
The two cases are not analogous. For Linux, there is only a single line
of development for the kernel, compiler, and libraries and all the
distributions you mention try to ship the latest version of each. The
only difference is packaging. Shattering has not occurred in the Linux
community to anywhere near the same extent as it has in other projects
(the three versions of Emacs, NetBSD vs Jolitz BSD). Part of this is
personality issues, I think, having to do with the stubbornness or
perceived stubbornness of the key developer(s).
This does not mean that shattering is necessarily a bad thing. There's
value in competition as well as cooperation -- too much cooperation can
lead to groupthink and rigidity, too much competition to everyone reinventing
the wheel and "not invented here" syndrome.
--
-- Joe Buck jb...@synopsys.com
Posting from but not speaking for Synopsys, Inc.
Formerly jbuck@<various-hosts>.eecs.berkeley.edu
Russell Nelson
nel...@crynwr.com (Russell Nelson) writes:
>So, is the competition resulting from shattering a good thing? Or is
>it bad because people could have been cooperating? But cooperating
>requires some compromising.
I tend to think (as the name implies) it "shatters" the cohesiveness
of the product. For example, if one of the "subgroups" produces a
not-so-good product, it reflects badly on the main product name.
Well, my thoughts on this are far from clear, but I'm quite sure that
shattered versions need to have different names. Certainly the GPL
requires that you put your own copyright onto modified versions. And,
once you have enough changes to be worth talking about, people will
invent a name, if only "Bob's Piffle package" vs "Jim's Piffle
package".
Another thing I've observed is that GPL shattering only occurs if the
maintainer of a package refuses to adopt a modification that some
find useful, or if the modifications don't get back to the maintainer
(as with Accton's packet driver versions).
Russell Nelson
nel...@crynwr.com (Russell Nelson) writes:
>We've all seen it. You distribute a system in source form, and
>multiple revisions result, each with a different feature set. John
>Gilmore coined the term ``shattering'' for this phenomenon. ...
>Emacs: Lucid Emacs, GNU Emacs, Epoch
>Linux: SLS, MCC, Slackware, Yggdrasil
The two cases are not analogous. For Linux, there is only a single line
of development for the kernel, compiler, and libraries and all the
distributions you mention try to ship the latest version of each. The
only difference is packaging.
SLS and Yggdrasil ship patched kernels. I don't know if their
patches are intended to go back into the main distribution or not...
david carlton
> Lucid, GNU, and Epoch have all been both innovating and adopting the
> others' innovations
Really? Seems to me that if the GNU folks had really adopted the
others' innovations, it wouldn't have been 3 (or more? At least 3)
years between the time that Epoch was publicly released and that GNU
Emacs 19 was released.
david carlton
car...@husc.harvard.edu
While you're chewing, think of STEVEN SPIELBERG'S bank
account.. This will have the same effect as two ``STARCH
BLOCKERS''!
david carlton
> In article <CARLTON.93...@husc11.harvard.edu> car...@husc11.harvard.edu (david carlton) writes:
>> Seems to me that if the GNU folks had really adopted the others'
>> innovations, it wouldn't have been 3 (or more? At least 3) years
>> between the time that Epoch was publicly released and that GNU
>> Emacs 19 was released.
> If you'd checked FSF status reports you'd have found that Lucid and
> FSF were exchanging information and code. As for why it took so
> long, FSF wanted Emacs 19 to work somewhat differently from Lucid;
> they could share some code, but the internals are dissimilar --- FSF
> had to develop the internals themselves instead of using Lucid's
> code.
Lucid and GNU started from the same source tree; I don't know that
much (any?) code has been incorporated from Lucid to GNU since the
trees 'shattered', though I could certainly be wrong. And I was
talking about the time between Epoch and GNU, anyways, which is a lot
longer than the time between Lucid and GNU.
david carlton
car...@husc.harvard.edu
Hold the MAYO & pass the COSMIC AWARENESS...
D. V. Henkel-Wallace
source code; most of the unix versions out there are incompatible to
varying degrees. In fact, I think GNU makes the problem easier to avoid.
meis...@osf.org
| Lucid and GNU started from the same source tree; I don't know that
| much (any?) code has been incorporated from Lucid to GNU since the
| trees 'shattered', though I could certainly be wrong. And I was
| talking about the time between Epoch and GNU, anyways, which is a lot
| longer than the time between Lucid and GNU.
Actually there has been a lot of cross pollination. FSF 19 took a lot
of stuff from Lucid (particularly the event model), and the most
recent Lucid took a lot of things from FSF.
--
Michael Meissner email: meis...@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Old hackers never die, their bugs just increase.