7 ms·
Please Don't Ask If an Open Source Project Is Dead
- poulpy123 3y agoI get that it can be a source of stress for the dev, but knowing if a project is still alive is needed before investing too much time in it
- SoftTalker 3y agoWhy? 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.
- StressedDev 3y agoIt 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.
- Falkon1313 3y agoThat 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.
- poulpy123 3y ago> Why? It's either useful or it's not 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
- StressedDev 3y agoI 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.
- cowsup 3y agoI'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.
- minimaxir 3y ago> 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.
- tedunangst 3y agoTIL there are people who get mad if the list of naughty strings doesn't get enough updates.
- simonblack 3y agoOpen 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?
- appplication 3y agoI’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.
- koito17 3y agoWhile 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).
- entrptaher 3y agoI 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.
- MiddleEndian 3y ago>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).
- andkenneth 3y agoIt's apache
- vegetablepotpie 3y agoNot 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.
- candiddevmike 3y agoDependabot 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.
- userbinator 3y agoIMHO 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.
- deleted 3y ago[deleted]
- popularonion 3y agoBit rot in third party dependencies that never get updated is a real problem
- rrdharan 3y agoSecurity vulnerabilities (particularly in dependencies) make this desire practically unachievable for many pieces of software.
- psunavy03 3y agoUhh . . . 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.
- fao_ 3y agoIf you target C+POSIX, uh, yeah. It's entirely possible to be "done" with a project. Likewise, a hell of a lot of SDL1.2 projects will still compile and run fine.
- userbinator 3y agoThat's what the propaganda wants you to think... 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.
- jckahn 3y agoPreach! 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.
- bmitc 3y agoI 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.
- dugite-code 3y agoSure... 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.
- koito17 3y agoAnecdotal 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.
- bmitc 3y agoI 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.
- ysavir 3y agoThis 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.
- avinassh 3y agoI checked both the issues mentioned, people have been respectful and showing empathy to author's situation https://github.com/minimaxir/simpleaichat/issues/91 https://github.com/minimaxir/simpleaichat/issues/91 https://github.com/minimaxir/simpleaichat/issues/92 https://github.com/minimaxir/simpleaichat/issues/92
- throwaway892238 3y ago> > 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.
- strongpigeon 3y agoThis 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.
- minimaxir 3y agoI admit that this post was unusually emotionally charged and I do not intend to make a habit of it.
- nlawalker 3y agoOn 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.
- kentonv 3y agoI'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.
- addisonj 3y agoI 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.
- olalonde 3y agoI 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?
- matheusmoreira 3y agoGitHub 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.
- olalonde 3y agoIt'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.
- 0x073 3y agoYes 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?
- 0x073 3y agoYes maybe something similar like LICENCE, that is parsed and put under about section on github.
- andrew_ 3y agohttps://liberamanifesto.com/ https://liberamanifesto.com/ 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.
- bachmeier 3y agoOpen 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.
- _madmax_ 3y agoI 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.
- 1231232131231 3y agoIf the project is dead, just say that. All they really did was ask about the future of the project, I don't really see the pressuring.
- Grimburger 3y agoThere'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?
- jpc0 3y ago"No it's not dead. 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.
- Grimburger 3y agoFair 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 :) And the response might be different?
- jpc0 3y agoFor 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. Assume incompetence not malice etc
- Aurornis 3y ago> 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.
- swyx 3y ago> 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
- dangus 3y agoTalk 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!
- deleted 3y ago[deleted]
- Falkon1313 3y ago>a release three months ago 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.
- dangus 3y agoIf 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: https://github.com/minimaxir/simpleaichat/issues/91 https://github.com/minimaxir/simpleaichat/issues/91 https://github.com/minimaxir/simpleaichat/issues/92 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.
- shmerl 3y agoYou 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?
- presentation 3y agoAs 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.
- deleted 3y ago[deleted]
- bjourne 3y agoI have several times submitted pull requests to projects only to find out the hard way that the project was abandoned by its maintainer. So I strongly disagree with minimaxir. It's not rude to ask whether a project has been abandoned. It takes literally seconds to answer yes or no and only a few extra seconds to clarify the situation. No one expects anyone to indefinitely maintain any code. But please be upfront about it. It is not burdensome to write in capital letters THIS PROJECT IS UNMAINTAINED in the README file if that is the case. And it saves a lot of time for others.
- matheusmoreira 3y ago> To be perfectly clear, this absolutely is applying pressure and being rude. I don't think so. The person was perfectly polite in my opinion. You don't owe anyone anything, they aren't paying you and it's absolutely fine to just drop everything and go do something else if you want. However, the people using your project will want to know what's up so they can deal with the consequences. They find out what's up by asking perfectly reasonable questions like the ones in the first screenshot. It's simple to provide a sincere answer to all of those questions. No response is also a valid and clear answer, there's no actual pressure to respond either. The point is it's not rude to ask. As a free software developer and user, when I ask such questions it's because I'm wondering whether I should fork the project or try to work with the maintainer. I've sent patches to projects, most recently cosmopolitan libc, because I knew the developers were actively maintaining the project. I've forked the pug/jade templating language into my own static site generator tool because the maintainer seemed to have moved on, I went there and asked just to confirm before I did so. I don't think there's anything rude or pressuring about it. We're just trying to decide what to do with our own time. Our decisions depend on your decisions and therefore we ask. It gets rude when people start subtly shaming you for not working on things. That's absolutely unacceptable but I don't think that happened in the first screen shot which was just polite questions.
- rgoulter 3y ago> It gets rude when people start subtly shaming you for not working on things. Seems like OP perceived shame by being asked this, though. -- Why would anyone ask "what's the status of this project?" (or however politely you want to phrase it) if the project were clearly being maintained? There's at least a meta-message of "you're not working on this enough", even without otherwise being hostile/rude. I'm reminded of the "ask vs guess culture" differences. But as you say, users aren't owed reliability. Perhaps a better interaction would have been "Is this dead?" "I haven't been working on it. I hope to work on it soon, though. But, I would rather not have to deal with PRs from others". Still, I think it'd be better if people didn't have to walk on eggshells when making interactions; and to reserve accusations of rudeness for more overt or persistent badgering.
- 3y ago
- factfindingisfn 3y agoThis sense of outrage on stupid things is getting old. If you are going to have a 3k star project and you get your feelings hurt over someone asking if it is after you took a break, that is a legitimate question. Dumb blog post got me again, I almost never click on them from here because it is either some VC self congratulating themselves or some developer griping about their hard life while driving their Tesla home to their $500k home.
- throwaway2037 3y agoAs Mike McQuaid from Homebrew once blogged: <<Open Source Maintainers Owe You Nothing>>[1] There are so many blog posts like this. And, a few times a year, HN likes to rehash this topic. Open source seems like a thankless, but necessary exercise in the modern world. At this point in history, I doubt there are any strong intellectual arguments to favour closed- over open-source. (However, there are economic arguments. For example: If you have excellent intellectual property, then it is much more economically valuable to keep as closed source.) I am so glad that I do not run an open source project with lots of attention. It looks like hell having to fight with Internet trolls all day long. To show some compassion for people who reach their wit's end and write a noisy blog post like this: It must be difficult being poked and prodded all day long. After you lash out, and a bunch of people (trolls?) tell you to "calm down". If only there was a (VR!?) simulator to put those very same people through the same hell to watch how they would react. [1] https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/ https://mikemcquaid.com/open-source-maintainers-owe-you-noth...
- eviks 3y ago> 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.” Why is this legalese so appealing as the answer to social issues that have nothing to do with licensing and warranty etc?
- taylodl 3y agoPlease stop complaining about people complaining about open source projects. I don't care, and you shouldn't care: unless you're under the (mis)impression that open source will provide you some sort of fame. Scratch your itch. It might scratch my itch too. If the users make demands that you don't want to deal with then let one of them take it on. Because that's what open source is supposed to be about - community. Nowadays it seems the community aspect is disappearing and what people want is commercial-grade software for free. Yeah, I'm not working for you for free, let alone you thinking you can make demands of me. You can go straight to Hell with that idea.