10.18 开源项目办公室（OSPO）与上游贡献

概述与动机

你的组织早已运行在开源软件之上：承载你产品的操作系统、编程语言、数据库和各种库，大多是由不为你工作的人所编写的。第 10.3 章讨论了采购和许可证合规，第 10.12 章讨论了开源与闭源的取舍。本章讨论的是让这一切协调统一的职能：开源项目办公室（OSPO），即负责公司如何使用、贡献和发布开源软件的团队。OSPO 是一段原本分散在每一个敲下 import 的工程师身上的关系的重心所在。

大多数组织都是一点一点“误打误撞”地进入开源领域，然后才一下子发现累积起来的风险敞口：收购尽职调查中的一次许可证疑问、一个只剩一位精疲力竭维护者的关键库、代码里一个没人知道自己在使用的安全公告。OSPO 把这种手忙脚乱变成一种被管理的能力。它制定的消费政策是为了赋能而非阻拦，它决定何时向上游贡献能服务于业务，它管理你发布的项目，并通过 InnerSource 把开放协作的方式应用到公司内部。这是一项与你的软件工程价值观（第 1.1 章）相连的战略职能，而不是一个合规打钩项。

对企业而言，驱动因素是规模：成千上万个依赖项，跨司法辖区的出口和许可证义务，以及每天各自做出细小开源决策的成百上千名工程师。一个统一的办公室为这种蔓延带来一根主心骨。对政府而言，驱动因素是政策和公众信任。“默认开源”和“公共资金、公共代码”正日益成为法律要求，因此公共机构需要有人能够安全地发布代码、跨机构复用代码，并要求供应商遵循开放标准。在这两种场景下，OSPO 都通过把隐形的、未被定价的风险转化为经过深思熟虑、有预算保障的工作，来实现自我回报。

关键原则

开源是一种双向关系，不是一个免费仓库。 你消费、你贡献、你发布，而 OSPO 三者都要负责。
贡献是战略，不是慈善。 向上游贡献能降低维护私有补丁的成本，并为你换来影响力。
打通快速通道，而不是死守关卡。 一项比直接复制代码还慢的政策会被无视，因此要让合规路径成为最快的路径。
资助你所依赖的维护者。 公地并非自我可持续的，你最关键的库可能只有一位没有报酬的作者。
要么好好管理你发布的项目，要么就别发布。 一个被遗弃的项目对声誉的伤害，比从未发布过任何项目还要大。
衡量参与度，这样你才能改进它。 统计的是贡献数量、依赖健康状况和审批耗时，而不是新闻稿。
在政府场景中，默认开放、默认发布。 开放是常态，封闭才是需要记录在案的例外。

建议

建立一个与你实际规模相匹配的 OSPO

起步时你不需要一个庞大的团队。在一家创业公司，OSPO 可以只是一名拥有书面授权、每周投入几个小时的工程师。在一家企业，它可以是一个小型中心团队，加上嵌入各产品团队中的一个由“倡导者”组成的联邦式网络。无论规模大小，都要给它一份清晰的章程，涵盖四项职责：消费政策与合规、上游贡献、发布并管理自有项目，以及社区和资助关系。要把它安置在既能看到工程、又能看到法务的位置，通常向 CTO 或工程副总裁汇报，并与法务和安全部门保持虚线联系。常见的失败模式是让 OSPO 完全隶属于法务部门，从而变成一个刹车；解决办法是配备会写代码、能交付的工程师，让它的指导在所服务的团队中具有可信度。

负责任地消费开源，并让安全路径成为便捷路径

风险大多是从消费环节进入的，因此要让良好行为变得毫不费力。提供一份经过预先审核的内部组件目录、在流水线中进行自动化的许可证和漏洞扫描，以及开发者无需提交工单就能遵循的清晰默认设置。借助第 10.3 章中的许可证纪律和第 2.18 章中的供应链与依赖健康实践：锁定版本、生成软件物料清单、留意软件供应链中被入侵或被遗弃的软件包，并在生命周期结束之前就追踪到，以免它逼你被迫迁移。OSPO 的工作不是逐一手动批准每一个依赖项，而是构建护栏，使百分之九十五的选择能够自动做到安全，只有真正不寻常的情形才会到达人工审核这一步。

