[Sussex] Re: Gentoo problems.

[Steve Dobson]

Thomas

On Tue, Feb 24, 2004 at 03:09:05PM +0000, Thomas Adam wrote:
>  --- Steve Dobson <steve at dobson.org> wrote: 
> > Steve
> 
> > Commercial organisations suffer from a controlling factor that just
> > isn't
> > a problem with open groups: marketing.  Debian has always said that
> > a new release is only made available when it is ready, and not before.
> > This has led to the two year gap between releases.
> > 
> > The kernel group have also "suffer" from the "it will be read when it's
> > ready" syndrome.  2.4 was a long time in coming.  2.6 was originally
> > meant
> > to be short (about six months IIRC) - it wasn't.
> 
> You have to remember that there are two different release models at work
> here.

I never for one moment meant to suggest that there were the same, far from 
it.

>       One is that distros such as Debian and gentoo and the work that goes
> into them is voluntary, and such means that sometimes the development
> cycle is intermittent. This is by the very nature both a design feature
> and a good thing, even if it is slow.
> 
> The other model is that commercial projects are often being developed by
> peple whom are getting paid, so they have a responsibility to get it done
> on time.

You'd think that, wouldn't you.  But there is some evidence that that 
reverse it true - see "The Cathedral and the Bazaar".  Personally I think
that the biggest factor contributing to this is that if you have a big
enough group of testers then all bugs become shallow.

Few, if any commercial projects have the man power for testing and 
developing that the Linux Kernel, Debian and Gentoo have available to 
them.

Another problem with commercial timescales and budgets is that they are 
based on "fiddled" engineering estimates.  The original estimates are
poor to begin with, and the better at estimating one gets the more likely
you are to extend you estimates.  Management, when it doesn't like what
it sees, moves the estimates to the left.  And what engineer is going 
to state that "it will take six weeks not four".  Is it any wonder that
projects overrun?

Here is an example.  One of my old companies bid for a new bit of work
in a new sector.  The Board wanted to move the company in that direction
so they made it a "must win" bid.  To help, they reduced both the timescale
and the cost.

The project, in order to "meet" the timescale needed to run far more 
overtime than in the forecast.  As a result the 20% profit margin was
eaten up.  The Board had the senior software engineer investigate.

The report was not good reading (for the Board).  It basically said that 
Engineering executed the project to within a reasonable margin of error.
If the Board decides to reduce the bid to win the business then the Board
could not blame Engineering for executing the project as Engineering
originally said it would.

Steve