以下是开源项目 ToolJet 是如何在一年的时间里取得 13000 颗星标和 200 个贡献者的故事。

ToolJet 是一款开源的低代码框架，用于快速构建和部署内部工具。它的代码库完全由 JavaScript 和 TypeScript 组成。

2021 年 4 月，一名开发者独自开始了 ToolJet 的开发，并于 2021 年 6 月推出公测版本，一炮而红。此后，ToolJet 成立了基金会。目前，我们已经有一个 20 人的开发团队。

为什么选择开源

在开发 ToolJet 之前，我曾担任一些企业客户的顾问。这些客户中的许多都庞大到足以维护构建几十个内部工具。尽管来自销售人员、支持人员以及运营人员不断要求对内部工具添加更多功能和修复错误，但开发团队却很难有精力来开发内部工具。

我尝试使用过多个平台来构建和维护内部工具。这些工具大多非常昂贵，而且经常不符合要求。我们需要进行修改，而且大多数工具不支持内部托管。

作为一名 Ruby 开发者，我最初使用 ActiveAdmin 和 RailsAdmin 来构建内部工具。这两款工具都是极好的，只是将它们应用在使用多个数据源的任务上比较困难。于是我意识到市场上需要一种可以构建用户界面，并能够连接多个数据源的框架。我相信任何为开发者制作的工具都应当是开源的。开发者日常使用的大部分工具与框架都源自世界各地人们的公开协作。

第一次提交

制作像 ToolJet 这样的工具需要全身心的投入，通过出售我的一个业余项目，我获得了五六个月的空闲，于是我立即着手将在我脑海里酝酿了两年的想法付诸现实。

2021 年 4 月 1 日，我完成了 ToolJet 的第一次提交（使用 rails new 命令）。

稍等！我刚刚说 ToolJet 的代码是完全基于 JavaScript 的？请接着往下看。

构建完成并推销给投资者

4、5 月间，我一直坐在电脑屏幕前编写代码和向种子轮的投资者推销我的工具。

我的工作还包括创建拖放式应用程序构建器，撰写所有的文档以保证有在主流平台上设置 ToolJet 的文档，创建项目网站，制作发布时所需的海报以及博客文章等等。这一过程进展顺利，没有遇到大的挑战。当时，ToolJet 的前端使用的是 React ，而后端则用的是 Ruby on Rails 。

编程工作进行得很顺利，然而向投资者推广的工作进行得并不顺利。我向专注于初创时期投资的风投和天使投资人发送了大约 40 封电子邮件，都石沉大海。大部分邮件都被忽略了，不过也有一些公司向我说明了拒绝的原因，另外一些则给我回了电话。

大部分的电话内容都是一样的：我无法说服他们接受开源商业模式。

工具发布

6 月 7 日是发布日。我们首先在 ProductHunt（LCTT 译注：ProductHunt 是一个新品发布平台）上发布。六个小时后，只有 70 名用户注册。但是我们有成为当天第一名产品的趋势（最终在那一周的产品中排名第三）。这里是原始的 发布帖。

下午 6 点左右，我又在 HackerNews 上发帖，一个小时内，这个帖子便升至榜首。大量的访问者注册并给我的版本库点亮星标，我对此很高兴。许多访问者和用户报告了软件和文档中的错误。距离在 HackNews 上发帖八个小时之后，超过 1000 名 GitHub 用户给 ToolJet 的 GitHub 版本库点亮了星标，并且有数百人注册了 ToolJet 云。上升趋势一直持续到三天后，ToolJet 版本库总计得到了 2400 个星标。

获得资助

ToolJet 项目在 GitHub 上的吸引力足以被风投（VC）世界注意到。发布之后的日子被各种来电挤满了。我们也有其他的选择，但从没有认真考虑过这些它们。这些选择包括：

• 引导性融资：在项目初期，难以获得付费用户，而我此前也没有足够的储蓄来支撑整个项目。
• 作为业余项目：在开发小型项目上这是可以的，但我不认为这在 ToolJet 的开发上行得通，毕竟在 ToolJet 平台能够为客户所用之前，我们需要创建大量的集成和 UI 控件。作为一个业余项目，要实现这些可能需要花费数月甚至数年时间。

我知道如果将 ToolJet 作为一个业余项目来开发，我可能需要花几个月的时间才能达到我期望的程度。而我希望通过扩大团队加速项目的成熟。鉴于该项目的吸引力，引入风险投资（VC）的资助是显而易见的选择。

好消息是在 HackNews 上发布之后的两周内我们成功募集了 155 万美元的资金。

