Of Bounties and Mercenaries

[Ian Lance Taylor]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

> Of course, such a model *does* cut out those people who have great
> need but little cash or small markets. If I develop for an embedded
> system, for example, I might offer $100 to request repair of some bug
> that annoys me -- but if a thousand people pay $10 each to fix
> something for the ia32, my poor embedded system will be out-of-luck, I
> think.
> 
> Ah, but no one really cares about those "fringe" systems, when the
> majority of people (the only really *important* ones) use Intel and
> AMD processors running Linux. And if no one's paying (for example) to
> improve floating-point speed and accuracy, it must not be important,
> eh? Anything important *must* have a dollar value attached, according
> to some GCC developers.

I don't have any solutions.  I'm just going to comment that I often
see the flipped version of which bugs are more important.  Bugs which
affect some particular embedded system are important to the
microprocessor vendor, or the customer who is stopped by the bug, and
they know perfectly well that the bug is unlikely to ever get fixed if
they don't pay for it.  So for them it becomes a straightforward
investment decision.  For bugs on popular platforms, on the other
hand, the hardware vendors generally comfort themselves with the
belief that since so many people use the platform, somebody else will
fix the bug.

Floating point performance is an example of a an issue so diffuse that
nobody feels responsible for fixing it.  On the other hand, Red Hat
and others (or perhaps a silent backer) are investing a great deal of
money in the tree-ssa reworking of gcc infrastructure, so this sort of
general overhaul is indeed possible.

Part of the problem is that gcc has become sufficiently complex that
it is difficult for the uninitiated to fix a bug.  Thus gcc partially
loses one of the usual advantages of free software--the fact that bugs
can be fixed by people with an itch to scratch.

Ian