10.13 组织间协作

概述与动机

组织间协作是指两个或更多个不共享同一所有者、预算或指挥链的独立组织，在软件和技术上开展的联合工作。它不同于公司内部的团队协作（第 1.2 章）。在一家公司内部，一位领导最终能够指挥人员、裁决争端、重新分配资源。而跨越组织边界，没有人能做到这些。每一方都保留着自己的法律身份、激励机制和退出权利，因此协作必须通过治理、合同和信任来赢得和维系，而不是靠下令。本章之所以放在管理部分，是因为组织间工作从根本上是一个具有技术后果的战略、治理和关系问题，而不是反过来。

其动机在于，没有任何一家单独的组织能够构建或掌控所有值得拥有的东西。诸如操作系统、加密库、网络协议和云工具等基础性软件，如今都是协作构建的，因为重复构建它们的成本极其高昂，而一个共享的、可互操作的基础所带来的价值，超过了任何一家私自囤积它所能获得的优势。竞合关系（cooperation 与 competition 的合成词，指竞争对手在一个共享基础上进行合作，同时又在其之上的产品层面继续竞争）已经变得司空见惯。相互竞争的公司共同开发同一个开源运行时，然后在其上构建的服务上进行差异化竞争。为了获得规模和网络效应，一个人人都能使用的共享标准，胜过一个只有你能使用的专有标准。

对企业和政府而言，利害关系直接而具体。企业加入联盟组织（为共同目的而成立、由成员出资的团体）和开源基金会，以塑造它们所依赖的平台，并避免被单一供应商锁定（第 10.3、10.11 章）。政府则时时刻刻面对这个问题。各机构必须共享数据，才能向公民提供一次被体验为单一交互的服务。各司法辖区必须跨境实现互操作。公共部门正日益构建共享平台：诸如身份认证、支付或通知等通用服务，构建一次，被多个机构重复使用。一个繁荣的政府科技（GovTech）生态系统（为政府构建技术的初创企业、供应商和公共机构组成的网络）依赖于在法律上各自独立的组织在实践中开展协作。

关键原则

没有人说了算。 跨越边界，你拥有的是影响力，而不是权威；要为达成共识而设计，而不是为下达命令而设计。
中立性使参与成为可能。 一个中立的归属地能让竞争对手参与贡献，而不必把优势拱手让给某个竞争对手。
在架构之前先对齐激励。 协作失败的原因，远比技术不兼容更常见的是利益不一致。
互操作性是技术基础。 开放标准和接口（第 3.8 章）是让独立系统真正能够互联的东西。
明确贡献和知识产权。 谁拥有什么、谁可以使用什么，必须在工作开始之前而不是之后写清楚。
信任是在小而可验证的步骤中建立起来的。 从小范围开始，交付成果，再随着业绩记录的积累而扩大范围。
为退出而设计。 任何一方都可能离开；协作必须能在成员离开后依然存续，而不至于崩溃或被人把持。

建议

选择与目标相匹配的协作形式

不存在单一的模式，所以要刻意地进行选择。行业联盟与联盟组织为某个领域设定方向并汇聚资金。开源基金会（例如 Linux 基金会或 Apache 软件基金会这样持有并治理共享代码的中立非营利组织）承载着许多组织共同构建并依赖的软件。标准组织（例如 ISO、IETF 或 W3C 这样发布协商一致的技术规范的组织）制定所有人都要遵循编码的互操作规则。合资企业为一个共同的商业目标创建一个新的共有实体。公私合作伙伴关系（PPP），即政府与私营企业共同分担一项公共服务的交付、融资和风险的长期安排，把公共使命与私营能力结合了起来。跨机构与跨政府协作直接连接各公共机构。共享平台与共享服务、数据共享安排，以及竞合关系，共同补齐了这套工具箱。要让形式与目标相匹配：轻量级的对齐需要一个联盟；共享代码需要一个基金会；一个持久的商业载体需要一个合资企业。

在边界之上建立中立治理

