使用专有服务开发开源软件

339 位读者喜欢这个。
A fortune cookie that says "to succeed, you must share"

Opensource.com

现在人们普遍认为,开源是生产软件的更优方式。几乎每个人都在做开源。特别是,用户能够查看内部机制并进行更改的能力,使得工具能够更好地适应他们的工作流程。这降低了被供应商锁定在不平衡关系中的成本和风险。这有助于持续改进的良性循环,模糊了消费者和生产者之间的界限。它使每个人都能够重新组合和发明新事物。它增加了共同的人类知识。

然而

然而,许多开源软件是在运行闭源代码的专有服务上(以及在它们的帮助下)开发的。无数的开源项目是在 GitHub 上开发的,或者借助 JIRA 进行错误跟踪,Slack 进行通信,Google Docs 进行文档编写和共享,Trello 进行状态看板。这听起来有点自相矛盾和虚伪——有点太“只许州官放火,不许百姓点灯”了。这是为什么呢?如果我们都同意开源有如此多的实际好处,为什么我们如此愿意在使用它来生产开源软件的工具上放弃这些好处呢?

但是它是免费的!

通常的论点是这样的:这些平台可能是专有的,但它们提供了强大的功能,并且它们是免费提供给我的开源项目的。我为什么要费力设置、维护和付费基础设施来运行功能较少的解决方案呢?或者我为什么要付费让别人为我托管它呢?诀窍在于,正如俗话所说,当产品是免费的,就是产品。在这种情况下,你的开源社区就是产品。

在最坏的情况下,你的社区成员的个人数据和活动模式将被出售给第三方。在最好的情况下,你的开源社区被强行征募到一支军队中,这支军队进一步增强了网络效应,使得下一个开源项目更难不使用该专有服务。

在所有情况下,你作为一个项目,决定不承担直接成本,而是要求你的每一位贡献者间接支付它。你强迫你所有的贡献者接受专有服务不断变化的条款,以便参与你的“开放”社区。

认识到权衡

重要的是要认识到这种情况的本质:一种权衡。一方面是闪亮的功能和便利性。另一方面是通过特定功能、数据格式、专有协议或仅仅是旧的网络效应和习惯来锁定你的社区。

每种情况都不同。在某些情况下,专有服务和开放平台之间的差距会非常大,以至于承担成本是有意义的。Google Docs 在它所做的事情上做得很好,当我协作处理比 Etherpads 或 Ethercalcs 更复杂的事情时,我发现自己会使用它。在光谱的另一端,当你可以使用 Framadate 时,真的没有理由使用 Doodle。同样地,Wekan 与 Trello 非常接近,你真的应该考虑它。对于 Slack 与 Mattermost 与 IRC 相比,权衡更加微妙。

作为旁注,当专有服务建立在标准协议之上时,锁定的成本会大大降低。例如,Gmail 不是什么大问题,因为它很容易使用 IMAP 来集成它(并可能在未来摆脱它)。如果 Slack 只是一个使用 IRC 协议和服务器的出色自以为是的客户端,那么它也不会成为什么大问题。

部分解决方案

对于这种权衡,任何简单的答案都将是教条式的。如果你使用专有服务,你并不是不纯洁,如果你为你的项目基础设施使用开源软件,你也不是在戴着有色眼镜。每个社区都会根据他们的根基和历史,以不同的方式回答这种权衡。

重要的是要承认没有什么东西是免费的。当做出选择时,我们都需要意识到我们获得了什么,又失去了什么。总之,我认为我们都可以同意,在所有其他条件相同的情况下,当存在具有专有产品所有功能的开源解决方案时,我们都更喜欢使用它。推论是,当这些开源解决方案变得更好时,我们都会受益。

因此,为了成为解决方案的一部分,请考虑帮助这些开源项目构建像专有替代方案一样好的东西,特别是当它们在功能方面非常接近时。这将使解决这种权衡变得容易得多。

本文最初发布在 ttx:reloaded 上,并经许可根据 CC BY-SA 4.0 许可重新发布。

User profile image.
Thierry Carrez 自 OpenStack 项目成立以来一直担任其发布经理,协调工作并促进贡献者之间的协作。他是 OpenStack 技术委员会的当选主席,该委员会负责项目的技术方向。

4 条评论

我们越来越多地面临闭源软件的一个问题是,企业家渴望获取关于我们的信息并从中赚取额外收入。典型的 EULA 非常宽泛,但在细节上却很模糊,所以你不知道你放弃了什么权利。
个人可能没有能力搜索使用开源软件的意外后果,但是当代码可用时,你可以合理地确定会有人查看它以了解它的工作原理。

很高兴看到这篇文章 - 我一直对许多社区中这种明显的矛盾感到震惊,这些社区提倡“开放”,但要求社区成员采用专有(封闭)工具才能参与... 我倾向于从头开始采用开放工具,*在可能的情况下*。我也认为有一种新兴的公理(请随意反驳这一点,我很想听听相反的论点):“权宜之计是原则的敌人”。我认为选择封闭来促进开放有点虚伪。(并且,为了记录,我们广泛使用 FOSS 工具,如 OnlineGroups.net、Rocket.Chat、Wekan 和 Kanboard、Gitlab 等 - 使用“开放”工具不是倒退。)

非常感谢这篇文章!非常好。

作为一名自由软件开发者,我正面临这些问题。
我正在开发一个 AGPLv3 Git 托管解决方案 (https://rocketgit.com),我担心没有人会使用我的解决方案,因为市场充满了闭源解决方案。或者免费核心解决方案,在我看来同样糟糕。

谢谢!

对于任何对使用专有工具的良好运行的开源项目表示怀疑的人,要问的第一个问题是:你使用 Mac、Windows 还是商业 Linux 发行版?如果是这样,你为什么要使用那个专有工具?

如果意识形态的纯洁性是你的主要目标,那很好,但对于大多数开源社区来说,目标是 1) 制作对你来说有用的软件,以及 2) 尝试鼓励其他人为你的项目做出贡献。对于任何独立或小规模的 FOSS 项目,你可能也在廉价地做这件事。因此,使用对你现有社区最*有效*的任何工具都是一个不错的选择 - 无论是否专有。

因此,许多 Apache 项目使用 JIRA,因为该制造商已向 ASF 捐赠了免费许可证以运行该强大的问题跟踪器。它在易于管理的平台(记住:ASF 为此运行自己的服务器)中具有比其他开源替代方案更多的功能,因此非常值得使用,以便为我们的项目社区提供功能。

有很多公司会向真正的 FOSS 社区捐赠以开发为中心的软件许可证,因此如果你在市场上,值得四处询问。

但我同意:这取决于专有工具*如何*影响你的贡献者的工作流程。任何 1) 对开发者来说成本高昂,或 2) 迫使项目开发周期锁定在该单一供应商中的任何事物都绝对是一种危险 - 无论是对今天吸引新贡献者,还是对你的项目在供应商提高价格时的寿命而言。

对本文的后续:提出了一个很好的观点,即任何使用专有工具的 FOSS 社区都应该进行研究并解释*为什么*这是一个好主意,以及它如何/是否影响贡献者的知识产权。社区收集这项研究并呈现它比希望每个潜在贡献者都这样做要容易得多。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可获得许可。
© . All rights reserved.