向上游贡献，是因为它划算，而不是因为它高尚

把向上游贡献当作一项经济决策来对待。你为某个依赖项维护的每一个私有补丁，都是你在每一次升级时都要缴纳的税，而且是永远缴纳，直到这个改动被合并进上游，或者这个分支偏离得太远，以至于你实际上完全拥有了它。把修复贡献回去，就能删除这笔税。向上游贡献还能为你换来对项目方向的影响力，让你依赖的组件的路线图向你的需求倾斜，同时也向你想招募的工程师展示了你的能力水平。给你的开发者一条快速、有文档记录的路径：一份预先审核通过的贡献者许可协议或开发者原创声明、一次确认改动可以安全公开的轻量级审批，以及为这项工作预留的管理时间。当替代方案是永久维护一个你自己无法掌控的项目的分支时，把改动贡献回去几乎总是更便宜的选择。

以真正的治理来发布自己的项目

当你要把自己构建的软件开源时，要么深思熟虑地去做，要么干脆不做。首先决定这份代码是值得共享的通用组件，还是值得保持闭源的差异化优势，运用第 10.12 章中的推理方式来判断。如果决定发布，就选择一个与你意图相符的许可证（宽松式许可证有利于最大化采用，Copyleft 许可证则能保持生态系统的互惠性），通过一份书面治理模型记录清楚由谁决定什么事情，并为项目名称注册商标，这样你既能保护它不被滥用，又能保持代码的自由。要承诺真正的管理责任：一个公开的问题跟踪器、一份贡献指南、一份行为准则，以及一份带有协调披露机制的安全策略，让报告者知道如何联系到你（第 4.2 章）。指定一位维护者并为其时间预留预算。一个你敲锣打鼓发布、却在一年内被弃之不顾的项目，对声誉造成的伤害，比你从未发布过它还要大。

运用 InnerSource 在公司内部开展协作

让开源得以运转的那些习惯（公开的代码仓库、清晰的贡献指南、按贡献价值评审、首次提交补丁的低门槛），在防火墙内同样行之有效。InnerSource 意味着任何工程师都可以查找、使用并改进任何内部项目，可以跨团队边界发送拉取请求，而不必提交工单然后苦等。这打破了部门壁垒，促进了代码复用，并让你的员工提前熟悉了他们日后向外部贡献时会用到的那套工作流程。OSPO 是 InnerSource 的天然归属地，因为它已经掌握了相关工具和文化打法。从几个高价值的共享库入手，在内部发布它们的贡献指南，并奖励那些能优雅接纳外部补丁的团队。

资助并维系你所依赖的维护者

你的生产系统可能建立在某个人业余时间维护的一个库之上。那是一种供应链风险，诚实的应对方式是帮忙分担这份重担。从你的物料清单中识别出最关键的依赖项，找出那些维护者基础薄弱的项目，并为每一个都选择一种应对方式：直接赞助维护者、贡献工程时间、加入资助该项目的基金会，或者作为最后手段，准备好分叉或替换它。资助公地远比其崩溃之后的紧急处置更便宜，并且能让你所依赖的组件保持健康，并朝着你能够施加影响的方向发展。

制定能够快速批准的贡献政策

制定贡献政策的目的是快速说“是”，而不是慢慢说“不”。要明确写清哪些内容工程师无需请示就能贡献（缺陷修复、文档，以及对你已经在使用的项目做的小功能），哪些内容需要一次轻量级检查（涉及差异化优势或专利的任何内容），以及知识产权和贡献者协议如何被集中地、一次性地处理，而不是每次贡献都重新处理一遍。把枯燥的部分自动化：许可证检查、预先签署好的公司贡献者协议，以及一个能标记出真正需要人工审核的少数提交的机器人。衡量审批耗时，并把缓慢的队列当作政策本身的一个缺陷来对待。

权衡：利弊

