共计 1460 个字符,预计需要花费 4 分钟才能阅读完成。
在许多对于开源我的项目和社区治理的探讨中,人们往往偏向于把关注放在流动或资源上。尽管理解和记录这些信息非常有用且必要,但它们并不是真正意义上的开源治理。那什么才是开源治理呢?
简而言之,治理(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…
https://snyk.io/series/open-s…
https://www.redhat.com/en/blo…