This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Of Bounties and Mercenaries


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

    > My fear (and that of others) is that GCC has become so
    > commercialized that it fails to address the needs of the
    > community at large. I'm not anti-commercial -- I'm just looking
    > for some model that meets the needs of certain forgotten and
    > ignored constituencies.

I think you are being to narrow.

Existing commercial interests are _part_ of the community at large.

One interesting question is if you can identify needs of _theirs_ that
are being forgotten and ignored.   Perhaps some of those might even be
shared by whatever "ignored constituencies" you have in mind.

Is there, for example, a tragedy of the commons phenomenon in play in
which existing commercial interests have not yet discovered how to
organize funding for basic improvements that will benefit them all,
but will not be paid for by any third-party customer, but are
desirable to protect the future value of GCC?

A team of hackers at Intel could write a whitepaper saying "Why (and
how) ICC needs to be rewritten from scratch to keep it viable for more
than 3 years".  They could make that case to Intel and, there being a
single payer for such work, they'd only need to win one customer.

A team of hackers on the net could write a whitepaper saying "10
Sweeping Overhaul's Needed to Keep GCC viable for more than 5 years"
or another saying "What Businesses Benefit From Ensuring GCC Runs Well
on Modest/Outdated HW?" but if they want to sell those plans and don't
want to find a sugar-daddy-corp to pony up for the whole deal -- they
need to sell to N customers and get multiple payers for a single
project.

The industry is _fairly_ bad at that N-payers/Single-project pattern.
The social and organizational practice of consortium-forming is pretty
regularized now --- you can even find services who will help you do it
--- yet, nevertheless, it remains a quite heavyweight process.   Good
luck networking well enough to even enter into talks with the Right
People for such a thing.

OSDL is interesting in part because it finally manages to generalize
the process a little bit.   It's a comparatively open-ended
consortium.    Consequently, all the players are already joined at a
given table.   The start-up and infrastructure costs of a consortium
process are ammortized.    They can use OSDL as a vehicle to rapidly
and efficiently do all kinds of N-payer kernel-related projects.

What's the next step in the generalization process that OSDL has
started?

-t



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]