Repository navigation
Suggestion: Display a projects business model #6
Description
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 supportedwith a link to the enterprise backing - for something like keystonejs
maintenance: company supportedwith a link to the company backing statement - for an individual project actively maintained
maintenance: individual supportedwith a link to their patreon page or whatever - for an project no longer maintained
maintenance: free time supportedwith no link - for a project maintained through bounties:
maintenance: bounty supportedwith 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.
Reacted by Matthias Wagler, ulrichb, Ankur Oberoi, Christian Kaatz and morbidick
Activity
mcollina commentedon Nov 27, 2018
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 commentedon Nov 27, 2018
A badge isn’t programmatically usable; perhaps a package.json field, like the spdx-compliant license field, would be more useful?
ahmadnassri commentedon Nov 27, 2018
related: https://maintained.tech and http://unmaintained.tech
and agreed on utility of a badge being limited and non-programmable
balupton commentedon Nov 28, 2018
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.
[-]Display a projects business model[/-][+]Suggestion: Display a projects business model[/+]mhdawson commentedon Jan 7, 2019
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:
mhdawson commentedon Jan 7, 2019
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 commentedon Jan 24, 2019
First cut at a baseline practice which incorporates this suggestion: #139
Eomm commentedon Aug 31, 2019
This has been addressed in #220
Closing
Feel free to reopen if we miss some point