当我们思考一个开源项目要运作需要什么时，首先想到的可能是许可证。首先，如果没有经过批准的 开源倡议组织 (OSI) 许可证，在许多人看来，一个项目就不是真正的开源。此外，选择使用像 GNU 通用公共许可证 (GPL) 这样的著作权许可证或像麻省理工学院 (MIT) 这样的宽松许可证可能会影响围绕项目成长和使用项目的社区类型。
然而，Linux 基金会开发者关系副总裁 Chris Aniszczyk 认为，同样重要的是要考虑项目的开放治理，因为许可证本身实际上并没有告诉你项目是如何治理的。
Aniszczyk 认为这些是需要回答的一些问题。他补充说，在争议出现之前回答这些问题，并以一种被所有参与者视为开放和公平的方式回答这些问题，会导致项目往往更成功地长期发展，尤其是在规模增长时。
每个项目的 6 个开放治理问题
- 谁做决定？
- 如何添加维护者？
- 谁拥有域名的权利？
- 谁拥有商标的权利？
- 这些事情是如何治理的？
- 谁拥有构建系统的工作方式？
然而，虽然所有这些问题都应该被考虑，但并没有一个正确的答案。不同的项目——以及托管项目的基础会——采取不同的方法，无论是为了适应特定社区的要求，还是仅仅是出于历史原因。
后者通常发生在一个项目使用通常被称为终身仁慈独裁者 (BDFL) 模型的情况下，在这种模型中，一个人——通常是项目的创始人——通常对主要的项目决策拥有最终决定权。许多项目最终默认采用这种模式——最值得注意的是 Linux 内核。然而，红帽的 Joe Brockmeier 向我指出，现在这主要被认为是一种反模式。“虽然一些 BDFL 驱动的项目已经成功地做得很好，但其他项目在这种方法上却步履蹒跚，”他说。
Aniszczyk 观察到，“基金会有不同的章程、宪章以及它们的结构方式，这些组织之间存在着有趣的差异。例如，Apache 以 Apache 之道而闻名，这就是他们期望项目运作的方式。他们对发布是如何完成的有很多护栏。[这] 有点像一个孵化器过程，每个项目在毕业成为顶级项目之前都要经历很长时间。在项目治理方面，几乎有无限多的方法，”他总结道。
最低要求
话虽如此，Aniszczyk 列出了一些最低要求。
“至少在许多 Linux 基金会和云原生计算基金会 (CNCF) 项目中，我们的模式是一个 governance.md 文件，其中描述了如何做出决策，如何进行治理，如何添加、删除维护者，如何添加、删除子项目等等，发布是如何完成的。这将是第一步，”他说。
所有权
其次，他不“认为你可以在资产不被中立拥有的情况下进行开放治理。归根结底，有人拥有域名、商标权，可能还有一些版权。有很多很棒的组织非常轻量级。有像 Apache 基金会、公共利益软件和软件自由保护协会这样的组织。”
Aniszczyk 也将一些常见的方法视为至少是潜在的反模式。一个关键的例子是贡献者许可协议 (CLA)，它定义了知识产权（如代码）贡献给项目的条款。他说，如果一家公司想要“构建产品或使用双重许可类型模型，那么 CLA 是一个非常合理的理由。否则，我认为 CLA 对开发者来说是一个高摩擦的工具。”
开发者原创证明
相反，他通常鼓励人们“使用我们称之为‘开发者原创证明’的东西。这就是 Linux 内核的工作方式，基本上它采用了大多数 CLA 所做的所有基本事情，比如，‘这段代码是我写的吗？我没有从其他地方复制吗？我有权把它给你吗，你签字同意吗？’这在内核和许多其他生态系统中已经是一个非常成功的模式。我通常不太支持使用 CLA，除非有真正的严格的业务需求。”
项目命名
他还看到了很多他认为是命名上的错误。“项目品牌建设非常重要。有一种常见的模式，人们会启动一个项目，它可能是在一家公司内部，或者你自己，或者你有一家初创公司，你会把它叫做，比如说，‘Docker’。然后你有 Docker 项目，你有 Docker 公司。然后你还有 Docker 产品或 Docker 企业产品。所有这些东西服务于不同的受众。这会导致混乱，因为我固执地认为事物的名称附带价值主张。请将你的公司名称与你的项目名称、你的产品名称分开，”他认为。
信任
最后，Aniszczyk 指出了开放治理在建立信任和信心方面的作用，即一家公司不能单方面为了自己的目的而拿走一个项目。“信任是建立强大社区的基本条件，因为如果没有项目中公开治理的机构，信任就很难获得，”他总结道。
可以在此处收听 Chris Aniszczyk 的言论所摘自的 Innovate @Open 播客节目。
评论已关闭。