36、开源项目参与者管理与法律事项解析

开源项目参与者管理与法律事项解析

一、参与者管理

（一）致谢原则

在项目中，对参与者表达感谢时，要像批评和赞扬一样具体。不要只是泛泛地感谢某人很棒，而要针对他们做出的非凡贡献致谢，并说明这些贡献为何如此出色。在项目中，要平衡好对个人贡献的认可和强调团队协作，尽量倾向于团队利益，避免局面失控。

（二）分叉类型

1. 短分叉（Short Forks）

短分叉非常常见，是如今大多数项目开发的常规方式。开发者创建项目主仓库的公共副本，进行修改后直接从分叉副本将更改提交回项目。这是日常开发的一部分，对项目的社会凝聚力没有负面影响。例如 GitHub 推广的“拉取请求（pull request）”工作流就属于这种情况。其流程如下：
1. 开发者创建项目主仓库的公共副本。
2. 在副本中进行代码修改。
3. 直接从分叉副本将更改提交回原项目。

2. 社会分叉（Social Forks）

社会分叉较少见，但影响重大。当一群开发者对项目方向不满，决定创建更符合自身愿景的不同版本时，就会发生社会分叉。这可能涉及创建项目仓库、错误数据库等资源的副本，代表着潜在的永久性分歧。社会分叉通常伴随着长时间的讨论，开发者会试图说服对方接受自己的观点，或者结束分叉重新统一。了解如何建设性地发起或应对社会分叉很有必要，有时甚至能避免分叉的发生。

（三）分叉后的情况

1. 项目归属判断

项目分叉后，没有明确的标准来判断哪个分叉是“真正”或“原始”的项目。这本质上是一个认知问题，当足够多的观察者达成一致时，某种说法才会被认可。如