2022 March 12

从知识溢出的视角分析开放式协作

缘起

OpenTEKr 的狄安最近非常高产，连续写了好多篇开源相关的深度分析，也激发了我进一步学习的兴趣。主要参考的文章是这样两篇：

我在学习了一些相关的论文之后，写了如下这篇文章。

什么是知识溢出（维基百科版）

在学术界，比较有代表性的定义是哈佛大学的Zvi Griliches（1992）的定义：做相似的工作并从彼此研究中受惠。更加详细的划分又有三种类型：MAR 溢出、Porter 溢出和 Jacobs 溢出。

以下内容摘录并翻译自英文维基：

Marshall–Arrow–Romer（MAR） 溢出

马歇尔-阿罗-罗默（MAR）溢出效应起源于1890年，英国经济学家阿尔弗雷德-马歇尔提出了知识溢出效应的理论。后来，经济学家肯尼思-阿罗（1962）和保罗-罗默（1986）对知识溢出进行了扩展。1992年，Edward Glaeser、Hedi Kallal、José Scheinkman 和 Andrei Shleifer 将 Marshall-Arrow-Romer 关于知识溢出的观点拉到一起，并相应地在1992年将该观点命名为 MAR 溢出。

根据 MAR 的观点，在一个共同的行业中，企业之间的距离往往会影响到知识在企业之间的传播，以促进创新和增长。企业之间的距离越近，MAR 溢出效应就越大。思想的交流主要是员工与员工之间的交流，即一个行业中不同企业的员工就新产品和生产商品的新方法交流思想。交流思想的机会，导致创新的关键是新产品和改进生产方法。

商业园区是一个很好的例子，集中的企业可以从 MAR 溢出中受益。许多半导体公司有意将其研究和开发设施设在硅谷，以利用 MAR 溢出效应。此外，加州洛杉矶和其他地方的电影业依靠专家（导演、制片人、编剧和布景设计师）在地理上的集中，将电影制作的狭窄方面汇集成最终产品。

然而，对剑桥 IT 集群（英国）的研究表明，技术知识溢出可能只是很少发生，其重要性不如其他集群效益，如劳动力市场的汇集。

Porter 溢出

波特（1990）和 MAR 一样，认为专门的、地理上集中的产业中的知识溢出会刺激增长。然而，他坚持认为，相对于地方垄断而言，地方竞争促进了对创新的追求和快速采用。他列举了意大利陶瓷和黄金珠宝行业的例子，在这些行业中，数百家公司分布在一起，激烈地竞争创新，因为创新的替代方案是消亡。波特的外部性在具有地理上专业化的竞争性产业的城市中得到了最大化。

Jacobs 溢出

根据雅各布斯的外溢观点，来自不同行业的企业的接近程度会影响知识在企业间的传播，以促进创新和增长。这与 MAR 溢出效应不同，MAR 溢出效应关注的是一个共同行业的企业。雅各布斯溢出效应的多样化邻近性使具有不同观点的个人之间的想法汇集在一起，以鼓励思想交流，并在工业多样化环境中促进创新。

1969 年，城市学家简-雅各布斯和约翰-杰克逊提出了这样一个概念：底特律的造船业从 19 世纪 30 年代开始，是导致 1890 年代底特律汽车工业发展的重要前奏，因为汽油机公司很容易从为船舶制造汽油机过渡到为汽车制造汽油机。

什么是知识溢出（个人解读版）

理解知识

知识其实分为很多种，有书本上的，容易普及、传授的知识。也有非常私人化、经验性的知识，只能通过师父带徒弟，口传心授，才能够掌握的知识。

书面知识、口头知识、技术、技巧、经验、心得、秘方、专利等等，都是知识的各种形态。

理解溢出

溢出、转移、扩散，都是从一个人到另一个人，或者从一个企业到另一个企业。有可能是没防住，也可能是无所谓，也可能是主动的传授。

另一方面，在溢出的过程中，可能是 A 解决了一个问题，B 采用同样的方法，解决了同样的问题。也可能是完全不同的行业中类似的问题，甚至是两个不相干的问题，但是 A 的方法，启发了 B 。还有一种可能，溢出过程与创新过程，成为一个整体。

理解模型

理解地域

