I see a solution to this for both sides: encourage published forks. This allows the contributor to shoulder the burden of packaging and support. If you support the patch, adopt the fork and advocate on the issue. If you find issues, help refine it in the fork’s issue tracker.

▲

jaggederest 2 days ago | parent [-]

Or build a proper plugin system, or other means of composition.

I like the "core" plus "contrib" model myself, but it does require a lot of upkeep which is often the reason to say "no" in the first place.

	▲	saulpw 2 days ago \| parent [-]
		There will be pressure to make it easier to discover plugins, install plugins, install plugin dependencies, manage plugin options, uninstall plugins, verify and validate plugins, etc. It's all well and good to punt these problems to 'someone else' but that usually means either no one, someone who does a one-shot that becomes immediately out-of-date, or someone nefarious. The project mono-repo is the way to go. Long-term maintenance is the primary software challenge, and distributed maintenance is strictly more difficult. If the project truly has hundreds of motivated contributors, then forks or plugins might be worthwhile, but most projects struggle to keep more than one motivated contributor.