在开源中积累很重要

发布后不久，我们发现许多人希望为 ToolJet 项目做贡献，但是他们几乎都是 JavaScript 开发者。我们也意识到像 ToolJet 这样的项目在未来会有成百上千的数据接口，只有基于插件的架构才行得通。我们于 2021 年 8 月决定从 Ruby 迁移到 TypeScript 上来。即使这花费了一个月的时间和巨大的努力，这仍然是我们在 ToolJet 项目上作出的最正确的决定。今天，我们有一个由我们的 插件开发套件 支持的可扩展的基于插件的架构。我们获得了来自超过 200 名开发者的贡献。关于这次迁移的文章参见 这篇博客 和 另一篇博客。

发布 v1.0 版本

自 8 月份以后，很多用户已经在生产环境中使用 ToolJet ，该平台并没有出现过任何稳定性或扩展性的问题。我们准备在发布 v1.0 版本之前完成开发人员平台的功能。开发人员平台允许任何 JavaScript 开发者构建和发布 ToolJet 插件。这样开发人员就可以为 ToolJet 开发数据接口。把集成测试的时间算上，创建一个 ToolJet 接口的时间也只需要30分钟。

创建持续成长的社区

我们没有在销售上投入资金，我们的大部分精力都放在了传播 ToolJet 的消息、撰写我们的经验教训以及维持开发社区的活跃上。我们有一个关注社区里问题的三人团队。

商业模式

如果没有 商业产品 来支付账单，ToolJet 就无法成为一项可持续的业务。我们构建了 ToolJet 的客户付费的企业版本。ToolJet 的免费的社区版本没有任何使用限制，企业版中的额外功能都只与大型团队有关。我们现在的客户已经有超大型公司。我们有足够的银行存款来打造更好的 ToolJet ，因此我们目前正聚焦于产品提升上。

接下来做什么

我们在开源社区的不断反馈和贡献的帮助下，我们可以经常性发布更好的 ToolJet 版本。很多主要的优化、大量的数据接口以及 UI 组件正在开发进程中。我们正以前所未有的速度朝着我们的最初目标前进，即成为一个可以连接到数百个数据源和构建最复杂的用户界面的开源框架。

via: https://opensource.com/article/22/10/tooljet-open-source-journey

作者：Navaneeth PK 选题：lkxed 译者：CanYellow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

林纳斯定律 Linus's Law 即“ 只要有足够多的眼睛关注，任何漏洞都无处隐藏 given enough eyeballs, all bugs are shallow ”。那么林纳斯定律是如何应用于开源软件安全的呢？

这篇文章讨论 Linux 对开源软件安全的影响。

开源软件的一个常被赞扬的优点是它的代码能够被任何人审查（安全专家通常称之为“代码审计”）。然而，如果你真的去问很多开源软件用户他们上一次检查代码是什么时候。你大概只能收获他们茫然的眼神或者是喃喃的低语。此外，对于一些相当大型的开源应用，有效地审查每一行代码也是困难的。

根据上述这些稍显不安的事实，我们不得不思考：如果没有人察看这些代码，它是开源还是闭源真的有关系吗？

你应该相信开源吗？

计算机爱好者倾向于作出认为开源软件比其他软件更加安全的传统假设。我们通常不会讨论这意味者什么：比较的基础是什么（比什么“更”安全？），或者上述结论是如何得到的。这是一个危险的陈述，因为它表明只要你将一些东西称之为“开源”，它就自动如魔法般地继承了更高的安全性。这不是开源，事实上，这正是开源安全非常反对的。

除非你已经亲自审计并理解了软件代码，否则就不应该假定一个应用程序是安全的。一但你做到了这一点，就可以给予它 终极信任 ultimate trust 。终极信任 不是对计算机而言的，而是对你本人而言的，至少在这一应用程序被渗透攻击之前，你信任它是因为你选择了相信它是安全的。

使用者本人是唯一可以对软件代码给予终极信任的人，因此任何人想要获得这样的享受都必须亲自审查代码。相信其他人的话是不管用的。

在你已经亲自审计并理解了软件代码之前，你对一个应用程序给予的最大信任度是一个范围，可以是从 根本不信任 到 相当信任 之间。然而我们并没有一个关于信任程度的标准对照表，这是一个你必须亲自做出的个人选择。如果你已经从非常信任的人那里听说了一款应用程序是安全的，那么你可能会更信任这个软件，而不是信任那些你没有得到信任建议的东西。

然而，因为无法审计专有（闭源）软件代码，你不可能给予它 终极信任。

林纳斯定律