因为没有任何一个参与方能够指挥其他各方，治理就必须是明确的，并且理想情况下是中立的。把共享资产（代码、商标、路线图）归属于一个中立基金会，而不是任何一个成员，这样就没有任何参与方能够单方面地攫取或操控它们。要清晰地界定决策权：谁决定技术方向（通常是一个技术指导委员会）、谁掌控预算，以及争议如何解决。发布一份共享路线图，让各方能够依据一个共同的方向进行规划。采用一套书面的治理模式，使权威来自约定好的规则，而不是来自谁的嗓门最大或体量最大。Apache 的”功绩制”（通过贡献赢得影响力）和基金会理事会结构，是已经被证明有效的范例。

事先明确贡献和知识产权条款

知识产权（IP，指代码、专利和商标等受法律保护的创造成果）是善意协作最常破裂的地方。要在写代码之前把它解决好。使用一份清晰的开源许可证（第 10.3 章），让每个人都清楚自己使用和再分发的权利。要求签署贡献者许可协议（CLA）或开发者原创声明（DCO），这是贡献者用以确认自己有权贡献其代码并授予必要许可的机制，使共享资产拥有清晰的来源。要明确处理专利问题，通常通过一项不主张权利或专利承诺条款，使贡献者日后无法起诉共享成果的使用者。书面的知识产权条款，把模糊的善意变成了持久的、可强制执行的清晰约定。

就数据、隐私和反垄断问题审慎地订立合同

独立组织之间的协作，承载着公司内部工作所没有的法律风险。数据共享协议必须明确目的、允许的用途、安全控制措施、留存期限和责任归属，并必须遵守隐私和数据保护法律（第 4.5 章），包括共享个人数据的合法依据，以及在需要时的数据处理协议。反垄断（禁止不公平限制市场的协议的竞争法）在竞争对手协作时始终是一项现实的约束。要把合作限定在竞争前（pre-competitive）的基础层面。避免交换诸如定价这样的商业敏感信息。要记录清楚合作的目的是互操作性和共享基础设施，而不是串通。及早让法律顾问介入。一次数据或反垄断方面的失误可能摧毁整个协作，并使成员暴露在处罚风险之下。

建立在互操作性和开放标准之上

互操作性，即独立系统交换和使用信息的能力（第 3.8 章），是使一切其他事物成为可能的技术基础。优先选择开放标准（任何人无需许可或付费即可实施的公开可用规范）以及稳定的、有文档记录的接口（API，应用程序编程接口），使各方能够互联，而不必依赖某个供应商的专有内部实现。在政府领域，正是通用的数据标准和共享 API，让各机构能够跨越边界组合服务（第 7.1 章）。没有互操作性，协作就会退化为脆弱的点对点集成，加深依赖，而不是创造共享价值。

有意识地培育激励和信任

因为参与是自愿的，每个组织都必须看到持续的收益，每个组织也都必须对其他各方有足够的信任才愿意投入。要让共享价值可见，并大致与贡献成比例，这样主要贡献者就不会感到被利用，搭便车者也不会占据主导。从一个小范围、低风险的领域开始，交付一些真实的成果，只有随着业绩记录的积累才扩大范围。这与创新合作伙伴关系（第 10.9 章）和内源（InnerSource，第 1.2 章）背后的信任建立逻辑是一样的，只是把它延伸到了公司边界之外。透明度（公开的决策、公开的路线图、公开的指标）是在权威无法发挥作用的地方维系信任的东西。

权衡：优缺点

方式	优点	缺点
开源基金会	中立的归属地；成本共担；广泛采用；没有单一所有者	决策较慢；必须投入资金和人力；治理开销大
联盟组织 / 行业联盟	塑造方向；汇聚资金；行业分量	可能陷入政治僵局；存在被大成员把持的风险
标准组织	持久的互操作性；广泛的合法性	速度极慢；规范可能落后于实践；流程繁重
合资企业	所有权明确的商业载体；投入资源有保障	组建和解散都很复杂；退出和知识产权纠纷
公私合作伙伴关系	把公共使命与私营能力结合起来	问责和锁定风险；合同冗长且僵化
竞合关系	共享基础，之上仍保持竞争性差异化	反垄断风险；共享与竞争之间的边界微妙

