Question

在资产可以被无限复制和轻易改变，且其环境文化既不是强制权力关系也不是物质稀缺经济的情况下，“所有权”该如何理解呢？

实际上，开源文化对这个问题有着简单的回答：一个软件项目的“所有者”就是在社区中众所周知的对软件版本改动有唯一发布权的那个人。

（在讨论“所有权”这一节中，我使用单数形式，因为所有项目都有一个“所有者”，但有的项目是由一个小组共有的，我们将在后面讨论小组的内部动力学。）

根据标准的开源许可证，在软件演化的游戏中所有人一律平等。但实际情况是，“官方”补丁和“流氓”（rogue）补丁有着公认的差别：“官方”补丁由公众认可的维护者发布，人们会接受它并将它合并到软件中；而“流氓”补丁由第三方发布，它很少见，也常常不被信任。 ²

公开发布是很重要的事情，这很容易理解。开源社区通常鼓励人们因个人需要而给软件打补丁，而且也不关心在一个封闭的用户圈子或开发者圈子内的变更发布，只有当改动被经常性地发布到开源社区中，并和原版造成竞争时，“所有权”问题才会产生。

通常有三种方式获得开源项目的所有权：第一种也是最显然的，就是去创建这个项目，当这个项目在开始时就只有一个维护者而且这个维护者仍然起作用的时候，所有权问题是连提都不该提的。

第二种方式是获取前任对所有权的移交（有点像“接力棒传递”）。这在社区中很容易理解，当项目“所有者”不愿意或者不能在开发和维护中投入必要的时间时，他（她）有义务将项目移交给一个有能力的继任者。

如果是重大项目的控制权移交，做一个隆重的公开声明是很有意义的。虽然没有听说过开源社区能够实际干涉所有者对继任者的选择，但习惯做法上显然认为合法性公开是非常必要的。

对于较小的项目，如果发生所有权变更，通常在项目发布的变更历史中说明就可以了。如果控制权的交出在实际上并非出自前任的自愿，通常认为，在一个合理的时间段内，前任可以通过公开反对来获取社区支持并最终夺回控制权。

第三种方式是一个项目需要维护但项目所有者已经消失或失去兴趣了。如果你想维护该项目，你的责任是努力找到这个“所有者”，如果找不到，你可以在相关场所（比如 Usenet 上专注于该应用领域的新闻组）声明该项目似乎是一个“孤儿”，而你想为之负责。

习惯上你需要等一段时间后再声明你自己是新的所有者，在这个时期内，如果有人宣称他们事实上在为这个项目工作，那么他们的声明有效而你的无效。一般来说，向公众声明你的意图应该超过一次，比较好的做法是在多个相关论坛（以及新闻组、邮件列表）上发布声明并耐心等待回应，在等待前任所有者或其他权利人的响应上，你所做的看得见的努力越多，在没有回应时你的声明就越有效。

如果你通过了这个过程（在用户社区的见证下）并且没有任何异议，你就可以声称自己拥有这个孤儿项目的所有权，并将之写入 history 文件。然而，比起所有权交接，这种方式稳妥性略差，在你做出实质性改进（在用户社区的见证下）之前，你不能认为自己有完全的合法性。

我观察开源软件中这些习惯做法已经有 20 年了（可回溯至前 FSF 的古老年代），这些习惯有一些非常有意思的特点，其中最有意思的是，绝大多数黑客在并不了解习惯做法的情况下就知道去这样做。事实上，本文大概是第一次有意识和比较完整地总结了这些做法。

另一个有意思的特点是，他们对这种习惯做法的遵循，表现出非凡的（甚至是让人震惊的）一致性。我注意过足有数百个开源项目，不管是亲眼看到的还是听说的，严重违反传统的事情屈指可数。

第三个有意思的特点是，这些习惯会随时间演进，并有着连贯一致的趋势，这个趋势鼓励更多的公众责任心、更多的公众注意，以及对项目名誉和变更历史维护的更多关心，其目的是建立和巩固项目当前所有者的合法性。

这些特点表明习惯做法不是偶然产生的，而像是某种内在程序或生成模式（generative pattern）的产物，这些程序或模式对开源文化起着至关重要的作用。

早先曾有本文的评论者指出，比较互联网黑客文化和骇客/盗版文化（如“warez d00dz”，它主要围绕游戏破解和盗版专题 BBS）有助于弄明白两者的生成模式。本文的后面部分将比较开源和 d00dz。