Table of Contents:
The currently drafted proposal for a support
field[1] is very large in scope, introducing a number of net-new concepts, making it hard to gain consensus.
I've created an updated proposal that looks to split out the three primary areas of concern (ie. Backing Maintainers, Maintenance Level & Activity & Supported Environments & Targets) in the hopes of moving the conversation forward. This proposal reflects smaller package.json
-specific changes.
Things that should be kept in mind are:
- Why does this exist?
- What is the solution?
- How is that solution implemented?
- Who is the intended audience or implementator?
Package maintainers want to clearly indentify how their software is currently, or could be in the future, supported monetarily.
- See Prior Art: Funding Maintainers
- Provide a means to identify the type of backing
- Provide a means to reference existing backers or funding opportunities
- Add a
funding
field topackage.json
- supports a string URL or object with...
- keys that support arbitrary string identifiers (ex.
"sponsor"
,"sponsors"
,"foundations"
,"donations"
,"bounties"
,"contributors"
,"patrons"
etc.) - values that represent a string URL or an array of URLs
Examples:
{
...
"funding": "https://www.patreon.com/my-account"
...
}
{
...
"funding": {
"foundations": "https://openjsf.org/"
}
...
}
{
...
"funding": {
"corporations": [
"https://microsoft.com/",
"https://google.com/"
]
}
...
}
{
...
"funding": {
"sponsor": [
"https://github.com/users/my-account/sponsorship",
"https://opencollective.com/my-account",
"https://www.patreon.com/my-account"
],
"sponsors": "https://github.com/users/my-account/sponsorship#sponsors",
"contributors": "https://opencollective.com/my-account#section-contributors",
"patrons": [
"https://patrons-site-one.com/",
"https://patrons-site-two.com/",
"https://patrons-site-three.com/"
]
}
...
}
- npm intends to ship support for the
funding
field in npmv6.13
- Adding notification at the end of output for
npm i
(ex.23 packages are looking for funding. Run "npm fund" to find out more.
) - Adding
--no-fund
flag to opt-out of this ouput when installing - Adding
npm fund
subcommand which will: open the URL (string) OR list the funding references (object) - Adding a visual representation for the funding field/value on package pages at
npmjs.com
- Adding notification at the end of output for
Package maintainers want to communicate their availability & a response time they can accomodate.
- See Prior Art: Maintenance Level & Activity
- Provide a new field to reference mutable "support level & activity" documentation
- Add a
support
key topackage.json
which supports a string URL
Example:
{
...
"support": "https://unpkg.com/browse/my-package/SUPPORT.md",
...
}
- npm is prepared to display this link on package pages while considering other options/additions to the Packument object going forward.
Package maintainers often want to maintain a subset of their published software &/or the environments in which that software functions.
- See Prior Art: Supported Environments & Targets
- Provide a new field to reference mutable "supported environments & package targets" documentation
- Add a
support
key topackage.json
which supports a string URL
Example:
{
...
"support": "https://unpkg.com/browse/my-package/SUPPORT.md",
...
}
- npm is prepared to display this link on package pages while considering other options/additions to the Packument object going forward.
- Open Collective
- GitHub Sponsors
- License Zero
- GitCoin
- Feross:
thanks
- Feross:
funding
- Indieweb: payment
- microformats:
rel-payment
- Shields.io: Funding
- ThanksApp: Donate Spec
- Bevry:
sponsored
- OGAG:
civic.json
- Open Source licenses explicitly outline software as being distributed "as-is"
- Maintenance expectations have been & are considered "best effort"
- Maintenance expiry is communicated through deprecation
- Help information is communicated through the
bugs
field (typically an issue tracker reference) - Maintainer information is communicated through
author
,contributors
,maintainers
&owner
[10]
- PM WG: "Document support levels" Draft
- PM WG: "Document support levels" Blog post to announce
- PM WG: "Document support levels" Blog post to validate
- PM WG:
support
fieldlicense
Issue - PM WG: "Future direction of
support
field" Issue - npm:
sustainability
PR - npm:
support
PR thanks
: "Read URL frompackage.json
" Issuefunding
: "Collaborate with the PM WG" Issue- Differences between: "author", "contributors", "maintainers" & "owner"