Subject: Re: a model of competition between free and proprietary software
From: kragen@pobox.com
Date: Sun, 27 May 2001 04:33:28 -0400 (EDT)

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> >>>>> "Seth" == Seth Gordon <sethg@ropine.com> writes:
>     Seth> and if F's maintainer is competent, F's quality is roughly
>     Seth> proportional to the number of developer-hours spent on it.
> 
> Not likely.  First, competent maintainers for large scale projects are
> hard to come by in free software.  Cf Fred Brooks on teams; suffice it
> to say that as the number of developer hours rises, what matters are
> the management skills of the maintainer, not the programming skills.

FWIW, they're pretty hard to come by in proprietary software, too.

> What seems more plausible is developer-managers, who operate in a
> partnership.  But as the project expands, you need more dev-mgrs, and
> they start to discuss among themselves.  This is why Linux distros are
> "easy" to scale: you just split up the packages -- little coordination
> needed.

I'm not sure this is true.  Debian, as far as I understand it without
being on any of its mailing lists, has several hundred people, each of
whom contributes several hours per week to exactly this kind of
coordination.

> This is one of the big advantages that P has over F.  There's an
> operational definition of quality: "what the customers will pay for".
> Another is that where quality and features compete for attention from
> the same developer, as they often do, P can pay the developer to work
> on quality.  

Actually, this is an advantage for F: P will pay the developers to
work on what will bring benefits to the company, while F will pay the
developers to work on what will bring benefits to the users.  Things
that bring benefit to the company may or may not benefit the users:
getting to market earlier, not competing with other products from the
same company, making it harder for users to compete with the company
(e.g. not including "eval" in an interpreted language), filling in
checkboxes on analysts' reports.

> This was mentioned by somebody else, but it's worth noting that to
> extent that customer perception of "quality" depends on a "coherent
> vision" of "what the product _is_", a single architect is more
> likely to supply coherence, and money is the most effective tool
> known for getting other people to implement one's vision.  Another
> win for P.

It appears to me that more free-software projects retain the same
single architect for ten years or more than proprietary-software
projects; proprietary-software architects tend to get promoted, go
work for other companies, and have to compromise for political
reasons.

Also, in my experience working for proprietary-software companies,
I've observed that people who are merely paid to implement a vision
have less commitment to it than people who believe in it.  You find
the latter in proprietary-software companies, too, of course.

On the flip side: quality also depends on a *good* vision, which
typically requires the architect to listen to other people's ideas
(and reject most of them, but not the best ones).  This seems to
happen more in free-software projects.