From: James Rogers (jamesr@best.com)
Date: Fri Apr 13 2001 - 12:43:22 MDT
At 10:48 PM 4/12/2001 -0700, James Higgins wrote:
>Has there been any serious discussion about making this an open source
>project? Instead of debating how open to be, if/when to hide, etc. maybe
>you should consider the exact opposite. I believe it has many advantages.
There are also a lot of disadvantages. I personally would be strongly
inclined to at least keep the initial implementation limited to a small
number of competent engineers. Having an initial implementation that is
superbly engineered sets the architecture standard for when the unwashed
programming masses get their hands on it, making it much easier to control
down the road if nothing else. I believe that this is also a tenet of the
Open Source doctrine.
>2) It would pull in some of the rogue groups who would go it alone.
In this particular instance, I suspect this would not be the case. There
is way too much religion involved for most groups that attempt to do this
type of thing.
>3) Open Source could massively speed up the process. Instead of having a
>few coders working on it, thousands or more would be able to
>contribute. (with very high quality control, of course)
This is a somewhat naive view of the software engineering process. At a
minimum, the first release of the core application really needs to be done
totally "in house". Quite frankly, few people are competent enough to
contribute to this type of development; the cost of maintaining QC with a
large number of wanna-be contributors would almost certainly exceed the
potential benefit to the codebase. Also, initial development (i.e. in the
absence of a prior development context) is a lot easier when you have a few
engineers because you are far more likely to create or have a common
context for development between a few people than between hordes of them.
Furthermore, I don't think that the code for something like this could be
easily broken down into a lot of independent pieces that you can throw
hundreds of developers at. I expect the core codebase would be relatively
small and functionally very dense. There might be a use for outside
developers on software components peripheral to the core engine, but you
wouldn't want more than a half-dozen good developers working on the core
engine itself.
>4) Probably the #1 biggest benefit is improved quality. Open Source in
>many ways is the pinnacle of code reviews. Having so many ideas study the
>source would reveal far more errors and problems than an isolated team
>could ever accomplish.
This is too simple a view. Code reviews are useful, but not just for the
sake of doing a code review. I've seen a lot of code reviews that add no
value to the process, frequently because the reviewer isn't sufficiently
competent to evaluate (both structurally AND contextually) the code they
are reviewing. The best kind of code review is when you have a small
number of very competent individuals working on the same project that code
review each other -- it keeps the S/N very high.
But that is just my opinion. I don't really want to dwell on the topic.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT