请不要问开源项目是否已死

Over the past few months, 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. I took a break from working on my projects during that time, which should have been fine. One of my latest open source projects is simpleaichat, a Python package with 3k GitHub Stars for interfacing with ChatGPT, and it was explicitly designed with limited scope and minimal dependencies so that I could take a break from development without my code…breaking.

After I was in a good place mentally to resume my open source work, I glanced at the GitHub Issues for simpleaichat and someone filed a issue simply titled “has this been abandoned?” with another GitHub user following up with “With all due respect, I am also interested in the answer.”

What the hell? I panicked and checked if there was a new breaking issue or dependency and there weren’t any.

Two days later, someone else filed another issue: “Is this package still in ongoing development?”:

To be perfectly clear, this absolutely is applying pressure and being rude.

The Expectations of Open Source Software Development#

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.”

simpleaichat regretfully isn’t my first open source project with complaints like this. The Big List of Naughty Strings to track adversarial user-input text strings, which I pushed to GitHub about a decade ago, is essentially just a txt file with 45k GitHub Stars. There will never be dependency issues, and additions to the list that don’t target a distinct string issue may clutter the list more than it already is so I’m hesitant to accept every pull request. But despite that, people are angry.

The duality of comment reactions.

The duality of comment reactions.

Some seem to think that there’s such a thing as GitHub Issue-zero or pull request-zero, which like inbox-zero is infeasible in practice due to the realities of professional life. 1 Every nontrivial open source project will have an issue/PR queue, which necessitates a triage priority: not all issues and PRs are equal and it takes time and care to sift through the queue. That’s something I’ve had to repeatedly learn the hard way as a maintainer since accepting a misguided PR will create technical debt and take even more effort to address.

I get that it’s a bummer to come across a cool GitHub project that hasn’t been updated in awhile. That happens to me all the time. If the code still works, that’s excellent and I’m happy. But if it doesn’t, I move on, or use it as a fun new opportunity to hack it to my needs. That’s the beauty of open source! If there’s an inactive open source project that’s absolutely critical for your own commercial project, then that’s a good financial reason to offer a consulting contract or a bounty to add the appropriate functionality.

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.

The AI industry is unique because it is indeed moving and evolving so fast that development expectations have shifted. Recent beneficiaries of the ChatGPT boon such as LangChain, LlamaIndex, and AutoGPT have created a false sense that open source AI projects have to always be shipping 🚀🚀🚀. The difference is that they are maintained by those who do it as their full-time job and are now managed as companies backed by significant amounts of venture capital.

The pressure to continually provide support for an open source project has become the biggest deterrent for me to continue my open source work. Personally, I’ve stopped pushing fun one-shot projects and AI models because I likely will not have the bandwidth to handle the inevitable “hi this is broken plz fix thx” DMs whenever a dependency on the project breaks years later. I’d gladly quit my professional job as a Data Scientist to work on my open source projects full-time if I was able to make an equivalent salary by doing so. Ultimately, the only way to make it work nowadays would be to raise venture capital like all those AI startups.

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.


  1. 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. ↩︎

译文

在过去的几个月里,我在GitHub上的开源 AI工作遇到了生存危机,特别是因为对 AI 的抵制越来越强烈,而且 AI 行业发展得如此之快,以至于我完全不相信没有足够的带宽来跟上。在那段时间我暂时停止了我的项目工作,这应该没问题。我最新的开源项目之一是simpleaichat,这是一个具有 3k GitHub Stars 的 Python 包,用于与ChatGPT交互,它是明确设计的,具有有限的范围和最小的依赖性,这样我就可以在不破坏代码的情况下从开发中休息一下。

当我精神状态良好地恢复我的开源工作后,我浏览了 simpleaichat 的 GitHub 问题,有人提交了一个简单标题为“这个已经被放弃了吗?”的问题。另一位 GitHub 用户接着说道:“恕我直言,我也对答案感兴趣。”

我勒个去?我惊慌失措,检查是否有新的重大问题或依赖性,但没有。

两天后,其他人提出了另一个问题:“这个包还在开发中吗?”:

明确地说,这绝对是施加压力和粗鲁。

对开源软件开发的期望#

我从未见过任何关于询问开源存储库是否已死是否合适的讨论或文章。是否存在隐性合同来积极维护您发布的任何开源软件?如果您在 GitHub 上达到一定的星级数量,或者通过 GitHub Sponsorships/Patreon 寻求资金,您是否有义务提供免费支持?毕竟,大多数宽松的开源代码许可证(例如MIT 许可证)都包含“软件按“原样”提供,没有任何形式的保证”的某种变体。

遗憾的是,simpleaichat 并不是我第一个有此类抱怨的开源项目。大约十年前,我将用于跟踪对抗性用户输入文本字符串的顽皮字符串大列表推送到 GitHub,本质上只是一个具有 45k GitHub Stars 的txt 文件。永远不会出现依赖性问题,并且不针对不同字符串问题的列表添加可能会使列表比现在更加混乱,因此我对接受每个拉取请求犹豫不决。但尽管如此,人们还是很愤怒。

评论反应的双重性。

评论反应的双重性。

有些人似乎认为存在 GitHub Issue-zero 或 Pull request-zero 之类的东西,就像收件箱零一样,由于职业生活的现实,在实践中是不可行的。1每个重要的开源项目都会有一个问题/PR 队列,这需要优先级:并非所有问题和 PR 都是平等的,并且需要时间和细心来筛选队列。作为维护者,这是我必须反复学习的,因为接受错误的 PR 会产生技术债务,并且需要付出更多的努力来解决。

我发现遇到一个很酷的 GitHub 项目已经有一段时间没有更新是一件很糟糕的事情。这种事经常发生在我身上。如果代码仍然有效,那就太好了,我很高兴。但如果没有,我就会继续前进,或者将其作为一个有趣的新机会来满足我的需求。这就是开源的美妙之处!如果有一个不活跃的开源项目对您自己的商业项目绝对重要,那么这是提供咨询合同或赏金以添加适当功能的一个很好的财务理由。

开源的一大好处是,如果具有宽松许可证的开源项目确实变得不活跃,它可以无缝分叉。有时分叉可以变得比原始项目更好,这对每个人来说都很棒!但根据我的经验,它反而被用作威胁。维护者的错误是为分叉创造理由并分裂开发社区。

人工智能行业是独一无二的,因为它确实正在快速发展和发展,以至于发展预期已经发生了变化。最近 ChatGPT 的受益者,例如LangChainLlamaIndexAutoGPT,造成了一种错误的感觉,即开源 AI 项目必须始终保持交付状态。不同之处在于,它们是由那些将其作为全职工作的人维护的,现在作为由大量风险资本支持的公司进行管理。

持续为开源项目提供支持的压力已经成为我继续开源工作的最大障碍。就我个人而言,我已经停止推动有趣的一次性项目和 AI 模型,因为每当几年后对项目的依赖关系中断时,我可能没有足够的带宽来处理不可避免的“嗨,这已损坏,请修复 thx”DM。如果我能够通过这样做获得同等的薪水,我很乐意辞去数据科学家的专业工作,全职从事我的开源项目。最终,如今让它发挥作用的唯一方法是像所有那些人工智能初创公司一样筹集风险投资。

询问开源项目是否已死的最佳情况是您惹恼了维护人员并延迟了开发。最坏情况是,您给维护人员一个机会重新考虑继续致力于开源项目是否值得。


  1. 有趣的真实故事:约会应用程序上的一场比赛曾经要求查看我的开源项目,在我发送了我的一个存储库的链接后,她回复了一张显示已打开的 GitHub 问题数量的图片和一个 😱 表情符号。 ↩︎

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值