Open Source Diversity a Good Thing™

I got interested in an ongoing mini-debate in the java blogs. Oddly enough
between James
Gosling
and John
Munsch
. I posted a comment on John’s blog (sorry that mind doesn’t
support that. I’m not a big draw. Email me. dallas OVERAT hockley dot ca
-) )

The general thought I’ve got is essentially a development biodiversity
(comment 14 I believe). Not only can we not stop duplication of effort
on various very similar projects, but that sort of diversity and
inefficiency should actually be encouraged. 1 in 10 startups
actually succeed. Better hope we start enough to get a successful one.
-)

The post is copied below. For the original references, follow the links.

You have a point as far as getting Open Source software to accomplish
something. Humans being what they are, you also seem to agree that
opinions and differences of opinion will result in duplication and
diversification of effort (Gnome and KDE for example). There are a
couple more aspects that are ripe for consideration in this context.
Programmers can’t just go and start writing useful code, and grok the
world of the Right Thing&trade.

Just as for those that did the compSci degree, they write hello world,
and binary tree code, and yet another pascal compiler, etc. etc.,
there is a learning process. I think that’s where Gosling is coming
from. Learning. I think the fact that “perusing Freshmeat” brings up
90 scripting language projects. Like we need another one. -)

502 projects around text editors. Guaranteed not all are gems or
“worthy” of the efforts of people. Let’s say that 10 deserve a place
in the “commercial-quality” level, in that they serve different user
groups, segments, tasks etc. Should anyone with a desire to code on
those pick one of the top 10 and just dive in?

I personally hope not. We didn’t all start coding on the same day, we
don’t all have the same experience or ability level. Start with a
simple, non-featured one that might be a bit hacked up. Look at the
code from the leader. Get into the concepts. Understand some of the
approaches. Try some things yourself. And don’t expect to get your
code accepted by the top project all the time. To get to the level
that your code and ideas are truly good enough for the project, you
need to evolve your skills, views, ideas and code to the level of the
project. You need to do that by learning and trying. On a duplication
of an existing project in a lot of cases. Just another level of
another “hello world” program.

If you still don’t see the point, perhaps we should have dumped all
the effort into Minix rather than Linux. What was Linus thinking when
he didn’t just evolve one of the many open source efforts of the time?
Lucky that he did go his own way, as his particular mode of work, and
base of code, and level of ability seem to have done something the
other efforts didn’t or couldn’t achieve.

Diversity and inefficiency is a very, very effective way of trying
various strategies. Not all will work. Not all the eggs are in one
basket. And gradually, through selection, merit, (marketing?) a top
contender may get extra deserved(?) attention like ALSA did. But if
you only try one way, you’re going to get whatever quality you started
with.

Vive la difference!

Posted by Dallas Hockley at March 25, 2004 09:28 PM

Leave a Reply

Your email address will not be published. Required fields are marked *