[Sussex] Re: Gentoo problems.

[Geoff Teale]

On Tue, 2004-02-24 at 17:09 +0000, Steve Dobson wrote:  
> I was not trying to suggest that software houses are negligent - just that
> they have different influences and that those influences appear to
> adversely effect software production.  The goal of all software projects is
> to produce functionally complete, bug-free software.  In the past it has
> been assumed that if the right controls and protocols are used then better
> software will result.
> 
> F/OSS development is showing that for complex software projects, and most
> software these days is complex given the power of the machines being used,
> that a chaotic, bazaar development model produces better software.
That depends on your definition of better.  What I would say is that it
holds true that it's not rigid control but the application of many,
interested and capable minds that leads to the quality of F/OSS
software.  In short a project is exposed to group of technical users
most interested in it and as such the major problems are discovered and
resolved more quickly and effectively.

This of course breaks down where there is little interest from technical
users.  Notice the lack of good quality F/OSS accountancy software out
there - no home finance apps don't count.  

> Agreed. I was not trying to belittle Red Hat, just that being a commercial
> company they are subject to the same marketing forces that Sun, HP, IBM
> or Microsoft are.  Remember the glibc problems of a few years back.  IIRC
> the blame was clearly placed on a marketing need to release.
Didn't mean to imply you were - just expanding my thoughts.  

Again there are things that only corporate sponsorship achieves - like
writing decent accounting applications and doing large scale usability
trials.  What we want, and need is for those companies to realise that
far from being a threat to them, embracing open source could have
significant benefits for them.  Unfortunately this usually only come
about when community led projects start to compete with existing
projects.



> Strange.  To become a Debian Developer one has to agree to the Debian
> Social Contract.  That states that commercial use of Debian is allowed.
> Indeed the DDs I know take pride where Debian is being used as the base
> for another distro.
Some people are petty.  That is life.



> That is one of the goals of XP.  But XP does not scale.  Medium sized 
> projects is about the most it can deal with.
I'm not sure why you feel that way.  

A more valid point is that it requires incredibly enlightened
management.  

It's odd how dogmatic people can be about eXtreme Programming, mostly
these people dismiss it out of hand without practical experience.  I
won't claim that XP is the "one true solution", but I will argue with
anyone making vague claims about it.  The reality is that XP is hard for
people to put into practise because it deals with real world problems
that people don't want to deal with.  XP puts some real issues of
software development front and centre and forces non-developers to
recognise them (this causes a lot of tension!).  

XP is very developer centric to the mind of the average non-developer,
because it forces them to accept that whilst they have needs from from
software (and those needs are very important and business critical) they
can't have the moon on a stick (no matter how much they pay you, or how
much they shout at you) and they won't get anything worthwhile unless
they put in the resources required and help make the tough decisions.
This particular way of thinking is not very popular with business
people.

Unfortunately in most cases the hard truths that XP highlights are
entirely the reason that it doesn't get used.  The customer doesn't like
to be told that they'll have to work hard to get the software they are
paying you to develop (of course they're also not prepared to hear that
information in retrospect).

The XP model for development is very close to the "Bazaar" of OSS
development in large projects except the priorities are defined by a
given customer rather than by community and personal preference.

In fact many of the core benefits of XP only outweigh their costs when
you are working on a large project.  Small projects can be much more
accurately planned and controlled by traditional methods than large
ones, and the inter-developer communication, pairing, rotation and
continuous integration (and testing) really start to pay off and
complexity and timescales increase.


-- 
Geoff Teale
Cmed Technology <gteale at cmedltd.com>
Free Software Foundation <tealeg at members.fsf.org>