多机构开源项目的治理模型

Question

我正在从事一个开源项目，其中有来自几所大学的全职专业开发人员，还有几个其他组织。该产品有十几种部署、各种变体、插件、相关组件等。通常到目前为止，开发都是由机构“自食其力”驱动的，但其目的是将改进工作合并到中央代码库中。

随着它开始成熟，我对可能的开源治理模型感兴趣。(所以这个问题不是“有什么好事情要做”，而是“哪些现有的、经过测试的模型值得考虑，并可能遵循”)

这类模型可能涉及的具体方面：

• 如何做出关于重大影响的改变的决定(如果有人在没有先讨论的情况下做出重大改变，会发生什么？)
• 谁来管理产品的公众形象(产品营销，因为没有更好的术语)
• 在任何与“竞争”产品的比较中，谁代表产品？
• 增强是否成为“核心”、“插件”、“相关产品”等
• 是否和如何创建和发布路线图
• 如何处理产品的变化(在本例中，是针对不同学科的版本)
• 项目参与者的期望和义务
• 这些开发商所服务的机构的期望和义务

我们将寻找像轻量级和非正式的一样实用的东西。

Answer 1

一个好的结构是让几个主要的开发人员(可能来自每个大学/组织)管理一个易于管理和控制的存储库(GitHub是一个很好的选择)。贡献者版本将以拉-请求的形式进行，然后被主要的开发人员接受。应该有一些基本的规则来避免争论。一个示例规则是，发行版必须进行测试，或者需要证明代码是如何测试的。这些规则应该在ReadMe中发布。

贡献者或领导者可以被命名为“营销人员”，并向ReadMe提交拉请求，并对Wiki进行更新，并负责路线图等。

对于版本控制，尽可能使用一个标准来传递小的更改和破坏的更改。语义版本化是一个越来越为开源项目所接受的好模型。

变体可以作为分支和/或私有分叉来处理，GitHub也使得这很容易。这篇文章讨论了使用Git的一个很好的分支模型。

这在工具上可能过于具体，但这些工具确实成功地维护了许多与多个贡献者高度协作的开源项目。