开源项目治理需要回答的6个问题

（原标题：开源项目治理需要回答的6个问题）

要说开源代码项目该发挥什么作用，很多朋友首先想到的就是开源许可。一方面，不少人认为不符合开源代码倡议（OSI）许可的项目根本就不能算真正的开源。另外，选择使用GNU通用公共许可证（GPL）、MIT许可证等公共版权许可，则有可能给项目的使用方式与社区发展带来深远影响。

但Linux基金会开发者关系副总裁Chris Aniszczyk看来，许可本身并不会真正提示我们该如何管理项目。因此，如何对项目进行开放式管理才是问题的核心。他还补充道，在纠纷出现之前回答这些问题，并对一切参与者提供开放、公平的见解表达渠道，正是项目在规模扩大的过程中取得长期成功的前提。

开源项目需要解决以下6大治理难题： 谁来做出决策？ 如何添加维护者？谁拥有域内权利？谁拥有商标权？具体事件如何治理？谁负责确定构建系统的运作方式？

面对上述难题，可以看见并不存在那种百试百灵的正确答案。无论是出于社区的特定需求、还是某些历史原因的影响，不同项目以及托管项目的基金会往往采用自己的方法。

也正因为如此，不少项目决定选择“传递的独裁者”（BDFL）模式。在这种模式当中，将由一个人（通常是项目的创始者）对重大项目决策拥有最终裁定权。默认情况下，不少项目止步于此，Linux内核项目本身就是这样的例子。但是，Red Hat公司的Joe Brockmeier却在观察中发现，BDFL已经成为一种典型的“反模式”。“虽然确实有一部分项目在BDFL的推动下取得了成功，但更多项目也由此彻底迷失了前进方向。”

Aniszczyk发现，“不同的基金会往往拥有不同的章程、条款及其组织方式，而且具体组织层面存在大量差异因素。例如，Apache Way就颇具盛名，这也是Apache指导自身运作的方式。这是一种孵化器过程，各个项目需要凭借自己的努力一步步走向毕业。从项目管理角度来看，这基本属于「广撒网」的竞争筛选方式。”

Aniszczyk就项目管理提出了一些最低要求。他强调，“在众多Linux基金会与云原生计算基金会（CNCF）项目当中，我们采取的是Governance.md文件模式，其中描述了如何制定决策、如何管理事物、如何添加/撤销维护者、如何进行子项目添加/删除、如何发布开发成果等等。这些仅仅只是第一步。”

其次，他认为“如果不以中立方式设定资产所有权，就根本不可能实现开放式治理。毕竟最终，域、商标权及某些其他版权必然归属于某个人或某些人。不少运营出色的组织在这方面就采取极轻量化机制，例如Apache基金会、Software in the Public Interest以及Software Freedom Conservancy等，都做出了自己的尝试。”

Aniszczyk还提到，目前相当一部分常用方法都在某种程度上属于反模式。以贡献者许可协议（CLA）为例，其中定义了代码等知识产权进行项目贡献时应当依据的条款。在他看来，如果企业希望“制造产品或使用双重许可类模型，那么CLA无疑值得考虑。但对于其他需求，我认为CLA反而会给开发人员带来巨大的困扰。”

相反，Aniszczyk鼓励人们“使用所谓「开发者原研证书」（Developer Certificate of Origin）。作为Linux内核项目选择的解决方案，它吸纳了CLA中的大部分主体内容，例如「这段代码是我亲手所写吗？我是否承诺从未将其复制到其他项目？我是否有权将这些成果移交给您，并由您认可及处置？」这是一套非常成功的模型，已经在Linux内核及多种其他生态系统中发挥了作用。除非有着严格的业务需求，否则我个人真的不太建议使用CLA。”

他还发现了很多命名错误情况。“项目品牌非常重要。人们往往会先在企业内部或者以个人方式启动一个项目，比如说「Docker」，之后据此建立生态系统，接着是创建起Docker公司，最终是Docker产品或企业级方案。所有这一切，都将服务于不同的受众，也因此引起不少误解。所以我个人有一种固有信念，即某一事物的名称天然具有附加的价值主张。因此，大家最好能把企业名称、项目名称与产品名称区分开来。”

最后，Aniszczyk还提到了开放式治理在建立信任与项目信心方面的作用。通过这种方式，企业会强调自己不会只在项目中单方面强调自己的需求与规划。他总结道，“要想建立起强大的社区，信任是一种必要的前提。如果开源项目缺少开放治理机构的支持，贡献者很难说服自己为项目贡献宝贵的时间与精力。”