Enabling OSS sustainability

Enabling_OSS_sustainability.md

Add "requesting sponsorship" to package metadata

Package formats (nuget, npm etc) should be amended to add the concept of "this package is requesting sponsorship via ...". The "via..." part could be influence by the GitHub Funding.yml convention.

Surface "requesting sponsorship" in tooling

Once "requesting sponsorship" metadata is added, tooling can expose this in a variety of ways. For example:

• Prompt/inform on package installation
• Displayed on package listing websites
• Displayed when package info is viewed in IDEs
• As part of "what sponsored packages" are we using
• As part of dependency tree analyses. ie transitive referenced packages that are requesting sponsorship

Ability to restrict project features based on sponsorship

Allow restriction of project hosting features based on sponsorship status. Features that could be potentially be restricted:

• Issues.
• Pull Requests
• Discussions
• Documentation (or parts thereof)
• Release notes

Ability to restrict package access based on sponsorship

Package websites should be able to restrict access to packages based on sponsorship. This restriction could be limited to preview releases.

Integrated "flow" to request paid support

Project hosting sites should make "request paid support" a first class feature. Project maintainers could define their terms: $rate, warranty, interaction approach etc. Then this information can be exposed in a projects hosting site. Eg when raising a bug "this project offers paid support, see...". The payment should be handled through project hosting site, with them taking a % cut to recoup the cost.

Some thoughts on this:

Ability to restrict project features based on sponsorship

That will ultimately hurt the viability of the project for everyone, including paid users and maintainers, if the set of people who can report issues, participate in discussions, and send pull requests get limited. All of those activities are value-add to most parties.

Better way of handling this, based on our experience actually doing this on the Akka.NET project: issues submitted by sponsors (or in our case, people who buy support plans that guarantee this) get triage and patch priority. Otherwise we fix all other issues in whatever priority suits us unless they're patched by another contributor, in which case the same applies for when we review it and include it in a new release.

Ability to restrict package access based on sponsorship

Pretty much what we're doing with https://sdkbin.com/ right now, based on selling subscriptions. Endorse.

Integrated "flow" to request paid support

Great idea - we're working on this for some of the bits around our OSS projects right now to make sure users know where to get paid support if they need something urgently.