【外评】哪些开源项目被广泛使用,但仅由少数人维护?

我能想到的只有一个人维护的 sudo (https://github.com/sudo-project/sudo/graphs/contributors),它被所有主要的 Linux 发行版所使用

你也许感兴趣的:

共有 99 条讨论

  1. 列出哪些基本项目有一个以上的活跃维护者,感觉会更容易一些。

    许多核心库和工具大多已经完成,每年的活动很少。如果一个项目的最后一次活动是由一位维护者在 3 年前提交了一两次提交,或者仅仅是合并了一两次提交,而在 5 年前又合并了几次提交,那么这个项目有多少维护者呢?是算 2 个维护者、1 个维护者还是 0 个维护者?5 年前的 “维护者 ”是否仍有提交权限,如果出现合并请求,他们参与的可能性有多大。

    即使是活跃的项目,90% 的工作由一个主要维护者完成也是很常见的。

    1. > 许多核心库和工具已基本完成,每年的活动很少

      是的。是的,JavaScript、“网络 ”和全栈网络应用的临时、事实上的 “标准库”。

      开放源码软件生态系统有时就像 “魔法王国中的沉沦者”。真遗憾,我们没有享受到 “贱民 ”社会的其他福利!

    1. > 也许还有: sqlite […]

      SQLite 不接受来自核心团队以外的贡献;加入核心团队是一个复杂的过程,因为他们正在采取极端措施,以确保其在尽可能多的司法管辖区继续被认可为公共领域的作品。您仍然可以通过向他们支付工作报酬(或让您的雇主这样做)来支持该项目:

      https://www.sqlite.org/prosupport.html

      1. 我的理解是,你完全可以在不加入核心团队的情况下做出贡献,但你确实需要提交一些文件,以确保代码可以保留在公共领域。之所以需要法律文件,是因为公有领域在多个国家都不存在。

        1. 理由和法律要求解释得很清楚:https://www.sqlite.org/copyright.html

          简而言之:他们有一家公司合法雇佣了每一位合著者,以便能够向你出售 “所有权保证书”,以防你的公司/司法管辖区等对公有领域有意见。

      1. 没错,但问题涉及的是维护者的数量。是指发挥某种作用的人,而不仅仅是路过的人。

        Redis 团队由 8 个人组成:https://github.com/orgs/redis/people

    2. 15 人不是 “少数”,而是一个庞大的团队。

      你提到的其他团队有多少维护者?

    1. 实际上,我对’猫’的变化之大感到惊讶。人们会认为这样的程序已经 “完成 ”了。

      1. > 我对’cat’的变化之大感到惊讶。

        ‘cat -v’被认为是有害的 “是一个流传已久的流行语,但也有它的道理。http://harmful.cat-v.org/cat-v/

        cat(1) 连接文件。有些软件应被视为已完成。

      2. 从大约 2008 年开始,标记为 “maint ”和 “all ”的软件会触及多个文件,但似乎不会对 cat 等软件进行实质性修改。自从这种分类开始以来,只有 10 个改动是针对 cat 的。

      3. “true “的历史记录如何:https://github.com/coreutils/coreutils/commits/master/src/tr…

      4. 公平地说,有很多提交只是更新了版权年或文档。在我看来,这只是常规的内务整理,并不意味着猫一开始就没有 “完成”。

    2. 这些工具中的大部分工作都是更新版权年号。

      1. 这似乎完全没有必要。根据我的理解,只有起始年份就足够了。

        1. 在年份没有任何变化的情况下,版权年份不应该更新。否则,你所声称的版权期限是从内容创建后的某个日期开始的,因此它被人为地延长了。

          1. 问题的关键不是从 “版权(C)2023 ”到 “版权(C)2024”,而是从 “版权(C)1998-2023 ”到 “版权(C)1998-2024”。因此,你的情况并不适用,也不会造成混淆。我的意思是,据我所知,有 “版权 (C) 1998 ”而不改变它就足够了。

            1. 是的,我理解你的意思是,有起始年份并每年更改就足够了。其实不然,但我在其他地方经常看到这种情况,所以值得指出。

          2. 每次修改代码并提交,不都是一个新程序吗?

            新版本的书有新的版权年限,因为它们是新书。

            代码也是一样

            1. 所以我的第一个词是 “缺席”。

    1. 这个答案不错。特别是考虑到 2021 年的戏剧性事件和维护者的仁慈独裁者身份。如果社区不同意仁慈的独裁者的决定,会发生什么?

      https://lwn.net/Articles/870478/

      1. > 当社区不同意仁慈的独裁者的决定时会发生什么?

        他们会进行讨论,试图达成妥协,如果都失败了,就把它叉掉。

        也许这并不理想,但话又说回来,当 “董事会 ”管理这些项目时,人们似乎也有很大的问题,所以……

  2. 列举拥有较多维护者的少数项目可能会更容易一些。我认为绝大多数项目都只有几个维护者。

  3. 我只是好奇这些人是如何安排的。

    -他们的雇主是否认可他们的努力,并为副项目提供工时?

    -他们大多是承包商,因此可以相应地安排时间?

    -捐赠?

    -还是主要出于爱好?

    1. 我没有像这些项目那样受欢迎的项目;但如果你有一个受欢迎的项目,潜在雇主可能会为它提供工时,让你成为一名员工。

      此外,我和另外一位维护者共同参与了一些现在很流行的项目,我可以说我主要是为了好玩才这样做的。我现在的雇主对我的贡献不屑一顾,但如果有新雇主用它来吸引我,我会立刻跳槽。

      1. 在大多数司法管辖区,你所做贡献的版权可能属于在职期间的雇主。

        1. 我的雇佣合同明确规定,我可以保留我在自己的时间和设备上所做的不在某些领域竞争的任何事情的权利,并列举了这些行业。

        2. 也许吧,但你可能有权限将其开源。

    2. 你忘了一个重要的选项:

      没有报酬,不是业余爱好,没有多少激情,因为公众需要而做。(可能开始的原因是,该死的,总得有人写它/接手维护)。

  4. 请注意,封闭源代码项目的情况也不会好到哪里去。

    当然,你的供应商可能会修复错误,但可能要花费一些时间,直到他们找到一个对该代码库有任何了解,并且在上周的改组、春季的重组和去年的收购中幸存下来的人。

    1. 我不知道封闭源代码项目是否更好,但无论如何,开放源代码都有封闭源代码所没有的逃生门。如果出了问题,你可以自己维护,或者分叉。

      我自己就这么干过。

      如果你想要长寿,开放源代码总是比封闭源代码更安全。

      在我的案例中,我想它将项目的寿命又延长了 20 年。

    1. 有那么一瞬间,我以为你指的是开源硬件。然后我就失望了。

  5. Byte Buddy – Java 虚拟机的运行时代码生成 – https://github.com/raphw/byte-buddy

    Byte Buddy 是一个用于 Java 虚拟机的运行时代码生成工具 – > 它很稳定,并被 Mockito、Hibernate、Jackson、Google 的 Bazel 构建系统等著名框架和工具所使用。Byte Buddy 还被大量商业产品使用,并取得了巨大成功。目前,它每年的下载量超过 7500 万次。

  6. 如果你真的想深入研究这个问题,虽然应用程序有很多案例,但不要忘了 “每个人 ”都依赖的底层库。

  7. 从某种意义上说,无处不在的 “unzip ”没有维护者。

    根据上游 https://infozip.sourceforge.net/,“UnZip 6.0 于 2009 年 4 月 29 日发布”。

    但并不是真正的 0 维护者,因为发行版维护着自己的补丁集,例如: https://git.launchpad.net/ubuntu/+source/unzip/log/

    (顺便说一句,unzip 可以说功能并不完整。自 2009 年以来,ZIP 规范已更新多次,其中值得注意的是增加了 Zstandard 压缩方法,以及其他一些内容 https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT)

  8. 编辑:我漏掉了 “广泛使用 ”部分。

    [Orca](https://gitlab.gnome.org/GNOME/orca)。对 Linux 桌面盲人用户非常重要。如果你更喜欢框架,[ATSPI](https://gitlab.gnome.org/GNOME/at-spi2-core) 或 [AccessKit](https://accesskit.dev/) 可能更适合你。或者,如果你喜欢贡献他人的应用程序,不妨看看如何利用这些 [Tips for application developers](https://github.com/GNOME/orca/blob/main/README-APPLICATION-D…),让它们变得更无障碍。

  9. OmegaT 在专业翻译领域被广泛使用,由一人维护,只有极少数活跃贡献者(本地化人员除外)。

    https://omegat.org

  10. 外籍人士

    LibreSSL

    Linux-PAM

    OpenSSH

    re2c

    tzdata

    zlib

    这些只是我想到的。

    1. 不错的清单。有时最简单的贡献方式就是捐点钱,这样现有的维护者就可以继续专注于他们的工作。OpenBSD 是 OpenSSH 和 LibreSSL 的 “母舰 ”项目: https://www.openbsd.org/donations.html

      遗憾的是,我找不到任何关于如何向这些项目捐款的信息:

      https://re2c.org

      https://github.com/libexpat/libexpat

      https://github.com/linux-pam/linux-pam

      https://zlib.net

      tzdata 实际上由 IANA 维护:

      https://www.iana.org/time-zones

      1. 我没想到 IANA 还贡献了 debian 软件包和 rpms。/s

        他们负责维护列表,但必须有人来打包。

        1. 请链接如何为 Debian 做贡献:https://www.debian.org/devel/join/

  11. dnsmasq。在数十亿台设备(包括 Android)上运行,一个人(Simon Kelley)。

  12. quic-go:https://github.com/quic-go/quic-go/

  13. 丰富。每月下载量达 1.97 亿次。有两名维护者。

  14. flex 和 bison。尤其是 flex,似乎几乎无人维护。

    1. 我很惊讶听到这个消息,有更多信息吗?

        1. 在 PHP 上有很多人在做(好的、有价值的)事情,但对引擎有深刻理解的活跃人士却屈指可数。(我过去为引擎和其他部分做了一些小贡献)

          1. Nikita Popov (nikic) 就是其中之一。当他离开 JetBrains 去做其他项目时,PHP 的核心开发受到了重创。

  15. 都是比较好的。维护者越多,质量就越低。直至彻底毁灭

  16. zlib: 马克-阿德勒

    ncurses/xterm: 托马斯-迪基

  17. 学术界经常有人问这个问题。这个系统几乎是在鼓励创造重复软件和/或对某一领域或利基市场至关重要的废弃软件,因此有大量这样的软件(也有大量非常好的稳定软件,但暂时不考虑这个问题)。这使得新的参与者很难找到他们可以信赖的开源软件,资助者也很难决定支持什么软件,机构也很难跟踪他们的贡献等等。

    我正在开展一个项目,以解决这个具体问题(以及许多其他问题),该项目横跨开源和开放科学生态系统,从开源研究软件开始,但最终打算触及整个领域。除其他外,我们希望对开源项目的健康状况、开源项目的使用情况、对开源项目的看法、“开源项目的影响 ”以及开源项目的需求进行持续测量。我们正在将数据收集与语法标记和最终的信任网结合起来。

    该项目由 NumFOCUS 孵化,包括来自学术界的合作。

    在此介绍该项目,供大家参考。

    该项目名为 “开源科学地图”(MOSS),建立在 “简单全知层”(SOL)之上。它本质上是一个无所不知的开放式无权限图数据库,包含数字知识和研究生态系统,以及相应的可视化(最终人们将能够构建自己的可视化,并与 SOL 相连接)。

    最近在佛蒙特 PyData 大会上的演讲:https://www.youtube.com/watch?v=7c51njj9JPs

    近期更新:https://www.opensource.science/updates/the-map-of-open-sourc…

    该计划的登陆页面: https://opensource.science

    来自我们的网站:

    “MOSS “是一个全面、可组合、互动的数字知识和研究生态系统地图。我们确定开源研究软件项目、研究论文、组织、专利、数据集、融资途径、人工智能模型和应用以及推动这一切的人之间的联系。

    到目前为止,MOSS 的概念验证已经展示了九个用例:

    为您的研究确定相关工具

    展示制作和维护开源研究工具的人员的影响和联系

    展示构建、支持和资助开源研究工具开发的组织的影响和联系

    展示开源研究工具的影响和联系

    确定开源研究工具的差距

    引导开源研究工具功能的重复

    识别、预防和重振被遗弃的开源研究工具

    简化拨款提交和审查流程

    安全漏洞识别导航–联系谁、哪些下游工具会受到影响、有哪些替代工具” 888/0/lynx23

    1. brew 公式由许多人维护,“brew ”命令行工具有数十名贡献者,提交次数超过 100 次。

    1. 提交者多到维护者无法控制质量。

      1. 对于这样一个大项目,稳定候选版本的测试人员也非常少。

  18. 人们曾经为上游工厂把用过的干净水退还给河流而斗争。这是生态学家的斗争。

    现在,公司做的项目预算中都有 5 个或更多的零,而且有很大一部分代码是自由软件或开放源代码。而他们对自己寄生的自由或开放项目的回报却是零。

    几年前,我在自己的博客上写过一篇文章(西班牙语,抱歉),“自由软件已经失败”:https://tomatesasesinos.com/2019/07/11/el-software-libre-ha-…

    1. 我认为这属于 “Show HN: My Tangentially Related Thoughts”(展示 HN:我的切身相关想法)。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注