传统的经济学，还没有开始介入到对于互联网上的知识溢出的研究。所以才会从经济地理的角度，分析区域、城市、地理因素，对于知识溢出的影响。但是到了互联网时代，在开源社区里，知识溢出就非常容易成为“全球性”的规模了。

知识溢出在开源社区中的表现

在狄安的文章《代码穿流》中，他提到了一个算是行内共识的观点：“在沟通误解和语言歧义的困境面前，程序代码比日常语言有着更加精准表达的优势。”

不过，我总觉得他论证的 Talk is cheap, Show me the code ，让我想到另一个开源社区经常会提到的名言 Community over Code 。如何理解在开源社区里，Talk、Code、Community 的关系与重要性呢？

在我看来：在开源社区里流动着各种类型的知识，代码是其中最精准的一种，但是社区也在努力提高其他类型知识的交流效率与准确性。

因为在社区里，我们不可能只通过代码交流所有的内容，文字、音频、视频，甚至线下见面，总是必不可少的。

代码溢出

在狄安的另一篇文章《诺奖模型下的开源代码溢出》中，已经对于代码溢出的现象做了非常深入的分析。通过可以执行、调试、修改、分发的代码，程序员们能够更加高效、准确、深入的交流各自的知识与技巧，我非常赞同。

在2019年，我的另一篇文章里，还提到了另一个说法：“Talk is messy, the code is clear”。大概也是表达了类似的意思。

Code Review 的过程

在开源社区的知识交流中，有一个很重要的过程，是 Code Review 。由于是围绕一段代码进行讨论，甚至借助 GitHub 的帮助，程序员们可以一行一行的深入讨论。这样的 Talk ，一点都不 Cheap 。相反却是非常有价值的。

甚至不仅是在开源社区，在企业内部，有效推行的 Code Review ，也是一种非常有效的，企业内研发人员之间，传递知识的方式。

Issue 与 Pull Request 模板

现在的 GitHub 已经支持 Issue 与 Pull Request 模板，其实也是一种提高交流准确性的努力。泛泛的要求写得清楚一些，其实很难。将可能提交的内容，进行分类。然后提示用户：提交某一类的文字，应该按照模板，填写哪些必须的内容。

模板/规范化/格式化，虽然会限制个人的发挥，但是也会促使写作者，更加清晰的表达自己的意思。

社区提问的礼仪

越是成熟的社区，越是注重交流的礼仪与规范，同样也是希望大家能够有效交流，免得浪费大家的时间。这里面有很多非规范的，非模式化的，但是却必不可少的交流，大家也只能靠个人的自觉了。

高质量的文档

吸引更多的新人，快速加入自己的项目，高质量的文档也是一个“刚需”。当然，如果能够做到这一点，也可以认为是在主动进行“知识外溢”。

布道师

当然，更加主动的“知识外溢”，也是开源社区特有的现象，就是有以布道师为志业的人，他们写文章，做演讲，组织线上、线下的聚会，运营社区，推广自己的开源项目。既是技术传播，也是招揽新人。

知识溢出在开源生态中的表现

前面讨论的，还是在单一社区内的“知识溢出”现象。我们可以再扩大一步，看看整个开源生态、甚至整个技术生态里，存在的各种“知识溢出”现象。在《从法律思维的角度看代码——《Code 2.0》读后感》，我提到了一个“虚拟空间的地理学”。正好，在知识溢出里，也有一种经济地理学的思考角度。

因此，我们可以套用类似的思考角度，将网络上的大大小小的社区、项目，看成是地理上的国家、城市与街区。区别在于：在物理世界，一个人从一个城市到另一个城市旅行，还是要花不少时间的。但是在网络上，从一个社区到另一个社区，也许仅仅是切换一个窗口的事情。

但是，我们依然不能假设所有的社区，都是等距离的。事实上，由于自然语言、编程语言、技术领域、工具平台、合作&竞争关系等等原因，各个社区之间的距离，并不是相等的。我们也常常能够看到，一种技术、技巧，在多个开源社区里，逐步流行起来的过程。

设计模式，或其他技术实践

设计模式当然不是在开源时代诞生的技术。但是，从 1994 年《设计模式》出版以来，从 C++ 语言到其他编程语言；从英语编程世界，到其他非英语国家的编程世界；从一本经典原著，再到各种各样的衍生书籍、网站以及相关讨论。整个过程，就是一次典型的知识溢出的过程。