现实很骨感，并不是每个人都是程序员，同时也不是每个程序员都有时间检查数以万计的代码行。因此如果你没有亲自审查代码，你就只能选择（一定程度上）相信那些 亲自 审查了代码的人。

那么，有哪些人会审查代码呢？

林纳斯定律声称 只要有足够的眼睛关注，任何漏洞都无处隐藏，然而我们并不知道多少双眼睛是“足够”的。请不要低估这一数量，应用程序往往经过了远超你想象数量的人员审查。原始开发人员以及后续开发人员显然清楚他们自己写下的代码，不过开源软件往往都是团队成果，开源时间越长，阅读了代码的开发人员越多。新加入的开发人员也必须回顾项目代码的核心部分，因为他们必须学习基础代码以加入新的功能。

同时，为了使开源软件能够在 Linux 发行版上可用，负责开源软件打包分发的开发人员会加入多个项目。有时一个应用程序可能会在不熟悉项目代码的情况下打包，但是大多数时候，开源软件打包人员都是熟悉所打包的项目代码的。这不仅仅是因为他们不想在他们不信任的软件上签名，还由于他们可能不得不修改代码来使得程序能够正确编译。漏洞报告人员和漏洞修复人员一般也是熟悉代码库的，因为他们需要尝试解决小到运行异常，大到程序崩溃的问题。当然，一些漏洞报告人员不是通过亲自审查项目代码，而是通过关注明显未按预期工作的现象，无意中揭示了代码漏洞。系统管理员通常都是通晓用户依赖的重要应用软件的代码的。最后，还有一些安全研究人员，他们专门深入代码内部以揭露潜在的漏洞。

信任与透明

很多人先入为主的认为大型软件的审计是基本不可能的，因为它由数以万计的代码行组成。不要被软件运行所需的代码量欺骗了。我们不需要真的阅读数以万计的代码行。代码是高度结构化的，可被利用的代码漏洞仅仅只是其中的一行，不过它通常影响软件的全部功能。

当然，也有例外。有时仅仅一个系统调用或者链接一个有缺陷的库文件就可能引入一系列漏洞。幸运的是，多亏安全研究人员以及漏洞数据库所扮演的积极角色，这些错误相对而言是容易发现的。

一些人指着错误追踪系统，比如 通用漏洞披露 Common Vulnerabilities and Exposures （CVE）网站，并推断开源软件显而易见是不安全的。毕竟已经向公众公开了大量的安全风险，涉及许多开源项目。但是不要被数据欺骗了。只是因为我们看不到现闭源软件的漏洞，并不意味着闭源软件中不存在漏洞。事实上，已经有很多针对闭源软件的漏洞攻击提出了，闭源软件也是存在漏洞的。区别在于开发者（以及用户）可以查看开源软件的 所有的漏洞 从而降低漏洞的影响。这是扩大对开源软件信任的系统机制的一部分，却正是闭源软件软件所缺少的。

对于任何代码而言，可能永远没有“足够的眼睛”来发现漏洞，但是开发社区越壮大、越多样化，越有机会发现和修复代码中的缺陷。

信任与人

在开源社区中，参与同一项目的众多开发者已经发现“不安全”的漏洞，却保持沉默的的可能性是微乎其微的，因为人们很少同意以这样的方式合谋。我们已经看到了在应对 COVID-19 的过程中，人类的行为是如何不一致了，在这里也一样：

• 我们都发现了漏洞（病毒）。
• 我们知晓如何避免它传播（待在家里）。
• 然而病毒还是在持续传播，因为总是有一个或者多个人偏离了消减疫情的计划。

开源软件中的漏洞也一样，如果有人发现了漏洞总会公之于众（当然，我们说的是“假如”能够发现）。

然而就专有软件而言，有很大可能参与项目的众多开发者即使注意到不安全的漏洞却仍然保持沉默，因为专有模式依赖于薪水。如果一个开发者将漏洞泄漏出来，他可能只是伤害了该专有软件的声誉，进而降低软件的销售额；或者，在更糟糕的情况下，他可能因此而丢了工作。开发人员拿着薪水秘密地研究软件，往往不会谈论其缺陷。如果你曾经是一名开发者，你可能曾经签署过 NDA （LCTT 译注： 保密协议 Non-Disclosure Agreement ），也被培训过商业秘密的重要性，等等不一而足。专有软件鼓励在面对严重的秘密缺陷时保持沉默，更多时候甚至是强制要求沉默。

信任与软件

不要信任未经你审计的软件。

