This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc branches?
>> Surely planning is an important function of the SC.
> Only to a very limited extent. Since we have no means
> of enforcement or sources of funding, and depend
> entirely on volunteers, it is limited what planning can
> do.
Right. I recognize that. SC legitimacy is historically meritocratous
although there is a tiny bit of practical authority originating out of
the distribution of CVS and web site passwords. Mostly it was the
EGCS foo and subsequent nearly-monotonic improvments to GCC that give
the SC its standing. Y'all seem to be proud of that and that seems
appropriate to me.
What comes after that success?
Some of the volunteers the SC works with are corporations and part of
their contribution is funded work. I think it's legitimate for the SC
to approach those companies about how to make their spending more
efficient for them, and more effective for gcc as a whole. The SC is
far better positioned, politically, than I or any other individual to
have that kind of conversation with those volunteer corporations.
If you have some individual volunteers that want to make a long-term
quasi-commitment to your project, it's customary to give some guidance
about what work needs doing -- not just a task list, but a real
negotiation/planning session that helps to produce a task list. The
corporations are volunteers who are making long-term quasi-commitments
to spend a decent amount of money on GCC.
> Remember, we are still in a recession. Discretionary
> spending is very hard to "sell".
Many business leaders/educational materials, etc. will tell you that
during a recession, R&D spending and marketing are the two things you
want to protect and even increase. It's part of how recessions get
fixed. Canceling product lines that aren't going to make it, forming
mergers, tuning productivity gains -- those are the ways to align
spending to reduced revenue.
> I'd love to have a "Gcc Foundation" (within the FSF of
> course)
I proposed that a while back and the feedback was almost universally
negative. I think it strikes people as too much like socialism, or
something: there's a definate resistence to handing over substantial
budgets to NPOs. There is something appealing about the companies who
fund much of GCC spending their own money directly. People like
capitalist freedoms.
So I'm not proposing a big SC budget today.
Here's an analogy to what I'm proposing: let's suppose it was the
80s and GCC was an in-house project at a large vendor. Let's suppose
that GCC had a small team of project-leads from various divisions --
the SC -- who held engineering, not management titles (i.e., they have
little or no budgets). In that circumstance, it would be quite
ordinary and useful for the project leads to suggest plans and
budgeting strategies to the managers, and for that to be an important
factor in how budgeting happens. Since the project spans divisions,
there'd be some politics among the managers to figure out which
budgets provide what parts of the funding -- but the SC would be
providing project-perspective guidance about how to coordinate that
budgeting.
Now, GCC isn't an in-house project, and the management in question
doesn't span divisions -- it spans companies. But it's still useful
to try to coordinate spending among those managers more directly than
at the level of todo list / patch acceptance / release management.
GCC is interesting in particular because, historically, it is a
"template project" -- a successful commercialization of free software
that people try to emulate with other projects.
That's all very general. With `arch', it gets a bit more concrete
because what I've been proposing are tools that specifically address
lowering the costs and raising the quality of source-based cooperation
among the volunteers. That's an issue that is demonstrably useful for
gcc (scan the past year of the dev list on the topics of CVS, testing,
and branch management). And it's an issue that, if addressed
cleanly, can benefit other projects as well.
In economic theory, the volunteer corporations like projects like GCC
because of the low "transaction costs" for inter-corporate
cooperation. They should be receptive to plans that reinforce and
improve that, especially if the plans can help other projects as well.
The FSF, meanwhile, likes volunteer corporations because they
contribute useful work: it should be receptive to plans that can
improve the quality and quantity of what volunteer cooperations can do
per dollar spent.
Fine. However, I personally have my own "fun, cool, interesting"
project(s) that I'm already working on, or that I want to work on.
The same applies to many of us, or we have no time/interest hacking
on new projects after our days jobs.
While a big SC budget isn't popular, perhaps (as with executive
boards) SC members should receive honorariums or stipends for their
SC activities.
[Kawa] was an example of an established project close to my heart
that has technical superiority (I and others think) and happy
users, but I still can't raise enough money for it to pay
myself a decent wage. So while you have my sympathy, I can't
offer you more.
Ok. Kawa may be symptomatic of another (related) problem: that the
free software businesses haven't (for the most part) figured out how
to invest in strategic, practical research in any kind of systematic
way.
In general, there's too much "magic cauldron" thinking implicit in how
the industry is relating to free software these days.
Regards,
-t