定义内源的意义

问题 #

人们经常问我内源的定义是什么。那么,什么是内源?我想分享一些关于内源以及它对我意味着什么的想法。

让我从一开始就明确:这些是我的个人观点,而不是官方立场。虽然我目前担任内源共同体基金会主席,但内源是由许多我深深尊敬的先驱者塑造的。他们的贡献构建了今天的内源。

内源的基础来自企业实践、学术研究,当然还有开源本身演进的交织。鉴于这种丰富的织锦,我个人声称定义内源是自以为是的。仅仅因为我目前担任主席,并不意味着我有权威或智慧独自创造这个定义。

与其提供一个单一的权威答案,我想分享对这个问题的不同观点,提供可能帮助你发现自己的定义和理解内源对你的环境意味着什么的视角。


通往内源的两条路径 #

我们正处于一个有趣的拐点。让我更明确地说明我的意思。今天来到内源的人本质上有两种类型:

第一组包括那些一直在实践开源,发现其协作方法强大,并自然地在内部应用这些原则的人。对他们来说,内源只是给他们已经在做的事情起了个名字——将开源协作的卓越性带入他们的组织。

第二组将内源作为一种命名的方法论发现。他们可能没有广泛的开源背景,但他们认识到内源作为一种组织方法论为转型提供了巨大价值。他们采用内源不是因为他们是开源实践者,而是因为内源本身承诺了组织利益。

这种二元性在我们的社区中创造了迷人的机会。第一组直觉地理解在组织内实施内源意味着什么,以及内源和开源的价值和文化。因此,他们可能思考内源应该如何定义,并在开源框架内思考它。 另一方面,第二组不一定参与开源,所以他们倾向于寻求关于它实际是什么的更清晰想法。

90%


从DevOps学习:命名的力量 #

要理解内源的定义挑战,让我们看看DevOps。这是我对其演进的理解:像Flickr这样的公司的实践者正在做一些创新的事情——打破开发和运维之间的孤岛。当他们分享经验并有人给它起了个名字——“DevOps”——神奇的事情发生了。突然,各地的公司意识到他们在做类似的事情,他们都开始分享他们的故事。

关键洞察是:实践在名字之前就存在,但命名创造了社区。随着社区而来的是工具、共享概念、会议和爆炸性增长。DevOps不是被发明的;它是被发现和命名的。命名催化了其他一切。

内源遵循了一个非常相似的模式。Tim O’Reilly在2000年的一篇博客文章中提到了它。2015年,Danese Cooper和同事们,当时在PayPal,正式化了内源共同体,后来将其分拆为一个基金会。但他们没有发明这种实践——他们命名了人们已经在做的事情。

这种命名是神奇的。突然,孤立的实践者意识到他们并不孤单。“哦,我们对内部库做的那件事?那就是内源!“社区爆炸式地分享模式,导致了像内源模式这样的资源,捕获集体智慧。

今天的DevOps是什么?众多观点中的一个 #

人们以无数种方式定义DevOps,我不可能涵盖所有这些。这里是一个如何理解它的例子:

  • 传统上分离的团队之间的协作文化
  • 一套实践和自动化工具
  • 反对传统瀑布开发的哲学
  • 方法论和框架的集合
  • 扩展到专业领域:BizDevOps、DevSecOps等等

这只是一种解释。问十个实践者,你会得到十种不同的重点。这种多样性不是弱点——它是进化的力量。

90%


“内部开源"的多重含义 #

“内部开源"这个短语似乎是矛盾的,这个矛盾揭示了为什么内源对不同组织意味着不同的事情。让我分享一些从我们社区讨论中出现的代表性例子:

内源作为开源成熟度的路径 #

对一些人来说,内源开辟了通往开源参与和数字化转型的有机路径。这不仅仅是为最终的开源贡献做准备——它是关于创造一个环境,让组织能够成长为真正的软件公司。像微软和谷歌这样的公司体现了这种旅程,内部实践自然演进以镜像外部实践,在公司内外创造无缝协作。

但是制造公司、零售商或金融机构呢?虽然他们可能使用大量开源,但他们的旅程是不同的。对他们来说,内源可能是更长转型中的第一步——构建软件能力,培养创新文化,也许最终找到自己独特的方式来参与与其商业模式一致的开源。

内源作为组织透明度 #

许多人被内源的文化转型所吸引。这不仅仅是发送拉取请求——尽管这是其中的一部分。它是关于创造有机透明度,你可以:

  • 向其他团队提交功能请求
  • 看到邻近团队正在构建什么
  • 理解更广泛的组织技术景观
  • 打破阻止协作的孤岛
  • 创造一个更开放、更透气的组织文化,信息自然流动