方式	优点	缺点
中心化 OSPO	政策一致，专业能力深厚，归属清晰	如果只把关而不赋能，就可能成为瓶颈
联邦式 OSPO（团队中的倡导者）	可扩展，决策贴近工程师	需要强协调，否则政策会渐行渐远
向上游贡献	消除私有补丁税，换取影响力，助力招聘	需要持续投入、知识产权审核，且要配合他人的进度
维护私有分支	完全掌控，按自己的时间表发布	永久的维护税，会偏离上游的安全修复
发布自己的项目	生态、声誉、共享维护	真实的管理成本；被遗弃会损害声誉
资助维护者	保护关键依赖项，换取善意	直接成本，选择资助谁也涉及政治因素
没有 OSPO（临时应对）	零建立成本	隐形的法律、安全和可持续性债务

核心张力存在于管控与赋能之间。一个逐一手动审核每一个依赖项和每一次贡献的 OSPO 让人感觉安全，但它会变成工程师们想方设法绕开的东西，反而催生了它原本想要防止的隐形影子依赖。一个只发布愉快指导意见、却没有任何自动化强制机制的 OSPO，一旦截止日期临近就会被无视。解决办法与贯穿第 10.3 章的那一条相同：把常见情形自动化，使合规路径成为最快的路径，把人工判断保留给真正新颖的情形。把这个平衡拿捏对了，这个办公室就是一个力量倍增器；无论往哪个方向失衡，它要么变成一个刹车，要么沦为一个摆设。

与团队讨论的问题

今天谁负责你与开源的关系，明天他们能回答一个棘手的问题吗？ 如果一个潜在收购方的律师索要你的许可证清单，或者一位记者询问你的支付路径中有哪个无人维护的库，答案背后有一个具体的名字吗？对大多数组织来说，诚实的回答是“没有人”，这意味着每一位工程师都在悄悄制定政策，却没有人为整体结果负责。把证据带到会议上：试着拿出获批许可证清单、软件物料清单，以及在尽职调查中能够回答 Copyleft 相关问题的那个人。如果这些材料并不存在，或者指向的是“没人”，你就找到了 OSPO 的第一项任务。要做的决定不是要不要设立这项职能，而是由谁来负责、他们拥有怎样的授权，哪怕这个办公室只是一个人一周投入一天。
你是否维护着本可以贡献到上游的私有补丁，这让你付出了什么代价？ 许多团队都悄悄维护着一堆针对依赖项的本地修改，在每次升级时手工重新应用，并把合并的痛苦当作理所当然的自然法则去承受。每一个这样的补丁都是一笔反复缴纳的税，也都是一个可以贡献回去、从而让这笔税消失的候选项。把具体情况带来：列出你的构建实际携带的分支和本地补丁，估算每一个每年花费的工程小时数，并注明哪些上游项目很可能会接受这项改动。相竞争的考量是真实存在的，因为向上游贡献现在就要付出努力，而且要配合维护者的时间表，但要比较的对象是永远缴纳这笔补丁税。答案应当把“我们总是直接重新应用它”变成一个经过深思熟虑的选择，并配上一条快到工程师真的会去用的贡献路径。
如果某个依赖项的维护者突然离开，哪一个会造成最大的伤害，你打算怎么办？ 你的技术栈中某处有一个组件，一旦出问题就会中断某项营收或关乎使命的服务，而维护它的是一个人或少数几个人，你从未资助过或感谢过他们。公地感觉起来是免费的，直到它不再免费的那一刻，而这一课昂贵的版本，就是在维护者放弃或出现未修补漏洞之后的手忙脚乱。带上你的物料清单，按影响范围给依赖项排序，然后记下排名靠前的那几个的维护者人数和资助状况。对每一个关键但人手单薄的依赖项，提前决定你是要赞助、贡献时间、加入基金会，还是准备好替换它。这会把一个潜在的单点故障，转化为一段被管理的关系，并按照其他任何运营风险同样的标准来对待（第 2.18 章）。
在把下一个内部工具开源之前，你是否准备好为它管理多年，还是只打算发布之后事后道歉？ 公开发布是一项长期承诺：需要有人分诊的问题跟踪器、需要有人守着的安全邮箱，以及需要有人捍卫的名字。团队往往为了助力招聘或博取好感而选择开源，随后才发现一个带着陈旧未处理问题、被遗弃的项目，对他们希望建立的声誉造成的伤害，比什么都不发布还要大。带上证据：列出你已经发布的项目，对每一个都说明其未处理问题的存续时间、是否有指定维护者并预留了工时、是否有治理模型、是否注册了商标、是否有协调披露政策，以及这份代码究竟是值得共享的通用组件，还是应当保持闭源的差异化优势（第 10.12 章）。相竞争的考量是，真正的管理会占用本可以投入产品的工程时间，因此诚实的选择往往是少发布一些项目，但把它们真正管理好。对企业而言，这意味着发布前要经过法务和品牌审核；对政府而言，这意味着商标、披露渠道以及默认发布豁免流程都要在代码仓库公开之前就落实好。
一名工程师要让一个依赖项获批、或让一次贡献获得放行，实际需要多久，这是否比绕开你更慢？ 一项开源政策直接与工程师能找到的最快变通方案竞争，任何比直接复制代码还慢的流程都会被绕过，从而催生出这个办公室原本想要防止的隐形影子依赖。这里的张力在于管控与赋能：每一次人工审核都会增加一条审计轨迹，并抓住那些真正罕见的问题，但也会增加延迟，把中位数情形推离合规路径。把数字带到会议上：一次标准依赖项和一次标准贡献的实测审批耗时、由自动化处理与由人工处理的决策占比，以及上个季度真正需要人工判断的例外数量。在一家拥有成百上千名工程师、每天都在各自做出小决策的企业里，一个两天的队列会悄悄变成成千上万次被绕过的审核；在政府场景中，同样的延迟会与要求留下变通方案所跳过的书面记录的采购和审计义务发生冲突，因此解决办法是把常见情形自动化，而不是配备一个更大的关卡。
哪些内部项目最能从 InnerSource 中受益，今天是什么阻止了另一个团队向你发送拉取请求？ 让开源得以运转的那些实践（公开的代码仓库、贡献指南、按贡献价值评审、首次提交补丁的低门槛），在防火墙内同样能带来回报，打破部门壁垒、扩散代码复用，并训练人们熟悉他们日后向外部贡献时会用到的那套确切工作流程。相竞争的考量是，公开一个内部项目需要一份贡献指南、富余的评审能力，以及一个关于哪些代码出于安全或监管原因必须保持受限的决定。带上具体情况：说出那些高价值的共享库、注明哪些已经发布了内部贡献指南，并描述今天一次跨团队拉取请求是如何被处理的（）是受到欢迎，还是石沉大海。对企业而言，回报体现在众多团队之间避免了多少重复的内部构建；对政府而言，同样的习惯延伸到跨机构边界，形成跨机构复用，使默认发布和共享组件减少而不是成倍增加重复的公共支出。

行业视角

创业公司。 给这个办公室配一位有名有姓、每周投入几个小时的工程师，配上一页纸的章程，而不是一个委员会。默认采用宽松式许可证，配合流水线中的扫描器，只向上游贡献那少数几个每次升级都真正带来痛苦的私有补丁，并为那个你真的离不开的单人维护库设立一份小额月度赞助。速度在这里比覆盖面更重要：一条比复制代码更快的合规路径，胜过一份没人遵循的周全政策。

小型企业。 你不会配备专职的 OSPO，因此要通过你已经在用的工具购买这项能力：一个能标记许可证和漏洞问题的扫描器，以及一份经过预先审核的组件目录。把这项工作定位为许可证合规和依赖健康方面的卫生习惯，而不是一个项目：了解你的软件物料清单中有什么、了解每份许可证要求什么、了解哪个单一维护者的依赖项一旦消失会造成伤害。相比自己搭建，优先选择购买扫描和编目能力。

企业。 运行一个小型中心办公室，加上嵌入各产品团队中的倡导者联邦式网络，让政策保持一致，同时让决策贴近工程师。把许可证、漏洞和出口扫描自动化，让每一位工程师从入职第一天起就被一份预先审核通过的贡献者协议所覆盖，并把审批耗时作为一项报告指标来跟踪。资助你关键依赖项背后的基金会，在众多代码仓库中推行 InnerSource，并把整个资产组合当作一个拥有健康度和参与度指标的投资组合来管理，而不是一堆零散的个别决定。

政府。 在默认开源和公共资金、公共代码的原则下运营：除非有记录在案的安全或隐私豁免适用，否则新服务都发布在公开代码仓库中。运行一个跨机构目录，让各团队先复用再构建，把开源和开放标准要求写入采购流程，使供应商交付可复用、权利得以保留的代码，并对你发布的内容处理协调披露。资助多个机构都依赖的共享库的维护工作，这样就不会有某个团队悄悄独自拥有整个政府都依赖的基础设施。

示例

创业公司。 一家二十人规模的创业公司让首席平台工程师兼任 OSPO 负责人，配有一页纸的章程。她制定了一项简单的消费政策（宽松式许可证预先批准，Copyleft 许可证需要审核，流水线中配有扫描器），并注意到团队针对一个开源队列库维护着三个私有补丁，每次升级都要痛苦地重新应用。她把这三个补丁都贡献到了上游；其中两个在一个月内被接受，从此永久删除了这笔升级税。她把一个小型内部工具开源，配上一份真正的 README、一份许可证和一个安全联系人，主要是为了吸引工程师，并为产品所依赖的那个单人维护的解析器设立了一份月度赞助。这一切都不需要增加编制，只需要一位有名有姓的负责人和一份清晰的授权。

企业。 一家全球性银行运营着一个由六人组成的中心 OSPO，加上嵌入每个产品组的开源倡导者联邦式网络。中心团队负责政策、自动化的许可证与出口合规扫描，以及从第一天起就覆盖每一位工程师的贡献者许可协议。倡导者们负责本地审核，并指导自己团队如何进行贡献。这家银行资助了几个基金会，它们的项目支撑着该行的交易系统；它还把修复贡献回上游一个被广泛使用的数据框架，从而不再需要维护一个分支；并在两百个内部代码仓库中推行 InnerSource，使任何团队都可以向任何其他团队发送拉取请求。一次标准贡献的审批耗时不到两天，这被作为一项指标，由 OSPO 每季度报告一次。

政府。 一个国家级数字机构在“默认开源”和公共资金、公共代码的要求下运营。其 OSPO 把新服务发布在公开代码仓库中，除非有记录在案的安全或隐私豁免适用；它运行一个跨政府目录，让各机构在构建之前先复用代码；并把开源和开放标准要求写入采购流程，使供应商交付可复用、文档完善的代码，同时政府保留相关权利。该办公室还为其发布的代码处理协调安全披露，并资助一个现已被多个机构依赖的共享身份库的维护工作，这样就不会有某个团队悄悄独自拥有整个政府都依赖的组件。

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

最明确的回报，是消除了本可避免的、代价高昂的意外。缺乏管理的开源会产生按自己的时间表到来的危机：收购尽职调查中浮现出的一次 Copyleft 违规、一次针对已死组件的紧急迁移，或是一次追溯到某个从未列入清单的依赖项的入侵事件。OSPO 把这些低概率、高成本的事件，转化为稳定的、有预算保障的日常工作。再叠加上来自上游贡献的持续性节省：你每退役一个私有补丁，就停止了对未来每一次升级征税，而在一个庞大的资产规模下，这会累积成真正被归还给产品工作的工程能力。

在总拥有成本这本账上，相对于它所保护的东西，这个办公室是廉价的。它的成本是一个小团队、一些扫描和编目工具，以及适度的维护者资助。把它与没有这个办公室的成本相比较：法律责任、失败或延迟的尽职调查、安全事件、对本已作为开源存在的东西的重复内部构建，以及没人选择却一直在维护的分支所带来的缓慢失血。还有一些更难定价但真实存在的上行回报：对你所依赖组件方向的影响力、一个可信的开源存在所带来的招聘和声誉优势，以及因为工程师复用而非重建所带来的更快交付。在向领导层论证时，把 OSPO 定位为针对你代码库大部分内容的供应链管理，外加一份战略红利。在政府场景中，还要加上合规维度，因为开放往往是强制要求的，做好这件事既能避免不合规，也能避免重复的公共支出。

反模式与陷阱

