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)
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:
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:
Rant over - can you tell I used to do this regularly in the old day job?
Some excellent points and links here. Thank you!
Fork n republish is the way my friend
How many times have you forked and how many times have you found and used such a forked version of a project?
Forked never, but I used forked versions of the base repo a couple of times, mostly for versioning reasons
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?
Most of them are published on the npm registry, here is an example: github.com/akveo/ng2-smart-table
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.
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: dev.to/tidelift/the-current-state-...