如果你必须相信未经你审计的软件，那么选择相信已经面向那些更有可能将软件缺陷公之于众的开发者公开代码的软件。

开源软件并没有比专有软件继承更高的安全性，但是修复它的系统得到了更好的规划、实施和人员配置。

via: https://opensource.com/article/21/2/open-source-security

作者：Seth Kenlon 选题：lujun9972 译者：CanYellow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Stack Overflow 临时封杀 ChatGPT

OpenAI 的新通用聊天机器人原型 ChatGPT 过去几天风靡互联网，它在解决各种问题上的能力使其可以部分替代谷歌等搜索引擎和 Stack Overflow 等编程问答社区。Stack Overflow 上也涌入了数以千计的用 ChatGPT 回答的问题，但由于 ChatGPT 给出的答案正确性太低，发布的人也缺乏专业性，甚至也不愿意验证正确性，对寻求正确答案的用户来说是有害的。Stack Overflow 因而发表声明，宣布临时封杀 ChatGPT。如果用户被发现使用 ChatGPT 回答问题，他们可能会受到禁止继续发帖的惩罚。

消息来源：Stack Overflow

老王点评：虽然 ChatGPT 能做到一些令人惊讶的对话，但是本质上并不是有效的知识和思考，因此，这些似是而非的回答确实可能会毁了寻求答案者的信任。但是，有个问题是，Stack Overflow 如何识别这些以假乱真的回答？

开源软件托管商 Fosshost 关闭，CEO 失联

非盈利托管商和云计算服务商 Fosshost 免费托管了多个知名的开源项目，其中包括 GNOME、Armbian、Debian 等项目的部分内容，不过，GNOME 和 Debian 的核心基础设施并不依赖 Fosshost。Fosshost 发布了即将下线的公告称，由于情况超出了志愿者的控制，服务器无法保证能继续上线，他们预计将会很快下线。据称下线原因是控制着银行账号和资金的 CEO 已经失联了六个月，以至于无法支付服务器托管费用。

消息来源：Solidot

老王点评：本来很好的开源项目，却由于不良的管理而导致结束。希望有开源基金会或科技企业可以伸出援手。

PyTorch 终于进入 2.0，性能大幅提升

在 2021 年，开发者们对 PyTorch 1.10 是否应该被标记为 2.0 版本进行过简短讨论。当时认为 PyTorch 1.10 与 1.9 相比没有足够的根本性变化，不值得将其升级到 2.0 的主要版本号。但现在，开发者们认为是 PyTorch 2.0 的正确时机，因为该项目引入了一个新模式，称为 torch.compile，大幅提升了速度。经验证，在 2.0 试验版的大约 160 个开源模型上，速度提高了 43%。

消息来源：Venture Beat

老王点评：虽然有部分代码是 C++ 写的，但是能取得这样的性能提高也非常可观。

新的包管理器让开源贡献者得到报酬

MacOS 包管理器 Homebrew 的创建者新开发了一个名为 Tea 的包管理器，作为 Homebrew 的最终继承者。Tea 除了一些包管理器的新功能之外，还有一种基于区块链的方法，以确保开源软件的创造者、维护者和贡献者都能为他们的努力获得报酬。他从 NFT 中获得了灵感，简单来说，关注开源软件生态健康的人可以购买通证并质押，而 Tea 作为一个 DAO 会奖励质押者和注册的软件包及其依赖关系的贡献者。

消息来源：Stack Overflow

老王点评：一个探索的方向，不过我不是很看好。

协调世界时将停止添加“闰秒”

11 月 18 日，全球代表在计量大会（CGPM）上投票决定，“从 2035 年起，将搁置在官方时钟上增加‘闰秒’以使其与地球自转同步的做法。”这意味着从 2035 年开始，或者可能更早，天文时间（称为 UT1）将被允许与协调世界时（UTC）相差一秒以上，甚至多达一分钟，而协调世界时是以原子钟的稳定滴答为基础。添加闰秒的做法始于 1972 年。

消息来源：《自然杂志》

老王点评：添加闰秒给互联网服务和各种依赖精确计时的服务带来很多麻烦，而且我们可能还面临着史无前例的负闰秒。取消了也好。

GIMP 2.99.14 发布

这是迈向 GIMP 3.0 的最新开发版本，GIMP 3.0 将从 GTK2 切换到 GTK3 工具箱，并有大量仍在开发中的其他改进。此版本的具体改进没有什么太值得说的，在发布公告中说，“从 3.0 的路线图中可以看出，大多数项目都‘接近完成’或‘已经完成’。……真正接近了 GIMP 3.0 的发布。……开始针对具体的痛点，很多痛点。”

