Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all.

Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it finds resonance with its users." with the perfect example

> This threat can take many forms. The most obvious is a feature that’s wildly out of scope, like a request to add a GUI to a CLI tool

Indeed, a threat to the project that can transform a niche tool into a widely used one of at least reduce the usability barriers for a wider user base. Shoo the "incoherent vision" of a drive by Trojan horse bearing gui contribution gifts!

> there is a significant transfer of responsibility when a PR is merged. ... maintainer who is suddenly on the hook for it.

> we’ve introduced and documented the contrib

Oh, so all you had to do to get off the hook was add a comment that you're not responsible?

▲

sdenton4 2 days ago | parent [-]

You are free to fork and make whatever mess of features you wish for!

▲

eviks 2 days ago | parent | next [-]

You're free to address any of the actual points in my comment instead of using an irrelevant cliche!

	▲	const_cast a day ago \| parent [-]
		Scope creep destroys projects and software. Most software is bad because it does too much, so most of it barely works and of the parts that do kind of work, they don't work together. Writing code is easy. Not writing code is much harder. Know what code to write, and what not to, is hardest.

▲

IshKebab 2 days ago | parent | prev [-]

Not really. That solution only works if you are willing to maintain your fork forever just for your one patch, and you're happy to build the software yourself every time you need it and it's a "leaf" project (e.g. it's not good if you want to add a feature to Linux and it only exists on your machine).

This answer is very much like "well if you don't like Trump you're free to live in another country!". Technically true.. ish. Practically dumb as hell.

	▲	sdenton4 a day ago \| parent [-]
		The "willing to maintain your work" forever is the crux here - the open-source contributor is doing some amount of work to bring their contribution in line with the expectations of the repository, but it's up to the repository's maintainers to decide if they want to take on the work of maintaining that contribution forever. And that asymmetry exactly what TFA is about. If there's great features missing form a library which are out of scope for the library, you have options - fork it, make a new library depending on the other one, launch a new linux distribution, and so on. These options require taking on the long-term work that the other library is saying (implicitly) that they don't want to do. Libraries /should/ be tightly scoped and think hard about serving broad use-cases with simple API's: Otherwise maintenance, documentation, and discoverability of features become nightmares. It's also completely OK for composition to happen, as new libraries serve new sets of features for their own specific use cases, with dependencies on existing work. It's an ecosystem! It's ok!