Re: MAINTAINERS file

[Thomas Lord]

So, one or both of us should probably get rightly flamed soon
for being too off-topic or not trimming CC's or something
but I'll risk at least one more round:

Juanma Barranquero wrote:
> I don't think Richard's policies are crazy; I respect him and his
> accomplishments. But I'm don't think either that what I'm suggesting
> is a radical change in policy, unless "stop and look at the
> alternatives" is considered radical.
>
>   


As a kibbitz I agree with you.   I'd even put it more strongly.
And this will also illustrate how I basically agree with ESR's
sentiment about version control even if I disagree with many
details of where he took it:

The GNU project as amassed an enormous treasure of software
tools:  all of the programs dubbed "GNU".   Legal ownership
of copyrights is all over the map but in some tangible way you
could say that "GNU just *has* all of these software 'assets'."

Most of those tools, by the way, are moving targets: development
continues on them with or without a GNU project per-se.  So,
this is a very "virtual" collection of software that comprises GNU.
It's a big bag of projects-that-share-mutual-good-will as much as
its any particular big bag of source code bits.

GNU has historically been good at growing its treasure of software
tools, but historically very poor at organize those into larger systems.
Other people, other groups, with agendas that are different from the
the free software movement's have taken over that function:  Parties
outside of GNU organize collections like this into "complete systems"
but GNU itself has failed to do so.

Well, it doesn't take "rocket science" to organize lots of tool
projects into a "complete system" project but it does take a lot of
coordination, record keeping, archival, etc.   There's a huge
*information management problem* to solve and that problem is about
organizing the output of all of the individual, moving-target,
software-tools free software source code projects.

Another way to say it is that, to really start thinking about
building a complete system, GNU has to find a way to turn the
list of GNU programs into a kind of living archive of those source
code resources.   With things nicely organized, then a lot of the tedious
work of assembling complete distros can begin to be systematized.

The alternative to that kind of "bureaucratization" looks like
Debian: throw people at the problem.    Debian works on the
integration problem by doubling up, roughly, on the number of
project maintainers so that every project has a shadow maintainer
in Debian who does the pavement-hitting foot work of gathering
up source and moving into the Debian collection.

The Debian-like alternative is *incredibly expensive* if we are
counting up *labor*.   It is (relative to most projects) a *huge*
effort.   There has to be a more efficient approach.

GNU *could* contemplate the dvcs problem from *that* angle:
trying to find ways to encourage the individual projects to make
tool choices that make complete systems much less expensive
to assemble.   That, in my opinion, would be a good investment
strategy (though a challenging mess of tactical problems).

A dcvs choice is important from that very broad perspective:
thinking about it as a choice that governs the "inventory system"
for the GNU project's source code.

It's hard, though, to make  that case.   There's not a lot of point
to making up strategies for organizing all the source of a complete
distro unless it's realistic that there will be resources to follow up
on that strategizing.   There seem not to be such resources so, there's
a sharp limit on the value of strategic thinking for GNU.

-t