这种透明度将组织从僵化的层级结构转变为活跃的协作网络。

最终,这些有助于工程师、产品团队和组织内每个人的幸福和福祉。在支持性工作环境中感到被信任——默认被信任——是极其重要的。这与开发者体验相关,因此导致改善人才保留,同时也为招聘带来积极结果。

内源作为资源优化 #

传统的层级项目管理在每个层级都增加边际。需求向下流动,每一层都为不确定性增加缓冲时间。当工作到达实施时,时间线已经膨胀,工程师被挤压。

内源颠倒了这一点。最接近问题的人最了解问题。他们可以优先考虑、讨论和解决问题,而无需级联会议和批准。这并不总是正确的——现场团队只了解他们的领域——但当与战略监督平衡时,它是强大的。

但资源优化超越了人力和团队资源。它也是关于利用组织的代码资产、知识产权和竞争优势。当团队可以分享并建立在彼此的工具、库和知识之上时,他们创造了在孤岛结构中不会存在的协同效应。你的团队构建的那个内部机器学习库?另一个团队可能以你从未想象的方式扩展它。给你竞争优势的测试框架?在内部分享它会在整个组织中倍增其价值。内源帮助组织意识到他们的代码和知识资产是在分享时变得更有价值的资源,而不是囤积。


定义困境:上下文就是一切 #

这种多重含义的挑战对内源来说并不独特。考虑开源项目办公室(OSPO)倡导者如何在内部推广开源。他们绝对对不同受众使用不同的信息传递,因为每个活动都需要不同利益相关者的支持,组织的每一层都有不同的兴趣和关注点。

对于内源倡导,信息传递可能看起来像这样:

对工程师:“与杰出同事协作,从最好的代码中学习,为超出你直接团队的激动人心的项目做贡献”

对中层管理:“减少重复,提高效率,通过重用和协作加速交付”

对高管:“降低成本,提高创新速度并保留顶尖人才”

同一个内源倡议同时服务于所有这些目标,但你对不同受众强调不同方面。这不是欺骗——这是认识到内源,像任何变革性方法论一样,在多个层面提供价值。

你的内源定义不仅依赖于受众——它还依赖于阶段。这完全没问题。


你的内源之旅:不断演进的定义 #

那么什么是内源?它是你定义的。

也许在未来,内源共同体基金会将开发一个更清晰、更可传达的定义,使内源是什么立即显而易见。就个人而言,我期待那一天,尽管我认识到在如此多样性中创造这样的定义是一项极其困难的任务。

此外,你的定义可以并且应该演进。帮助你开始旅程的内源可能与你三年后实践的内源不同。随着你的组织成熟、挑战变化、理解加深,你的定义可能会转变。

你可以将你的定义带到社区,分享你的观点,并帮助我们所有人一起思考这些问题。这种集体探索是我们最终将达成共同理解的方式——不是通过自上而下的法令,而是通过协作发现。

90%


行动呼吁 #

与其寻求完美的定义,我鼓励你体验内源:

  • 提交一个描述你看到的问题的议题
  • 发送修复文档的拉取请求
  • 向另一个团队请求功能
  • 与同事分享你的代码
  • 探索其他团队正在构建什么
  • 跨组织边界协作

通过实践,你将发现内源对你的组织意味着什么。你甚至可能发明我们其他人可以学习的新模式。

加入对话 #

在2025年,随着AI改变我们编写和协作代码的方式,内源原则变得更加相关。当AI可以瞬间生成数千行代码时,我们如何保持质量?当代码创建自动化时,我们如何保持知识分享?我们如何确保人类判断仍然是软件开发的核心?

对于这个问题,请参考涵盖AI时代协作方法论的文章

嗯,这些问题还没有答案,但我相信内源——强调开放性、透明度、优先指导和自愿代码贡献——在探索它们方面具有独特的地位。

内源有许多风味。你可以添加你自己的。你可以命名存在但尚未阐述的模式。这就是为什么内源令人兴奋:它是一个横幅,在其下社区成长、演进和传播创新。

内源共同体基金会欢迎这些讨论。我们的社区成员每天都在探索这些问题,分享经验,并构建内部协作的未来。

所以我问你:你的内源是什么?你将如何为你的组织定义它?你将发现和分享什么模式?

让我们一起探索这些问题。旅程才刚刚开始。我期待在*innersourcecommons.org*欢迎你加入对话。

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.