[TCLCORE] Re: [TCLCORE] Words to consider...

[Jim I. <ji...@ap...>]

Also sprach Jeffrey Hobbs:

> I found this on Slashdot (The Cathedral and The Bizarre), which
> is based on this article:
> http://www.macopinion.com/columns/macskeptic/00/07/07/index.html
> 
> The whole thing is well worth reading, but I'm excerpting some juicy
> bits to ponder:
> 

There are two points here that I want to address.  One is the bit about
incompatible changes in Perl4->5.  That was a big change in the language,
they were adding a lot more structure, and if it was necessary to break a
few older scripts, then maybe that was not such a bad thing.  Perl kind of
sabotages itself in this regard, because it allows so many ways of
expressing the same thing that I imagine it is pretty hard to change things,
and support ALL possible ways to write Perl code.  The Perl code that I
wrote for NASA went from 4->5 no problem, however, so...  I don't think that
this is a relevant argument for or against OpenSource in the long run...

However, the more important point is that there you can't just open the
doors to all comers, and allow coherent software to come out of it.  But
this is not a new observation, and there are successful long-term software
projects that have found ways around this.  Gcc is one example, and recently
gdb is another.  Both are starting from fairly crusty inherited source
bases, with long histories and LOTS of users from all walks of life.  Gcc,
(starting with the egcs fork) put a lot of effort into setting up a steering
committee that contained both developers and users, and was not dominated by
any one interest.  Then they maintain a parallel, technical review structure
that maintains code quality through a system of area maintainers and careful
submission & review practices to assure that (a) submitted code is in line
both with the gcc design principles, and future goals and (b) the knowledge
of same are transmitted from one generation of gcc hackers to the next.
They have also documented these practices clearly, with Hack rules and well
defined maintainers lists, and supported them with a nice CVS repository,
and mailing lists for patches and general discussion...

Sorry to go on so long, but the main point is that there are good models for
doing open source development that don't fall into the trap of having the
maintainers try to do too much, and thus always fall behind community
expectations, and not take full advantage of the community; and a too open
system that makes the software inconsistent and ugly...

Jim


-- 
Jim Ingham                                 ji...@ap...
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.