[nSLUG] Article on why monoculture gets picked
D G Teed
donald.teed at gmail.com
Wed Apr 25 21:25:39 ADT 2007
On 4/25/07, Ian Campbell <ian at slu.ms> wrote:
> On Wed, Apr 25, 2007 at 04:11:21PM -0300, D G Teed wrote:
> That's not really the point I was trying to make, and it's a bit of an
> unfair generalization. The quality of the code is more a function of
> the talent and attitudes of the developers involved -- you're just as
> likely to have bad/unstable code in a small(er) project as a large
> Look at Mozilla, BIND, Sendmail... all large and popular projects, all
> with moderate to poor code quality, security track records etc.
Some smaller projects are good quality and have a real niche need.
I've used projects like udpcast, which have essentially one developer
and work great. No complaints.
But then you look at a situation like Hans Reiser, whose company
Namesys is going to be sold to pay his legal bills (or so I've read),
and there are people and distros backing off from using reiserfs
by default now. Somehow the short lived popularity of reiserfs
didn't surprise me. When I had my first experience with a corrupted
reiserfs and saw the notice appear to mail $25 to get support,
it revealed this was very different than what I consider true open
source community centered software, of which there are hundreds
of better examples.
Bind powers the majority of the DNS servers on the planet.
Sendmail is still commonly used, and is so core to Unix
that a simulation of it is provided with other mailers.
If you consider them poor quality, you have not dipped
anywhere near the bottom of the barrel yet.
In open source, poor quality is abandoned, rewritten, forked.
No one is forced to use this stuff. Bind, sendmail and mozilla
are success stories of quality software. With the large target,
comes opportunities to find security flaws. How many linux
kernel security flaws have been documented and patched?
Would the pure number be enough for you to rate it
as severely as sendmail, bind and mozilla?
> Really, I'll never evaluate all 800+ Linux distros, nor try every type of
> > shell, etc.
> > so it is pointless to have the extremes of variety. However, I might
> > at a few imap server options or content management options.
> 'I only want this kind of variety, not that kind'
Variety isn't a problem. The problem is egos and the novelty
or status of forging your own project. These form an
enticement which should not be nearly as cool as it is.
I imagine the extension of that is that you appreciate variety in
> things you're looking for an improvement in, and you don't like it in
> things you're already happy with.
You don't get it. I'm arguing for the abandonment of the
thinking "what projects can I open on sourceforge today?"
in favour of "what project can I help on sourceforge today?"
Perhaps that way of thinking isn't always possible, but I think
there is lots of room for improvement. It might start with
some social pressure. Years ago when people spotted
someone needlessly printing stuff on paper they would
say "you just killed another tree", and eventually it became
uncool to just click "Print" willy-nilly, and more cool to copy/paste,
save or use a bookmark or grep or something. The same should
happen for opening more projects. Perhaps people should
be asked: "Did you start that project just to add bragging rights to
your resume?" or something like that. It should be something
that a person does with some justification that would stand
some scrutiny, not the automatic "ya! another
open source project! The more we have, the less M$ has".
Working within community should be praised. Working
renegade should be questioned.
You may just read all of this and summarize that I complain
about variety. What I'm telling you is that this variety is
too extreme, and it is hurting open source and Linux
and the advancement of them in ways you've probably never
witnessed, if you work in a computing environment where you
are at the center of all decision making.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG