InnerSource 是个谎言 - 对常见误解的回应
当你在 YouTube 上搜索"InnerSource"时，你很可能遇到的第一个结果之一就是一个声称"InnerSource 是个谎言"的视频。
(链接: https://youtube.com/shorts/53jEP3mPP3E)
这种观点代表了许多人在初次了解 InnerSource 时容易陷入的典型陷阱。
我想用这个视频作为案例研究来解释它推广的误导性结论。这也是我过去犯过的错误，是许多没有深入探索这个领域的人容易陷入的陷阱。这就是为什么我想通过自我反思来审视这个问题，并通过解开这些陷阱来帮助其他人找到正确的道路。
第一个误解：“使用 React 让其他人可以贡献” #
让我首先分析这个案例中的论点。视频建议在内部应用程序中使用 React，理由是"使用 React 因为其他人可以为它做贡献。“这种推理在实际的 InnerSource 讨论中很少听到。
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
这个论点可以分解为三个关键问题：
- 对 InnerSource 实际含义的根本误解
- 为 InnerSource 应用选择了错误的领域
- 混淆了个人与团队的视角
InnerSource 的真正含义 #
InnerSource 是关于在公司内部实践开源原则。它不是仅仅关于"贡献"或"接受贡献”。
大多数与开源互动的人只是"用户"。有些只是消费者，有些提交错误报告，只有一小部分人实际提交拉取请求。InnerSource 在内部应用开源学习，创建开放、广泛可访问、决策透明、团队关系建立在通过所有权和指导建立的信任基础上的组织。这创造了透明和协作的文化。
这就是"在内部实践开源"的含义——它不仅仅是关于"接受拉取请求"。拉取请求只是这种文化的一个结果，而不是主要目标。
InnerSource 应用的次优领域 #
第二个问题是这个论点在 InnerSource 和开源面临特殊挑战的领域中展开。
如果你想要"接受拉取请求"或"让许多人使用你的代码来提高质量"，这可能会受到你产品性质的限制。很明显，共享"高依赖组件"或平台级工具会比最终用户应用程序创造更多价值。虽然流对齐团队在有益时仍应采用开源实践，但协作动态有显著不同。
根据我与企业公司合作的经验，将 InnerSource 用于最终用户是"非工程师"的项目级倡议会带来独特的挑战。为什么？因为最终这些产品需要服务于可能缺乏开发技能和与开发团队直接沟通渠道的"最终用户"或"业务用户"的需求。这创造了复杂、个性化的需求和更长的沟通前置时间。
当应用于共享库、平台组件、开发工具和基础设施代码时，InnerSource 实施往往效果相对较好——这些领域的"用户"主要是其他开发人员，他们可以有意义地贡献并从协作开发实践中受益。
虽然将 InnerSource 实践应用于面向用户的应用程序可以带来有价值的好处，如透明度和改进的问题跟踪（仅此一点就使其值得）。
个人与团队视角 #
第三个问题涉及"你"是指个人还是团队。
重要的是要注意，InnerSource 不一定是等待某人为公司内"你的个人项目"做贡献。当应用 InnerSource 时，可能会有人为在 20% 时间内开发的项目做贡献的情况，就像大型科技公司那样，但这不一定是主流方法。
InnerSource 主要被引入和维护是因为它通过成本降低、避免重复造轮子、创造协同效应、质量保证和消除层级决策的沟通开销来产生投资回报率。这通常涉及共享的内部库、专有竞争优势组件，或在企业内具有高依赖性但相对小众的东西。这些"业务好处"通常在大多数情况下回流到"团队运营"中。最终，这都是关于团队和组织的投资回报率。如果我们不考虑团队，有人会阻止你为项目做贡献。无论是短期还是长期，你都需要证明你的投资回报率。
InnerSource 的独特之处在于它根本上是关于团队间协作。这是大多数实施最终的结果。它不一定是个人随机为方便的个人项目做贡献。它通常通过主机团队和客户团队关系来实施，客户团队与主机团队维护的部分一起工作。大多数企业都有具有明确角色和责任的员工，协作往往在这些结构内发生。
因此，当平台团队和流对齐团队（客户团队和主机团队）之间建立关系时，InnerSource 特别有效。流对齐团队或个人之间的主动共创更不确定能自然成功。
基于不太可能成功的场景来批评整个 InnerSource 在逻辑上没有意义。
第二个误解：“这在真实公司中永远不会发生” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
实际上，这正在发生。案例研究证明了这一点。就是这样。
第三个误解：“99.69% 的 InnerSource 项目会失败” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
这可能是正确的，取决于你如何定义"InnerSource"。如前所述，InnerSource 不是关于"接受 PR 贡献"。
然而，有三个重要点需要考虑：
- InnerSource 特别适用于战略组件——不是所有组件都需要
- 好处超越了主动贡献
- 开源也有同样的"失败率"问题
InnerSource 是企业战略 #
当人们想到 InnerSource 时，他们有时会想象激进的想法，如"在企业内共享所有代码"或"每个人都为一切做贡献"。他们可能设想公司内有数百个共享存储库，每个人都积极交换贡献。就像开源是公司的战略一样，InnerSource 也是有优先级的企业战略。公司首先共享"值得共享的东西"。
因此，代码在团队间积极流动和充满活力的跨团队协作发生的代码库的实际数量相对较少。这可能确实是个位数百分比。然而，即使没有积极的跨团队协作，许多项目也可以从开放和透明中受益。在这种 InnerSource 意义上，企业通常可以在更多情况下共享价值。
虽然 InnerSource 包括个人贡献，但它主要专注于团队间协作。因此，通过 InnerSource 共享的内容往往在企业内相对小众，或者是特定目的的项目，如为特定需求分叉的 Linux 发行版。或者它可能只是开源式的开发文化，就像 GitHub 在所有员工中共享 Ruby on Rails 代码一样。
当我们将这个百分比讨论限定在积极协作并作为共同需求维护的 InnerSource 上时，百分比可能确实相对较低。然而，像文档拉取请求或客户团队和平台/主机团队之间的小配置更改（发送小补丁）这样的小协作相对频繁地发生。当你包括这些微协作和防止重复努力的透明度好处时，这些数字会显著增加。
开源有同样的"问题" #
另一方面，如果我们这样定义，开源也会是一个"谎言"。因为"99.69% 的开源项目会失败"。大多数作为开源发布的代码都不会收到贡献。但没有人因此说"开源是个谎言"。人们追求开源是因为除了接受贡献之外还有好处。
再次，“被贡献"不是 InnerSource 的唯一价值。 开源价值也是如此。
透明度的真正好处 #
保持内部代码开放而不是隐藏——在 GitHub，收入团队的架构师或解决方案工程师可能能够检查源代码以找到相关信息，可能找到非常接近客户请求的细节，促进更顺畅的支持对话，并从问题中提取更准确的信息。我住在东京，有时直接查看 Ruby 代码来检查实现，或者去问题中检查更改的背景，比等待位于旧金山的产品团队醒来询问关于更改及其背景的实现问题要快。
使用 git blame 命令，你可以识别代码的"真正"利益相关者并询问决策背景的问题。
不用说，这同样适用于其他开发团队。拥有关于可能创建依赖关系的组件的现成信息明显减少了沟通开销。
InnerSource 是关于在内部实践开源原则。InnerSource 不仅仅是来回发送拉取请求——它是关于确保透明度并通过开源式协作获得好处。这些好处远远超出了少数积极维护的存储库，扩展到更广泛的文化实施好处。
第四个误解：“你离开时会被叫回来” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
资源有时会无人维护，但这不是对 InnerSource 本身的适当批评——这是对未能正确实施 InnerSource 的批评。这不是对 InnerSource 的批评，而是对缺乏维护文化（没有人维护代码）的批评。这源于未能正确实施 InnerSource 或根本没有考虑它——缺乏所有权的结果。
DevOps 类比 #
这是对未能做好 InnerSource 的批评，不是对 InnerSource 本身的批评。有时这会混淆逻辑。用 DevOps 术语来说：这就像说"公司最终采用了几个月的缓慢审查周期或审计，或为发布决策添加流程，所以发布变成季度或一年只有两次。因此，声称能够实现快速发布的 DevOps 不好。“这不是因为 DevOps 方法论不好，而只是因为"有些情况下 DevOps 无法实施。”
打破业务流程极其困难，许多公司说 DevOps 是不可能的。但即使人们认为不可能，也有勇敢的先驱者努力改变文化并实现了 DevOps。InnerSource 也可能发生同样的情况。
第五个误解：“你必须 100% 拥有一切” #
you own it 100% (这意味着：你不 100% 拥有的 InnerSource 是不可能的)
“InnerSource 意味着放弃代码所有权"是错误的。InnerSource 实际上要求团队拥有代码。这是一个常见错误。这就像想要放弃维护责任并说"让我们把它开源"的人。那不会起作用。
个人与团队所有权 - InnerSource 是强代码所有权吗？ #
首先，这个"你"是单数还是复数？虽然个人可能在组织的 CODEOWNERS 文件中被列出，但团队最终对代码负责。从上下文来看，它很可能在谈论强代码所有权。但在考虑组织维护时这并不好。因为员工可能会辞职。
InnerSource 不是强代码所有权。 至少，多个人需要共享责任。话虽如此，我承认强代码所有权可能在短期内出现，在项目的早期阶段，强烈的个人意志可能自然导致这种安排，但如果你想实现长期成功，有必要委派权力，以便组织能够集体处理维护。
团队所有权的类型 - InnerSource 是集体代码所有权吗？ #
这种论点有时可能指的是集体所有权。在这种情况下，论点似乎也暗示 InnerSource 意味着集体所有权，但这实际上是不同的。InnerSource 不是集体代码所有权 InnerSource 涉及主机团队最终处理维护。InnerSource 是弱代码所有权。所以虽然维护责任是 100% 正确的，但说"你必须拥有 100% 而 InnerSource 是不同的"是完全不合逻辑的。这实际上是一个不正确的观点。
正如 Martin Fowler 关于代码所有权的著名论述，让每个人都 100% 拥有代码（集体所有权）有时会创造没有人承担责任的情况。这是非常有问题的——责任变得不明确，项目最终失败。
弱代码所有权模型 #
在弱代码所有权中，维护者存在，主机团队维护项目，特定部分可能从其他团队引入受信任的提交者/维护者。有人可能贡献，有人可能维护，但不是"你"或"你的团队” 100%——这可能相当不同。例如，98% 的代码可能由你的团队拥有，而 2% 可能由其他团队拥有。
在这种情况下，记住即使个人在组织中被指定为代码所有者，团队最终对代码负责。团队应该拥有它，不要忘记这个重要点。
第六个误解：“有人会给你扔 7000 行代码” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
突然出现 7000 行拉取请求本身就是引入 InnerSource 文化的失败——这不是通过做 InnerSource 发生的事情。这种情况可能担心引入 InnerSource 会使这种协作发生，但这是完全错误的。
真正的问题 #
这个论点代表未能实施 InnerSource 文化和协作实践，而不是 InnerSource 本身。7000 行实现是非常有限的情况。这代表协作文化的失败，其中 7000 行在没有任何通知的情况下突然作为拉取请求提交——组织应该修复这个根本的文化问题，这是 InnerSource 之前的问题。
如果你想防止这种情况，有一个解决方案。在你的组织内培养 InnerSource 文化:)
现实：InnerSource 实际上是什么 #
InnerSource 是文化实施——使用开源协作实践来享受开源通过协作获得的各种好处。InnerSource 的最终目的不仅仅是接受贡献（拉取请求），还包括通过问题的功能请求、支持协调和各种其他好处，加上决策透明度和实际的文化推广。
因此，我明确拒绝"实施 InnerSource 最佳实践来获得拉取请求是个谎言"的说法。
理解贡献现实 #
“没有人会贡献”
在开源协作中，贡献者确实是极少数。在 1000 个用户中，也许绝大多数只是用户，20 个可能提交问题或功能请求，5 个可能发送拉取请求，也许只有一个成为维护者。
再次，InnerSource 最佳实践不会让所有 1000 人都贡献。InnerSource 帮助诱导这种协作，但最终旨在打破企业孤岛，改善受传统组织约束阻碍的协作，减少信息孤岛的前置时间，并使用开源实践优化组织资源分配。
结论 #
虽然这个案例中的论点触及了一些真实的挑战，但它们基于许多人在初次学习 InnerSource 时遇到的常见误解。这些是社区中众所周知的陷阱，可以理解某人在没有深入探索这个领域的情况下如何得出这些结论。
关键洞察是 InnerSource 不是将开源实践强制纳入僵化框架。相反，它是回到根本问题：我们可以从开源中学到什么？通过更广泛的视角审视开源，我们可以更好地在内部适应这些原则。
你可以加入这个对话并带来新的视角。无论你想基于这个讨论进行构建，探索更具体的实施细节，还是完全挑战这些论点——所有方法都是受欢迎的。最重要的是保持对开源学习的广阔视角，以及它们如何转化为内部组织环境。
有关 InnerSource 的全面信息，我建议查看 InnerSource Commons Foundation。他们欢迎不同的观点和关于开源原则如何在组织内创造价值的持续对话。