与设计模式类似的，还有 UML、XML、MVC 模型、线程池、DSL （领域专用语言）、SOAP 与微服务等等技术实践，都在不同的时期，在整个技术世界传播、风行。这些，都可以从知识溢出的角度来理解。

从StackOverflow 到 Gist

早在 Mailist、IRC 与 BBS 的时代，开发者们就会在各种社区里提问、回答。而这些问答，往往会形成一种简单的格式：困难/报错 -> 解决方案（ Shell 脚本、代码修改）。

等到有了 GitHub Gist ，很多开发者会将自己的经验，以代码片段的形式分享出来。只要有足够好的搜索引擎，我们都能够快速的找到解决方案，Copy from StackOverflow / GitHub。

可复用组件

更好的知识溢出，现在通过各种高级语言的包管理工具，大量发生。最极端的情况，是 is-promise 这样的包。你很难想象：开源生态的依赖性，已经到了如此紧密的程度了。

当然，如果不考虑极端情况的话，我们还是应该更加乐观。因为绝大多数的开源社区的开发者，都会优先选择复用他人的成果，也会非常积极的分享自己的成果。这就是“知识溢出”希望看到的现象了。

再造一个轮子

虽然程序员都会念叨：DRY（ Don’t repeat yourself ），但是可以重复造一个人家造过的轮子。以 Yet Another 开头的著名开源项目，都好多好多。有些是换一种编程语言，实现类似的功能，比如从 Rails 到 Grails 。也有一些干脆就是不服，就是用同一种语言，再来一个。比如著名的 React vs. Vue vs. Angular 。

这是不是一种浪费呢？其实不是，面对相同的问题，尝试选择另一种解决方案，能够有效的刺激更多的创新。这就是上文提到的 Porter 溢出。

Upstream First

社区分裂毕竟不太好，所以 Upstream First 还是一种更加值得倡导的协作模式。相对“知识溢出”，可以称之为“知识回流”。当然，由于这样的回流，发生在公开的社区里，自然会有更多的人受益。

从知识溢出的角度来看开放式协作

经过上面非常琐碎的分解/分析，我们大概可以对于开源世界里存在的各种知识溢出的现象，有一个大致的了解。但是，我们需要一些总结，然后才能够发挥其更大的价值。我们的逻辑分析链条，是这样的：

开放性的价值

一切的价值，都起源于 Working in public 。不仅代码是开放的，围绕代码的讨论，各种 bug / feature 的交流也是公开的。甚至整个社区，都是以一种尽可能开放的精神建设起来的。这样的开放性，为知识溢出，提供了充分的可能性。

工具对于交流的支持

在《三代开源社区的协作模式》，我就已经分析了随着时代的进步，开源社区用到的协作工具不断演进的过程。

事实上，即使是非程序代码类的项目，依然可以在 GitHub （或类似平台） 上很好的进行开放协作。只不过，很多非程序员人群，对于开发工具、交流工作、管理工具，没有那么热衷罢了。

模板化的追求

框架、模板、Checklist ，都是各种各样的约束。但是完全自由的自然语言交流，恰恰非常难以实现高效、准确，当我们仔细的分析常见的交流类型，并为某一种交流类型，制定一种表达模板时，交流的效率反而能够大大提高。

其实，在其他行业，一直也有类似的实践：标准作业程序（Standard Operating Procedure / SOP）、表单填写、公文流转，其实都是基于相同的思路。

营造一种共同体的氛围

成功的开放协作，都会强调“达成共识”，有共同的价值观，有共同的目标、方向与判断逻辑的群体，更容易实现高效的合作。这些都离不开有意识的社区运营工作。如果能够让社区内的成员，有更多的归属感，更多的向心力，自然会形成更好的沟通，创造更好的成果。

再结合根源性的开放性，这样的开源共同体，自然能够溢出更多的知识。

结语

这篇文章，依然是开源学的一次尝试。按照以万法观开源（从知识溢出的角度看开源），再由开源融万法（将开放协作的经验推广的开源项目之外），希望能够给读者一些启发。

参考资料

All content is licensed under CC BY-NC-SA

Buit with Jekyll and 3-Jekyll theme • Hosted on Github