特别说明：本文由开源之道发布并授权转载 。
企业若要拥抱开源，离不开自身就是开放、共享文化的倡导者与实践者，如果没有这些内在文化基因，则就需要改变，改变文化、改变风格。那么内部开源就是这样一剂良药，让员工很舒服的接受变化，进而拥抱变化。你所在的公司准备好迎接内部开源了吗？不妨试试本文的方法。
最近几年，对开源产生兴趣的组织和公司逐渐的增多，而且还发生在了非技术的公司，虽然他们可能并不一定在其产品和服务中最大程度上使用开源，但是他们对引进开源的文化到他们的组织中非常的感兴趣。类似的“内部开源”能够给他们带来诸多益处。
作为一名资深的社区顾问，在帮助公司构建内外的社区时，发现企业面临的最大的挑战是如何制定内部开源的程序、有效的部署资源、并实现有条不紊的增长。
为了帮助这些欲实现内部开源的公司，我构建了一个高层次的模型，即如何构建一致的、可预测的、可持续的内部开源计划，这些公司可以直接采用此模型，对实际情况稍作调整，即可以在公司内部创建一个蓬勃发展的社区。
从本质上来说，内部开源对于公司来说是一个文化转变的问题。尽管很多人也认为这就是传统的软件工程流程的变动，人们需要专注于建立一个异步的、宽容的、精明的和协作的环境。当然，内部开源 会包含开发的工作流程，但是远不止此。
改变文化的挑战在于：文化是思想，意见，习惯，恐惧，梦想，价值观等等无定形的东西。在你打算将 内部开源 集成到公司里，你必须明确的了解现有文化的驱动力在哪里，然后在根据这些推行 内部开源。
人们能够在一起工作的核心就在于协作的基础设施和流程，其中包括有：代码托管、代码revierw、持续集成、自动化测试、文档创建、知识库、奖励计划等等，你必须去了解其中的每个细节，并确定他们是如何在一起工作的，也要了解其中的不足之处，如大范围的使用以及工作人员的个人经验。
我建议由团队打破组织，然后重新组合一张地图：
除了协作的事情之外，了解人本身同样重要。一家公司让来自不同背景的很多人聚集起来，他们拥有完全不同个性和观点。你需要真心的理解他们、知道他们的目标、他们害怕什么、甚至是他们的规划，文化变迁必须注意其运作环境的现实。你不可能仅从命令上构建内部开源的文化，你需要建构的是人们想用的东西，是被鼓励的行为。
建议您建立自己的组织结构图：
在理解了公司的当前的环境的情况下，接下来你要做的就是构建蓝图：达到平滑、高效、包容、享受的 内部开源 环境。
第一步要做的事情是建构整体的战略，一个很复杂但是仍在你的想象范围之内。将开源原则整合到公司中涉及到一系列不同的考虑，诸如开发者工作流、基础设施、沟通、政策（如开放度和透明度）、激励模式、分段参与、更广泛的消息传递、治理等等。
你不仅要做很多工作，而且因为你的工作重点会有所不同（其中一些项目相比其他项目要更为迫切），您的资源有限，公司的一些同事可能会拖慢甚至阻止该项目。
想要让人们参与进来，你需要做下面几件事：
我建议制定一个整体更广泛的战略计划，映射到未来一两年，涵盖关键的重点领域。接下来，将该计划分解成较短的执行周期，从更广泛的计划中提取关键目标，并将其映射到具有指标的实际可交付成果。这将形成你的Backlog。
本质上来说，战略就是一张告诉你去哪里的地图。战略需要转换为实际的工程，以及利用某些资源来交付的成果，资源的话，诸如开发时间、资金等。而挑战在于每个战略规划都涉及到众多的子项目，以及各种目标。此种情形下，最好的办法就是使用backlog。
简单来讲，backlog就是较大的、共享的要做的事情列表，当你制定好了战略时，就可以将所有的独立的项目转换为backlog了。这就为大家提供了一个可以讨论、重新定义、改进个人成果的地方。当这些可交付成果中的一些可以实施时，人们就可以从backlog转化为实际的工作计划，并分配相应的资源。这也就是意味着你可以在backlog中逐步实现你的战略，哪怕是没有资源积极的跟上。
据我个人的和客户打交道的经验中，其中最大的挑战是，他们要在自己的组织中构建内部开源，但是对于内部开源成功是什么样子没有任何的概念。现在，这句话听起来像是商业书籍的废话，但这个问题是真实的。举例来说，如果你打算改进开发者的效率，比如代码review，你是如何知道这个目标实现的样子？你如何衡量工作？并如何得知那些指标是需要紧盯的？对于许多这些问题，您正在建立定性的文化变革。我们如何衡量呢？
对于不同的受众团队，这个挑战还可能更加的剧烈。虽然参与执行这项工作的人们希望能够获得成功的成果，但高级管理层和利益相关方不会想要细节，而只是要求有关重要趋势的信息。对付此种情形的一个有效的方法就是：“成熟度模型”。
成熟度模式，能够将解决方案的不同的进化阶段打破，成为成功应该是个什么样子的一组期望。我倾向于考虑这些不同的时间顺序阶段：
对于每一个阶段，都要有着明确的期望。举例来讲，如果你想将代码审核带入到公司来，那么在“探讨期”就意味着“一小部分团队正在积极地在非关键的代码进行尝试性的代码审核。”
有了战略、backlog、和成熟度模型，你已经知道了你要做什么了。接下来就是要真正的动起来——执行。
随着backlog的就位，你首先要做的事情就是在你的工作计划当中决定那个项目是优先级较高的。决定这一点取决于最紧迫的工作和目前可用的资源。虽然工作的紧迫性很重要，但资源是这里的真正定义标准 - 巧妇难为无米之炊。
我建议你有一点的规律来做这件事（每两周，每个月，或每个季度）。汇集计划的关键带头人，审核backlog，定义资源，然后确定工作计划。
随着你的计划逐一到位，就开始到了要结果的时候了，你需要定义里程碑、指标、并定期审查可交付的成果。鉴于对这项工作的文化影响，沟通 - 在某些情况下，要更多的沟通 - 才是关键。我们要确保在公司范围内，关键的干系人、带头人、高层等拥有一个好的感觉：
请记住，不同的团队有不同的沟通需求。高级的领导者需要的是概览和结果，关键带头人会要求更为深度的，而团队的带头人则需要每一个细节。
你需要创建既能深入又可以拔高概览的方法，从而能够和正确的团队沟通，并定期的更新（可以采用周报的方式）。另外，请务必定期向整个公司发信息。
商业公司引入内部开源，还远远没有完善，方法论和实践都很欠缺，公司各不相同，人也各不相同，方法也会各不相同。但是你必须去自己动起来，从而寻求在此过程开始时想要了解的特定需求。
因此，定期评估你的工作并评估其进展情况至关重要，因为需要进行适当的改进。做这样的评估并不容易，它可能会引起人们对于失败的恐惧，但是征服这样的恐惧又是非常重要的。开始做的一些事情可能不顺利，而其他人将提供次优的结果。确定对工作产生负面影响并纠正这些缺陷的缺点才是你的分析要点。
第一步就是收集数据，换句话说叫收集数字。你每工作的项目，定义一系列打算追踪的度量值，你将能够通过这些指标来确定项目是否成功。举例来说，这些指标有：使用量、贡献量、代码、消息、参与度、等。除非有一个关键的测量方法，否则不应将项目带入工作计划。
分析数字是比较方便的，毕竟现在我们人人都拥有计算机来做日常工作的。但是冷冰冰的数字未必就是全部的事实，我们也需要跟踪一些人本身的因素，如幸福感、赋权、包容等等。非经验分析很难做，因为这些东西通常不能很好地映射到数字。
解决此类问题的一个实用的办法是进行定期的匿名调查，即询问人们有关上内部开源的一些行为、情感上的感受，那些相关的工作人员必须是感到很舒服、顺畅的，否则就问题大了。你需要做的是赋予他们明确的权限，而不去理会后果。
和调查执行一样重要的是，所问的问题和选项，这些都是非常关键的。措词和选择往往会无意中影响回应，所以我的建议是要找一组人来设计调查。
一旦你拥有了这些数据，就可以询问你自己和团队一些难一些的问题了，即关于这些说明的趋势和模式。你如何改善整体策略、如何重新组织backlog、调整项目的优先级，构建和管理与他人。要记住：帮助一家公司实施内部开源是非常复杂的，有着数不清的细节需要处理，但是我希望本文提供了一个大体的框架，至于具体的工作，请根据实际情形自行定夺。
Jono Bacon 是卓越的社区经理、演说家、作家。他目前担任 GitHub 的社区总监，Bacon 是一名很有特点的作家，社区管理的布道师和实践者，并且是畅销书《社区的艺术》（O’Reilly）的作者。并且是社区领导力峰会（主要定位于社区管理者和领导者的年度会议）的创始人，也是社区领导力论坛的创始人。Bacon 还创建过很多的项目，如Ubuntu Accomplishments、Jokosher、Acire、Python Snippets、 Lernid 软件等。
本文由作者Jono Bacon 发表在Opensource.com上：How to create an internal innersource community。由开源之道精心翻译。本文在Creative Commons BY-SA 4.0许可证下发布。欢迎转载！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。