消息来源：Phoronix

老王点评：我觉得需要大伙帮忙砍一刀。

开源代码可能是当今大多数公司最可行的选择，但它也伴随着自己的问题。

许多人支持使用 开源软件 open source software （OSS）。毕竟，我们为什么要不断地尝试构建代码来解决别人已经解决过的问题？为什么不分享信息并逐步和迭代地增强当前的开源解决方案呢？这些 平等主义价值观 egalitarian values ，可能是整个文明的根本，更不用说软件了，但还是包含了几千年来一直存在的冲突。

开源软件安全的问题在于，尽管任何人都可以查看源代码，但这并不意味着他们会这么做。有一些广泛使用的开源项目仅由数量有限的工程师维护。这些工程师无法完全自愿地提供时间和精力，因为他们也需要支付他们的账单。

即使对于更复杂的开源项目，这也是一个问题。举个例子，Linux 内核项目由 3000 多万行代码组成，包含数百个需要解决的缺陷，并有近 2000 名活跃的开发者。每个活跃的开发者都写了超过 15000 行的代码。

根据 Linux 基金会最近的一项研究，一个应用程序平均有 5.1 个重大漏洞仍未解决，41% 的企业对其开源软件的安全性缺乏信心。而更糟糕的是，只有 49% 的企业拥有开源安全策略。

即使开源软件有安全漏洞，这也不能保证它能被修复。调查显示，目前修复一个漏洞平均需要 97.8 天，使使用该软件的企业在几个月内容易受到攻击。这就是开源软件安全有时被忽视的地方：就像好人可以寻找代码中的错误和漏洞来修复它们一样，坏人也可以寻找同样的漏洞来利用它们。

仅仅依靠志愿者社区来发现漏洞、报告漏洞和修复漏洞是一个漫长的过程。在你继续受益于开源的广泛优势的同时，花钱请人检查你的开源解决方案的安全性可以帮助弥补这个问题。

由于必须部署开源软件的更新和补丁以保证系统的安全，这一要求会带来独特的困难。如果你的解决方案依赖于某个软件版本，更新你的关键任务软件可能会导致功能损失和/或计划外的停机。当情况对业务至关重要时，聘请专家来回传补丁并维护一个时间更长的版本可能比让大型社区愿意去做更加优雅。

开源社区经常使用的一句话是：“这是开源的，去改变它吧！”它强调了一个关键点：当别人在项目中投入时间、精力或金钱的时候，期望白白得到良好的安全水平是不合理的，也是不可持续的。

要么按原定计划为开源做出贡献，改进代码并为他人发布，要么聘请专业人士管理开源代码并在必要时进行调试，这些都是选择。然而，这个行业无法承担完全不做贡献。

via: https://www.opensourceforu.com/2022/10/security-issues-with-open-source-in-todays-world/

作者：Laveesh Kocher 选题：lkxed 译者：KevinZonda 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

对开源仓库的攻击越来越频繁了。

根据近日的研究，由于越来越多的企业使用开源代码仓库来开发他们的软件及解决方案，网络犯罪分子正在借此获利。根据软件供应链管理服务提供商 Sonatype 最近所做的研究，在最近三年里，受感染的软件包、以及对这些软件平台的 仿冒攻击 typosquatting assaults 和类似的黑客攻击的频率大幅增加。

该企业在过去三年中发现了大约 95000 个有害软件包，以及超过 55000 个最近才使用他们的存储库防火墙公布出来的危险软件包。届时，这个数字在三年内平均增长了 700%。

该企业称，他们的存储库防火墙将通过融合行为分析和自动策略执行的方式，不断发现并阻止有害软件包及潜在的易受攻击的组件。此外，它还使用了人工智能对每个新发布的开源软件进行评估，看它是否会带来一些安全风险。而且该企业断言，由于开源代码的迅速增加，人工分析已变得几乎不可能。

然而，这与企业是否在它的最终产品中包含受感染的恶意组件无关。该公司声称，如果那些恶意组件已经被下载到他们的端点上，就已经太晚了。

“恶意网络攻击的数量、频率、严重性和复杂性还在增长。但企业不能，也不应该仅为保护自身而避免使用开源代码。” Fox 补充说：“但他们可以使用预防性的工具，例如 Sonatype 防火墙来保证开发人员的工作进度和软件供应链的安全。”

via: https://www.opensourceforu.com/2022/09/attacks-on-open-source-software-are-on-the-rise/

作者：Laveesh Kocher 选题：lkxed 译者：自由的铁矿 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出