No Maintenance Intended | Hacker News Reader

No Maintenance Intended

unmaintained.tech

236 pointslifthrasiir49 comments

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/

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/

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".

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).

We haven't, I'd like to get some more traction (and build a welcoming community) first before expanding to anything else.

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.)

These are great ideas, thank you! I will file the issues now (they'll be at https://gitlab.com/codeshelter/codeshelter-web/issues if you want to track them).

Even if you don't get a maintainer for a project, just providing ownership transfer and holding of no longer maintained projects is probably useful. Getting the owner to turn over the keys when they update the readme might be easier than 10 years later.

Yeah, this is one of the reasons I wanted this. The owners have nothing to lose (they aren't maintaining the projects anyway), the maintainers have nothing to lose (there's no time requirement), and at some point you might come across a project that you want to use but that has been abandoned, and you can just click "join" and become its maintainer.

Not that I have massively successful projects but one thing I would love is to just hand over keys to someone I can trust to vet the person the keys are handed to. I'd be fine with "verired no malware, no spam, no adware." as a handoff.

That's what Code Shelter does (provided you trust us to vet people, I guess).

I added one of my projects (https://github.com/akavel/rsrc) some time ago, when codeshelter was announced for the first time; it has a "maintainer" listed; but noone seemed to either contact me or do anything with the repo, ever. It feels weird to me. I can understand that there's no requirement for them to do something; but it still feels weird as it is now — someone seems to claim to (want to?) be a contributor, but didn't seem to even try and reach out to me.

Thinking out loud, maybe there could be some form, where if a candidate maintainer clicks the button to "join a project" (or whatever), they'd have to compose some message that would be sent to the owner, to at least break some first ice and initiate some contact? I don't know what's going on with the person. If there was an easy way, I would be happy to reach out to them and ask them, like, "hey, howdy'a doing?" Also, it would be nice if I was sent an email with a notification when someone "claims" my project, and with a chance to connect with them. Maybe you could try and start contacting people to see how is this working, and if not, to try and dig down on the underlying reasons? maybe this could lead to some now ideas for improvements and helping people work together?

Thanks for the feedback! This was probably later than when you added the project, but we added a "note to maintainers" feature:

https://gitlab.com/codeshelter/note-to-maintainers

It's basically a text file where you describe how you want future maintainers to handle the project, give instructions, caveats, etc (whatever you want, basically).

I assume this specific maintainer situation happened because it's easy to click a button and be added to the project, so maybe the maintainer was planning to do something but didn't get around to it, or something similar.

About the communication, you're right, we encourage maintainers and authors to join our chat server (https://codeshelter.zulipchat.com/) so they can be in contact.

Code Shelter was built with more of a long-term prospect in mind (obviously we can't guarantee that we'll find you a maintainer right away), maybe I should amend the copy to manage peoples' expectations, because I hear from a lot of people that they expected someone to pick up their project and were disappointed when it didn't happen.

That's... something. But it still feels very passive.

What do you think about the ideas I listed in the post above? I assume you know who are the people on both sides, and that you have their emails, so I'd guess you're in a good position to actively facilitate communication, no? Is there a way how I could actively reach out to a person that's listed as a maintainer on my project? Why not add a form that would let me do that? even without necessarily revealing their email, if they don't want to? though to tell the truth, why wouldn't they want to, if they claim to want to contribute? Similarly, how about a notification, so that I learn that someone joined my project, with their email so that I can reach out with a welcome? why passive encouragement to a chat server instead of an active facilitation of first contact over email?

Oh, I definitely agree with you that communication should be more active, it's just that right now this is more left to the new maintainer to do. On Github, everyone's email is public anyway, so the new maintainer could message the old one.

I don't think Github/Gitlab provide any automated way to send people messages (short of creating a new issue and mentioning people). Actually, creating an issue on a maintainer joining might be a good idea, I will look into it.

Other than that, we have to take many scenarios into account (many people don't want to talk to the new maintainer, for example, because the project is completely abandoned).

We should definitely add something, though. I'll see if we can automatically add issues that will be something like "Introduce yourself" with a body of "Hello @maintainer1, @maintainer2! @newmaintainer just joined, please say hi".

I have opened an issue if you want to contribute: https://gitlab.com/codeshelter/codeshelter-web/issues/34

Thanks! I'd say "you're welcome to say hi" sounds softer than "please say hi", but other than that, sounds good to me!

Oh, yes, the copy was just illustrative.

I've implemented your suggestion, thanks! Here's a sample issue that is automatically created:

https://github.com/sirodoht/atom-pastery/issues/3

Seems like a great idea. One big worry with handing over ownership is fiascos like https://news.ycombinator.com/item?id=18534392 where the author handed over ownership of an unmaintained project and the new owner released malicious code. I'd love to see a better systematic way to keep projects maintained in a way that the community can trust.

Yep, all maintainers are vetted specifically to avoid that. If Code Shelter existed back then, this (hopefully) wouldn't have happened.

> how much more difficult it is to create a fork that will be discoverable over the original

Part of the problem has been GitHub being unable to even show a fork graph for highly-forked projects. If that instrumentation was in better shape, one might imagine there would be more convergence.

A related challenge is the lack of conventions or infrastructure around describing the intent of a fork.

So instead of a transparent single page summary of a repo's forks, their original vision, actual activity, and relationships... individual consumers each do their own exploratory flailing around - "the github dance". In isolated repetition, as there's no convention/mechanism for sharing "I just spent an hour examining all these forks... here's what I learned, to spare you doing the same".

Perhaps a minimalist alternative to a codeshelter, might be linking to some persistent discussion forum thread, to bless an coordination process, rather than one particular result.

Though which forum has adequate properties... Perhaps use an Issue? Perhaps with some naming convention, like "Relationship to other forks"? "Related Work"? "Forks"?

I've felt GitHub started well, was building out needed infrastructure... but then stalled out with much left undone.

I'm just not sure codeshelter has the right shape. I've found people being briefly motivated to take something over, and then vanishing, to be a common case. So is "simply transfer ownership" the right model? Sometimes no one person wants to own it, but several would be willing to variously chip in, but the coordination barrier for that is currently unnecessarily high.

But maybe someone has already created a "github fork network summarizer" service site, and I've just not yet heard of it? Perhaps the transition from a startup, to a "we're not pathological anymore, really truly" Microsoft, has changed the incentives around supporting parasitic services exploring and addressing niche needs? Could "a better github" information design exercises/services become a thing?

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?

Yeah I think it should at least not be red, indicating there is some problem.

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.

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.

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.

> 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...

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.

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

Thank you!

> 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%20Inten...

- https://img.shields.io/badge/Status-Actively%20Maintained-br...

- https://img.shields.io/badge/Status-Obsolete%20Project-red

- https://img.shields.io/badge/-No%20Maintenance%20Intended-ye...

- https://img.shields.io/badge/-No%20Maintenance%20Intended-br...

The badge color debate threads here are textbook bike shedding [1].

[1] https://en.wikipedia.org/wiki/Law_of_triviality

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

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."

The badge should be yellow. Implying a warning.

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.

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

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.

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.

>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.

Don't these issues apply to commercial software too?

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#pack...

Alternatively, you can use the “Abandoned” or “Unsupported” badges from 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.

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.

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.

But most people copy and paste licenses into their own LICENSE file.

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.

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?

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.

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)

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.)

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.

Reply on news.ycombinator.com