RE: Interesting article ZDNet re informal software develop ment quality

[Nick Lothian <nl () essential com au>]

> On 6 Jan 2004 at 18:06, George Capehart wrote:
>
> > I agree with the sentiments.  I'd like to take them a step further,
> > though.  I spent a lot of time in the manufacturing environment and
> > led several BPR projects.  They all had a quality component to them,
> > but used different (quality) methodologies.  After a while I came to
> > believe that for quality (as for security), process is important.
> > The nature of the process is not anywhere nearly important as is the
> > discipline and focus of the process.  What I mean is this: Whether
> > it be waterfall, RUP, XP, or whatever, if quality(/security) is
> > important to the process, it will be there.  If quality(/security)
> > is *not* important to the process, it will not be there, even if the
> > process is CMM Level 5.
>
> I have to agree with this.  Over the last several years, I have had
> the opportunity to look at several dozen in-house applications built
> by various companies -- ranging from utilities to software development
> houses -- sized between 500 KLOC and 15 MLOC.  I have to say that any
> development methodology beats none, and almost any formal methodology
> beats almost any informal methodology.  

To bring this back to Open vs. Closed source, I think most open source
projects have more process than many closed source projects - even if it
isn't written down.

I expect we've all seen closed source projects where the developers can't
explain their configuration management process. OTOH, I don't think I've
ever seen an open source project where config and release management isn't
frequently discussed on the mailing list, and most developers have a pretty
good understanding of how releases happen.

If we look at the recent Linux kernel attempted malicious code modification
(<http://kerneltrap.org/node/view/1584>) it was a well understood process of
distributed review that caught the exploit. While the Linux kernel might be
an extreme case, most Open Source would have had some chance of catching
something like that because of the emphasis on the review process.

Two separate points:

1) Before someone else says it -  if a close source project doesn't have a
proper configuration management process they are likely to have many other
problems before they even manage to deliver an insecure product

2) WRT the Linux Kernel security breach, I think it would be very
interesting to see what processes other (close source) operating system
developers have in place to catch unauthorised modifications of code already
in their source-control archive. I've never seen any discussion or
recommendations for processes to combat that kind of problem, and I think
that most development shops would be caught out by something like that.

Regards
 Nick Lothian