Suggestion: Display a projects business model

[balupton]

I think having a badge in a project's readme with their business model is a good idea.

For instance:

• for something like react can get maintenance: enterprise supported with a link to the enterprise backing
• for something like keystonejs maintenance: company supported with a link to the company backing statement
• for an individual project actively maintained maintenance: individual supported with a link to their patreon page or whatever
• for an project no longer maintained maintenance: free time supported with no link
• for a project maintained through bounties: maintenance: bounty supported with a link to their used bounty services
• for projects with absolutely no support: maintenance: abandoned

Or something like this. If this becomes popular, then the different tiers will get more wider understanding, and help in people making their decisions.

https://github.com/bevry/projectz and https://github.com/bevry/badges could automate this so that in an entry in the package.json file is all that is needed to generate this meta information, which could even be scanned by tooling to look for free time supported packages as warnings. Projectz would also be able to automate the insertion of say a npm keyword or a github topic.

[mcollina]

I'm not necessarily fond of having this in a badge, mainly because it's a lot of information to convey. However +1 to disclosing this information explicitly.

[ljharb]

A badge isn’t programmatically usable; perhaps a package.json field, like the spdx-compliant license field, would be more useful?

[ahmadnassri]

related: https://maintained.tech and http://unmaintained.tech

and agreed on utility of a badge being limited and non-programmable

[balupton]

perhaps a package.json field, like the spdx-compliant license field, would be more useful?

Agreed. This enables tooling like projectz to take that field and render it as a badge as well as a readme section, as well as "business model" / "maintenance" linters to scan deps for unsupported packages.

---

Will need to have a discussion of what the different tiers should be. The one's in the OP I think are good enough, but are probably likely to need revision.

[mhdawson]

I suggested something similar for a "support statement" in #119. I was thinking of support levels, but the "business model" is a different dimension from what level of support is targeted. I might not call it business model but instead maybe "sponsorship".

So I think we may want 2 new package.json entries:

• support level (see Discussion: Baseline practices - brainstorm initial list #119 (comment))
• sponsorship

[mhdawson]

I'm also thinking that this fits into the "baseline" practices being discussed in #119. A baseline practice would be to state your level of sponsorship and then we define/maintain the list to make it easier for the module owners to choose. We might also want to talk to npm to see if we can have the default which is generated by npm init be "individual" supported.

Another level to add to the list might also be project supported (or maybe foundation?), with the ability to list that project. This would be useful, for example for modules that are under the 'nodejs' org and for modules that are part of the JavaScript foundation.

[mhdawson]

First cut at a baseline practice which incorporates this suggestion: #139