治理需要回答的6个问题

总裁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产品或企业级方案。所有这一切，都将服务于

（编辑：牡丹江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!