[ossig] The Virtues of Monoculture

[Ditesh Kumar]

On Wed, 2007-04-25 at 17:50 +0800, Dinesh Nair wrote:
> To be honest, C# is largely what I’d do if I could rewrite Java from
> scratch with no concerns for backward compatibility. It has a couple of

c# is indeed nice. from a technical perspective, it was well thought
out. its main implementations (microsoft, mono) are decent too.

> Visual Studio is a slick tool that really does let you bang out
> applications (and with VSTO, plug ins for Office) is very little time.

one man's meal is another man's poison. vs may have its strong points
but it has its fscked-up-ness too.

> For the Microsoft Guy, no such confusion. You use ADO.NET, ASP.NET, C# and
> Windows. They all work, they’re all well documented from the perspective
> of a developer’s needs, with nary a disparaging ‘go look at the source’

the microsoft .net stack has its share of problems. from what i got at
fosdem listening to miguel, serialization in .net 1.0, .net 1.1, .net
2.0 don't inter-operate with each other (the irony!!). so an app written
in .net 1.1 cannot serialize and deserialize on a 2.0 .net app. this is
within the same .net solution space, indicating that even when working
in the same solution stack, there are issues.

debugging on a purely microsoft only platform is a big hassle. why?
firstly because microsoft program managers have consciously or otherwise
decided to aggregate all knowledge on solving common problems into one
big database and thus discouraging smaller communities from forming.

this makes it difficult when using external search engines such as
google when searching for solutions. furthermore, this discourages
freeflow dicussions common on foss technical mailing lists where anybody
can (and will) chip in with their 2cents on how to solve the problem.

secondly, a microsoft only platform is fully proprietary and there are
times when "go look at the source" argument has merit: when nothing more
to be done other then to look at the source and figure out why shite is
hitting the fan. this is not possible on proprietary platforms.

ok i could write more but i'm diverging from the original thread here :)

> same question, we should be asking ourself “Why don’t they pool their
> effort and produce one really good solution?”, rather than celebrating
> diversity for diversity’s sake alone.

sigh, the author is an idiot. and i'll tell you guys why. he's not
arguing for a monoculture, he's actually arguing for a single stack -
the kind that redhat provides - operating system, desktop, database,
development tools, support options etc.

the importance of a commercially available single stack does not negate
the importance of diversity in the ict ecosystem. here is a "why
diversity is important 101":

a) because diversity allows good ideas to flourish

look at ruby on rails. it has serious problems such that nobody in their
right mind would use it in a real production environment. but the ror
team showed how activerecord as a particular design pattern can solve a
common set of problems well. this concept then bubbled up into the
higher stratosphere of far more popular languages such as php.

b) because people have ideas which may not be fully explored on existing
platforms

for a long time, mysql didn't have all the bells and whistles people
thought were necessary for real world use. mysql gained immense
popularity as people realized that they were very willing to trade off
acid if it meant greater speed in a many-reads-few-writes environment. 

using the author's argument, mysql would never have been born and the
niche of many-reads-few-writes would have never been adequately
explored. diversity can be seen here as the seed of innovation.

c) because it allows one to build something from scratch that doesn't
suck

it may not be possible to fix problematic issues in an existing project
without significant effort put in. given that substantial time and
effort will be put in anyhow, developers may choose to start something
from a clean slate and derive the benefit of not having to deal with
legacy issues.

netscape's rendering engine is a good example of this. it was a
monolithic piece of shite and the decision to rewrite it gave birth to a
far flexible and well designed system which has is driving much of the
innovation we see on the web today.

d) because it allows one to focus on something very specific

in a large project, wanting to focus time and energy of developers in a
specific direction doesn't work in an oss project. despite common
misconceptions, successful oss projects are well managed and have focus
and direction. patchsets are generally accepted if and only if they
don't break existing functionality and is not a radical change for
end-users.

thus, it may be necessary to fork a project and start something new to
be able to focus energies on a specific direction. a good example is
EGCS which wikipedia gives a history of:

"By 1991, GCC 1.x had reached a point of stability, but architectural
limitations prevented many desired improvements, so the Free Software
Foundation started work on GCC 2.x. But during the mid-1990s, the FSF
kept such close control on what was added to the official version of GCC
2.x that GCC was used as one example of the "cathedral" development
model in Eric S. Raymond's essay The Cathedral and the Bazaar.

As GCC was free software, programmers wanting to work in other
directions — particularly those writing interfaces for languages other
than C — were free to develop their own fork of the compiler. Multiple
forks proved inefficient and unwieldy, however, and the difficulty in
getting work accepted by the official GCC project was greatly
frustrating for many.

In 1997, a group of developers formed EGCS, to merge several
experimental forks into a single project. Projects merged included g77
(Fortran), PGCC (Pentium-optimized GCC), many C++ improvements, and many
new architectures and operating system variants."

e) because existing licensing prevents improvements

fsf (and therefore the gnu tools) was started when rms got pissed at the
inability to fix the printer in his office. gnome got started because
kde was based on non-free software. linux got started because minix was
not free. freebsd got started because of legal concerns with the 386bsd
codebase.

plenty of other examples. basically, when it is necessary to improve the
system but existing licensing is not sufficient free, it is necessary to
fork or build something new.

f) because personality conflicts can kill innovation

where there is more then one person involved in a project, the
probability of personality conflicts stands at 100%. when personality
conflicts get untenable, it is necessary to fork to be able to continue
development. openbsd is a prime example of this. if it wasn't for the
ability to fork and start another operating system project, much of the
goodness that came out of openbsd would not have been realized.

in conclusion, diversity is a driving force of innovation in the ict
space. it fosters experimentation, encourages creativity and has a
strong history of breeding great ideas.

-- 
  May your signals all trap                     Ditesh Kumar
May your references be bounded                ditesh at gathani.org
      All memory aligned                http://ditesh.gathani.org/blog
    Floats to ints rounded              http://www.openmalaysiablog.com