其中定义性的张力是共享价值与个体控制之间的张力。一方越多地把资源汇入一个中立的公共池，集体收益就越大，而它能够单方面控制结果的程度也就越小。解决之道是刻意地划清界限。在竞争前的基础层面上协作，那里人人都能从一个共同的基础中获益。在真正的竞争优势或主权优势所在之处（第 10.11、3.8 章），则要保留控制权。

与团队讨论的问题

我们的共享资产是归属于一个中立的归属地，还是掌握在某个日后可能对其进行分叉、重新许可或撤回的参与方手中？ 跨越组织边界，没有人说了算，所以谁掌握着代码、商标和路线图，谁最终就能操控或攫取它们。一个中立基金会能让竞争对手参与贡献，而不必把优势拱手让给某个竞争对手，这正是 Linux 基金会和 Apache 软件基金会这类模式存在的原因。如果某个单一成员拥有这个公共池，那么其他每一个成员都只差一次重新许可的决定就会被把持。拿出你贡献的每一项共享资产，问一问它在法律上归属于哪里、由谁掌控其方向。如果答案是”我们最大的合作伙伴”，那你在投入更多工程精力之前，就有一个被把持的风险需要解决。
我们是刻意地选择了与目标相匹配的协作形式，还是默认采用了熟悉的那一种？ 轻量级的对齐需要一个联盟；共享代码需要一个基金会；持久的互操作规则需要一个标准组织；一个有承诺的商业载体需要一个合资企业；一项公共服务需要一个公私合作伙伴关系。每一种形式都带来不同的速度、成本和退出后果，而选错形式正是协作陷入政治僵局或在一份僵化的长期合同中僵化的原因。要让形式与你实际需要的东西相匹配，并优先选择能实现目标的最轻量结构。拿出你希望从某项特定协作中得到的具体成果，用它去检验各个选项。如果你为了做一件一个共享代码仓库加一份书面治理说明就能搞定的事，而加入了一个重量级联盟组织，那就该精简一下。
我们如何防止搭便车，并让贡献大致与收益成比例？ 当各方只消费共享成果却从不贡献时，一个公共池就会衰败；而当主要贡献者感到被搭便车者利用时，它就会分裂。要让共享价值可见，让贡献大致与收益成比例，并从一个小范围、低风险的领域开始，以便在扩大共享范围之前先积累信任和业绩记录。透明度（公开的决策、路线图和指标）是在没有人有权强制合作的地方维系合作的东西。拿出一份诚实的记录，说明你的组织从每个共享项目中获取了什么，又回馈了什么。如果你在某个你所依赖的东西上是净索取者，你就是在悄悄削弱那个保护你不被单一供应商锁定的东西。
我们合作的边界与我们竞争的边界划在哪里，谁有资格来监督这条边界？ 竞合关系只有在所有人都同意协作止步于竞争前基础层面时才能奏效，因为一旦竞争对手交换定价、揭示市场策略的路线图或客户数据，合作就变成了串通，并使每一个成员都暴露在竞争法处罚的风险之下。对大型团队而言，危险在于深陷于一个共享代码仓库中的工程师，会仅仅因为这条边界从未被划定，而逐渐滑向分享一些法律顾问绝不会批准的内容。拿出一份书面声明，说明协作涵盖什么、明确排除什么，加上你的法律顾问已经审阅过的反垄断防护措施，并指名负责在新工作组成立之前进行审查的人。在监管者密切审视合资企业和联盟组织的企业和政府场景中，要把一条有文档记录、经法律顾问批准的边界，当作参与的前提条件，而不是在调查开始之后才补上的文书工作。
如果这项协作被把持、停滞或崩溃，我们的退出计划是什么，治理机制真的能保护我们吗？ 任何一方都可能离开，一个占主导地位的成员可能把公共池引向自己的目的，一个联盟组织可能开了多年的会却从未交付任何东西，所以你必须提前知道自己将如何脱身、又能保留什么。相互竞争的考量在于，为退出而设计（可移植的数据、以开放许可证发布的可分叉代码、不依赖单一供应商）需要投入精力，而在关系健康时这会让人觉得是在浪费。拿出许可证条款、商标和路线图在法律上归属于何处，以及一个关于如果一个关键合作伙伴在某一周退出、你的组织会怎么做的具体答案。对于承担着对公民多年义务的公共机构而言，一个由单一成员掌控、无法分叉的平台，是人们所依赖的一项服务的持续性风险，所以在加入之前就要以书面形式要求中立托管和退出权利。
我们将如何衡量这项协作是否真正在创造价值，什么样的证据会让我们选择离开？ 组织间工作会积累出一批”僵尸会员资格”：那些你早已在收益消退之后仍在出资和投入人力维持的联盟组织，因为退出感觉像是一种政治表态，也没有人在跟踪回报。要事先约定成功是什么样子（相对于自建的成本节省、在共享基础上交付的功能、被削减的锁定程度），并设定一个会触发对你参与情况进行审查的门槛。拿出你席位的年度成本、你投入的员工工时，以及一份对过去一年你所得到的回报的坦诚评估。在会员资格在各部门之间不断增加、又很少被取消的企业和政府组合中，要指定谁负责每一段关系、按固定节奏审查它，并拥有退出的权力，因为一段没有人负责审查的协作，就是一段永远不会有人退出的协作。

行业视角

初创企业。 你最稀缺的资源是工程注意力，所以只应为了不再重复发明一项商品化依赖而协作，绝不应为了在某个标准委员会上博取声望而协作。共同维护那一个你无力独自拥有的共享库，使用一份轻量级的治理说明和开发者原创声明以保持来源清晰，并把范围保持得足够小，以至于离开的代价只是一次分叉而已。速度比在桌旁占据一席之地更重要：在共享基础直接威胁到你的生存之前，跳过重量级联盟组织。

小型企业。 由于没有专职的法律或标准专家，应把组织间工作当作你加入的东西，而不是你构建的东西，并依靠中立基金会现成的许可和贡献条款，而不是自己起草。在签署任何数据共享安排之前，就你可以对共享数据做什么、责任归于何处获得通俗易懂的答案，因为一次隐私或反垄断方面的失误，代价可能超过协作本身的价值。优先选择你可以直接采用的成熟开源基金会和已发布的标准，而不是需要你自己谈判和监督的定制双边协议。

企业。 把协作作为一个跨众多团队的组合来管理：一份登记册，记录你所属的每一个联盟组织、基金会和合资企业，各自消耗的成本和员工时间，以及它带来的价值。坚持要求对共享资产进行中立托管、经法律顾问审阅的反垄断边界，以及一套书面的治理模式，这样一个占主导地位的合作伙伴就无法把持你所依赖的平台。明确地为参与和贡献的投入做预算，把私有投资留给真正的竞争优势所在，同时在人人共享的商品化基础上共担成本。

政府。 采购规则、透明度义务和公共问责塑造着每一项安排，所以要偏向于没有任何单一供应商能够把持的开放标准和中立治理，并在每一份合同中要求数据可移植性和退出权利。要公开共享平台的治理、路线图和数据共享条款，使公民和监督机构能够看到一项服务是如何运作的，并让跨机构数据共享建立在明确的合法依据和隐私保障之上。先让敏感性较低的服务上线以验证这个模式，并把对具有实际后果的决定的问责，留给一位指名的公职人员，而不是把它分散到一个联盟组织中。

示例

初创企业。 三家早期初创公司都依赖同一个开源数据解析库，而这个库由一位不堪重负的志愿者独自维护，他的职业倦怠威胁着所有这三家公司。他们没有各自悄悄地分叉这个库，而是同意在一个中立的共享代码仓库中共同维护它，配以一份轻量级的书面治理说明和一份开发者原创声明，使贡献拥有清晰的来源。他们只在这个商品化的解析器上协作，把自己的产品严格地分隔开来，并从一个小范围（仅限安全补丁）开始，以便在扩大共享范围之前先建立信任。