把 OSPO 当作一道关卡。 一个只审核、只阻拦、从不赋能的办公室，会被绕开，从而催生出它原本想要防止的影子依赖。
贡献表演。 一边宣布开源战略，一边把审批流程拖得如此缓慢，以至于实际上没有人真正去贡献。
被遗弃的发布。 用一篇发布博文推出一个项目，然后再也不处理任何问题，对声誉造成的伤害比保持沉默还大。
分叉后就不管了。 为一个修复分叉一个依赖项，然后永远维护下去，逐渐偏离上游的安全补丁。
搭脆弱维护者的便车。 依赖一个关键的单人维护库，却从不资助、感谢或帮助背后的那个人。
忽视商标。 发布一个项目却不保护它的名字，眼睁睁看着某个分支或供应商借你的声誉牟利。
只由法务部门拥有。 把 OSPO 完全安置在法务部门内，使其指导在工程上毫无可信度，各团队直接屏蔽它。
虚荣指标。 统计星标数和媒体提及次数，而不是依赖健康状况、审批耗时和退役的私有补丁数量。

成熟度模型

第 1 级，启动： 工程师们在没有政策、没有负责人的情况下添加、修补，偶尔发布开源项目。消费、贡献和发布都是被动且临时的，由个人主动性驱动。私有分支在无人察觉的情况下不断累积，没有人资助任何上游项目，也没有人能在尽职调查中回答许可证相关问题。
第 2 级，发展： 基本实践开始出现，但因团队而异。存在一份粗略的消费政策和一份获批许可证清单，也有人大致负责，但贡献流程缓慢且逐案处理，一些团队做得远比其他团队多。少数关键依赖项已被识别，但可持续性、发布和管理仍然参差不齐。
第 3 级，标准化： 一个拥有明确章程的 OSPO 负责消费、贡献、发布和社区事务，相关实践已被记录并在整个组织范围内得到执行。扫描和软件物料清单已实现自动化，存在预先审核通过的贡献者协议和快速审批路径，已发布的项目具备真正的治理、商标和安全策略，InnerSource 正在扩展。政府团队默认发布。
第 4 级，管理： 开源职能被对照基线加以度量和控制。审批耗时被对照目标进行跟踪，贡献量和上游接受率被报告，依赖健康和维护者数量仪表盘标记出单点故障，头部风险依赖项中获得资助维护者覆盖的比例被监控，私有补丁和分支的清单逐季度呈下降趋势。已发布项目的问题响应时间被度量，例外情况按固定节奏被审查，星标之类的虚荣指标被弃用，改用这些指标。
第 5 级，编排： 开源是一项被管理的战略能力，与工程、法务、安全和采购规划相整合，并被持续调整适应。贡献是日常事务，关键维护者和基金会得到资助，组织既管理好运行良好的自有项目，也在引导它所依赖的生态系统的走向，InnerSource 已成为常态。参与度和健康度指标驱动持续改进，投资组合会随着依赖项、风险和授权要求的变化而重新平衡。

讨论话题

一个赋能型 OSPO 与一个设卡型 OSPO 之间的界线在哪里，从外部你要如何判断自己建立的是哪一种？
你携带的私有补丁或分支，哪些是出于习惯而非必要，把排名前三的贡献到上游需要做什么？
当关键依赖项的清单比预算还长时，你应当如何决定资助哪些维护者和基金会？
如果你必须从第一天起就以真正的治理、一个商标和一份协调披露政策来发布下一个版本，你的项目实际上会发生什么真正的变化？
对于公共部门的读者而言，在不悄悄削弱原则的前提下，为代码豁免默认发布制定一套站得住脚的流程应该是什么样的？
哪些内部库最能从 InnerSource 中受益，今天是什么阻止了另一个团队向你发送拉取请求？

关键要点

OSPO 负责与开源的整段关系：负责任地消费、向上游贡献、发布自己的项目，以及维系你所依赖的维护者。
向上游贡献是战略，不是慈善；它能消除私有补丁反复缴纳的税，换取对项目方向的影响力，并帮助你招聘人才。
通过自动化和精选，让合规路径成为最快的路径，使这个办公室能够赋能工程师，而不是设卡阻拦他们。
只有在具备真正的治理、一个选定的许可证、受保护的商标和协调安全披露的情况下，才发布自己的项目，否则就不要发布。
资助并帮助你生产系统所依赖的关键维护者，因为公地并非自我可持续的。
运用 InnerSource 把开源式协作带入公司内部；在政府场景中，默认开放、默认发布，先复用再构建。

参考文献与延伸阅读

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-license list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance