在许多关于开源项目和社区治理的讨论中，人们往往倾向于把关注放在活动或资源上。虽然了解和记录这些信息十分有用且必要，但它们并不是真正意义上的开源治理。那什么才是开源治理呢？
简而言之，治理（Governance）是根据项目来决定什么人可以做什么或者应该做什么、如何完成以及什么时间完成的规则和策略。而开源治理是指导开源项目的公认规则和惯例，由于定义了项目中的角色，因此可以基于每个开发人员的活动，来进行相应的开源项目治理。
6 种开源治理模型
根据 Red Hat，我们可以总结出以下六种开源治理模型：
- Do-ocracy： 在这个治理模型下，开发者为决策者，在此模型中同行评审（peer review）扮演重要角色。
- 创始人-领导者（Founder-Leader）： 这种开源治理模型常用于新项目或只有少数贡献者的项目。在这个模型中有一条清晰的治理路线，通常是最初的人或开发团队。但需要注意的是，由于创始人/领导者在整个软件生命周期内决策治理，可能会让治理处于独裁模式（Open Source Dictatorship）。
- 自任命委员会或董事会（Self-appointing or board）： 在这种开源软件治理模型中，需要创建一个委员会来监督项目开发步骤。但这种模式的缺点是领导委员会可能会拒绝团队其他成员的参与和提出的建议。
- 选举（Electoral）： 在此模型中，通过社区选举来进行开源治理，当项目具有大量社区投入且大多数开发人员的技能水平和角色类似时，该模型会让决策过程更加公平。但是更多的层级和责任细化，可能让社区成员因为争夺领导角色而产生内讧。
- 企业支持（Corporate-backed）： 在这种软件治理模式下，企业或行业根据开源许可协议接管软件的分发。此模型提供了对软件开发的控制，但也限制了开源项目的外部贡献。
- 基金会支持（Foundation-backed）： 这种模式由非营利组织管理，治理通常由单一结构严格控制。
开源治理中的角色
项目贡献者在开源软件治理中有正式的对应角色。其中最受认可的是：
- 维护者：这可以是为开源项目编写了大量代码的人，也可能是为项目制作文档的人，再或者是是项目的布道者。这位贡献者对项目的总体方向抱有责任感，并通过不同方式让项目发展的更好。
- 贡献者：为项目做出贡献的任何人，比如评论问题或编写代码。
- 提交者：对项目作出贡献并得到核心维护团队的认可，最终获得特殊提交访问权限的人。
尽早进行开源治理
根据 Gartner 数据显示，有超过90%软件使用了开源组件。这意味着开源治理应当成为企业 IT 部门和高层管理的优先事项。开源治理、项目贡献者和领导层的政策应该得到良好地定义和沟通，参与开源软件开发的每个人都需要知道他们在项目中的角色。
开源治理策略为企业的安全风险到运营风险提供解决方案。缺乏治理可能会减慢软件开发周期、延迟发布或在产品上线后需要修复。添加治理模型可以解决潜在的合规问题。比如，企业的治理策略应当包含 SCA 工具，来帮助其更清晰地了解依赖项中的潜在漏洞和许可问题。
在任何开源项目中都应当尽早实施开源治理。越早制定文档，就越容易定义期望和目标。如果项目是由公司或基金会支持的，则应在启动项目之前进行内部讨论，以便清晰流程。
参考链接：
https://opensource.com/articl...
