http://invisible-island.net/personal/
Copyright © 2009-2018,2019 by Thomas E. Dickey
The term "maintainer" means different things to different people.
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:
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.
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.
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:
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,
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".
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: