Why? It's either useful or it's not, and if it is and it's open source you can take it and use it or enhance it as you like.
If your use of open-source code is predicated on the expectation that someone else will always be there to take care of it, then you're just a freeloader.
It really depends what ecosystem you are in. For example, the nodejs/npm ecosystem is on a never-ending cycle of package upgrades. If a maintainer is not maintaining a package, it will eventually have to be replaced for one of the following reasons:
1) One of the package's dependencies has a breaking change which breaks the package
2) One of the package's dependencies has a security bug. The dependent package cannot be upgraded to a fixed version because the dependent package's fixed version has a breaking change which breaks the original package.
Basically, ecosystems which do not have strong backwards compatibility tend to require packages/libraries/creates/assemblies/DLLs to be maintained forever.
That seems like a really good reason not to use that ecosystem. It's not the fault or the problem of the person who created the open-source project. If you choose to use open source code in a system like that, then that's what you've chosen.
the maintenance is not a small part of the usability of a software
> it's open source you can take it and use it or enhance it as you like.
No, I need to have the ability and the time to do so
> then you're just a freeloader.
I don't remember the part in the free software licence that doesn't allow me to chose to use or not use a specific software or a clause that force me to take over it's development in case the original dev abandon it
I agree with you. That being said, I also suspect there are a lot of rude and entitled people who treat maintainers poorly. Here are my thoughts:
1) Be polite - Open Source developers and maintainers are incredibly generous, and they should be treated with respect.
2) Treat maintainers with respect - For example, instead of asking if something is dead, try writing something like "Are you still working on this project? Would types of issues will you fix? Security bugs? Serious bugs? What else?"
3) Give back - If you depend on a project, ask the maintainer if there is anything you can do to help?
4) Consider giving money to the maintainer as a thank you. If you really like a project or really depend on it, you should probably give the maintainer some money. There are two reasons for this. First, it shows you appreciate their work. Second, it encourages them to keep on supporting the project.
5) Let maintainers know that you appreciate their work. Also, let them know what you like about it.
One thing I think a lot of people are not thinking about is real people work on open source software and these people have limitations, desires, likes, etc. They are not meat bags which create software because users demand it or feel they are entitled to it.
I've been on both ends of this. People who aren't paying me for code are upset that I'm not providing an endless stream of useless stuff; and code I rely on is seemingly abandoned and I'm cautious before using it.
The polite thing to do is to check in on the status, in a public setting, and get an answer from the maintainer, which is what this person is doing. Yes, it's entirely possible that there's nothing new to add to it, and it's "done." But what if there is somehow some sort of major change to OpenAI's API, or they deprecate [current API version] and you're expected to migrate to a new one? Or, worse still, a major exploit is found? These are valid concerns that even free users would want to know, and the best way to do that is to check the pulse of the project.
The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it. Also worth mentioning is the user who commented saying there are "relevant and important" PRs and issues that haven't been addressed over the last year. Whether they're relevant and important, I don't know, based off my experience I'll say likely not... But the fact that you're allowing irrelevant and non-important things to go stale, without closing them, only lends credence to the possibility that the project is abandoned and, if something were to go wrong in the future, nobody would be around to fix it.
Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now. They asked what the status was before putting in the work to fork it and attempt to move users away from your project. That is a courtesy notice, not a threat, designed to save everyone time and frustration.
It is a good thing for someone's open-source code to have interest by the community, and for users to want to use it. Getting angry at those same users for checking on the status won't do any good.
> But what if there is somehow some sort of major change to OpenAI's API, or they deprecate [current API version] and you're expected to migrate to a new one? Or, worse still, a major exploit is found?
The more constructive open source move would be to file an issue explicitly noting "the upstream dependency may breaksand there will need to be changes to accomidate it" or "there is a zero-day that needs to be fixed ASAP" instead of "is this repo dead." In the former case, others will have more information and it saves the maintainers time.
Many of my other projects have had people do that and I've been very greatful.
> The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it.
"What's the status of development?" or "Will this incorporate X feature coming up?" is polite and gives enough information on aliveness. The comment I screenshotted is passive-aggressive at best, and there's no really good way to ask "is this repo dead" without being passive-aggressive. My day-to-day job that actually pays me a salary wouldn't ever provide a bulleted list of the reasons I suck, let alone a project I develop in my spare time.
If I mass close stale unimportant issues/PRs the argument would then be "you don't want issues/PRs so no reason to contribute." Lose-lose situation.
> Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now.
I would definitely not be frustrated (assuming that they give proper license/credit to the source code which is a different issue)
The fork comment wasn't directly related to the screenshot, but was a part of other discussions over the years where people say "I'd use a fork but the forks aren't as popular" which becomes an annoying Catch-22.
> The comment I screenshotted is passive-aggressive at best
It's polite and it asks questions that are very pertinent, given how you claim to manage your repos.
> How can the community support?
I've been involved in a project that accepted drive-by PRs and I get that that sucks. You know what helped? People who asked how they could tick something off my personal todo list before they tried to crowbar their pet feature in.
> Can we expect development by the maintainer?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo?
All of these questions really just ask the same one: should I fork your repo if I want to make a change.
Your very next point discusses a repo where you don't accept PRs, don't reply to issues, but also refuse to say it's not being "developed". You literally ask for PRs in the README.md, but then ignore them? Are people supposed to figure out that you think it's perfect as-is and doesn't need more input in contradiction to that?. All of the questions other than #2 are literally just trying to get you to put that in writing.
Forks suck. There's no if's, and's, or but's.
At best the original project is dead and the fork goes on to be kind of a successor. But it never really will be, because 90% of people will stay on the original, 5% of people will move to the fork, 18% of people will post on both repos about how it's unclear which one they should use, and 7% of people will post on the new repo threatening to sue because they found a similar-sounding project in some disclosure and they don't agree to your imaginary terms that allow you to sell their private info to the Illuminati.
But the worst is when the original project isn't dead. You go and do a significant amount of work to fork it, and then the original author comes back with some pretty major changes that completely break the foundation of your fork. Now you're stuck on a legacy fork, or a ton of work to rebase onto the core library. If other people are depending on your fork that's a difficult question to answer.
This email is basically asking "should I go and do all of that work?" in as polite a way as possible. If you put together a canned response (cough CONTRIBUTING.md cough) that would solve 100% of this:
> Thanks for your interest in contributing. I think this project is pretty complete as-is. If there are breaking changes or zero-days that come up, I plan on fixing them. Otherwise I don't expect to approve many PRs. If you feel you need to get a change in, feel free to fork the repository and make your change there.
Forks don't suck, BSD is a fork. There would be no linux without forks. Libreoffice is a fork, when is the last time you ever heard somebody say the cursed words "open office"? Probably about 15 years ago, when it was forked. Forking is normal and encouraged. Fork for literally no reason, all the time. It's fine.
Another prominent example KHTML forked to WebKit forked again to Blink.
I understand both points of view. Ideally if you decide to fork it and you're willing to take it up then leave a note in the issues on the original mentioning the fork. The original might decide to point to your fork or at least others can go look if your fork looks like a better fit for their needs.
> The comment I screenshotted is passive-aggressive at best, and there's no really good way to ask "is this repo dead" without being passive-aggressive. My day-to-day job that actually pays me a salary wouldn't ever provide a bulleted list of the reasons I suck, let alone a project I develop in my spare time.
There is nothing passive-aggressive about that comment. There is nothing problematic about it at all. Nobody's calling you slurs or making demands. I see one guy who might as well be a Mormon Boy Scout from Canada. "Is this repo dead" is not passive-aggressive, just ineloquent. Fuck my eyes until the jelly leaks out my ears if a courteous and professionally-written question constitutes "applying pressure and being rude" these days.
I don't know what a "bulleted list of the reasons [you] suck" has to do with anything (I don't see where anybody sent you one) but you're coming across as someone who invites people to your garage sale and then brandishes a shotgun and starts screaming when they set foot on your property.
> I’ve never seen any discussions or articles about whether it’s appropriate to ask if an open source repository is dead. Is there an implicit contract to actively maintain any open source software you publish? Are you obligated to provide free support if you hit a certain star amount on GitHub or ask for funding through GitHub Sponsorships/Patreon? After all, most permissive open source code licenses like the MIT License contain some variant of “the software is provided ‘as is’, without warranty of any kind.”
Here's an example of why everyone should ask if an open source project is dead:
A number of issues complain about it leaking OpenAI keys. Nobody's figured out how, but it'd be nice to know if anybody's working on it, if it's worth submitting a PR, if it should be forked, if it's worth bothering with at all. This code is a massive liability in its current state. Its creator is absent. It warrants questions being asked about its future. Yeah, it's as-is software, but it's not an affront to your mother's virtue when someone asks if your shit still works or if you have plans to fix it. Nor is it a call for you to offer free labor.
> I’ve had an existential crisis about my work in open source AI on GitHub, particularly as there has been both increasingly toxic backlash against AI and because the AI industry has been evolving so rapidly that I flat-out don’t have enough bandwidth to keep up
Herein lies the problem? You sound overwhelmed. I've been there myself. I don't know what your year's been like but you genuinely might want to get away from the screen and get some fresh air. This is a good time of year to do it, since things generally slow down at work.
I agree with you, and it’s why I stopped posting on Github. It was called “social coding” after all. I got tired of people asking me to fix stuff. But rather than complain about people asking, I just removed it from Github.
I used to think the world would be worse off if more people do what I did by removing code they don’t want to maintain. I don’t think that anymore. There are enough people and businesses who, for various reasons, want to maintain free (in both senses of the word) software. I don’t think the marginal people like me - the people who don’t want to maintain, and who don’t want to be nagged - really contribute more than negligible value.
I make stuff to scratch my itches. I stopped being so big-headed as to think that others need to see that stuff. But if I really wanted to post it, I’d put it on a website, probably under a pseudonym, with a warning not to nag me. Not on Github.
True. But I’ve concluded it’s disingenuous to post on a place labeled “social coding” and then say: leave me alone. It would be like posting on HN and saying “do not respond to my comment.”
I think those who post PRs and messages on GitHub are not entitled to any response. But I can understand those who think it’s rude not to reply. I would rather not reply. So there’s no reason to post in the first place.
GitHub is more like a city there are different places, open stores, private building, parks.
Everyone can go into stores.
Repo that is promoting themself on GitHub or other websites.
No one will go into your private house that you don't want into it.
Private repo or repo with no readme , description or topics.
If you have a park with trees that look nice, maybe some people like it too and wann chill on it, if you don't want people on it write a shield private or do not step on the grass.
Repo that is willing to be used by third parties, as other are interested into it as they see it.
You don't want something write a rule into readme.
Yeah, I think it's a little ridiculous. You can opt to turn off issues if it's such a big deal having someone ask politely if the project is still maintained.
Yes, open source maintainers aren't obligated to do anything. Doesn't mean that asking if a project is dead or not is rude or problematic.
agreed. the author is overtly insecure and projecting animus that isn't even remotely there. the post is all but a textbook example of how to ask if a project is still active or dead, and the response has only exposed how poorly the author views himself and his management of the project than frame the questioner as a villain. i think your assessment is accurate and the author would benefit from some time out. don't put so much pressure on yourself and then assume everyone else is piling on when you're beating yourself up
I've been publishing code on github for what feels like a decade and i have never felt that anyone taking the time out of their day to write a message to me via the issues page is rude. I think you're the rude one, if you don't want public interaction mark your repos prvate.
Perhaps something that could you help is adding an H1 to the readmes like "This project is finished, not being developed", with some explanation like "Unless you found a security vulnerability, your issues and PRs may be ignored or receive delayed responses. Feel free to fork this repo if needed. Please do not ask if this is dead."
This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.
Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed
Perhaps it'd be good to have a template that open source projects can use to set expectations, or a badge or something. Based on your suggestion it could be something like
I consider this project
- actively developed
- a toy
- finished
- still interesting to me
- no longer something I expect to progress
I will / will not review PRs [unless they are Security / some category].
Your best option if you would like changes is
- raise a PR
- ping me
- fork it
- use a different project
- pay me
My attitude to forks is
- The more the merrier
- A necessary evil
- I'd like to avoid them for this project if possible
- Not allowed by the license
> My day-to-day job that actually pays me a salary wouldn't ever provide a bulleted list of the reasons I suck, let alone a project I develop in my spare time.
The questions you received were:
> Can we expect development from the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
This is far from a "bulleted list of the reasons I suck". Whoever asked this cared about your project and its future. They just wanted to know what was going on. They might have been intending to contribute patches to you: they specically asked if you were accepting pull requests for review. It's extremely frustrating when you send a patch in and don't get a response.
This was my approach when I received similar questions:
Open Source projects that don't appear to be be in continuing development are probably better thought to be 'in stasis' rather than 'dead'. They can be picked up and worked upon at any time by anybody, even if many years have passed since they were last developed.
Then again, maybe there is no ongoing development, but the application is being used on a daily basis. Could you class something in everyday use as being 'dead'?
To most people in the world, the Usenet News Reader 'Tass' (remember Usenet?) is still stuck on version 3.6.4 from around 2006 and would be considered 'dead'.
Looking through my archives, I see that I developed my internal-use version 3.7.0 in January 20014, and version 3.7.2 in April 2017.
So ... is the 'Tass' Usenet News Reader 'dead'? Or is it not?
I’m not sure this fits my experience. Once a project starts to lose momentum, not many turn that back around. “Code rot” is a real, if nebulous, thing. As less people regularly contribute, there is lost internal knowledge as to why certain decisions were made, roadmaps, what the core problem the library seeks to solve, etc. Basically OSS projects are as much the maintainers’ ambitions as they are the code themselves.
Personally I am (I think rightfully) hesitant to use a library that hasn’t had a commit in years. Similarly, downward trends in usage are also a pre-indicator of a library’s long term health, as it can signal lack of user trust, better competition, or just that the original need isn’t quite there anymore.
So you’re right that it can be picked back up, but I think in practice this is far from the most common outcome.
While I agree lack of experience or internal knowledge is a problem for complex projects (ahem, etcd), most "dead" open source libraries IME suffer from these two properties:
1. the people with the commit bit in the original repository are all gone
2. people fork the repository to fix one minor thing, and never update again
I've frequently ran into libraries where there are multiple forks with no activity, and it is not obvious whether there is a "best" choice of fork, and it is unlikely that the next fork will become the successor to the original project.
There's a certain social problem that I can't describe very well. Projects should have a form of "succession planning" or else they end up in the state I just described (impossible to commit to the original repo, numerous inactive forks that merged 1 or 2 stale PRs).
2) is exactly what happened to the Python docopt project. It works well for most users but some corner cases trigger annoying bugs that are not fixed because the maintainer is mia. Lots of people have fixed the bugs in their own forks of docopt, but as there is not clear which if the forks is the "successor" to docopt, people keep running into the same bugs and keep forking over and over again.
Is that actually challenging? My MC launcher can pull in 1.7.10, add a mod loader, and load mods into it just fine. Do you mean if you try to run a 1.7.10 mod in a modern MC version? That's not a realistic goal because of dramatic API changes between versions. There are a number of breaking versions that require basically rewriting mods. But you can still play the on the old version and most modded minecraft players are many breaking versions behind by default. This is the norm in most games, where game updates are routinely expected to break all backwards compatibility. And considering modding minecraft has never been officially supported, it's surprising it works as well as it does.
I'm playing a 1.7.10 pack lately actually, still just as good as when it came out!
I’ve never liked the “code rot” euphemism. Code doesn’t rot. What happens is platforms change out from under your code by platform vendors who no longer give a shit about backwards compatibility.
If you take a piece of application software, tar it up including its dependencies, you should be able to untar it 15 years later and it should compile and run. If it doesn’t, it’s not your fault as a developer—it’s the fault of everything else that changed and broke that previously working code.
If vendors took compatibility seriously, we wouldn’t have “code rot”.
I'm not sure what a better term is, but I think the problem will exist anyway. 15 years of backwards compatibility from software that's often written by volunteers is unreasonable to say the least.
>15 years of backwards compatibility [...] is unreasonable to say the least
As a Windows user, it's sad that so many people think that way nowadays.
I've encountered one DOS program from the early 90s that doesn't run anymore because it used its own custom memory management which newer systems don't allow, but that one was later re-released in an updated version that still works today. And there were one or two late-90s Windows programs that no longer run either because they have 16-bit components or depended on some then-standard now long-gone libraries to be on the system, but those run in a VM.
Other than that, there is plenty of software dating back to the 90s, some to the 80s, that mostly still works fine. It doesn't need constant maintenance and updates. It worked about 30 years ago and still works today and should still work tomorrow. You'll find even older legacy code in major organizations that's still chugging along.
That's hard to find in modern software. Now everyone always has to have the latest thing and it has to be updated almost every single day just to keep a massive chain of transitive dependencies from collapsing out from under it.
I guess that's why people get rude and ask whether a project is 'dead' even though patches have been released for it multiple times within the last 10 years.
I’ve run into this with a niche but fairly popular open source program. It had been used by big tech cos for years, while the maintainers moved on one by one until the last guy who seems to have thrown in the towel in 2020.
I considered picking it up, but I’d have to make some hard decisions about the code base that wouldn’t make everyone happy, and I just don’t have the context to do that. Another issue is the lack of testing infrastructure.
So for everyone who still cares, the path of least resistance is to maintain their own fork or do a rewrite in a different language.
> They can be picked up and worked upon at any time by anybody,
There is/was a clojure library for Apache Spark. It stopped being maintained. In ensuing 9 years, the tooling it uses has completely changed, the 3rd party libs it uses either changed or stopped being maintained and underlying Spark changed a great deal.
It would be less effort to start over than try to pick it up
> They can be picked up and worked upon at any time by anybody, even if many years have passed since they were last developed.
Assuming it's maintainable and not the illegible scrawlings of someone crazy, sometimes software is just some random folk in Nebraska's pet project and it's been dropped for something shinier/they gained employment.
But isn't the Github archive function for exactly this use case then? I have asked maintainers that haven't updated their repo in years, whether this project is actively maintained or can be archived - archived says exactly that: this repo isn't developed any further, but you may still use it.
I once heavily relied on a project called Prisma. Our business depended on it as did others.
Then suddenly one day they have decided to completely remove a few crucial feature without much warning and release a version 2, without giving any sort of alternative to those great features.
They stopped support for prisma 1, deprecated the packages, changed whole codebase and links, features and so on.
It was open source project but at a very large scale where their change impacted thousands of businesses. A lot of people wanted to sponsor or support ongoing development of prisma 1 until the similar functionalities have been developed on prisma 2. But their repo, their rules, their business decisions. Which I respect. Nothing to do there, except accepting and moving on and creating alternative solutions.
It was devastating for me personally. Took me half a year to refactor a lot of code in a lot of different projects that were purely business logic dependent on prisma 1. And I couldn’t do anything as a solo dev at that point.
What could I do? I waited and created alternative solutions until we get official ones.
...
I still use prisma. Its a great piece of tool, backed by a the awesome community and team. They are doing wonders.
But the incident taught me a different reality of open sourced projects.
I tried to connect that case with the post and thinking back, I think you are right, and at same time, you could ask for sponsorship for your time, or share your situation instead.
People have expectations. Its what keeps them connected and growing.
>But their repo, their rules, their business decisions
Was it not BSD or GPL or some similar license? If so someone could just fork it while ignoring their rules and business decisions (as long as at least one other person had the code I guess).
Not OP, but looking at the products GitHub, Prisma uses an Apache license. Regardless, I don’t think whether the ability to clone and own is the issue, rather the question is: do you want to take on the scope of maintaining a library or other piece of software that’s not at the core of your business?
Maybe you’re a developer who can keep account of multiple layers, or all layers in your stack. If so that’s great. But we’re all limited to varying degrees and there’s only so much one can do. Really, you need to find reliable partners who can own some of that complexity for you.
In OPs case, they picked a partner that was not reliable. They paid for it with more maintenance. But this is what you get with open source. You can get it for free and you can set it up fast because you don’t need to negotiate contracts, but your dependencies are under no obligation to support your use cases.
I guess my interpretation of "A lot of people wanted to sponsor or support ongoing development of prisma 1 until the similar functionalities have been developed on prisma 2." was that they had some sort of team potentially ready to go, but perhaps they were stopped by an "open source" license that wasn't a "free license" or whatever.
But yeah I get it, too much of a pain, too unrealistic, etc.
Of course, open source software is not the only thing at risk of this, seems like most modern software gives you little control over what version you use.
Dependabot kinda helps here. If you see a bunch of issues opened for upgrading dependencies for months+, it's probably a dead project. You can always fork it though and take over maintenance if the license allows.
IMHO there's never "dead" when it comes to software. It's just "done".
I don't know who came up with and propagated the notion that software needs to be constantly "in motion" and perpetually changing (perhaps to justify their continued employment?), but it's an irritating trend.
Uhh . . . because it's 2023 and no software exists on an island? OSes evolve. Dependencies evolve. Literally everything in industry is constantly changing, be it for compliance reasons or because the foundational architecture (language, build pipeline, etc.) is changing. Put software on a shelf and it will rot. "Maintenance mode" is not feasible for any credible corporate application or FOSS project.
>"Maintenance mode" is not feasible for any credible corporate application
Tell that to the banks, government, and companies still running software older than I am. And for which, on the rare occasions when maintenance is needed, the developers are likely using tools older than I am to do the maintenance. (I'm middle-aged btw.)
It's been a nice 23 years since the major Y2K projects, and we've still got 15 more until we really have to hustle on the Y2038 projects.
Preach! Open source maintainers don’t owe non-paying users a thing. Open source isn’t a cheat code for getting work done for free. It’s a means of sharing work that was already done so that it doesn’t need to be done again by others.
I think this is the wrong attitude. Users of software and contributors (even potential ones) don't owe anything either. In fact, no one owes anyone anything when no paid contract is involved, so everyone should just relax and get out of that adversarial mindset.
I've been a bit upset (more confused) myself as a user/contributor when I've spent hours or even days debugging something, clearly and politely communicating the issue or bug, and then it gets immediately closed with something like "we're just volunteers" as if I demanded something by merely pointing out an issue (that I offered to help with!). What does being unpaid volunteers have to do with any of that? It's just knowledge and information I have reported, but then I have to deal with a maintainer getting upset because I simply used their advertised library, one they advertised on their CV, in talks, in books, etc.
I was wanting to start being a regular contributor, so what's the point of treating a potential contributor like that? I'm not totally sure I get it. They don't owe me anything, and I'm also fine with their library willowing away into obscurity and going off and doing my own thing.
Sure... but asking if a project is being maintained like in the first screenshot in the OP isn't being entitled or rude or even asking for work for free. I looked at the thread that the second screenshot comes from and I would honestly say the OP didn't reacted well to someone asking if there was a recommended active fork and then someone else reacted even worse to the OP's comment.
Honestly feel this reflects poorly on the OP more than anything else.
Anecdotal evidence here, but one thing I've found interesting as a Clojure(Script) developer is how projects with one commit in the past year are considered active by most of us, whereas in the JavaScript and Python world, it seems that a few months without a commit makes people start asking if the project is abandoned.
On the flip side, one thing I dislike a lot about the Clojure community is when people say "sometimes software is complete and there is nothing else to do" as an excuse to tolerate libraries that have gone unmaintained for years. Again, anecdotal evidence, but half the time I hear "the software is complete", I end up finding a bug in said software.
Lastly, this paragraph summarizes a bigger problem with consumer behavior in open source:
The best-case scenario for asking if an open source project is dead is that you annoy the maintainers and delay development. The worst-case scenario is that you give the maintainers an opportunity to reconsider if continuing to work on the open source project is worth it.
People seem to forget that the vast majority of open source projects are thanklessly maintained and it is annoying having to deal with e.g. people who blatantly ignore instructions in your README, file an issue resulting from said negligence, then open a pull request to "fix" this problem that can be avoided by simply following instructions in the README. (I have had this happen in a few projects I maintain). One of my friends calls this style of PRs "drive-by PRs", and I wouldn't be surprised if most of the PRs in the author's project are just that. I want to say the author slightly alludes to this situation when stating
... accepting a misguided PR will create technical debt and take even more effort to address.
I am sorry to hear about the author's issues, but I do think it's a little dramatic to call this being rude and applying pressure. The person pretty clearly stated some basic and legitimate questions, offered support, etc.
I think it would behoove open-source developers who are sensitive to dealing with potential users and collaborators to more clearly state and set expectations on the repository's README. Many authors clearly like to use open-source packages they maintain as a sort of professional portfolio, which is perfectly fine, and this author even asks for paid support at the bottom of the README. Is it really out of line to ask about the status if it is not otherwise clear?
All of these little scuffles from maintainers towards contributors and users are often from lack of communication and expectation setting on the side of the maintainer(s) and code owner(s), although contributors and users can also be demanding. I think the issue is that everyone has their version of expectations in their head but not everyone shares those. It's the same as with any human communication, so the more information the better.
I think there is a bit of a mismatch between advertising code, asking for paid support, etc. and then being upset at activity in the repo without more clear guidelines. I have seen plenty of repositories that very clearly state that they won't accept pull requests, they won't accept anything but the simplest of bug fixes, that this library is really just for the author's use but it is being open sourced in case it's useful to someone else. That's a good example of setting expectations that provides more context than pointing to a license.
This was my take as well. It seems like the author did the bare minimum to communicate the state of the project and is now complaining when people don't understand the situation. For all the anxiety they feel, it could have been prevented with just a minute's worth of effort.
I think the author is going through a tough time and probably just needs to step back from software, especially with the implied pressure being felt. We've all been there, in varying degrees, and software and technology is the least important thing in our lives.
But there's some general commentary here that I think is applicable to maintainers appropriately setting expectations that contributors can abide to or be held to when interacting with the given projects.
That first screenshot is an incredibly polite comment from someone also willing to offer help to the maintainer.
In my opinion, it's perfectly reasonable to ask if a project is still being maintained. I often come across packages that have had no updates in a year, and it's hard to know if that's because they aren't being maintained, or if they are being maintained and no updates have been required.
I hear the argument from some open-source maintainers that they have no obligations to the people who use (and depend on) their software. But there are lots of open-source developers that actually want people to use (and to depend) on their software. Being an open-source developer of a widely-used application or package can bring great benefits to the developer - at the very least it garners them respect from the community and potentially from future employers, and in some cases it can lead to huge financial rewards: acquisitions, great career prospects, paid trips around the world to speak at conferences, etc.
It's definitely more of a two-way street than some developers would lead you to believe.
Quoting people out of context? Tsk, tsk. I thought we were all adults.
Why didn't you post the whole comment?
> I really like the philosophy and design of this package but it appears its development process has basically stopped. I don't mean to pressure or to be rude but if @minimaxir could share his thoughts on this I would really appreciate it.
> Can we expect development by the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
Stay stressed long enough and paranoia starts clouding your judgment.
He seems burned out over trying to keep up with the fast pace of AI development (which is understandable). He's clearly putting inhuman amounts of effort into whatever he's doing and it's wrecking him, so I'm guessing he's perceiving questions about his project's longevity because he hasn't addressed issues from six months ago as seeing vultures circling in anticipation of his imminent demise. He's giving it his all and he's being presumed dead after six months...what more can he give?
That's all totally ok and understandable, and I hope he takes some time off to relax in the next few weeks. But I also wish that he would take this article down. He's externalized his own internal struggle as authoritative-sounding advice proscribed to the community at large, based on his own misguided perceptions of perfectly-acceptable discourse. It's Toxic-with-a-capital-T.
> > I don't mean to pressure or be rude but if @minimaxir could share his
> > thoughts on this I would really appreciate it.
> To be perfectly clear, this absolutely is applying pressure and being rude.
It's really not.
I've been in open source development for two decades. It's not rude to ask if a project is abandoned. If asking that question causes somebody to quit, it's probably for the best.
This feels emotionally charged and I can understand why. The commenter in the second screenshot was definitely rude with their “Be realistic” comment, implying that you’re full of crap.
That being said, the first comment seems rather polite and considerate to me. Yes accusations of neglect are rough, but if that isn’t the case it shouldn’t be too hard to put a disclaimer in the README as to why the project isn’t moving much.
Your feelings are valid, but so are theirs (although in some case should have been expressed more thoughtfully). It doesn’t feel productive to dismiss their questions on the ground that you behave differently when faced with this situation.
On the topic of emotional charge: a lot of the terms used around this topic ("dead", "abandoned", "neglected", "ignored") are themselves emotionally charged and carry a lot of negative connotations, not in the least because they're often used when referring to sentient beings that feel pain. Loved ones die; children are abandoned; pets are neglected; cries for help are ignored. Even a lot of other similar words that don't carry that level of emotion still imply laziness or carelessness.
An open source project does not have any opinion or feeling about not being under active development, but people interested in the project might, and they can use those words to communicate their displeasure by evoking those feelings. But, I'd wager that there are just as many instances where no connotation or hard feelings are intended.
Words are powerful! If you are merely asking, maybe avoid "dead" or "abandoned" when "no longer actively maintained" will do. And if you're not merely asking and really do want to communicate your displeasure, maybe just don't.
I'd encourage independent open source maintainers to remind themselves that they don't owe anyone anything. If someone asks for something, it's perfectly reasonable to tell them "Sorry, I don't plan to work on this" and "PRs welcome" -- or even "sorry, I'm not accepting PRs, feel free to fork". If they get indignant about it, just ban them. You don't have to feel bad. You write your code for you, if others find it useful, great, if they don't, that's their problem and not yours.
It's really sad to see people decide they don't want to publish code because some strangers have weird expectations. Of course ideally those strangers wouldn't exist, but that's not something anyone can change... but it's perfectly OK to kick them out of your space.
I don't want to say I disagree with the author, what he says here is entirely valid, but I do have one suggestion to anyone facing this issue:
Make a practice out of README's having more context about who is behind this work (individual, team, etc), the status of it, and the desired outcomes. I think this helps not just to make it clear that users shouldn't have an expectation of support, but also if a solo project it will end and flow.
I think that this kind of becoming a requirement because open -source is in a really peculiar place and these sorts of issues are likely going to get worse before they get better.
It isn't just the number of open-source projects that is growing, but the variety in models and desired outcomes for open source that is diversifying, and in many cases, more towards where any project with traction is less likely to be a fun side thing for a smart dev and more seen as a 'product'
I am not sure how I feel about this trend overall, but I do know I have appreciated this sort of context in projects and it does seem to at least make it easier to close issues by pointing at those statements.
I feel like GitHub should have a better process in place to handle abandoned or poorly maintained repositories. It could be as simple as making actively maintained forks more visible in the UI? Or maybe having a more structured way for people to nominate themselves as maintainers?
GitHub allows archiving projects which have "read only" and "public archive" prominently displayed. When someone asked me about a project I wasn't planning on developing anymore, I replied to let them know and archived it.
It's a step in the right direction but it doesn't solve the problem of helping the community of users and contributors settle on a new maintained repo.
Yes that a way if you dont work on it anymore, but what if you still working on it but in another frequency or fixing only security issues and no new features will developed?
As a relatively prolific open source maintainer; there is absolutely nothing wrong with asking if a project is dead, abandoned, or otherwise stuck in the mud. Open source projects fall off every day, and there's nothing wrong with that or inquiring about it. If your project is dead, post a note on the README to that effect or explaining the current status. One can always put a call out for maintainers as well.
If a question like that, or critical comments in general, negatively affect your well-being, seek help and immediately disconnect or disengage. Alternatively, one can always disable Pull Requests, Issues, and Discussions for proper isolation and read-only code sharing.
In short, quit telling people how they need to be and take some personal responsibility for your well-being or mental state in the realm of Open Source Software.
Open source isn't for everyone, and that's fine, nothing to feel bad about. If getting questions of this nature is too much for you to handle, then creating a public repo on Github just isn't your thing. Accept that and move on with your life. Expecting people to avoid asking any questions at all that you don't like (such as the status of your project) is not realistic.
I think it's okay to ask if the project is dead, but when they start pressuring you like they're your PM it may be time to remind the users that the project is open source and that they have the option to fork it to work on it on their own and make their own version with what they think is missing.
Furthermore I think that this sample is exactly what can discourage an open source project maintainer to stop development and work on something else, maybe something closed and private, which is bad for open source generally.
So people need to be more patient and read the code of conduct of any project they want to interact with.
There's far more consumers than producers of open source, so that probably reflects the opinions in here defending the person asking if a project is dead.
Having dealt with a fair share of this along with bizarre interactions over PR's that leave me stressed out, my question to them would be: if the author simply said "no it's not dead", would you accept that as a closed issue?
Or are they expected to actually make some commits in response?
If you find a bug, security issue or dependency issue I will attempt a fix or accept a PR."
That is a closed issue. Maybe as other's have said put that in the readme but that's up to you, it might just prevent the same issue popping up in 5 months.
Fair call. My reasoning behind such a blunt "no" was that the question itself was short and blunt
Perhaps the person could have said:
> Hi, we at ACME Corp are planning to use this library but are not entirely sure about the current state of it, can you confirm it's still maintained? It would make my boss very happy, also thanks for your work, appreciate it :)
For native English speakers or western audiences being blunt seems rude, to some wasting people's time with fluff would seem rude or even might be be the best they can do.
Both sides can definitely introspect but I'm not on OP side on that one.
> One of the great things about open source is that if an open source project with a permissive license does become inactive, it can be forked seamlessly. Sometimes the fork can become even better than the original project, which is great for everyone! But in my experience, it’s instead used as a threat. And it’s the maintainer’s fault for creating a reason for a fork to be made and fragment the development community.
I understand the pressure open source maintainers are under (having been there myself), but the general advice has always been to fork a project if the maintainers can't or won't integrate PRs and fixes that you need.
If we can't ask questions about the repo's status, the backlog of legitimate PRs is growing without response, and even forking the project is considered hostile, that leaves no real options.
If someone wants to publish something to GitHub with expectations like this, it's better IMO to advertise them at the top of the README.md. Or better yet, don't publish a project to GitHub if you don't want to have to read GitHub issues and you don't want anyone forking your work.
> The best-case scenario for asking if an open source project is dead is that you annoy the maintainers and delay development. The worst-case scenario is that you give the maintainers an opportunity to reconsider if continuing to work on the open source project is worth it.
This is remarkably cynical. I've seen many GitHub issues asking about the status of a project that turned into constructive discussions about adding more maintainers, collaborating on future work, or coordinating a newly-maintained fork with an updated link in the README.md.
To say that the outcome can only possibly be negative or that spending 60 seconds responding to a couple legitimate GitHub questions (I checked, the repo has had 3 new issues in 2023) will significantly "delay development" is really negative.
If such simple communications are causing the developer to publish long rants on their blog and consider withdrawal from open source completely, I think there's something deeper going on. This long rant in response to a single legitimate GitHub question is more than the typical open source maintainer frustration.
Talk about overreacting. The user wasn’t asking for support or effort be sent their way, they just want to know if the project is active.
If you don’t want to interact with people keep the source to yourself.
Or maybe ask yourself why it isn’t immediately obvious that your project is active. I see a project with a low semantic version number and a release three months ago.
Nowhere in the readme is there any blunt statement on the current status of the project or what kind of state it’s in.
Some direct and affirmative language like that can go a long way there. Put info in the readme somewhere prominent and it would probably stop a lot of people from asking questions.
Tell us how when to raise issues or not. You can even tell people not to ask whether the project is active and they might just comply!
Calling that 'dead' and demanding status updates is the overreaction here. Unless you're paying this person to work on it full-time.
One of the bits of software I use has an update as recently as 2019, and before that 2015 and two 2013. It's clearly still relatively active. For software released in its current form in 1997, after being ported from an older version.
Even if modern software might sometimes need more frequent updates, it's still pretty demanding to insinuate death and demand status notes from an open-source maintainer just because they're not moving quick enough for you.
If you look at the actual issues that ask about the development status, all the people who asked were really polite and gave the author of the tool best wishes as he works through his mental health. At no point would I describe those issues as “demanding,” just “inquiring.”
The people who asked those questions were greeted by a software author who lashed out at them. See for yourself:
One person who asked (rightfully, IMO) pointed out that all these questions are reasonable considering the project has sponsorship and Patreon links. The author is collecting $100 a month in Patreon and GitHub sponsorships, which is not nothing.
> Funny true story: a match on a dating app once asked to see my open source projects, and after I sent a link to one of my repos, she replied with a picture of the number of opened GitHub Issues and a emoji.
honestly, that sucks but also she mustve been interested enough to do due diligence, i see that as an absolute win
You can understand the other side too. Let's say you are looking for a project that fits your needs and you narrowed it down to a few choices with similar functionality and notice that one of them wasn't updated in a while. Is it wrong to ask if the project is still active in such case to decide it further?
As a developer running a company using an open source library my primary concern is, will this technology choice serve my project’s needs?
Happy to contribute to help but knowing that the persons who actually understand and took the responsibility to maintain a library are around, informs my choices.
It’s fine if you don’t want to fix problems in your library anymore, that’s your choice, I just won’t use that library—but I need to know what’s going on or else I can’t make choices for my own benefit.
Whether you like it or not, posting an open-source library is equivalent in my and many developers minds, to telling other people that they ought to use your code in some way. If the way you signal them to use it is as a dependency in their own critical software, by posting it to a package manager and hyping up the benefits of your design choices and code, I do think it’s kinda on you if people get burned by deciding to work with you, even if indirectly.
Communication is the point - if you don’t want people to expect maintenance of your software, say that you won’t maintain it, don’t put it on a package manager, or else people will get the wrong idea, because open sourcing and posting the code is also communicating something, even if in your case it’s unconscious and not what you actually meant.
108 comments
[ 3.1 ms ] story [ 174 ms ] threadIf your use of open-source code is predicated on the expectation that someone else will always be there to take care of it, then you're just a freeloader.
1) One of the package's dependencies has a breaking change which breaks the package
2) One of the package's dependencies has a security bug. The dependent package cannot be upgraded to a fixed version because the dependent package's fixed version has a breaking change which breaks the original package.
Basically, ecosystems which do not have strong backwards compatibility tend to require packages/libraries/creates/assemblies/DLLs to be maintained forever.
the maintenance is not a small part of the usability of a software
> it's open source you can take it and use it or enhance it as you like.
No, I need to have the ability and the time to do so
> then you're just a freeloader.
I don't remember the part in the free software licence that doesn't allow me to chose to use or not use a specific software or a clause that force me to take over it's development in case the original dev abandon it
1) Be polite - Open Source developers and maintainers are incredibly generous, and they should be treated with respect.
2) Treat maintainers with respect - For example, instead of asking if something is dead, try writing something like "Are you still working on this project? Would types of issues will you fix? Security bugs? Serious bugs? What else?"
3) Give back - If you depend on a project, ask the maintainer if there is anything you can do to help?
4) Consider giving money to the maintainer as a thank you. If you really like a project or really depend on it, you should probably give the maintainer some money. There are two reasons for this. First, it shows you appreciate their work. Second, it encourages them to keep on supporting the project.
5) Let maintainers know that you appreciate their work. Also, let them know what you like about it.
One thing I think a lot of people are not thinking about is real people work on open source software and these people have limitations, desires, likes, etc. They are not meat bags which create software because users demand it or feel they are entitled to it.
The polite thing to do is to check in on the status, in a public setting, and get an answer from the maintainer, which is what this person is doing. Yes, it's entirely possible that there's nothing new to add to it, and it's "done." But what if there is somehow some sort of major change to OpenAI's API, or they deprecate [current API version] and you're expected to migrate to a new one? Or, worse still, a major exploit is found? These are valid concerns that even free users would want to know, and the best way to do that is to check the pulse of the project.
The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it. Also worth mentioning is the user who commented saying there are "relevant and important" PRs and issues that haven't been addressed over the last year. Whether they're relevant and important, I don't know, based off my experience I'll say likely not... But the fact that you're allowing irrelevant and non-important things to go stale, without closing them, only lends credence to the possibility that the project is abandoned and, if something were to go wrong in the future, nobody would be around to fix it.
Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now. They asked what the status was before putting in the work to fork it and attempt to move users away from your project. That is a courtesy notice, not a threat, designed to save everyone time and frustration.
It is a good thing for someone's open-source code to have interest by the community, and for users to want to use it. Getting angry at those same users for checking on the status won't do any good.
The more constructive open source move would be to file an issue explicitly noting "the upstream dependency may breaksand there will need to be changes to accomidate it" or "there is a zero-day that needs to be fixed ASAP" instead of "is this repo dead." In the former case, others will have more information and it saves the maintainers time.
Many of my other projects have had people do that and I've been very greatful.
> The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it.
"What's the status of development?" or "Will this incorporate X feature coming up?" is polite and gives enough information on aliveness. The comment I screenshotted is passive-aggressive at best, and there's no really good way to ask "is this repo dead" without being passive-aggressive. My day-to-day job that actually pays me a salary wouldn't ever provide a bulleted list of the reasons I suck, let alone a project I develop in my spare time.
If I mass close stale unimportant issues/PRs the argument would then be "you don't want issues/PRs so no reason to contribute." Lose-lose situation.
> Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now.
I would definitely not be frustrated (assuming that they give proper license/credit to the source code which is a different issue)
The fork comment wasn't directly related to the screenshot, but was a part of other discussions over the years where people say "I'd use a fork but the forks aren't as popular" which becomes an annoying Catch-22.
It's polite and it asks questions that are very pertinent, given how you claim to manage your repos.
> How can the community support?
I've been involved in a project that accepted drive-by PRs and I get that that sucks. You know what helped? People who asked how they could tick something off my personal todo list before they tried to crowbar their pet feature in.
> Can we expect development by the maintainer? > Are you open to PRs and reviewing them? > What's your time commitment? > Should someone just fork the repo?
All of these questions really just ask the same one: should I fork your repo if I want to make a change.
Your very next point discusses a repo where you don't accept PRs, don't reply to issues, but also refuse to say it's not being "developed". You literally ask for PRs in the README.md, but then ignore them? Are people supposed to figure out that you think it's perfect as-is and doesn't need more input in contradiction to that?. All of the questions other than #2 are literally just trying to get you to put that in writing.
Forks suck. There's no if's, and's, or but's.
At best the original project is dead and the fork goes on to be kind of a successor. But it never really will be, because 90% of people will stay on the original, 5% of people will move to the fork, 18% of people will post on both repos about how it's unclear which one they should use, and 7% of people will post on the new repo threatening to sue because they found a similar-sounding project in some disclosure and they don't agree to your imaginary terms that allow you to sell their private info to the Illuminati.
But the worst is when the original project isn't dead. You go and do a significant amount of work to fork it, and then the original author comes back with some pretty major changes that completely break the foundation of your fork. Now you're stuck on a legacy fork, or a ton of work to rebase onto the core library. If other people are depending on your fork that's a difficult question to answer.
This email is basically asking "should I go and do all of that work?" in as polite a way as possible. If you put together a canned response (cough CONTRIBUTING.md cough) that would solve 100% of this:
> Thanks for your interest in contributing. I think this project is pretty complete as-is. If there are breaking changes or zero-days that come up, I plan on fixing them. Otherwise I don't expect to approve many PRs. If you feel you need to get a change in, feel free to fork the repository and make your change there.
Most forks don't even become relevant enough to be known
I understand both points of view. Ideally if you decide to fork it and you're willing to take it up then leave a note in the issues on the original mentioning the fork. The original might decide to point to your fork or at least others can go look if your fork looks like a better fit for their needs.
There is nothing passive-aggressive about that comment. There is nothing problematic about it at all. Nobody's calling you slurs or making demands. I see one guy who might as well be a Mormon Boy Scout from Canada. "Is this repo dead" is not passive-aggressive, just ineloquent. Fuck my eyes until the jelly leaks out my ears if a courteous and professionally-written question constitutes "applying pressure and being rude" these days.
I don't know what a "bulleted list of the reasons [you] suck" has to do with anything (I don't see where anybody sent you one) but you're coming across as someone who invites people to your garage sale and then brandishes a shotgun and starts screaming when they set foot on your property.
> I’ve never seen any discussions or articles about whether it’s appropriate to ask if an open source repository is dead. Is there an implicit contract to actively maintain any open source software you publish? Are you obligated to provide free support if you hit a certain star amount on GitHub or ask for funding through GitHub Sponsorships/Patreon? After all, most permissive open source code licenses like the MIT License contain some variant of “the software is provided ‘as is’, without warranty of any kind.”
Here's an example of why everyone should ask if an open source project is dead:
https://github.com/mckaywrigley/chatbot-ui/issues
A number of issues complain about it leaking OpenAI keys. Nobody's figured out how, but it'd be nice to know if anybody's working on it, if it's worth submitting a PR, if it should be forked, if it's worth bothering with at all. This code is a massive liability in its current state. Its creator is absent. It warrants questions being asked about its future. Yeah, it's as-is software, but it's not an affront to your mother's virtue when someone asks if your shit still works or if you have plans to fix it. Nor is it a call for you to offer free labor.
> I’ve had an existential crisis about my work in open source AI on GitHub, particularly as there has been both increasingly toxic backlash against AI and because the AI industry has been evolving so rapidly that I flat-out don’t have enough bandwidth to keep up
Herein lies the problem? You sound overwhelmed. I've been there myself. I don't know what your year's been like but you genuinely might want to get away from the screen and get some fresh air. This is a good time of year to do it, since things generally slow down at work.
I used to think the world would be worse off if more people do what I did by removing code they don’t want to maintain. I don’t think that anymore. There are enough people and businesses who, for various reasons, want to maintain free (in both senses of the word) software. I don’t think the marginal people like me - the people who don’t want to maintain, and who don’t want to be nagged - really contribute more than negligible value.
I make stuff to scratch my itches. I stopped being so big-headed as to think that others need to see that stuff. But if I really wanted to post it, I’d put it on a website, probably under a pseudonym, with a warning not to nag me. Not on Github.
Sadly, I didn't have the opportunity to maintain a relevant enough repo.
But, why not just develop at your own pace and simply not give a damn about complaints?
Maybe a README to clarify the situation, specifying that it's your project, you are doing it at your leisure, and that's all.
I think those who post PRs and messages on GitHub are not entitled to any response. But I can understand those who think it’s rude not to reply. I would rather not reply. So there’s no reason to post in the first place.
GitHub is more like a city there are different places, open stores, private building, parks.
Everyone can go into stores. Repo that is promoting themself on GitHub or other websites.
No one will go into your private house that you don't want into it. Private repo or repo with no readme , description or topics.
If you have a park with trees that look nice, maybe some people like it too and wann chill on it, if you don't want people on it write a shield private or do not step on the grass. Repo that is willing to be used by third parties, as other are interested into it as they see it. You don't want something write a rule into readme.
Yes, open source maintainers aren't obligated to do anything. Doesn't mean that asking if a project is dead or not is rude or problematic.
I'm not sure how to ask that won't in some way feel like either a demand for action or and accusation of abandonment.
Maybe just look at the commit history. If nothing has been committed in 6-12 months and if the code is not great as is then fork or move on.
I've written a couple of libs I consider done. They are still super useful but there's nothing I want to add for 2-3 yrs now. They are not abandoned
This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.
Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed
Yes, I do have inherent guilt for not updating my projects often enough.
I consider this project
I will / will not review PRs [unless they are Security / some category].Your best option if you would like changes is
My attitude to forks isThe questions you received were:
> Can we expect development from the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
This is far from a "bulleted list of the reasons I suck". Whoever asked this cared about your project and its future. They just wanted to know what was going on. They might have been intending to contribute patches to you: they specically asked if you were accepting pull requests for review. It's extremely frustrating when you send a patch in and don't get a response.
This was my approach when I received similar questions:
https://github.com/matheusmoreira/liblinux/issues/16
I think it's better to just be sincere and provide the necessary context.
Then again, maybe there is no ongoing development, but the application is being used on a daily basis. Could you class something in everyday use as being 'dead'?
To most people in the world, the Usenet News Reader 'Tass' (remember Usenet?) is still stuck on version 3.6.4 from around 2006 and would be considered 'dead'.
Looking through my archives, I see that I developed my internal-use version 3.7.0 in January 20014, and version 3.7.2 in April 2017.
So ... is the 'Tass' Usenet News Reader 'dead'? Or is it not?
Personally I am (I think rightfully) hesitant to use a library that hasn’t had a commit in years. Similarly, downward trends in usage are also a pre-indicator of a library’s long term health, as it can signal lack of user trust, better competition, or just that the original need isn’t quite there anymore.
So you’re right that it can be picked back up, but I think in practice this is far from the most common outcome.
There's a certain social problem that I can't describe very well. Projects should have a form of "succession planning" or else they end up in the state I just described (impossible to commit to the original repo, numerous inactive forks that merged 1 or 2 stale PRs).
This is especially common, for example, if you want to revive the source of a Minecraft 1.7.10 mod, say.
As more and more code build scripts pull in external things, the harder it is to get them running again years later.
I'm playing a 1.7.10 pack lately actually, still just as good as when it came out!
> if you want to revive the source of a Minecraft 1.7.10 mod
i.e. if you want to change/alter or recompile a mod for version 1.7.10
None of the things you have mentioned apply to this.
If you take a piece of application software, tar it up including its dependencies, you should be able to untar it 15 years later and it should compile and run. If it doesn’t, it’s not your fault as a developer—it’s the fault of everything else that changed and broke that previously working code.
If vendors took compatibility seriously, we wouldn’t have “code rot”.
As a Windows user, it's sad that so many people think that way nowadays.
I've encountered one DOS program from the early 90s that doesn't run anymore because it used its own custom memory management which newer systems don't allow, but that one was later re-released in an updated version that still works today. And there were one or two late-90s Windows programs that no longer run either because they have 16-bit components or depended on some then-standard now long-gone libraries to be on the system, but those run in a VM.
Other than that, there is plenty of software dating back to the 90s, some to the 80s, that mostly still works fine. It doesn't need constant maintenance and updates. It worked about 30 years ago and still works today and should still work tomorrow. You'll find even older legacy code in major organizations that's still chugging along.
That's hard to find in modern software. Now everyone always has to have the latest thing and it has to be updated almost every single day just to keep a massive chain of transitive dependencies from collapsing out from under it.
I guess that's why people get rude and ask whether a project is 'dead' even though patches have been released for it multiple times within the last 10 years.
I considered picking it up, but I’d have to make some hard decisions about the code base that wouldn’t make everyone happy, and I just don’t have the context to do that. Another issue is the lack of testing infrastructure.
So for everyone who still cares, the path of least resistance is to maintain their own fork or do a rewrite in a different language.
There is/was a clojure library for Apache Spark. It stopped being maintained. In ensuing 9 years, the tooling it uses has completely changed, the 3rd party libs it uses either changed or stopped being maintained and underlying Spark changed a great deal.
It would be less effort to start over than try to pick it up
Assuming it's maintainable and not the illegible scrawlings of someone crazy, sometimes software is just some random folk in Nebraska's pet project and it's been dropped for something shinier/they gained employment.
Then suddenly one day they have decided to completely remove a few crucial feature without much warning and release a version 2, without giving any sort of alternative to those great features.
They stopped support for prisma 1, deprecated the packages, changed whole codebase and links, features and so on.
It was open source project but at a very large scale where their change impacted thousands of businesses. A lot of people wanted to sponsor or support ongoing development of prisma 1 until the similar functionalities have been developed on prisma 2. But their repo, their rules, their business decisions. Which I respect. Nothing to do there, except accepting and moving on and creating alternative solutions.
It was devastating for me personally. Took me half a year to refactor a lot of code in a lot of different projects that were purely business logic dependent on prisma 1. And I couldn’t do anything as a solo dev at that point.
What could I do? I waited and created alternative solutions until we get official ones.
...
I still use prisma. Its a great piece of tool, backed by a the awesome community and team. They are doing wonders.
But the incident taught me a different reality of open sourced projects.
I tried to connect that case with the post and thinking back, I think you are right, and at same time, you could ask for sponsorship for your time, or share your situation instead.
People have expectations. Its what keeps them connected and growing.
Was it not BSD or GPL or some similar license? If so someone could just fork it while ignoring their rules and business decisions (as long as at least one other person had the code I guess).
Maybe you’re a developer who can keep account of multiple layers, or all layers in your stack. If so that’s great. But we’re all limited to varying degrees and there’s only so much one can do. Really, you need to find reliable partners who can own some of that complexity for you.
In OPs case, they picked a partner that was not reliable. They paid for it with more maintenance. But this is what you get with open source. You can get it for free and you can set it up fast because you don’t need to negotiate contracts, but your dependencies are under no obligation to support your use cases.
But yeah I get it, too much of a pain, too unrealistic, etc.
Of course, open source software is not the only thing at risk of this, seems like most modern software gives you little control over what version you use.
I don't know who came up with and propagated the notion that software needs to be constantly "in motion" and perpetually changing (perhaps to justify their continued employment?), but it's an irritating trend.
Likewise, a hell of a lot of SDL1.2 projects will still compile and run fine.
I have binaries from the early 90s that I still use today (mainly small utilities). Win32 ain't going away.
The industry is full of solutions looking for problems. Ignore them and stick to the basics if you want what you do to last.
Tell that to the banks, government, and companies still running software older than I am. And for which, on the rare occasions when maintenance is needed, the developers are likely using tools older than I am to do the maintenance. (I'm middle-aged btw.)
It's been a nice 23 years since the major Y2K projects, and we've still got 15 more until we really have to hustle on the Y2038 projects.
I've been a bit upset (more confused) myself as a user/contributor when I've spent hours or even days debugging something, clearly and politely communicating the issue or bug, and then it gets immediately closed with something like "we're just volunteers" as if I demanded something by merely pointing out an issue (that I offered to help with!). What does being unpaid volunteers have to do with any of that? It's just knowledge and information I have reported, but then I have to deal with a maintainer getting upset because I simply used their advertised library, one they advertised on their CV, in talks, in books, etc.
I was wanting to start being a regular contributor, so what's the point of treating a potential contributor like that? I'm not totally sure I get it. They don't owe me anything, and I'm also fine with their library willowing away into obscurity and going off and doing my own thing.
Honestly feel this reflects poorly on the OP more than anything else.
On the flip side, one thing I dislike a lot about the Clojure community is when people say "sometimes software is complete and there is nothing else to do" as an excuse to tolerate libraries that have gone unmaintained for years. Again, anecdotal evidence, but half the time I hear "the software is complete", I end up finding a bug in said software.
Lastly, this paragraph summarizes a bigger problem with consumer behavior in open source:
People seem to forget that the vast majority of open source projects are thanklessly maintained and it is annoying having to deal with e.g. people who blatantly ignore instructions in your README, file an issue resulting from said negligence, then open a pull request to "fix" this problem that can be avoided by simply following instructions in the README. (I have had this happen in a few projects I maintain). One of my friends calls this style of PRs "drive-by PRs", and I wouldn't be surprised if most of the PRs in the author's project are just that. I want to say the author slightly alludes to this situation when statingI think it would behoove open-source developers who are sensitive to dealing with potential users and collaborators to more clearly state and set expectations on the repository's README. Many authors clearly like to use open-source packages they maintain as a sort of professional portfolio, which is perfectly fine, and this author even asks for paid support at the bottom of the README. Is it really out of line to ask about the status if it is not otherwise clear?
All of these little scuffles from maintainers towards contributors and users are often from lack of communication and expectation setting on the side of the maintainer(s) and code owner(s), although contributors and users can also be demanding. I think the issue is that everyone has their version of expectations in their head but not everyone shares those. It's the same as with any human communication, so the more information the better.
I think there is a bit of a mismatch between advertising code, asking for paid support, etc. and then being upset at activity in the repo without more clear guidelines. I have seen plenty of repositories that very clearly state that they won't accept pull requests, they won't accept anything but the simplest of bug fixes, that this library is really just for the author's use but it is being open sourced in case it's useful to someone else. That's a good example of setting expectations that provides more context than pointing to a license.
https://github.com/minimaxir/simpleaichat/issues/91
https://github.com/minimaxir/simpleaichat/issues/92
But there's some general commentary here that I think is applicable to maintainers appropriately setting expectations that contributors can abide to or be held to when interacting with the given projects.
In my opinion, it's perfectly reasonable to ask if a project is still being maintained. I often come across packages that have had no updates in a year, and it's hard to know if that's because they aren't being maintained, or if they are being maintained and no updates have been required.
I hear the argument from some open-source maintainers that they have no obligations to the people who use (and depend on) their software. But there are lots of open-source developers that actually want people to use (and to depend) on their software. Being an open-source developer of a widely-used application or package can bring great benefits to the developer - at the very least it garners them respect from the community and potentially from future employers, and in some cases it can lead to huge financial rewards: acquisitions, great career prospects, paid trips around the world to speak at conferences, etc.
It's definitely more of a two-way street than some developers would lead you to believe.
>"What's your time commitment?"
Why didn't you post the whole comment?
> I really like the philosophy and design of this package but it appears its development process has basically stopped. I don't mean to pressure or to be rude but if @minimaxir could share his thoughts on this I would really appreciate it.
> Can we expect development by the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
> Thanks
He seems burned out over trying to keep up with the fast pace of AI development (which is understandable). He's clearly putting inhuman amounts of effort into whatever he's doing and it's wrecking him, so I'm guessing he's perceiving questions about his project's longevity because he hasn't addressed issues from six months ago as seeing vultures circling in anticipation of his imminent demise. He's giving it his all and he's being presumed dead after six months...what more can he give?
That's all totally ok and understandable, and I hope he takes some time off to relax in the next few weeks. But I also wish that he would take this article down. He's externalized his own internal struggle as authoritative-sounding advice proscribed to the community at large, based on his own misguided perceptions of perfectly-acceptable discourse. It's Toxic-with-a-capital-T.
I've been in open source development for two decades. It's not rude to ask if a project is abandoned. If asking that question causes somebody to quit, it's probably for the best.
That being said, the first comment seems rather polite and considerate to me. Yes accusations of neglect are rough, but if that isn’t the case it shouldn’t be too hard to put a disclaimer in the README as to why the project isn’t moving much.
Your feelings are valid, but so are theirs (although in some case should have been expressed more thoughtfully). It doesn’t feel productive to dismiss their questions on the ground that you behave differently when faced with this situation.
An open source project does not have any opinion or feeling about not being under active development, but people interested in the project might, and they can use those words to communicate their displeasure by evoking those feelings. But, I'd wager that there are just as many instances where no connotation or hard feelings are intended.
Words are powerful! If you are merely asking, maybe avoid "dead" or "abandoned" when "no longer actively maintained" will do. And if you're not merely asking and really do want to communicate your displeasure, maybe just don't.
It's really sad to see people decide they don't want to publish code because some strangers have weird expectations. Of course ideally those strangers wouldn't exist, but that's not something anyone can change... but it's perfectly OK to kick them out of your space.
Make a practice out of README's having more context about who is behind this work (individual, team, etc), the status of it, and the desired outcomes. I think this helps not just to make it clear that users shouldn't have an expectation of support, but also if a solo project it will end and flow.
I think that this kind of becoming a requirement because open -source is in a really peculiar place and these sorts of issues are likely going to get worse before they get better.
It isn't just the number of open-source projects that is growing, but the variety in models and desired outcomes for open source that is diversifying, and in many cases, more towards where any project with traction is less likely to be a fun side thing for a smart dev and more seen as a 'product'
I am not sure how I feel about this trend overall, but I do know I have appreciated this sort of context in projects and it does seem to at least make it easier to close issues by pointing at those statements.
As a relatively prolific open source maintainer; there is absolutely nothing wrong with asking if a project is dead, abandoned, or otherwise stuck in the mud. Open source projects fall off every day, and there's nothing wrong with that or inquiring about it. If your project is dead, post a note on the README to that effect or explaining the current status. One can always put a call out for maintainers as well.
If a question like that, or critical comments in general, negatively affect your well-being, seek help and immediately disconnect or disengage. Alternatively, one can always disable Pull Requests, Issues, and Discussions for proper isolation and read-only code sharing.
In short, quit telling people how they need to be and take some personal responsibility for your well-being or mental state in the realm of Open Source Software.
Furthermore I think that this sample is exactly what can discourage an open source project maintainer to stop development and work on something else, maybe something closed and private, which is bad for open source generally.
So people need to be more patient and read the code of conduct of any project they want to interact with.
Having dealt with a fair share of this along with bizarre interactions over PR's that leave me stressed out, my question to them would be: if the author simply said "no it's not dead", would you accept that as a closed issue?
Or are they expected to actually make some commits in response?
If you find a bug, security issue or dependency issue I will attempt a fix or accept a PR."
That is a closed issue. Maybe as other's have said put that in the readme but that's up to you, it might just prevent the same issue popping up in 5 months.
Perhaps the person could have said:
> Hi, we at ACME Corp are planning to use this library but are not entirely sure about the current state of it, can you confirm it's still maintained? It would make my boss very happy, also thanks for your work, appreciate it :)
And the response might be different?
Both sides can definitely introspect but I'm not on OP side on that one.
Assume incompetence not malice etc
I understand the pressure open source maintainers are under (having been there myself), but the general advice has always been to fork a project if the maintainers can't or won't integrate PRs and fixes that you need.
If we can't ask questions about the repo's status, the backlog of legitimate PRs is growing without response, and even forking the project is considered hostile, that leaves no real options.
If someone wants to publish something to GitHub with expectations like this, it's better IMO to advertise them at the top of the README.md. Or better yet, don't publish a project to GitHub if you don't want to have to read GitHub issues and you don't want anyone forking your work.
> The best-case scenario for asking if an open source project is dead is that you annoy the maintainers and delay development. The worst-case scenario is that you give the maintainers an opportunity to reconsider if continuing to work on the open source project is worth it.
This is remarkably cynical. I've seen many GitHub issues asking about the status of a project that turned into constructive discussions about adding more maintainers, collaborating on future work, or coordinating a newly-maintained fork with an updated link in the README.md.
To say that the outcome can only possibly be negative or that spending 60 seconds responding to a couple legitimate GitHub questions (I checked, the repo has had 3 new issues in 2023) will significantly "delay development" is really negative.
If such simple communications are causing the developer to publish long rants on their blog and consider withdrawal from open source completely, I think there's something deeper going on. This long rant in response to a single legitimate GitHub question is more than the typical open source maintainer frustration.
If you don’t want to interact with people keep the source to yourself.
Or maybe ask yourself why it isn’t immediately obvious that your project is active. I see a project with a low semantic version number and a release three months ago.
Nowhere in the readme is there any blunt statement on the current status of the project or what kind of state it’s in.
Some direct and affirmative language like that can go a long way there. Put info in the readme somewhere prominent and it would probably stop a lot of people from asking questions.
Tell us how when to raise issues or not. You can even tell people not to ask whether the project is active and they might just comply!
Calling that 'dead' and demanding status updates is the overreaction here. Unless you're paying this person to work on it full-time.
One of the bits of software I use has an update as recently as 2019, and before that 2015 and two 2013. It's clearly still relatively active. For software released in its current form in 1997, after being ported from an older version.
Even if modern software might sometimes need more frequent updates, it's still pretty demanding to insinuate death and demand status notes from an open-source maintainer just because they're not moving quick enough for you.
The people who asked those questions were greeted by a software author who lashed out at them. See for yourself:
https://github.com/minimaxir/simpleaichat/issues/91
https://github.com/minimaxir/simpleaichat/issues/92
One person who asked (rightfully, IMO) pointed out that all these questions are reasonable considering the project has sponsorship and Patreon links. The author is collecting $100 a month in Patreon and GitHub sponsorships, which is not nothing.
Noone want use a libray that is not active maintained.
simpleaichat also use other dependencies, i think they are choosed by the developer the same way i would choose his library.
If its an library that implements things that dont change often like string functions this is not important.
But a library connecting to third party apis maintaining status is relevant. So asking if he need help or if its dead is a fair question.
dead and death are not nice words, but github is a world with many persons that dont speak native english.
honestly, that sucks but also she mustve been interested enough to do due diligence, i see that as an absolute win
Happy to contribute to help but knowing that the persons who actually understand and took the responsibility to maintain a library are around, informs my choices.
It’s fine if you don’t want to fix problems in your library anymore, that’s your choice, I just won’t use that library—but I need to know what’s going on or else I can’t make choices for my own benefit.
Whether you like it or not, posting an open-source library is equivalent in my and many developers minds, to telling other people that they ought to use your code in some way. If the way you signal them to use it is as a dependency in their own critical software, by posting it to a package manager and hyping up the benefits of your design choices and code, I do think it’s kinda on you if people get burned by deciding to work with you, even if indirectly.
Communication is the point - if you don’t want people to expect maintenance of your software, say that you won’t maintain it, don’t put it on a package manager, or else people will get the wrong idea, because open sourcing and posting the code is also communicating something, even if in your case it’s unconscious and not what you actually meant.