Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Display a projects business model #6

Closed
balupton opened this issue Nov 27, 2018 · 8 comments
Closed

Suggestion: Display a projects business model #6

balupton opened this issue Nov 27, 2018 · 8 comments

Comments

@balupton
Copy link
Contributor

balupton commented Nov 27, 2018

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
Copy link
Member

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
Copy link
Member

ljharb commented 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
Copy link
Contributor

ahmadnassri commented Nov 27, 2018

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

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

@balupton
Copy link
Contributor Author

balupton commented Nov 28, 2018

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.

@balupton balupton changed the title Display a projects business model Suggestion: Display a projects business model Nov 28, 2018
@mhdawson
Copy link
Member

mhdawson commented 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 mhdawson added the package-maintenance-agenda Agenda items for package-maintenance team label Jan 7, 2019
@mhdawson
Copy link
Member

mhdawson commented 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
Copy link
Member

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

@mhdawson mhdawson removed the package-maintenance-agenda Agenda items for package-maintenance team label Jan 24, 2019
@Eomm
Copy link
Member

Eomm commented Aug 31, 2019

This has been addressed in #220

Closing
Feel free to reopen if we miss some point

@Eomm Eomm closed this as completed Aug 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants