
No Maintenance Intended - lifthrasiir
http://unmaintained.tech/
======
StavrosK
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".

~~~
akavel
I added one of my projects
([https://github.com/akavel/rsrc](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?

~~~
StavrosK
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](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/](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.

~~~
akavel
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?

~~~
StavrosK
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](https://gitlab.com/codeshelter/codeshelter-web/issues/34)

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

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

[https://github.com/sirodoht/atom-
pastery/issues/3](https://github.com/sirodoht/atom-pastery/issues/3)

------
seanalltogether
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?

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

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

------
stanislavb
The badge should be yellow. Implying a warning.

~~~
Crinus
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
Nice idea! I think it would be great to add HTTPS to
[http://unmaintained.tech](http://unmaintained.tech).

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

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

------
cyphar
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...](https://doc.rust-
lang.org/cargo/reference/manifest.html#package-metadata)

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

------
k33n
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
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
But most people copy and paste licenses into their own LICENSE file.

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

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

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

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

