当我们说某件事物是“开放的”时，我们通常强调它的透明度或可见性。但开放性本质上与协作相关联，并因此与人们一起工作的方式有关。协作涉及处理诸如工作组织和决策权分配等问题——简而言之，就是我们通常所说的“治理模型”。
对于开放社区和其他组织来说，明确这些治理模型对于以下几个原因至关重要。首先，它有助于提高组织的透明度。人们可以知道一个团队考虑一个问题需要多长时间，贡献对组织产生影响的可能性有多大，或者当他们发言时谁会听到他们的声音。其次，明确定义治理模型也有助于更好地理解和分类开放组织是如何运作的。换句话说，治理模型揭示了组织固有的权力分配和权威分布的线索（例如，民主、精英统治、仁慈的独裁统治等）。例如，对特定治理模型的研究可以阐明开源环境下的精英统治定义（仍然存在争议的话题）。
但这只是我们潜在可以实现的。让我们从头开始：在本文中，我将回顾现实世界的源代码项目是如何运作的。它们是否足够透明？有人可以很容易地理解如何与他们协作吗？他们的治理模式是否清晰明确？
深入研究
我查询了 GitHub，收集了该平台上 25 个最受欢迎的开源项目。 然后，我仔细分析了每一个项目，包括以下几个方面：
- 基本活动指标（例如，提交或关注者）
- 协作指标（例如，问题和拉取请求）
- 文档（例如，
contributing.md,code_of_conduct.md,license.md） - 标签（例如，使用描述性标签）
在收集了这些信息后（我正在分享），我研究了每个项目的治理模型（如果存在或被注意到）。 一些分析的项目提供了足够的信息来理解他们的治理模型，但并不多：五个项目详细描述了这类信息，其中一个项目提供了有限的信息，而十九个项目根本没有描述任何信息。
我确实找到了一些治理透明度的好例子。 例如，Moby 项目清楚地描述了使用有意义的标签和参与该过程的每个阶段的人员的开发工作流程。NodeJS 项目提供了项目主要开发人员角色、其职责以及如何选举他们的详细描述。 React 项目链接到一个描述如何处理拉取请求的文档，其中详细说明了它们如何被审查和确定优先级。
回顾
这些结果明显好于我两年前获得的结果。 当时，我还分析了前 25 个最受欢迎的项目，结果惨不忍睹：我分析的项目中只有一项（Docker）实际上描述了这类信息，而其中七项只提供了一些部分线索，其余的甚至没有说一句话关于治理。
同样重要的是要注意，这两项研究中前 25 个项目的集合是不同的。 下图 1 显示了结果。
图 1（由 Javier Cánovas Izquierdo 提供，CC BY-SA）
在将新数据与我之前的分析结果进行比较时，我还注意到
- 更广泛地使用
code_of_conduct.md文件，该文件清楚地指导人们如何为项目做出贡献。 甚至还有促进最佳实践的倡议。 - 更多资源来教导新手开源是如何运作的，以及他们如何做出贡献。
contributing.md文件现在是 GitHub 项目中的一等公民。 - 使用更具描述性的技术，例如语义版本控制（有助于理解新版本的性质）或详细的标签，这有助于理解项目目的（特别关注广泛使用的标签，如“help-wanted”或“good-first-issue”，鼓励新人做出贡献）。
- 广泛使用社交网络和开发支持工具（例如，gitter）
此比较显示了相对于两年前获得的结果的改进。 所以我们对本文的主要问题有了一个答案。
但是，我相信还有很多工作要做。 幸运的是，一些运动和倡议（如我之前提到的那些）目前旨在促进对开源项目和社区中如何处理治理的明确解释。 它们为贡献提供模板，以及新手或许可指南。
也许下一步是方便开发人员轻松创建和自定义这些指南。 新的机制来授权开发者（和最终用户）表达（并明确）管理协作的规则和规范将有助于开源运动和开放组织。 额外的一步甚至可以包括开发工具来检查（或强制执行）协作是否遵循既定指南（例如，机器人强制执行特定的治理规则，例如联系开发人员以帮助及时解决问题）。
我知道这种分析不能被概括，但鉴于 GitHub 在开源社区中的重要性，我相信它可能是一个具有代表性的例子。 此外，这些项目是其中最重要的项目（至少，社区最关注的项目）这一事实也有助于展示事情是如何完成的。
订阅我们的每周新闻通讯，以了解更多关于开放组织的信息。
1 条评论