成熟度模型
各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
当内源在企业中的应用开始增加时，通过一个布道者对每个项目进行单独指导就变得不可行了。此外，越来越多的人至少对在内源项目中工作的意义有了基本的了解。纵观所有的内源项目，对这一概念的理解深度会有差异。团队可能没有意识到那些可以帮助他们进入下一阶段并解决他们所处理的问题和痛点的成熟模式。
一些团队已经开始采用内源实践。各个团队对该实践的确切理解程度不尽相同。团队遇到的具体问题也因每个团队的背景和工作环境而不同。因此，在内源项目中，对什么是重要的最佳实践的定义因每个团队而异。
分享内源经验的团队遇到了误解，因为他们没有意识到各自采用内源的水平。
团队认为，"这都是迁移到一个共享的软件开发锻造"（GitLab、GitHub或Bitbucket是这种锻造的众所周知的例子）。
团队没有意识到可以帮助他们解决日常工作中遇到的问题的最佳实践。
要求团队根据建议的成熟度模型进行自我评估。
产品和规划
内源项目路标规划在组织内公开透明，不仅可以使利益相关者能够更好地理解相关决策，也可以让组织内的其他人能够参与或影响决策。
PP-0：组织内没有正式的路标规划。由个人和团队不定期向多个利益相关方披露他们的计划或产品。
PP-1: 有公开路标规划。个人和团队在启动之前，向多个利益相关者展示他们的计划或产品。
PP-2：有公开的路标规划，并且有清晰的指引和贡献规则帮助和指导利益相关方进行反馈。但是，这些过程没有在组织内规范化和标准化，不是所有内源都能提供这些信息。
PP-3: 项目的路标规划默认是公开共享的，并且在组织内的每个内源项目有统一的标准流程和方法。对路标规划的贡献和变化也有明确的规范。
开发流程及工具
贡献者主动参与到内源项目可以让项目获得更好的发展。因此，需要在使贡献更容易和追求完美的技术目标之间达到平衡。。
DP-0: 互相区隔的开发团队。各团队有自己的开发流程和工具。没有和其他团队共享知识和作品。
DP-1: 公司内开发团队之间共享代码库。部分团队有自己的CI流程，没有使用公司统一或标准的CI工具。部分团队内部有自己的代码评审流程。但是公司没有统一的代码评审流程。
DP-2: 建设公司级的知识共享库。部分团队使用公司CI工具来开发自己的CI流程。公司存在统一的CI环境和代码检视流程。部分项目已经应用。代码审查会邀请外部团队成员协助完成。
DP-3: 大多数团队使用公司CI工具来完成自己的CI流程。有统一的CI环境和代码检视流程。代码检视由团队内部和外部成员共同完成。
决策
为了激励员工在他们所属的核心团队之外的工作中做出贡献，他们需要了解项目的决策过程，同时也要感觉到他们的声音是被倾听和重视的。
DC-0：决策者往往有意或无意的隐瞒与项目决策相关的数据和资源。
DC-1：决策结论定稿后，决策过程中的部分材料可共享可评审。
DC-2：人们感觉自己了解并帮助决策大多数（但不是所有）重要决定。决策过程公开，可在所参与的项目里程碑中获得决策的相关材料。
DC-3：人们感觉自己是集体决策的重要一环，决策过程公开规范，并且被组织所支持。可以持续地获取到决策过程中的相关材料。
提供有用的资源
为了吸引贡献者，需要让贡献者很容易获得有用的信息。
RS-0：个人和团队既不贡献，也不利用共享的知识库。
RS-1：个人和团队的交付件在内部评审。个人和团队有共享资源，但是知识是碎片化、不连贯的，存储在不同的系统和仓库内。个人和团队有共享资源，但无法确定信息是否敏感，对哪些信息需要共享没有达成共识，也没有标准和规范。没有“和他人分享想法”。
RS-2：个人和团队可参考已明确定义的信息共享格式或协议，可以让团队成员方便地获取相关资料。团队对于必须保留的敏感信息，仅提供了有限的细节、背景信息和共享范围。
RS-3：个人和团队可参考明确定义的信息共享格式和协议，可以让组织内部、外部相关人员方便地获取相关资料。对于必须保留的敏感信息，明确定义了共享范围，其他人也能够了解哪些信息不能共享。
总结经验
当在东道主团队中工作时，错误会自动被广泛看见。为了保持贡献水平，企业文化需要庆祝失败，作为大家共同成长和学习的机会。
ST-0：个人和团队不分享成功或失败的经验，其他人无法学习。
ST-1：个人和团队愿意分享成功经验，但不愿意分享失败经验。
ST-2：个人和团队在回顾和评审时，愿意分享成功和失败的经验。。
ST-3：个人和团队很方便的分享成功和失败的经验，并例行开展总结和学习活动。
提供反馈渠道
为了减少工作间壁垒（silos），同事们需要坦诚地分享反馈意见。一个简单的支持方式是跨层级使用相同的通信原则。 理想情况下，您最终会建立起适当的沟通渠道，并被整个组织广泛使用。这些渠道将聚焦于不同的目标（公告、用户支持、开发渠道、非正式讨论、等）。你将逐渐形成一套最佳实践，例如采用网络礼仪准则，为每一个新的内源项目开辟一套成熟的标准化沟通渠道（消息即时存档、可公开访问、提供搜索功能）。
CF-0: 没有流程也没有建立渠道。组织成员通过私人渠道或讨论分享资料。
CF-1：组织开始建立内部规范和渠道，以便组织的任何成员都可以使用，通过这样的渠道来鼓励对公司/部门决策提出不同观点。组织的一些成员利用非官方平台非正式地分享决策材料。领导者至少有一个明确、直接的渠道，让组织成员就一些与工作相关的事项分享有建设性的意见。
CF-2：组织已经确立了内部规范和渠道，并提供特定的资源（培训项目、获取内容等），来鼓励和征求对于团队或决策的多方意见。
CF-3：组织成员在官方认可的平台上分享决策材料，组织成员通过多种渠道和方法公开分享材料，征求反馈意见。领导者自己使用这些渠道，并公开鼓励其他成员使用这些渠道。对于收到的反馈以及针对反馈的处理意见，有专门面向团队的公开记录。
领导力
内源项目鼓励员工在不受其部门主管直接影响的情况下为部门外项目做出贡献。这需要信任的文化。
LS-0：在一个高度层级化的组织中，大家奉行的是指挥与控制文化。
LS-1：一些领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。
LS-2：多数领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。领导者在理解所有成员是否都感到有权力和能够分享时表现出消极的态度。组织鼓励领导者积极寻找对话中没有出现的声音，以求包容。
LS-3：成员们感到有力量，能够就任何与其工作有关的事项或他们有激情的事项建设性地分享意见。
组织和功能结构
当内源的理念离开单纯的编码层面，而是进入社区和工作团队的层面时，即使无法直接进行代码协作，也可以有效减少壁垒。
OF-0：工作团队中的成员构成和技能组合往往是长期不变的。
OF-1：跨职能部门团队存在，但团队的定位往往不明确，治理结构也很模糊。
OF-2：跨职能部门团队较常见，团队会公开指出他们的定位和目标。
OF-3：跨职能部门团队很常见，并在组织中广泛宣传他们的活动；反过来，组织也会推广这种合作的最佳实践。
贡献
为了减少壁垒，需要牢记改进组织内贡献模式的目标是为了增加职能部门间的合作。
CB-0：完全区隔的状态，团队和团队间没有协作。只是由于一些跨职能部门团队的需要，会有一些协作。
CB-1：组织成员会在团队间达成协作，但经常反映 "太难"。团队不经常注重审视合作的结果。
CB-2：团队中的成员会积极寻找合作机会。团队经常就他们的合作成果进行讨论、审视并辩论，并默认这些合作成果是公开可用的。
CB-3：组织成员通过内部和外部合作的方式，使所有参与者受益。团队经常就他们的合作成果进行讨论、重新审视和辩论，并在组织外分享他们的学习成果，并默认将这些成果对外公布。
共享策略
共同的共享价值观可以让大家跨越组织边界更好地协作起来。如果拥有一套标准、通用的共享规则及准则，那么跨团队协作将变得更加的容易。
SP-0：没有共享文化，也没有书面的共享政策。
SP-1: 组织中的一些成员联合起来协定价值观和原则，但他们这样行为并没有得到明确的支持。
SP-2：组织成员集体撰写共同的愿景和协议，如使命宣言和行为准则等，使其易于获取，并可以经常参考。入职材料和迎新仪式提供充分的背景材料和信息，以帮助新成员了解组织如何得益于他们的贡献。
SP-3：共同的价值观和原则为组织成员之间的决策、冲突解决和评估过程提供信息，组织成员以口头和书面的形式不断地引用这些价值观和原则。
组织的归属感
将内源引入组织的可能动因之一是员工参与度的增加。这一条目追踪了组织内推行内源时参与度的变化情况。
PA-0：参与度低，没有合作，人们不喜欢与他人分享。
PA-1：组织成员对于分享他们的想法和意见感到安全，但只在熟悉的领域发表意见。不必担心因此被攻击。人们明白，只有最好的想法会最终会被采纳，而领导权将会根据贡献和付出的多少来分派。
PA-2：组织成员在分享他们的想法和意见时，不必担心因此被攻击。领导者对组织的共同价值观表示认可并投入精力建设。
PA-3：组织积极主动地告诉成员，组织从他们的贡献中受益；因此，成员表现出强烈的集体意识和强大的执行力，并感到对组织的责任感。领导者明白，他们是通过帮助他人成长而获得自身成长的，因而他们会为组织的初级成员提供指导。
奖励
为了吸引更多的人参与到内源项目中，可以使用一些外在的激励手段来增加跨团队的协作。
RW-0：没有奖励。
RW-1：内源项目的管理者鼓励协作，想要奖励那些对项目作出卓越贡献的个人或组织，但是没有制定政策和流程来作为支撑。
RW-2 制定了标准的流程和制度来鼓励内源项目开发团队之外的组织和个人参与协作，并进行奖励，奖励谁是由项目管理者或者项目管理委员会来决定的。
RW-3：奖励不仅由组织提出，社区也会提出他们认为的更有价值的奖励。内源社区有责任决定谁应该得到奖励。
监管原则
内源项目需要一种自我评估的方法。度量指标可以作为促进自我评估的一个方面。此外，在一个成熟的内源项目中，我们期望采用一种基于清晰、一致指标的跟踪方法来监控内源项目。
MP-0：组织中不存在任何级别的监控策略。
MP-1：指标对某些团队很重要，但他们仅以一种孤立的方式在使用它们。
MP-2：在组织层面有一个关于度量指标的策略，有助于在整个组织内验证特定的政策。在某些内源项目的层面也存在监控政策。
MP-3：在组织提供的相应基础设施上，有明确的指导方针、建议和培训，来应用具体的度量指标。这在两个层面都起作用：在组织层面，以及内源项目层面。
支持和维护
内源团队不仅要负责特性开发，支持和维护也是内源团队核心任务的一部分。
SM-0: 由核心开发或支持团队给予支持和维护，通过商业合同来保证产品的支持和维护。团队之外对产品一无所知。
SM-1: 有由专门的支持团队提供的规则和制度，来使对产品的支持和维护正式确立。
SM-3: 有成熟社区的规则和制度正式支持产品。
文化
在多种层次上向合作文化迈进。
CL-0：筒仓型 - 团队独立的工作，相互封闭隔离，缺少交流和信息共享，甚至缺少协作。
CL-1: 被动型 - 团队独立的工作，但知道如何对依赖性中的缺陷做出反应。
CL-2: 贡献型 - 团队通过贡献积极帮助改善他们的依赖性。
CL-3: 积极型 - 团队积极寻求帮助、指导和招募新的贡献者。
内源角色
内源带有明确的角色。虽然在早期阶段，某些模式可能不需要采用这些角色，但是在项目内部使用明确的角色称号进行沟通会变得更加容易。
RO-0: 没有具体角色帮助内源夯实。只有常见的开发角色：开发人员、分析师、测试人员等。
RO-1: 偶尔有个人和团队参与其他项目。这些是技术贡献，即用户/贡献者角色。对于某些团队，可以指定至少一个成员作为技术指导，该成员向其他开发团队成员解释开发过程。他/她可以作为 Trusted Committer 角色的候选人。
RO-2: 内源管理者角色负责治理和支持，包括流程等。识别教育需求，并确保向组织提供所需的教育和培训。内源领导和教练负责组织参与内源项目。第一个正式步骤是：定义内源愿景和路标。组织定义了 Trusted Committer 角色，不仅为开发团队成员，而且为外部贡献者提供联系/参考。有一个标准的流程描述如何为社区做出贡献，贡献者角色是存在的。数据安全员角色负责管理内源活动留下的操作日志，这是需要衡量内源演变所必需的。Trusted Committer 角色将演变为更具技术性的形象，社区管理员将负责“激励”社区，他的主要职责是吸引和留住新的开发者/用户（贡献者/社区成员）。
RO-3: 布道师在组织内部活动，让其他人了解当前的工作，内源做什么以及如何做，并帮助其他人理解并成为内源动议的一部分。非技术贡献者出现。
所有团队都了解现有的最佳实践。
团队了解他们对内源的采用程度。
在采用内源作为工作模式之前，团队了解对他们的期望的做法--无论是短期的还是长期的。
Entelgy
Zylk
Bitergia
Daniel Izquierdo Cortazar
Isabel Drost-Fromm
Jorge
Nerea
Alexander Andrade （特别感谢拼写修正）
成熟度模型： 了解内源的最佳实践
结构化
于2019年9月起草