MAINTAINER

Definitions

The term "maintainer" means different things to different people.

The Hacker Perspective

ESR, who was a co-maintainer of ncurses until early 1996, later wrote one of his characteristic manifestos on the topic of maintainership at the time that he wrote "keeper". I noticed at the time, that some of that was a rehash of the arguments he made during 1996/1997 to assert control over and credit for my development work.

Quoting from those arguments gives some of the flavor of ESR's perspective:

To me "primary maintainer" is the person who manages the project and has the last word on matters of design and direction.
Accordingly, there is a fairly well-defined notion of "primary maintainer" for a project; the "primary maintainer" is the person who holds the hacker community's trust to steer a project. There are responsibilities associated with this position, and it can be compromised or lost (the trust can be eroded or destroyed entirely) if the holder fails to fulfil them.
despite what the GPL says, authors and primary maintainers *own* their software ... when people disagree with primary maintainers, they normally distribute patches rather than hacked source trees. It's a way of making your statement without violating the norms of succession.

In that context, there is no requirement that the maintainer actually be a developer or contributor to the project. In spite of that, the comment about "holds the hacker community's trust" assumes that the maintainer will receive recognition for their role.

Sunsite Maintainer

The manifesto which was on sunsite in North Carolina does not appear to be available anymore. It dealt with a hierarchy of maintainers (and given the context) was intended to point out the unworthiness of most people for being one of the maintainers of that site. Around the same time, Erik Troan was a co-maintainer. ESR has asserted since then that he was the sole maintainer "for a year since its startup", however there appears to be no reliable source giving the early history.

Homesteading the Noosphere

Like "The Cathedral and the Bazaar", ESR's paper was motivated by a desire to refute his most recent opponents. TCATB was generally observed to be targeted at the Emacs developers.

While there was (1995-1996) some material on ESR's homepage discussing "noosphere", the paper which is now available holds much based on ncurses, and presents a maintainer as being the owner of a project.

Attribution for contributors is mentioned, but only in the context that they're implied to be subservient to the maintainer (noting the verbiage distinguishing contributors and co-developers). They do not own their contributions, since the maintainer's ownership subsumes all other rights.

To give some context to the paper, here is an extract from an IRC log (billed as "SomeNet's first online forum") which I was discussing with an associate in May 1998:

<esr> (Besides, I've read at least one place that Intel intends to drop the NDA requirement once the chip is out of beta.)
<lilo> question from dan_b...."would you comment on the degree to which your noosphere paper was influenced by the ncurses 
thing?"
<esr> A *lot*.  Watching a major, disasterous violation of custom really clears up what the customs are.
<lilo> esr: for those of us who have not really kept up, can you talk a little bit about what happened, and how it 
affected your views?
<esr> In fact I think it's safe to say I wouldn't have written that paper for another five years without the ncurses debacle.
<esr> A junior maintainer hijacked the project.  I and the other copyright holder got pissed.  It got ugly.
<lilo> ah....that pretty well sums it up :)
<lilo> what was the licensing on ncurses?
<esr> I don't remember the original license anymore, but that was never a point of contention.  It's under GPL now.
<lilo> in what way did the junior programmer hijack the project....that sounds so....erm, non-open
<esr> No, I'm wrong.  It's under a BSD-like license, by special agreement.
<lilo> I guess I'm confused...if it was BSD'd, what could they have done to hijack it? *confused look*
<esr> Started issuing distributions against the founder's explicit objections.  Disabled optimizer code I had written against 
my objections.
<lilo> it sounds like a lot of bad blood was created there
<esr> There was this really cool vertical-movement optimizer stage I had written.  Original algorithm, scads faster than BSD's 
or AT&T's on common cases.  He disabled it in his distribution because it slowed down one rare case he happened to be interested in 
by 5%.  Grrrrrr.....
<Culus> But isn't that his right, it was GPL'd after all.
<lilo> or BSD'd in this case, but I guess the same criteria would apply
<esr> It wasn't GPLed at the time.  Even if it had been, this twerp was (in effect) defacing my work.
<Culus> So you are saying that to change a GPL/BSD'd program you need the authors permission?
<lilo> it sounds as if this is the sort of case that stretches the paradigm of open source to a real stress point
<esr> Read "Homesteading the Noosphere".  In a world in which GPL completely defined hacker custom, I would not in fact have 
any right to object.  But it doesn't; actual ownership customs (as I have observed them) are a lot more stringent, and a lot more biased 
towards project founders and long-time maintainers.
* lilo looks at the time...eeps!
<lilo> I think at this point we should probably look at ending the more "formal" part of the program....in just a bit, with Eric's 
permission, I'll unmoderate the channel
<esr> OK.  I'm easy.

Putting aside for a separate discussion the various prevarications expressed by ESR, it does support the statement that "Homesteading the Noosphere" is tainted by spite regarding ncurses.

Other comments by ESR are found in various places:

Software-Release-Practice-HOWTO

The Conventional View

A different view is that a maintainer is essentially noncreative, someone who collects other's work, makes minor fixes and presents the result to others. That attitude is reflected here and here, for instance.

This causes different responses from people having different backgrounds. Nontechnical people (in particular non-programmers) regard "maintainer" as a menial task, unworthy of recognition.

Some comments go beyond this. For instance, Kim Schulz, in Hacking Vim (admittedly a biased source) states

Today Thomas is the primary maintainer of Vile and the development is steered by him. His time for working on the editor is, however, very limited. So, it is mostly only bugfixes that he adds to the editor.

That was published in 2007. However, in context, vile's changelog for 2007 lists 97 changes (some have several parts, for describing new features, but those are not counted separately here). Of those,

22 describe new features,

53 describe improvements to existing features

22 describe bug-fixes

Stating that it is "mostly only bugfixes", by the way, crosses the boundary into libel, since that could only be true if the remaining changes introduce the bugs which are addressed in "mostly only bugfixes". However, since the source is biased, it has to be weighed in light of that, and all that is useful from it is an example of the types of opinions employed to deprecate the role of a "maintainer".

Balancing Viewpoints

Noting the diametrically opposed viewpoints, it is obvious that neither corresponds to the way a "maintainer" is viewed in the development process. Rather, they illustrate viewpoints which promote opinions.

Here is an outline of the activities assumed to be carried out for a software program:

reliable contact point for the development effort (hard to do if the maintainer is only an intermediary)
knowledgable about the design and implementation (which is only possible if the maintainer is also one of the primary developers).