3 ms·
> 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? O
by 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.
- shaftway 3y ago> 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.
- kelsey9876543 3y agoForks 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.
- leidenfrost 3y agoThat's a big survivor bias you have there. Most forks don't even become relevant enough to be known
- seba_dos1 3y agoSo what? Same applies to most projects in general.
- lovepronmostly 3y agoAnother 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.
- jstarfish 3y ago> 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: https://github.com/mckaywrigley/chatbot-ui/issues 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.
- kelsey9876543 3y agoI'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.
- jamescostian 3y agoPerhaps 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
- minimaxir 3y agoThis may be what I need to do. Yes, I do have inherent guilt for not updating my projects often enough.
- kybernetikos 3y agoPerhaps 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
- matheusmoreira 3y ago> 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: https://github.com/matheusmoreira/liblinux/issues/16 https://github.com/matheusmoreira/liblinux/issues/16 I think it's better to just be sincere and provide the necessary context.