企业。 几家相互竞争的云和软件供应商都依赖同一个容器编排平台。他们没有各自维护一个私有分叉，而是把它贡献给一个中立基金会，配以一个技术指导委员会、一套书面治理模式和一份贡献者许可协议。每家公司仍然在其构建于该平台之上的托管服务上激烈竞争（竞合关系），但它们共担这个公共核心的成本和方向。这避免了单一供应商锁定，并让所有人都依赖的这个基础保持健康。反垄断法律顾问确认，合作被限定在共享基础设施层面，而不涉及市场或定价。

政府。 一个国家政府建立了一个共享身份认证平台，使公民只需登录一次即可访问多个机构的服务。该平台由一个中立的中央机构治理，拥有已发布的路线图和明确的决策权，而每个机构仍然保持独立，通过开放 API 和通用数据标准（第 3.8、7.1 章）进行集成。跨机构数据共享协议精确地规定了可以共享什么、出于什么目的、在什么隐私保障之下（第 4.5 章），这样一位公民的数据才只会按照法律和同意所允许的方式流动。敏感性较低的机构先上线，以建立信任并验证这个模式，然后风险更高的服务才加入。

商业案例：动机、投资回报率与总拥有成本

组织间协作的经济学取决于成本共担和网络效应。其核心动机在于，基础性技术构建和维护成本高昂，但一旦共享，价值将远远更高。把投资汇集到一个共同平台或标准上，能把总拥有成本（TCO）分摊到众多组织之间，因此每一方所付出的成本只是自建成本的一小部分，同时还获得了一个能与其他所有人互操作的基础。投资回报率（ROI）来自避免了重复建设、在一个现成基础之上更快地推向市场、减少了锁定并在与供应商的谈判中占据更有利的位置，以及获得了超出任何单一组织围墙之外的人才和创意（第 10.9 章）。

这些成本是真实存在的，而且常常被低估：治理和法律开销、有意义参与所需的员工时间、回馈给公共池的贡献，以及比单一所有者所能做出的更慢的决策。对政府而言，商业案例还要加上公共价值，因为共享平台能减少碎片化、削减各机构的总体支出、改善公民体验，但这必须与问责制和集体惰性的风险相权衡。双方共同的陷阱是校准失当。在真正具有竞争优势或主权优势的事物上进行协作，浪费了差异化优势。而拒绝在商品化基础上协作，则意味着独自为整个行业早已构建好的东西支付全价。最有力的论证是在共享基础上汇聚成本，把私有投资留给真正需要控制权的地方。

反模式与陷阱

搭便车： 各方消费共享成果却从不贡献，使公共池日渐枯竭直至衰败（这正是奥斯特罗姆所研究的经典集体行动问题）。
治理被把持： 一个体量庞大或资源雄厚的成员悄悄把协作引向自己的私利，掏空了中立性。
激励不一致： 各方带着不相容的目标加入，这些目标只有在承诺做出之后才浮现出来，使努力陷入停滞。
没有中立的归属地： 共享资产掌握在某个参与方手中，该方日后可能对其进行分叉、重新许可或撤回。
知识产权条款模糊： 在所有权、许可和专利权利尚未解决之前就开始构建，保证日后会引发纠纷。
对反垄断问题视而不见： 竞争对手以”协作”为掩护交换商业敏感信息。
协作作秀： 一个开会、发文件但从不交付的联盟组织，消耗着预算和善意。
边界混淆： 把跨公司工作当作内部工作来对待，假定拥有一种实际上并不存在的指挥权威。

成熟度模型

