[Linux-aus] Open Source Monoculture

Arjen Lentz arjen at mysql.com
Tue Feb 17 06:55:02 UTC 2004


Hi Jeff,

On Mon, 2004-02-16 at 21:19, Jeff Waugh wrote:
> Would an Open Source monoculture...

First let us define where the term "monoculture" comes from, and what it
means... I personally think the use of this terminology for software is
somewhat odd. For reference:
http://dictionary.reference.com/search?q=monoculture

In the old agricultural sense, monoculture is growing a single crop on a
piece of land, year after year. As each type of crop uses specific
nutrients (some sometimes puts back different nutrients), the soil is
drained, becomes exhausted and unable to sustain this particular crop.
The farming solution:
 - Silly (IMHO) farmers: would stick with the one crop and start
chucking on a lot of fertiliser.
 - Smart (IMHO) farmers: rotate two or three crops across their
different fields; these crops are selected so that what one puts in, the
next one can use.

How does this relate to software in any way? Uhm... it does relate to
people. If a person is made to do the same thing all the time, they
become very drained ;-)


(bear with me - there is software-relevance, but it needs context)

Really smart (IMHO) farmers might also use multiple species of the same
crop, i.e. have a few different wheat varieties. Why? Reduce risk/impact
of disease.
Other (IMHO rather short-sighted) farmers may use genetically modified
super-crops that may be impervious to any known disease.

There the story becomes fascinating. I would argue that, like with other
living species, focusing on a single super-variety implies the
artificial demise of other varieties, thereby destroying genetic
diversity. If, at any point in the future, the super-variety turns out
to have a flaw, the other varieties may have been lost or at least
haven't been out there sufficiently to develop along with any diseases.
(there's also the accidental mixing of genmod crops with regular crops,
causing -unintended- crossbreeds that may exhibit new problems as well
as mess with the natural diversity and makeup of previous unmodified
crops)

As we all know, the latter story (genetic engineering of crops) is
highly controversial, and my opinion is by no means the only opinion out
there. Whereas I think that genmod is a bad idea in the long term,
pushed along by arrogant scientists and short-term business profits,
others feel that the scientists have really got it perfect this time and
it can't possibly go wrong.
Tricky to debate as the two viewpoints are very much opposed, and as
it's partially about risk, we may only find out who was right in the
long term. With hindsight.


This second form of monoculture may be more comparable with software
engineering. There are different programming languages, each with
particular advantages and suited for particular needs. But some people
profess that their fave language is perfect for everything.
Likewise, different operating systems exist, and there are multiple
implementations of specs/standards (like web servers, browsers, mail
programs, SQL databases, etc). In the Linux world there are even two
desktop environments, GNOME and KDE.

I currently think that, like with crops and programming languages, no
single operating system is suited for everything. Each OS has its strong
points and weak points. The same applies to applications. While they may
be implemented according to the same specs, numerous aspects can be
significantly different and thereby more useful to particular groups of
users.

Ok, now I'm ready to answer your specific questions ;-)


>   ... be better than a proprietary monoculture?

No. But it has little chance of a) becoming one and/or b) staying one,
for long.

Regarding operating systems, I think that there are interesting aspects
to Windows. And there is excellent cross-pollination (!) between BSD and
Linux. Wiping any one of these from the face of the planet would, IMHO,
not necessarily be a good idea in the long run. This may actually apply
to Windows in particular, since parts of it have a fundamentally
different architecture. We could benefit from having this around.

GCC/EGCS is another interesting example that someone else mentioned.
It's highly specialised stuff, but the specs are available: the language
specs on the one hand, and the CPU specs on the other. So it's an open
playing field. A group of GCC devs may in the future diverge again for a
while, try new exoting stuff, and either find out that it's not good, or
their ideas will be picked up by the mainstream.


>   ... be significantly better, enough to escape the commonly accepted
>       disadvantages of a monoculture?

The key is that the specs/standards are public. The basis for diversity
is available, different implementations are always possible. My only
note on this would be that we need to explicitly encourage this
diversity.

The genetic makeup of a piece of software can be seen as a combination
of specs and implementation. Both can contain flaws, and so we can
benefit from having lots of eyeballs check them out.


>   ... create a similar global, zero-innovation playing field in IT as the
>       current proprietary monoculture has?

No. But even in the proprietary segment, it depends on which bits are
proprietary. If the specs are closed, that is a problem.

Part of the diversity comes from different implementations of the same
specs. As different implementations use different angles, it is also
possible that more flaws in the specs are found (and fixed).

KDE and GNOME are a special example, I think. They provide different
environments, built on the same platform (X Windows - different crops
that can grow on the same land ;-). But it gets even better, because
applications can also use the underlying technology (Qt and GTK) on
other platforms, as those libraries are also available for Windows, etc.
So some aspects are shared (the X Windows foundation), but not even that
is an absolute. There is an abundance of diversity.

Going by the above, a closed-source implementation of an open spec is
not necessarily a problem. While it lacks scrutiny of its specific code,
it still adds diversity on the implementation level and may still help
find flaws in the underlying specs/platform(s).


>   ... actually be a monoculture at all?

Probably not. By definition, the openness encourages diversity.

I think it's primarily the specs, platforms, APIs that matter. Some
implementations can be closed source without harming the diversity
model. Of course, these implementations should not mess with the specs!


As a closing note, I do have to point out that the above line of thought
is controversial similar to the discussion about genetically modified
crops. Not everybody will agree with my angle! Some people will feel
that it would be fine if all the world used a single platform, and that
perhaps that platform would then be best because all energy would focus
there. And of course there is a third group, the many consumers who just
don't care and will eat/use whatever.

As mentioned earlier, I think it is very important that we encourage
diversity, particularly within the Open Source realm. But, perhaps
adding more controversity within the pro-opensource group: why not
extend encouragement to closed-source implementations of open standards?
Can we be that generous? Should we be?


Regards,
Arjen.
-- 
Arjen Lentz, Technical Writer, Trainer
Brisbane, QLD Australia
MySQL AB, www.mysql.com

Sydney 1 Mar 2004 (5 days): Using & Managing MySQL Training
Training,Support,Licenses,T-shirts @ https://order.mysql.com/?marl





More information about the linux-aus mailing list