This was written sometime in 2004, I think
How does the maintainer of a free software project decide which features to add? The guiding principle is simple: ask "why," rather than "why not."
All code is presumed harmful, because it will have bugs and maintenance costs, and introduce behaviors that will interact with other features. One feature often precludes or simplifies the implementation of some other feature, and these interactions can be unpredictable.
The basic job of a maintainer is to keep things on track, taking a long-term view. In practice this means saying "no" a lot. How do you convince a maintainer to add a feature? Provide a rationale which:
Bad rationales which apply to all possible features include:
Important homework for any feature:
Please don't assume that the key issue for accepting a feature is whether there's a patch. It isn't. It's easy to write a patch. It's hard to maintain a software project over the long term. Maintainers absolutely have to understand the rationale for each feature, not just rubber stamp the patches. If they don't understand a feature they can't maintain it over time. There will be future decisions about how the feature works, or how related features work, and the maintainer will have to make those decisions.
Thus the maintainer must understand why the feature exists, in detail. If they just take your word for it, they aren't doing their job.
See also this argument, specifically the part about preferences, which are especially likely to have poor rationales.
Please don't bother flaming maintainers because your feature hasn't gone in yet. Provide better rationale, yes. Randomly flame about the fact that maintainers have to say "no" a lot, no. Design by committee is far, far worse than rejecting a couple of patches. As Linus says, "If you don't get it, don't bother emailing me."
Special bugzilla rule: if you move a bug from WONTFIX or NOTABUG to REOPENED, you had better add additional, quality rationale at the same time.
Here's one way to look at it: If you're too lazy to do the homework and think through the big-picture rationale, I'm too lazy to add the feature. On the other hand, patches that come with well-thought-through rationale are often applied right away.
In addition to saying "no," maintainers have a couple of other obligations in my opinion:
Making your own patch set or distribution is often a good way to demonstrate that a feature is useful and build the case for including it in the mainline. (Caveat: external interfaces/APIs should be marked as nonstandard or vendor-specific in some way, if included in a nonstandard distribution. e.g. if you create a nonstandard function, call it yoyodyne_extension_blahblah(), not standard_namespace_blahblah().)
Of course, if a custom patch set or distribution is only of interest to 1% of users, it should conceivably stay custom forever, instead of being merged. But if it proves its worth for a good number of people, probably it should be merged.
Will maintainers make mistakes? Yes. But occasionally screwing up the exact line between accepted and rejected patches is a much lesser evil than taking every patch immediately would be.