【外评】哪些开源项目被广泛使用,但仅由少数人维护?
我能想到的只有一个人维护的 sudo (https://github.com/sudo-project/sudo/graphs/contributors),它被所有主要的 Linux 发行版所使用
你也许感兴趣的:
- 【外评】瑞士现在要求所有政府软件都必须开源
- 【外评】开源既不是社区,也不是民主
- Winamp 宣布将开放源代码
- 【外评】什么是开源贡献,什么不是开源贡献?
- 【译文】开放源代码与微软:新的反叛开始了
- 开源 Redis 的生命将就此终结?Redis 之父回应分叉浪潮:未来谁能领先,各凭本事!
- 开发者阵营分化,.NET 开源生态系统如何走向未来?
- 马斯克控告OpenAI违约、要求恢复开源;OpenAI否认三连
- 干开源 15 年后,我开启了“自救”,把开源项目变成一项月收入为 4.7 万元的业务!
- 中国开源,又一次让人失望了
列出哪些基本项目有一个以上的活跃维护者,感觉会更容易一些。
许多核心库和工具大多已经完成,每年的活动很少。如果一个项目的最后一次活动是由一位维护者在 3 年前提交了一两次提交,或者仅仅是合并了一两次提交,而在 5 年前又合并了几次提交,那么这个项目有多少维护者呢?是算 2 个维护者、1 个维护者还是 0 个维护者?5 年前的 “维护者 ”是否仍有提交权限,如果出现合并请求,他们参与的可能性有多大。
即使是活跃的项目,90% 的工作由一个主要维护者完成也是很常见的。
看看 sudo 的例子,似乎仍有很多定期和近期的提交。
https://github.com/sudo-project/sudo/commits/main/
> 许多核心库和工具已基本完成,每年的活动很少
是的。是的,JavaScript、“网络 ”和全栈网络应用的临时、事实上的 “标准库”。
开放源码软件生态系统有时就像 “魔法王国中的沉沦者”。真遗憾,我们没有享受到 “贱民 ”社会的其他福利!
– curl: Daniel Stenberg 等人 – https://github.com/orgs/curl/people
– Lua(编程语言):3 人小组 – https://www.lua.org/authors.html
– openssl: 15 人 – https://github.com/orgs/openssl/people
也许还有:sqlite、vim、nginx、redis
> 也许还有: sqlite […]
SQLite 不接受来自核心团队以外的贡献;加入核心团队是一个复杂的过程,因为他们正在采取极端措施,以确保其在尽可能多的司法管辖区继续被认可为公共领域的作品。您仍然可以通过向他们支付工作报酬(或让您的雇主这样做)来支持该项目:
https://www.sqlite.org/prosupport.html
我的理解是,你完全可以在不加入核心团队的情况下做出贡献,但你确实需要提交一些文件,以确保代码可以保留在公共领域。之所以需要法律文件,是因为公有领域在多个国家都不存在。
理由和法律要求解释得很清楚:https://www.sqlite.org/copyright.html
简而言之:他们有一家公司合法雇佣了每一位合著者,以便能够向你出售 “所有权保证书”,以防你的公司/司法管辖区等对公有领域有意见。
redis GitHub 上有 724 名贡献者。
没错,但问题涉及的是维护者的数量。是指发挥某种作用的人,而不仅仅是路过的人。
Redis 团队由 8 个人组成:https://github.com/orgs/redis/people
15 人不是 “少数”,而是一个庞大的团队。
你提到的其他团队有多少维护者?
在这个主题中: 对 “广泛使用 ”的定义大相径庭:)
你知道 GNU coreutils 中的 uname [1] 和 cat [2] 等工具在过去十年中基本上只有两个贡献者吗?
[1] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=histor… [2] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=histor…
实际上,我对’猫’的变化之大感到惊讶。人们会认为这样的程序已经 “完成 ”了。
> 我对’cat’的变化之大感到惊讶。
‘cat -v’被认为是有害的 “是一个流传已久的流行语,但也有它的道理。http://harmful.cat-v.org/cat-v/
cat(1) 连接文件。有些软件应被视为已完成。
从大约 2008 年开始,标记为 “maint ”和 “all ”的软件会触及多个文件,但似乎不会对 cat 等软件进行实质性修改。自从这种分类开始以来,只有 10 个改动是针对 cat 的。
“true “的历史记录如何:https://github.com/coreutils/coreutils/commits/master/src/tr…
公平地说,有很多提交只是更新了版权年或文档。在我看来,这只是常规的内务整理,并不意味着猫一开始就没有 “完成”。
这些工具中的大部分工作都是更新版权年号。
这似乎完全没有必要。根据我的理解,只有起始年份就足够了。
在年份没有任何变化的情况下,版权年份不应该更新。否则,你所声称的版权期限是从内容创建后的某个日期开始的,因此它被人为地延长了。
问题的关键不是从 “版权(C)2023 ”到 “版权(C)2024”,而是从 “版权(C)1998-2023 ”到 “版权(C)1998-2024”。因此,你的情况并不适用,也不会造成混淆。我的意思是,据我所知,有 “版权 (C) 1998 ”而不改变它就足够了。
是的,我理解你的意思是,有起始年份并每年更改就足够了。其实不然,但我在其他地方经常看到这种情况,所以值得指出。
每次修改代码并提交,不都是一个新程序吗?
新版本的书有新的版权年限,因为它们是新书。
代码也是一样
所以我的第一个词是 “缺席”。
阅读 https://en.wikipedia.org/wiki/Copyright_formalities#Shift_aw……,即使是这样,在世界的大部分地区(目前)也没有必要。
尽管如此,我也不敢就此提出任何主张。即使有《伯尔尼公约》(https://en.wikipedia.org/wiki/Berne_Convention),世界也是广阔而多样的。
时区数据库
https://github.com/eggert/tz/graphs/contributors
https://en.wikipedia.org/wiki/Tz_database
这个答案不错。特别是考虑到 2021 年的戏剧性事件和维护者的仁慈独裁者身份。如果社区不同意仁慈的独裁者的决定,会发生什么?
https://lwn.net/Articles/870478/
> 当社区不同意仁慈的独裁者的决定时会发生什么?
他们会进行讨论,试图达成妥协,如果都失败了,就把它叉掉。
也许这并不理想,但话又说回来,当 “董事会 ”管理这些项目时,人们似乎也有很大的问题,所以……
与 glibc 和 Ullrich Drepper 一样。
一场革命
列举拥有较多维护者的少数项目可能会更容易一些。我认为绝大多数项目都只有几个维护者。
我只是好奇这些人是如何安排的。
-他们的雇主是否认可他们的努力,并为副项目提供工时?
-他们大多是承包商,因此可以相应地安排时间?
-捐赠?
-还是主要出于爱好?
我没有像这些项目那样受欢迎的项目;但如果你有一个受欢迎的项目,潜在雇主可能会为它提供工时,让你成为一名员工。
此外,我和另外一位维护者共同参与了一些现在很流行的项目,我可以说我主要是为了好玩才这样做的。我现在的雇主对我的贡献不屑一顾,但如果有新雇主用它来吸引我,我会立刻跳槽。
在大多数司法管辖区,你所做贡献的版权可能属于在职期间的雇主。
我的雇佣合同明确规定,我可以保留我在自己的时间和设备上所做的不在某些领域竞争的任何事情的权利,并列举了这些行业。
也许吧,但你可能有权限将其开源。
你忘了一个重要的选项:
没有报酬,不是业余爱好,没有多少激情,因为公众需要而做。(可能开始的原因是,该死的,总得有人写它/接手维护)。
请注意,封闭源代码项目的情况也不会好到哪里去。
当然,你的供应商可能会修复错误,但可能要花费一些时间,直到他们找到一个对该代码库有任何了解,并且在上周的改组、春季的重组和去年的收购中幸存下来的人。
我不知道封闭源代码项目是否更好,但无论如何,开放源代码都有封闭源代码所没有的逃生门。如果出了问题,你可以自己维护,或者分叉。
我自己就这么干过。
如果你想要长寿,开放源代码总是比封闭源代码更安全。
在我的案例中,我想它将项目的寿命又延长了 20 年。
SQLite – https://www.sqlite.org/draft/crew.html
看起来这是非草案 URL – https://www.sqlite.org/crew.html
不错的尝试,Jia Tan!
bash 和 readline – Chet Ramey。均由 Brian Fox 原创 https://twobithistory.org/2019/08/22/readline.html
随着 OSH 的功能/速度接近均等,而且有了更多的维护者,也许总线因素已经不那么重要了 https://www.oilshell.org/
有那么一瞬间,我以为你指的是开源硬件。然后我就失望了。
Byte Buddy – Java 虚拟机的运行时代码生成 – https://github.com/raphw/byte-buddy
Byte Buddy 是一个用于 Java 虚拟机的运行时代码生成工具 – > 它很稳定,并被 Mockito、Hibernate、Jackson、Google 的 Bazel 构建系统等著名框架和工具所使用。Byte Buddy 还被大量商业产品使用,并取得了巨大成功。目前,它每年的下载量超过 7500 万次。
如果你真的想深入研究这个问题,虽然应用程序有很多案例,但不要忘了 “每个人 ”都依赖的底层库。
从某种意义上说,无处不在的 “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)
PCRE https://github.com/PCRE2Project/pcre2/issues/426
对这一主题进行了一些研究:
https://www.researchgate.net/publication/308894462_What_is_t…
编辑:我漏掉了 “广泛使用 ”部分。
[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…),让它们变得更无障碍。
我想到了 GnuPG 和 Werner Koch,10 年前有这样一个 HN 主题 https://news.ycombinator.com/item?id=9003791
我还想到了 FFMpeg 的 Fabrice Bellard 和他的项目。
我可能也说错了。
相当臭名昭著的 Liblzma。
不仅是软件,还有基础设施和协议: N.T.P.: – https://www.newyorker.com/tech/annals-of-technology/the-thor…
我觉得读起来很不错!
OmegaT 在专业翻译领域被广泛使用,由一人维护,只有极少数活跃贡献者(本地化人员除外)。
https://omegat.org
VLC – VideoLan
https://github.com/orgs/videolan/people
在我的记忆中,GnuPG 在一段时间内也是一个人的乐队。
Mocha js 测试框架被广泛使用,由一个小团队维护 https://github.com/mochajs/mocha/issues/5027
Jia Tan 正在寻找新项目?
不是很典型的 “广泛使用 ”项目,但最近安装量超过了 10 万+,有两个人兼职工作。
https://github.com/heyform/heyform
外籍人士
LibreSSL
Linux-PAM
OpenSSH
re2c
tzdata
zlib
这些只是我想到的。
不错的清单。有时最简单的贡献方式就是捐点钱,这样现有的维护者就可以继续专注于他们的工作。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
我没想到 IANA 还贡献了 debian 软件包和 rpms。/s
他们负责维护列表,但必须有人来打包。
请链接如何为 Debian 做贡献:https://www.debian.org/devel/join/
Coolify! https://github.com/coollabsio/coolify
以前也观察到过这种情况 https://xkcd.com/2347/
Kapitan
https://github.com/kapicorp/kapitan
wireguard [1] https://www.wireguard.com/repositories/
dnsmasq。在数十亿台设备(包括 Android)上运行,一个人(Simon Kelley)。
e2fsprogs (https://github.com/tytso/e2fsprogs) 是一个广泛使用的工具套件,用于创建、维护和修复 ext2、ext3 和 ext4 文件系统。
quic-go:https://github.com/quic-go/quic-go/
丰富。每月下载量达 1.97 亿次。有两名维护者。
Imagemagick
查看拉威尔的成功经验 https://github.com/laravel/laravel
flex 和 bison。尤其是 flex,似乎几乎无人维护。
husky (git hooks) https://github.com/typicode/husky
php语言
我很惊讶听到这个消息,有更多信息吗?
这是错的,至少不是我定义的少数人。
https://thephp.foundation/structure/
“核心开发人员 PHP 基金会与 10 名全职和兼职工程师签订了维护和开发 PHP 语言的合同。
在 PHP 上有很多人在做(好的、有价值的)事情,但对引擎有深刻理解的活跃人士却屈指可数。(我过去为引擎和其他部分做了一些小贡献)
Nikita Popov (nikic) 就是其中之一。当他离开 JetBrains 去做其他项目时,PHP 的核心开发受到了重创。
更不用说所有的志愿者了。
FastAPI
都是比较好的。维护者越多,质量就越低。直至彻底毁灭
zlib: 马克-阿德勒
ncurses/xterm: 托马斯-迪基
所有这些
看到拉威尔的成功
我知道的大多数项目:-)
curl
谷歌的 leveldb
学术界经常有人问这个问题。这个系统几乎是在鼓励创造重复软件和/或对某一领域或利基市场至关重要的废弃软件,因此有大量这样的软件(也有大量非常好的稳定软件,但暂时不考虑这个问题)。这使得新的参与者很难找到他们可以信赖的开源软件,资助者也很难决定支持什么软件,机构也很难跟踪他们的贡献等等。
我正在开展一个项目,以解决这个具体问题(以及许多其他问题),该项目横跨开源和开放科学生态系统,从开源研究软件开始,但最终打算触及整个领域。除其他外,我们希望对开源项目的健康状况、开源项目的使用情况、对开源项目的看法、“开源项目的影响 ”以及开源项目的需求进行持续测量。我们正在将数据收集与语法标记和最终的信任网结合起来。
该项目由 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
bash
dokku
酿酒
Homebrew 有大量的维护者。有些人随着工作重点的改变而离开,但也有一些人加入。
https://github.com/Homebrew/brew#who-we-are
brew 公式由许多人维护,“brew ”命令行工具有数十名贡献者,提交次数超过 100 次。
Linux 内核
这与事实大相径庭。1900 多人为最新版本做出了贡献。
https://lwn.net/Articles/981559/
提交者多到维护者无法控制质量。
对于这样一个大项目,稳定候选版本的测试人员也非常少。
人们曾经为上游工厂把用过的干净水退还给河流而斗争。这是生态学家的斗争。
现在,公司做的项目预算中都有 5 个或更多的零,而且有很大一部分代码是自由软件或开放源代码。而他们对自己寄生的自由或开放项目的回报却是零。
几年前,我在自己的博客上写过一篇文章(西班牙语,抱歉),“自由软件已经失败”:https://tomatesasesinos.com/2019/07/11/el-software-libre-ha-…
我认为这属于 “Show HN: My Tangentially Related Thoughts”(展示 HN:我的切身相关想法)。