DEV Community

Gabor Szabo
Gabor Szabo

Posted on • Updated on

Passing maintenance or deprecating projects?

I really need to gather my thoughts about the topic, but I would be glad to read your opinion.

Way to often I bump into Open Source projects that drive me nuts.
This time it is pylibdmtx a Python project used at one of my clients, but there are many more.

What disturbs me is that this project has 14 Open Pull-Requests and 31 Open issues (as of this writing on 2023.05.05) the last commit on the project was 2022.03.15, more than a year ago. 8 of the PRs and 10 of the issues were opened since the last commit.

The issues indicate that people are using the package and the PRs indicate that some people are willing to help improving it. However, the developers/maintainers don't seem to respond. (Though admittedly I have not checked if there were any responses to the issues and the PRs, but I guess if there was any activity we would also see commits.)

What's the status?

So what's the status of this project, why are contributions no dealt with? Have developers/maintainer moved on to some other project solving the same problem? Have they deprecated this project - at least for themselves? If so, I think it would be nice to add this information to the README so others who use this project can also move over.

Do they still use the project but don't have the time to deal with its development?

What could all the users of this package do?

Assuming this is still the best solution for the problem, what could users do?

People who need some of the fixes can make those fixes and use their own fork of the project using the same name.

Forking the project and changing its name is possible, but with most projects that would not be easy and besides if this package is actually not a direct dependency of my code then the intermediate packages also need to be changed to use the new name. A huge can of worms.

I think the ideal would be to become a maintainer of the project. That can be a lot of work, but way less than forking and renaming the project. It would be also a lot more valuable to the community than if the project was forked.

In a nutshell I think the continuation of the project is the question here. How can the original developers or the current maintainers make sure that the project can live on even after they move on?

End of rant

Anyway, I am not sure what is the solution, but there is a problem.

So what do you do when you encounter a project that you use but that has not seen any development activity lately?

Top comments (9)

perldean profile image
Dean Hamstead

I think this problem is accruing in all languages. CPAN is just the oldest repository and Perl doesn't have a standard library so you have to deal with it for things that IMHO you really shouldnt (like JSON and CSV... sigh... but i digress)
Some random thoughts:

  • if youre an author and the thing your library talks to goes away or becomes completely broken (like a webservice going out of business or ditching its v1 api that your library used) - then you should delete it entirely from CPAN and mark it as dead in github. Delete it from github if you like, although i think its kinder to leave it up with a notice of why its been marked as dead
  • Repos like CPAN are sort of a dumping ground. CPAN doesnt have any release signing at all, nor do any of the tools check CRC's on tarballs. So its basically inferrior to most warez sites that at lease publish the SHA signatures of the rar files. Even torrents check the file integrity.This is a known problem thats not entirely specific to Perl's CPAN. Node's NPM has had some real problems.
  • From the above problem, google has announced its "Assured Open Source Software" initiative.
  • I do think its utter and complete clowntown to just cpanm stuff from cpan and run it in prod.You're literally just running some random persons code in your production environment without vetting it at all.
  • Whilst its attractive and popular to perlbrew then cpanm to avoid using "system perl" - your distribution's perl packages and perl libraries are signed and checked when installed. The package maintainers are also actively managing CVE's so you don't have to. Do you know what CVE's are open against your perlbrew'd perl version in your prod?
  • I would like to see CPAN itself become more opinionated and proactive in managing the software it holds. What that would look like is interesting to discuss. Obviously signing releases and checking SHA's would be a good start. But i think that we can the system itself could set a higher bar for inclusion of software (checking all tests work before indexing for example) and it could start to hide old releases from search.
phlash profile image
Phil Ashby

This is an interesting problem and not just in software, we're talking about the sustainability of things that require people to continue to commit time and energy over a long term (possibly a long tail - the distribution of attention required follows a very familiar curve..). My thoughts:

  • It's entirely a people problem.
  • It's related to succession planning / handover.
  • There are organisations that operate a business based on it (eg:
  • There are individuals who want to maintain things, and have made a career out of this, on their own terms (eg: - aside: I'd love to be one of them!
  • Open source projects that become useful would do well to have published succession planning in place - this alone would greatly increase confidence in depending on them.
  • Succession planning does not have to wait for the originator / current maintainers to decide, contributors can provide this input while a project is still active, since they will have the ongoing interests, a silly example from the LKML concerning Linus from 2018 (it's long!):
  • Assuming we already have a dependency on a project that starts to rot, then it's a risk management problem, with the usual risk treatments (these from ISO27001):
    • Accept it - do nothing and accept the risk of something eventually going bad (CVE anyone?)
    • Avoid it - migrate to a fresher equivalent if one exists, leave the rotting corpse behind.
    • Mitigate it - commit time and energy to maintain the project in lieu of it's originators, this could be simply a fork and take it all on approach, or it could be paying others to look after it (see above!), or forming an organisation with other dependees and sharing the costs.
    • The choice depends on the uniqueness of the project, your level of dependency, and your long term strategies. The choice is not set in stone either, for example: an organisation can opt to maintain a dependency while they engineer their way out of it.

Rant over - can you tell I used to do this regularly in the old day job?

szabgab profile image
Gabor Szabo

Some excellent points and links here. Thank you!

sentientmachin3 profile image
Davide Bianchi

Fork n republish is the way my friend

szabgab profile image
Gabor Szabo

How many times have you forked and how many times have you found and used such a forked version of a project?

sentientmachin3 profile image
Davide Bianchi

Forked never, but I used forked versions of the base repo a couple of times, mostly for versioning reasons

Thread Thread
szabgab profile image
Gabor Szabo

How did you find out about the fork(s)? Did this mean you installed them from GitHub? Could you link to the projects you mentioned?

Thread Thread
sentientmachin3 profile image
Davide Bianchi

Most of them are published on the npm registry, here is an example:
This component is not maintained anymore and doesn't work / works partially on newer angular versions, there are a lot of forks that address this issue.

tiegz profile image
Tieg Zaharia • Edited

I definitely feel like this question doesn't get discussed enough in the dev community (for example, see this "unmaintained" search in GitHub).

We're trying to address this from two sides at Tidelift:

1) Pay maintainers (we call them "lifters") to keep packages up to date (and perform certain basic duties, like enable 2FA or address CVEs)
2) Offering companies a tool that lets them set standards on OSS dependencies. e.g. if you add a dependency to your Gemfile.lock or pom.xml, we'll tell you if it violates one of your own rules, like "this project hasn't been active for X days" or "this project has a conflicting license" or "this project has CVEs that haven't been addressed".

Speaking of package deprecation, I wrote up a summary of how it works across ecosystems a while back: