Organizational Maturity
Transparencyβ
Plans & Productsβ
Level 0
- Individuals and teams do not regularly disclose their plans or products to multiple stakeholders.
- No formal actions exists at the organization.
Level 1
- Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started.
- Shared roadmap.
Level 2
- There are already shared roadmaps with clear guidelines and contribution rules where stakeholders can provide feedback.
- However this is not standardized across the organization and not all of the projects provide this info.
Level 3
- Roadmaps are shared by default and there is a standard process and homogeneous way to do this across the organization at the level of each InnerSource project.
- This contains clear rules to contribute and influence in the roadmap.
Decisionsβ
Level 0
- Decision-makers often intentionally or accidentally withhold data and resources related to project decisions.
Level 1
- Materials that are part of decision-making practices become available for review after decisions are finalized.
Level 2
- People feel like they know aboutβand are helping to shapeβmost (but not all) important decisions as those decisions are unfolding.
- Materials that are part of decision-making practices are available at defined project milestones
Level 3
- People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses.
- Materials that are part of decision-making practices are continuously accessible during work processes.
Helpful Resourcesβ
Level 0
- Individuals and teams neither contribute to nor draw upon a shared repository of knowledge.
Level 1
- Individuals and teams release project materials for review internally, after they've finished their work.
- Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories.
- Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not.
- Do not "share thinking on others".
Level 2
- Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols.
- Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope.
- There are enterprise wide tools for knowledge sharing, but they are not widely adopted
- Efforts to consolidate and curate information is a continued effort
Level 3
- Individuals and teams make project-related materials broadly accessible to the organization β and possibly outside the organization as well β according to clearly defined and shared formats and/or protocols.
- Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them.
- The organization has clearly defined sharing protocols that are followed.
- Data, knowledge or tool duplication is minimized
- Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them.
- Data is consolidated and easily searchable
- Exceptions have a migration path
Storiesβ
Level 0
- Individuals and teams don't share neither successes nor failures for others to learn from.
Level 1
- Individuals and teams are comfortable sharing stories about successes, but not about failures.
Level 2
- Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews.
Level 3
- Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols.
Collaborationβ
Channels for Providing Feedbackβ
Level 0
- There are no processes nor established channels.
- Some members of the organization share materials via private channels or discussions.
Level 1
- The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them.
- Some members of the organization share decision- making materials informally using unofficial platforms.
- Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work.
Level 2
- The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions.
- Leadership support at varying levels
Level 3
- Members of the organization share decision- making materials on officially sanctioned platforms Members of the organization share materials openly via multiple channels and methods for feedback.
- Leaders use those channels themselves, openly encourage others to use them, and maintain teamfacing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback.
Leadershipβ
Level 0
- Command & control culture, within a highly hierarchical organization.
Level 1
- Some leaders are open to receiving feedback and creating an environment where people feel safe providing it.
Level 2
- Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it.
- Leaders show passivity about understanding whether all members feel empowered and enabled to share.
- Organization encourages leaders to actively seek voices not present in dialog out for inclusion.
Level 3
- Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate.
Organisational and Functional Structureβ
Level 0
- Working groups tend to be static in terms of membership and skill sets.
Level 1
- Cross-functional teams exist, but team roles are often unclear and governance structures are vague.
Level 2
- Cross-functional teams are common, and teams post their roles and goals publicly.
Level 3
- Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together
Contributionβ
Level 0
- Completely siloed, no collaboration outside the teams.
- Just some collaborations due to cross-functional teams.
Level 1
- Members of the organization and teams collaborate but frequently say it's "too difficult".
- Teams infrequently revisit the outcomes of their collaborations.
Level 2
- Members of the organization and teams actively seek opportunities to collaborate.
- Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default.
Level 3
- Members of the organization collaborate both internally and externally in ways that benefit all involved.
- Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default.
Communityβ
Sharing Policiesβ
Level 0
- No sharing culture nor written policies.
Level 1
- Some members of the organization unite to define values and principles, but are not clearly supported when they do.
Level 2
- Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often.
- Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions.
Level 3
- Shared values and principles inform decision- making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats.
Feel Part of the Organisationβ
Level 0
- Low engagement, no collaboration and people do not feel comfortable sharing with others.
Level 1
- Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains.
- People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment.
Level 2
- Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution.
- Leaders demonstrate dedication to the organization's shared values.
Level 3
- The organization is proactive in telling members that it benefits from their contributions; as such, members demonstrate shared consciousness and empowered execution, and feel a sense of responsibility to the community.
- Leaders understand that they grow by helping others grow, and they mentor junior members of the organization.
Governanceβ
Rewardsβ
Level 0
- No rewards.
Level 1
- Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established.
Level 2
- Standard processes are established to reward collaborations outside the developers' teams.
- Team leaders or boards decide who has to be rewarded.
Level 3
- Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards.
- The community is responsible to decide who has to be rewarded.
Monitoring Policiesβ
Level 0
- No existing monitoring policies at any level in the organization.
Level 1
- Metrics are important for certain teams, and they start using them in an isolated way.
Level 2
- There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization.
- This monitoring policy exists at the level of some of the InnerSource projects.
Level 3
- There are clear guidelines, recommendations, and trainings about the use of metrics with certain infrastructure provided by the organization.
- This works at both levels: InnerSource program to understand the general InnerSource adoption within the organization, and at the level of InnerSource projects.
Support and Maintenanceβ
Level 0
- Support given by the core dev or support team.
- A business contract guaranties the support.
- There is no knowledge about the product outside the team.
Level 1
- There are rules and regulations to formalize the support on the product, given by a dedicated supporting team.
Level 2
- Support for InnerSource contributions is formalized through InnerSource patterns like 30 Day Warranty or Service vs. Library.
Level 3
- There are rules and regulations to formalize the support on the product, given by a mature community
Cultureβ
Level 0
- Silos - teams work independently but also in isolation.
Level 1
- Reactive - teams work independently, but know how to react to flaws in dependencies.
Level 2
- Contributive - teams actively help improve their dependencies by contributing.
Level 3
- Activist - teams actively seek help, mentor and recruit new contributors.
InnerSource rolesβ
Level 0
- There are no specific roles helping InnerSource adoption.
- Only common development roles are present: developer, analyst, tester, etc.
Level 1
- Occasionally some individuals and teams contribute to other projects.
- These are technical contributions, where the user/contributor role is seen.
- For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members.
- He/she could be a candidate for covering the trusted committer role.
Level 2
- An InnerSource Officer role is in charge for governance and support, including processes, etc.
- Identifies the education needs and ensures it is provided to the organization.
- Leads and mentors the organization in the engagement in IS projects.
- Is the first formal step in the way, defining the IS vision and roadmap.
- The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors.
- There is a standard process describing how to contribute to the community, contributor role is present.
- Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution.
- Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/user(contributors/community members).
Level 3
- Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative.
- Non technical contributors appear.
Productβ
Technologyβ
Level 0
- XX% of legacy code
- XX% of orphan code
- Private Repos
- People refusing to share
- Nightly builds
- Mainframe code - code owners donβt have SMEs who understand the complexity of changing API
Level 1
Level 2
Level 3
Context for Implementationβ
Level 0
- Opportunity provided by central CI/CD implementation or code review
Level 1
Level 2
Level 3
Relevant Documentationβ
Level 0
- Are basic documents in place per codebase?
- Do they have strong READMEs?
- Published roadmap?
- SLAs for code reviews?
Level 1
Level 2
Level 3
Communityβ
Level 0
- Accepting contributions
- Do you have multiple people contributing and using the like-minded projects?
Level 1
Level 2
Level 3
Policiesβ
Monitoring Policiesβ
Level 0
- No existing monitoring policies at any level in the organization.
Level 1
- Metrics are important for certain teams, and they start using them in an isolated way.
Level 2
- There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization.
- This monitoring policy exists at the level of some of the InnerSource projects.
Level 3
- There are clear guidelines, recommendations, and trainings about the use of metrics with certain infrastructure provided by the organization.
- This works at both levels: InnerSource program to understand the general InnerSource adoption within the organization, and at the level of InnerSource projects.
Other categories/ criteria to be includedβ
Architectureβ
Level 0
- A mix of proprietorship ("my code is too good for anyone to change") and shame ("I don't want everyone to see this crappy code")
Level 1
- Clearly market projects willing to practice Innersource with clear instrcution on how to reuse artifacts
Level 2
- A curated and measurable InnerSource re-use program
Level 3
- Architecture influences the design of and re-use of InnerSource projects
Process & Controlsβ
Level 0
- There exist open projects that are known short cuts people copy for their projects. There is no concreate traceability done on those re-usable assets.
Level 1
- Attempts to collect re-usable artifacts together
Level 2
- There exists knowledge spaces where people search or ask questions
- Process for re-use of (InnerSource, Open Source or Propietary) assets
- CI of application artifacts (e.g. Open Source, SAST, DAST, Secrets) is mandatory
- Tracability & Auditability of CD process for application are adopted
Level 3
- Knowledge spaces are clearly defined e.g. Learning, How-Tos, Q&A and used with no drift
- Streamlined onboarding process for new hires
- Clear & measurable process for re-use of (InnerSource, Open Source or Propietary) assets
- CI of application artifacts (e.g. Open Source, SAST, DAST, Secrets) is mandatory
- Tracability & Auditability of CD process for application are adopted
Financial Supportβ
Level 0
Level 1
Level 2
- Various departments have in place formal support for InnerSource Projects
Level 3
- An InnerSource program office is fully funded to support mature projects as well as the incubation of new projects.
Source & Artifact Managementβ
Level 0
- There exists enterprise support for Source Control Management where code is open for anyone
Level 1
- There is an Source Control & Artifact Mangement strategy that works to converge tools & process
Level 2
- Policies & Standards support open projects & artifacts by default.
- Private repositories and artifacts are on exception basis only
Level 3
- Exceptions to the rules have a migration path
Reward and Recognitionβ
Level 0
Level 1
Level 2
Level 3
- Leaders reward reuse above writing brand new code at the highest levels