Forks and risks and monoculter (was Re:Hans Reiser Guilty of First Degree Murder)

[Christopher Browne]

On Thu, May 1, 2008 at 6:51 PM, Sy Ali <sy1234-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On Thu, May 1, 2008 at 12:26 PM, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>  > On Thu, May 1, 2008 at 11:54 AM, Sy Ali <sy1234-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>  >  >  ... Does one's future actions nullify
>
> >  >  one's previous (or current) achievements?
>  >
>
> >  It's absolutely possible, although it tends to require doing fairly
>  >  horrifying things, and tends to involve situations where the evil
>  >  actions are somewhat tied to the "achievements."
>
>  All very good thoughts.  I really liked this one.
>
>
>
>  >  In the case of ReiserFS, I have a different aversion, namely that the
>  >  fact that the "mind behind it" is:
>  >  a) Somewhat unavailable for maintenance, and
>  >  b) Evidently *somewhat* unstable in character (based on his displays
>  >  in the trial), and
>  >  c) Having some *serious* communications challenges,
>  >  this puts a crimp in the notions that:
>  >   1.  The filesystem can be supported, and
>  >   2.  We can have an expectation of its internals being sufficiently
>  >  widely + deeply understood.
>
>  One of the "selling points" of the idea of open source is that it's
>  possible to pick it up and make it one's own.
>
>  Are you arguing that in this case it's an insurmountable problem to
>  take over reiserfs without the original brain, or that it's simply not
>  worth the work compared to alternatives to that project?

Both could readily be true.

It's remarkably *DIFFICULT* to "fork" a project.  You frequently need
to create a new community of developers, as is quite likely to be the
case with ReiserFS, and there are a number of potential barriers to
success:

1.  Taking over someone else's code that you don't understand is
troublesome.  If it's "mature" code, with numerous patches and
adjustments to make it function with this, that, and the other thing,
that makes for a substantial learning curve.

2.  The "new community" may have fewer rights over the code than the
old one.  Not normally the case with BSD-licensed code, but
*definitely* the case with GPLed code, where the former authors
substantially owned the code base.  This would be the case, for
instance, for a "fork" of MySQL(tm); Sun has considerably more rights
concerning licensing (e.g. - with "dueling licenses") than would any
"fork community."

Hans Reiser was making something of a business of offering alternative
licenses to his code; that won't be an option open to a "fork."

3.  As observed with the "free" fork of Interbase, and, recently, with
the Debian issues with Mozilla, it's typically necessary to rename the
system.

That is probably *not* so much of a downside under the circumstances
:-).  But when something gets renamed, potential community can get
lost in the shuffle.

Thinking of various forks (Interbase/Firebird, SQLLedger/LedgerSMB,
XFree86/Xorg, Mozilla/Ice****, NetBSD/OpenBSD), it seems to me that
while these may all have been *necessary*, none were particularly
desirable, and they have tended to set the projects back a fair bit.
The term "necessary evil" fits pretty well.

>  I mean.. the entire "the lead could get hit by a bus" problem can
>  happen to any number of key people.  Many really inspired projects
>  would crumble in no time flat.  I always thought it would be more a
>  social or organizational person who does all the "cat herding" who
>  would be the key person.  Does the loss of a kind of deep technical
>  knowledge also present the same problem?  (when it's a different
>  person)

>  If so, isn't that kindof.. a horrifying problem for a number of projects?  =(

You bet it is, certainly at the level of looking at specific projects.
 There is enough diversity out there that I'm not too worried about
terribly many individual projects.  But it would not be difficult for
an adversary to hire away some "key people" and severely hinder some
free software projects.

>  I hope that I see way more alternatives to the software I use, so that
>  there are other things to go to when problem arise.  I'm already
>  leaning heavily on some obscure programs that I don't expect to ever
>  see updates for.  Heck, I decided to fund the improvement of a couple
>  of programs I like a lot.  =)

Wise things, all.

We're doing that sort of thing pretty actively on some of the stuff
that the public gets to access.  Monocultures are pretty dangerous,
and that's not merely a "Microsoft slam" (though M$'s products suffer
*horribly* from various "monoculture" vulnerabilities).  If the world
thought of Linux as "the only thing," I'd be almost as concerned as I
have been about similar beliefs about Windows(tm).  Likewise, I'm
uninterested in seeing either GNOME or KDE "win" :-).

The emergence of various journalled filesystems (circling back to
direct relevance) has been a good thing, in my view; it has been a
locus for actual OS enhancements.  The competition from ZFS has also
been healthy; that keeps people from getting too complacent :-).  If
people drop ReiserFS like a dead skunk, it's not as if there aren't
some pretty reasonable alternatives.

And in terms of features, ReiserFS was always pretty "edgy" in terms
of diverging from convention, which has kept people thinking about new
things to try.  Even if the project fails, that doesn't mean everyone
has lost.  If work on ext4, JFS, XFS, and things like NILFS and LFS
(log-structured filesystems) continue, then we have the diversity that
is indeed needed.
-- 
http://linuxfinances.info/info/fs.html
"The definition of insanity is doing the same thing over and over and
expecting different results." -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists