6 ms·

No Maintenance Intended

236 points by lifthrasiir 7y ago

seanalltogether 7y ago
Shouldn't the badge have a green checkmark to show everything's ok? Or is no maintenance intended supposed to imply your code is broken?
- bArray 7y ago
  Yeah I think it should at least not be red, indicating there is some problem.
  - hcs 7y ago
    There probably will be a problem, though, and if it's unmaintained no one will be around to change the status, so it's more honest to leave it red for all time.
    - bArray 7y ago
      But that indicates that it's actively failing, even if one day old. To me it needs to say "this project is not actively tested", not that it's broken. Depending on how simple/self dependent it is, it might not ever really break.
- tomxor 7y ago
  Yes, there should be green AND red! maintenance comes in two flavors, it's absence can be a sign of good or bad, depending on the project: Very small projects given enough time can be cut almost perfectly up front, a few patches maybe then it's done. In this case lack of maintenance is a sign of stability and completeness. At the opposite end of the scale, in very large and _dynamic_ projects, maintenance is a continual necessity. Not only because of it's own scope being so large it's difficult to settle on a coherent, complete and bug free solution, but because of how it also interacts with many other changing external projects, in short these projects are an ecosystem - In this case lack of maintenance signifies death, instability, insecurity and abandonment. I find it particularly annoying when the latter is applied to projects fitting into the former category. Some package managers even auto-quantify package quality based on maintenance (release frequency) - looking at you NPM. Some other phrase should be used to clarify this, maybe: "No maintenance needed", although that sounds a bit unrealistic, the point is the lack of release churn doesn't mean it's broken.
  - DougBTX 7y ago
    > Very small projects given enough time can be cut almost perfectly up front, a few patches maybe then it's done. Perhaps there needs to be a bigger distinction between "unchanging" and "unmaintained". In your example, a project could be unchanging simply because there is nothing to do, it is "done". But if a bug was found, would someone fix it? That's when maintained vs unmaintained would matter, perhaps it is only possible to know how well something is being maintained until problems are reported...
    - tomxor 7y ago
      Yes this is a better distinction, I suppose the problem is that inactivity tends to be equated with lack of maintenance - regardless of whether there are still people around that care but have nothing to do.
- eMGm4D0zgUAVXc7 7y ago
  The code for it is on GitHub, can someone please file an issue there to provide an additional green version? (Or fix it right away?) https://github.com/potch/unmaintained.tech/issues https://github.com/potch/unmaintained.tech/issues Thank you!
- susam 7y ago
  > Shouldn't the badge have a green checkmark to show everything's ok? Or is no maintenance intended supposed to imply your code is broken? Perhaps they can offer some way to customize the badge like Shields.IO does. For example, - https://img.shields.io/badge/Status-No%20Maintenance%20Intended-yellow https://img.shields.io/badge/Status-No%20Maintenance%20Inten... - https://img.shields.io/badge/Status-Actively%20Maintained-brightgreen https://img.shields.io/badge/Status-Actively%20Maintained-br... - https://img.shields.io/badge/Status-Obsolete%20Project-red https://img.shields.io/badge/Status-Obsolete%20Project-red - https://img.shields.io/badge/-No%20Maintenance%20Intended-yellow https://img.shields.io/badge/-No%20Maintenance%20Intended-ye... - https://img.shields.io/badge/-No%20Maintenance%20Intended-brightgreen https://img.shields.io/badge/-No%20Maintenance%20Intended-br...
stanislavb 7y ago
The badge should be yellow. Implying a warning.
- Crinus 7y ago
  I'd go with a blue, implying general information instead of some point in the same single dimension where the "all good", "warning" and "error" points also lie on. Also make this a PNG so it can be used outside of Github too.
naglis 7y ago
Nice idea! I think it would be great to add HTTPS to http://unmaintained.tech http://unmaintained.tech.
StavrosK 7y ago
A while ago I started an OSS maintainer community for exactly this purpose, I saw software that was in use, people wanted to contribute, the users were very active, but the developer had abandoned it, creating a hole. We all know how much more difficult it is to create a fork that will be discoverable over the original rather than just merge a few PRs. I would like to ask anyone who currently has a project they don't want to maintain to spend the minute to add the project to Code Shelter: https://www.codeshelter.co/ https://www.codeshelter.co/ This way, interested people can easily pick up maintenance and at least merge a few PRs/triage a few issues. Also, if you have some spare time or you see a project you'd like to help out with, please join Code Shelter as a maintainer: https://www.codeshelter.co/membership/ https://www.codeshelter.co/membership/ There's no reason to have abandoned projects nowadays, it locks them in a state of "I don't want anyone improving this" rather than "I don't have time to improve it, but feel free to if you want".
- aflag 7y ago
  This is awesome! Have you tried to get in contact with GitHub? It'd be nice if they embraced the project. Maybe adding a new button or tab with a shelter link to the project (they already have a forks view).
  - StavrosK 7y ago
    We haven't, I'd like to get some more traction (and build a welcoming community) first before expanding to anything else.
- bxparks 7y ago
  This is a great idea, thank you for creating it. Could I suggest 2 things? 1) Can you group the projects according to the language or framework (e.g. Python, JavaScript, Node, Arduino, C++, Java, etc). 2) Can you carve out a separate section for projects that currently have no maintainers? I had to scroll through the entire list to see if there was something that I could help with. (I'm on my phone, so if these sections already exist on desktop, I didn't see them.)
  - 7y ago
thefurman 7y ago
I think one of the problems people have with free open source in general is that it's hard to get a bearing on exactly what additional risks come with it now and in the future. Will it stay open source and free to use? Will it be actively maintained? Can I get support for issues in a timely manner? Will someone be there to helpfully guide or at least review and accept my contributions? There needs many more dimensions to the categorization and it would be very nice if OSS projects could be graded along them all.
- uncletaco 7y ago
  Hah I wish. My experience in a javascript shop is someone finds a library, they add it to the project, then one day in the distant future, long after the developer has left, everything breaks.
- indigochill 7y ago
  >Will it stay open source and free to use? This is a concern of mine as well, so when I find a repo I want to guarantee future access to, I fork it. Then I have a copy that's licensed with the original open source license and which will stick around as long as I care to keep it around. >Can I get support for issues in a timely manner? IMO this should not be an expectation in open source. It's nice when it happens, but expect to DIY. >Will someone be there to helpfully guide or at least review and accept my contributions? Also nice when it happens, also by no means guaranteed in open source. If someone else isn't available, you can always carry on in your own fork. Overall I think people place certain expectations on FOSS because they tend to align with the open source culture but strictly speaking, the reality of FOSS doesn't support those expectations in the long term.
- gumby 7y ago
  Don't these issues apply to commercial software too?
wyldfire 7y ago
The badge color debate threads here are textbook bike shedding [1]. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
- switch007 7y ago
  The badge looks like 90pc of the product to me. A bike shed at a nuclear plant is not part of it at all. It’s fair to comment on the design
  - mrfredward 7y ago
    How many people are commenting here because the color of this badge meaningfully affects them? The debate on this post is happening because it's easy to have an opinion, not because there is anything of significance to be gained here. From the wikipedia above: "...everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to add a touch and show personal contribution."
cyphar 7y ago
Rust has a similar feature in Cargo.toml[1], though they define multiple degrees of maintenance (actively-developed, passively-maintained, as-is, experimental, looking-for-maintainer, deprecated, none). [1]: https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata https://doc.rust-lang.org/cargo/reference/manifest.html#pack...
campfireveteran 7y ago
Nearly every week without fail, random people email me to ask random/dumb questions about projects I have on Github that are clearly marked Read Only/Archived. It's not worth my time to respond to assinine, pointless emails. I'm not their employees, and I owe these people NOTHING. Still, some of these people email me to scream their entitlement as to why I haven't answered their email to solve their problems. (LOL) They just don't get it. (LOL some more.)
- triangleman 7y ago
  FWIW I would never write an email like that to you. I would begin by thanking you for the work, then asking my question, then probably closing the email because I have successfully rubber-ducked my question, then days later rewriting the draft again with a better question, and finally ending the email with "If you ever get a chance, I'd appreciate you pointing me in the right direction" or somesuch.
signsoflife 7y ago
an interesting feature would be to have either Github or a third party "ping" projects with issues to see if the author is still a) responsive and b) interested in maintaining the project. obviously it would be best if Github itself implemented this, potentially along with an automated process to indicate that the author is no longer responsive/interested in maintaining the project (and potentially facilitate a transfer of "authority"). a third party system trying to determine the same might be ignored as spam by the author, and multiple third party systems (potentially jockeying for supremacy in the space) might exacerbate this. if folks think this would be valuable, i might pursue this as a project (after petitioning Github to do it themselves)
kotutku 7y ago
Does this badge imply that the project doesn't have any external dependencies? What if another Heartbleed or a vulnerability in the language itself is found?
- alangpierce 7y ago
  Nope, the "no maintenance intended" explanation definitely does not mean that the software is free from vulnerabilities. If you want to use an unmaintained project, you should look at its dependencies and assess for yourself whether it's a better idea to use the project or rewrite your own version. In many cases, it's best to fork the project and maintain it as if it was your own code.
k33n 7y ago
Why would I need to link to this badge, or use it at all? Also, why would someone want to pay for bandwidth for these badges? I just don't understand the point of the badge or the landing page. I could just write "No maintenance will be done on this repo" in my Readme and call it a day.
- coldtea 7y ago
  For the same reason others link to licenses. Because somebody wrote the thing, and expressed it better than they could, and the don't want to (a) be bothered to write their own version of this text, (b) just write a less good line like the above.
  - k33n 7y ago
    But most people copy and paste licenses into their own LICENSE file.
gumby 7y ago
Somewhat off topic but I thought when I clicked on the link that it would be about long-lived systems that didn't need maintenance. In an increasingly IoT world we'll have devices all over the place that can't afford to be visited between deployment and recycling.
deleted 7y ago
[deleted]
roryokane 7y ago
Alternatively, you can use the “Abandoned” or “Unsupported” badges from https://www.repostatus.org/ https://www.repostatus.org/: > Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development. > Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. repostatus.org is a project that defines eight statuses you can mark repos with: Concept, WIP, Suspended, Abandoned, Active, Inactive, Unsupported, or Moved. Each badge links to a short summary such as the ones above. It looks like No Maintenance Intended might explain the project status better with its dedicated web page, while repostatus.org is better for being able to categorize the state of all of one’s projects.

236 points by lifthrasiir 7y ago

Shouldn't the badge have a green checkmark to show everything's ok? Or is no maintenance intended supposed to imply your code is broken?

bArray 7y ago
Yeah I think it should at least not be red, indicating there is some problem.
- hcs 7y ago
  There probably will be a problem, though, and if it's unmaintained no one will be around to change the status, so it's more honest to leave it red for all time.
  - bArray 7y ago
    But that indicates that it's actively failing, even if one day old. To me it needs to say "this project is not actively tested", not that it's broken. Depending on how simple/self dependent it is, it might not ever really break.
tomxor 7y ago
Yes, there should be green AND red! maintenance comes in two flavors, it's absence can be a sign of good or bad, depending on the project: Very small projects given enough time can be cut almost perfectly up front, a few patches maybe then it's done. In this case lack of maintenance is a sign of stability and completeness. At the opposite end of the scale, in very large and _dynamic_ projects, maintenance is a continual necessity. Not only because of it's own scope being so large it's difficult to settle on a coherent, complete and bug free solution, but because of how it also interacts with many other changing external projects, in short these projects are an ecosystem - In this case lack of maintenance signifies death, instability, insecurity and abandonment. I find it particularly annoying when the latter is applied to projects fitting into the former category. Some package managers even auto-quantify package quality based on maintenance (release frequency) - looking at you NPM. Some other phrase should be used to clarify this, maybe: "No maintenance needed", although that sounds a bit unrealistic, the point is the lack of release churn doesn't mean it's broken.
- DougBTX 7y ago
  > Very small projects given enough time can be cut almost perfectly up front, a few patches maybe then it's done. Perhaps there needs to be a bigger distinction between "unchanging" and "unmaintained". In your example, a project could be unchanging simply because there is nothing to do, it is "done". But if a bug was found, would someone fix it? That's when maintained vs unmaintained would matter, perhaps it is only possible to know how well something is being maintained until problems are reported...
  - tomxor 7y ago
    Yes this is a better distinction, I suppose the problem is that inactivity tends to be equated with lack of maintenance - regardless of whether there are still people around that care but have nothing to do.
eMGm4D0zgUAVXc7 7y ago
The code for it is on GitHub, can someone please file an issue there to provide an additional green version? (Or fix it right away?) https://github.com/potch/unmaintained.tech/issues https://github.com/potch/unmaintained.tech/issues Thank you!
susam 7y ago
> Shouldn't the badge have a green checkmark to show everything's ok? Or is no maintenance intended supposed to imply your code is broken? Perhaps they can offer some way to customize the badge like Shields.IO does. For example, - https://img.shields.io/badge/Status-No%20Maintenance%20Intended-yellow https://img.shields.io/badge/Status-No%20Maintenance%20Inten... - https://img.shields.io/badge/Status-Actively%20Maintained-brightgreen https://img.shields.io/badge/Status-Actively%20Maintained-br... - https://img.shields.io/badge/Status-Obsolete%20Project-red https://img.shields.io/badge/Status-Obsolete%20Project-red - https://img.shields.io/badge/-No%20Maintenance%20Intended-yellow https://img.shields.io/badge/-No%20Maintenance%20Intended-ye... - https://img.shields.io/badge/-No%20Maintenance%20Intended-brightgreen https://img.shields.io/badge/-No%20Maintenance%20Intended-br...

stanislavb 7y ago

The badge should be yellow. Implying a warning.

Crinus 7y ago
I'd go with a blue, implying general information instead of some point in the same single dimension where the "all good", "warning" and "error" points also lie on. Also make this a PNG so it can be used outside of Github too.

naglis 7y ago

Nice idea! I think it would be great to add HTTPS to http://unmaintained.tech http://unmaintained.tech.

StavrosK 7y ago

A while ago I started an OSS maintainer community for exactly this purpose, I saw software that was in use, people wanted to contribute, the users were very active, but the developer had abandoned it, creating a hole. We all know how much more difficult it is to create a fork that will be discoverable over the original rather than just merge a few PRs. I would like to ask anyone who currently has a project they don't want to maintain to spend the minute to add the project to Code Shelter: https://www.codeshelter.co/ https://www.codeshelter.co/ This way, interested people can easily pick up maintenance and at least merge a few PRs/triage a few issues. Also, if you have some spare time or you see a project you'd like to help out with, please join Code Shelter as a maintainer: https://www.codeshelter.co/membership/ https://www.codeshelter.co/membership/ There's no reason to have abandoned projects nowadays, it locks them in a state of "I don't want anyone improving this" rather than "I don't have time to improve it, but feel free to if you want".

aflag 7y ago
This is awesome! Have you tried to get in contact with GitHub? It'd be nice if they embraced the project. Maybe adding a new button or tab with a shelter link to the project (they already have a forks view).
- StavrosK 7y ago
  We haven't, I'd like to get some more traction (and build a welcoming community) first before expanding to anything else.
bxparks 7y ago
This is a great idea, thank you for creating it. Could I suggest 2 things? 1) Can you group the projects according to the language or framework (e.g. Python, JavaScript, Node, Arduino, C++, Java, etc). 2) Can you carve out a separate section for projects that currently have no maintainers? I had to scroll through the entire list to see if there was something that I could help with. (I'm on my phone, so if these sections already exist on desktop, I didn't see them.)
- 7y ago

thefurman 7y ago

I think one of the problems people have with free open source in general is that it's hard to get a bearing on exactly what additional risks come with it now and in the future. Will it stay open source and free to use? Will it be actively maintained? Can I get support for issues in a timely manner? Will someone be there to helpfully guide or at least review and accept my contributions? There needs many more dimensions to the categorization and it would be very nice if OSS projects could be graded along them all.

uncletaco 7y ago
Hah I wish. My experience in a javascript shop is someone finds a library, they add it to the project, then one day in the distant future, long after the developer has left, everything breaks.
indigochill 7y ago
>Will it stay open source and free to use? This is a concern of mine as well, so when I find a repo I want to guarantee future access to, I fork it. Then I have a copy that's licensed with the original open source license and which will stick around as long as I care to keep it around. >Can I get support for issues in a timely manner? IMO this should not be an expectation in open source. It's nice when it happens, but expect to DIY. >Will someone be there to helpfully guide or at least review and accept my contributions? Also nice when it happens, also by no means guaranteed in open source. If someone else isn't available, you can always carry on in your own fork. Overall I think people place certain expectations on FOSS because they tend to align with the open source culture but strictly speaking, the reality of FOSS doesn't support those expectations in the long term.
gumby 7y ago
Don't these issues apply to commercial software too?

wyldfire 7y ago

The badge color debate threads here are textbook bike shedding [1]. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality

switch007 7y ago
The badge looks like 90pc of the product to me. A bike shed at a nuclear plant is not part of it at all. It’s fair to comment on the design
- mrfredward 7y ago
  How many people are commenting here because the color of this badge meaningfully affects them? The debate on this post is happening because it's easy to have an opinion, not because there is anything of significance to be gained here. From the wikipedia above: "...everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to add a touch and show personal contribution."

cyphar 7y ago

Rust has a similar feature in Cargo.toml[1], though they define multiple degrees of maintenance (actively-developed, passively-maintained, as-is, experimental, looking-for-maintainer, deprecated, none). [1]: https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata https://doc.rust-lang.org/cargo/reference/manifest.html#pack...

campfireveteran 7y ago

Nearly every week without fail, random people email me to ask random/dumb questions about projects I have on Github that are clearly marked Read Only/Archived. It's not worth my time to respond to assinine, pointless emails. I'm not their employees, and I owe these people NOTHING. Still, some of these people email me to scream their entitlement as to why I haven't answered their email to solve their problems. (LOL) They just don't get it. (LOL some more.)

triangleman 7y ago
FWIW I would never write an email like that to you. I would begin by thanking you for the work, then asking my question, then probably closing the email because I have successfully rubber-ducked my question, then days later rewriting the draft again with a better question, and finally ending the email with "If you ever get a chance, I'd appreciate you pointing me in the right direction" or somesuch.

signsoflife 7y ago

an interesting feature would be to have either Github or a third party "ping" projects with issues to see if the author is still a) responsive and b) interested in maintaining the project. obviously it would be best if Github itself implemented this, potentially along with an automated process to indicate that the author is no longer responsive/interested in maintaining the project (and potentially facilitate a transfer of "authority"). a third party system trying to determine the same might be ignored as spam by the author, and multiple third party systems (potentially jockeying for supremacy in the space) might exacerbate this. if folks think this would be valuable, i might pursue this as a project (after petitioning Github to do it themselves)

kotutku 7y ago

Does this badge imply that the project doesn't have any external dependencies? What if another Heartbleed or a vulnerability in the language itself is found?

alangpierce 7y ago
Nope, the "no maintenance intended" explanation definitely does not mean that the software is free from vulnerabilities. If you want to use an unmaintained project, you should look at its dependencies and assess for yourself whether it's a better idea to use the project or rewrite your own version. In many cases, it's best to fork the project and maintain it as if it was your own code.

k33n 7y ago

Why would I need to link to this badge, or use it at all? Also, why would someone want to pay for bandwidth for these badges? I just don't understand the point of the badge or the landing page. I could just write "No maintenance will be done on this repo" in my Readme and call it a day.

coldtea 7y ago
For the same reason others link to licenses. Because somebody wrote the thing, and expressed it better than they could, and the don't want to (a) be bothered to write their own version of this text, (b) just write a less good line like the above.
- k33n 7y ago
  But most people copy and paste licenses into their own LICENSE file.

gumby 7y ago

Somewhat off topic but I thought when I clicked on the link that it would be about long-lived systems that didn't need maintenance. In an increasingly IoT world we'll have devices all over the place that can't afford to be visited between deployment and recycling.

deleted 7y ago

[deleted]

roryokane 7y ago

Alternatively, you can use the “Abandoned” or “Unsupported” badges from https://www.repostatus.org/ https://www.repostatus.org/: > Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development. > Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. repostatus.org is a project that defines eight statuses you can mark repos with: Concept, WIP, Suspended, Abandoned, Active, Inactive, Unsupported, or Moved. Each badge links to a short summary such as the ones above. It looks like No Maintenance Intended might explain the project status better with its dedicated web page, while repostatus.org is better for being able to categorize the state of all of one’s projects.