第 1 级，启动（Initiate）。 协作是机会主义的、靠个人关系驱动的，仅凭握手协议来治理，没有书面的知识产权、数据或治理条款。竞争对手仅凭非正式的善意在一项共享依赖上进行合作。这在关键人物离开或争议出现之前都能奏效，之后便会崩溃。
第 2 级，发展（Develop）。 一些协作有明确的协议（许可证、CLA 或 DCO、数据共享协议）支撑，有明确界定的范围和决策权，但各团队的实践并不一致。一个团队把共享资产归属于一个中立的归属地，而另一个团队仍然依赖握手协议，治理即便存在，也是双边的、沉重的。
第 3 级，标准化（Standardize）。 一套有文档记录的、覆盖全组织的模式，规范着你们如何协作：共享资产存放在中立的归属地（基金会或中央机构），拥有公开发布的治理机制、路线图和以功绩为基础的决策权；在任何联合工作开始之前，都要求满足一份标准的许可证、知识产权、数据共享和反垄断条款清单；互操作性建立在开放标准之上（第 3.8 章）。这些规则被一致地强制执行，而不是任由各团队自行裁量。
第 4 级，管理（Manage）。 协作组合被度量并对照基线进行控制。你跟踪每一份会员资格的成本和员工工时、每个共享项目的贡献与收益、相对于自建的成本节省，以及被削减的锁定程度，并关注治理被把持的先行指标，例如某一成员在提交量、理事会席位或维护者角色中所占的份额。终止或续约的门槛被提前设定，因此一个停滞的联盟组织或一段净索取的关系，会依据证据被发现，而不是靠感情来辩护。
第 5 级，编排（Orchestrate）。 协作是一项被持续改进、整合于整个组织之中的战略能力。你塑造标准和基金会，而不只是消费它们；维系着健康的公共池；随着市场和风险图景的变化重新平衡竞合关系与退出；并依据你所跟踪的指标调整治理方式。组织间工作是一项核心能力：一个繁荣的政府科技或行业生态系统，而不是一堆彼此割裂的项目。

讨论话题

你的技术中，哪些部分是真正的竞争优势或主权优势，哪些是你应当分摊构建成本的商品化基础？
你要如何及早发现治理被把持，在一个占主导地位的成员已经悄悄把协作引向自己的目的之前？
在为一个联合项目投入工程精力之前，你需要什么样的最低限度的书面协议（知识产权、数据、决策权）？
对于一项跨机构数据共享倡议，你要如何在不陷入停滞的情况下，同时满足交付目标和隐私与数据保护法律（第 4.5 章）？
当一个主要贡献者威胁要离开一个共享平台时，你的治理机制如何让协作存续下去，而不是崩溃或被把持？
健康的竞合关系与反垄断风险之间的界线在哪里，你的组织中谁有资格来判断它？

关键要点

组织间协作是没有共享权威的独立组织之间的联合工作；它是通过治理、合同和信任赢得的，而不是被下令要求的。
刻意地选择形式，无论是联盟组织、基金会、标准组织、合资企业、公私合作伙伴关系、共享平台、数据共享安排，还是竞合关系，要与目标相匹配。
中立治理、清晰的决策权以及明确的贡献和知识产权条款，是让独立各方（包括竞争对手）能够安全协作的东西。
互操作性和开放标准（第 3.8 章）是技术基础；没有它们，协作就会衰败为脆弱的、易被锁定的集成。
就数据共享、隐私（第 4.5 章）和反垄断问题审慎地订立合同，尤其是在竞争对手合作时。
警惕那些失败模式（搭便车、治理被把持和激励不一致），并把治理和退出权利设计得足以抵御它们。
无论是企业还是政府，都应在共同基础上分摊成本，把控制权保留给优势和主权真正所在之处（第 10.11 章）。

参考资料与延伸阅读

Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action (1990)：关于共享资源如何在没有中央权威的情况下得以维系的奠基性研究。
Henry Chesbrough, Open Innovation: The New Imperative for Creating and Profiting from Technology (2003)：把跨越组织边界的协作视为创新来源的著作。
Apache 软件基金会：其治理模式、“Apache 之道”，以及基于功绩的决策机制（apache.org）。
Linux 基金会：为大规模开源协作提供中立托管和治理（linuxfoundation.org）。
Karim Lakhani 等人关于开源与社区驱动创新的著述；以及 Adam Brandenburger 和 Barry Nalebuff 所著 Co-opetition (1996)：关于同时进行合作与竞争的策略。
OpenSSF（开源安全基金会）与 OpenChain 标准（ISO/IEC 5230）：应对供应链与许可合规问题的跨组织方法。
关于共享平台与跨机构数据共享的政府数字服务与 GovTech 文献（例如各国的数字服务与开放标准指南）。