开源的开放性如何？
Michael DeHaan 发表了一篇题为“开源的开放性如何？”的优秀博文。我敢说这是他最好的一篇文章，尽管其中夹杂了一些（Linux）发行版偏见的评论。他提出了一套社区标准，用于衡量开源的真正健康和开放程度。在我看来，目前 OSI 的一个主要问题是，它（主要是无意地）使人们认为仅仅一个许可证就能使某事物成为开源。在我看来，开源许可证实际上是使软件开源的第一步。从根本上说，许可证提供了“分叉权”，以防“仅许可证开源”的运营者忽视社区。然而，分叉是一个相当浪费的过程。它会造成损害。在最好的情况下，大多数人会用脚投票。在最坏的情况下，最终会出现 2-3 个资源不足的项目。分叉是合作的进化和革命性替代方案。
许多“新晋”开源公司和“老牌”科技公司都参与到开源结构中，很大程度上是为了保持控制。这可能是出于多种原因，但一个主要原因是开源本身并不是一种商业模式。软件开发确实需要资金和资源。找到正确的资金筹集方式很困难。传统思维是划分一部分“资产”并收取入场费。然而，在这个过程中，你会削弱开源的一些优势。你会失去合作的协同效应。这些是华尔街的金鹅。这就是为什么，尽管经历了所有的失败，每个人仍然在寻找下一个数十亿美元的合并案。我们必须质疑，仅许可证开源的软件，其发行和合作特性（*1）与专有软件相同，是否真正实现了开源的许多好处，直到有人分叉它。这真的是开源，还是仅仅是潜在的开源？我保证这与你的开源供应商营销部门告诉你的不一样。
Michael 的博文 提出了可以总结和分类（底部附有注释和示例）的标准，如下：
项目健康
- 1. 临界规模 – 足够大的用户群来维持项目。
- 2. 问题跟踪 – 一个清晰的问题跟踪系统，允许每个人报告和跟踪错误、功能和任务的状态。
- 3. 用户拥护 – “你的用户正在与其他潜在用户谈论你的软件。”
协作
- 4. 开放论坛 – 一个开放的参与论坛
- 5. 参与式决策 – 决策在开放论坛中进行，没有单独的等级（内部列表）。
- 6. 外部参与 – 许多项目是由某些组织发起或资助的。衡量项目健康和生命力的一个关键指标是，组织外部的人员是否真的在提交补丁。这不仅仅是用户参与，而是外部开发人员。Michael 说得最好：“[要]做到这一点，你首先需要拥有快乐的用户和一个感觉他们可以提问并参与进来的社区。”
- 7. 网站导航快速引导至代码和发行版 – “在你的网站上很容易找到你的许可条款和下载代码的位置。如果不容易找到，那么你对开源的定义很可能就是‘你可以下载代码’，但开源开发模式并没有得到很好的遵循。开源不是你放在‘立即付款’页面上的一个功能，而是你每天都在做的事情。而且这不仅仅是关于代码，还关于过程。”
- 8. 欢迎来自潜在竞争对手的补丁 – *2
- 9. 上游补丁 – 许多开源软件都是基于其他开源软件构建的。整个社区健康的一个关键因素是，贡献是否可以从项目（例如 Ubuntu）向上游回流到它包含的软件包（例如无线驱动程序）。*3
- 10. “你的‘东西’的每一部分都是开源的 – 拥有非开源的‘专业’版本意味着你的高级功能无法从社区效应中受益。” *4
组织
- 11. 未经请求的补丁易于集成 – 一些项目有强大的上游，但在任何给定的发布周期内都无法集成新想法。开源的一个关键优势是这种参与式的适应性。你可以贡献代码，而无需等待供应商在他们的长期计划中考虑清楚。
- 12. 发布计划 – “你的用户知道你的未来发布计划是什么。”
- 13. 细粒度参与 – 无需加入委员会或人类已知的最高流量邮件列表即可参与的能力。
正如 Michael 总结的那样，“底线结论：努力在你所做的一切中保持开放”。
那么你认为呢？OSI 是否应该制定超出当前以许可证为中心的、被称为“开源定义”的标准集之外的标准？
注释
- 1. 向供应商提出请求或付费。
- 2. 我们最近在微软对 ADODB 的补丁中看到了一个有趣的例子。
- 3. 例如，JBoss 应用服务器包含来自 Apache 的许多软件包。Ubuntu Linux 发行版包含大量 Debian 软件包以及来自许多其他组的软件包。
- 4. Adobe Flex 是一个关键的例证。尽管 Adobe 从许可证的角度开源了 Flex，但如果没有专有运行时，你就无法运行 Flex 应用程序。有一些自由/开源的努力，例如 Gnash，但这些努力在一个真空环境中运作，并且 Flex 应用程序通常需要相当现代的 Flash 版本。另一个例证是 Sun 发布的 OpenJDK，其中包括 受限许可证下的二进制文件。Iced Tea 解决了这个问题……实际上是一种分叉。