Skip to main content

Project Maturity

Tooling and Processes

Development & On-boarding

  • Level 0:

  • Level 1:

  • Level 2:

    • External developers can build and test the code locally with minimum help from core team.
    • Team hosts open office hours at a regular cadance
  • Level 3:

    • External developers can pull, build and test the code locally and automatically.

Continuous Integration & Testing

  • Level 0:

    • Code compiles and can be executed.
    • A mix of automated and manual tests
  • Level 1:

    • Unit tests are automated
    • Teams has develops their own CI process, using non corporate or standard CI tools.
  • Level 2:

    • Automated builds execute a range of tests and pre-release gate checks- Integration tests are automated
    • There are CI environments.
    • Teams has developed their own CI process, using corporate CI tools
  • Level 3:

Continuous Deployment & Building

  • Level 0:

    • Builds are manual or scheduled (ie nightly)
    • Approved PR does not guarantee Production release
  • Level 1:

    • Builds are automated on merge. Not automatically releasing to pre-prod environments.
    • Approved PRs are integration-tested and deployed to Production on host team cadence
  • Level 2:

    • Approved PRs can be deployed to Production independent of host team release cadence
  • Level 3:

    • Automated CI/CD allows Production release upon PR approval, consistent with the organization's regulations and processes.
    • Releases should be gated on meeting code quality metrics and standards.

Development Practices

  • Level 0:

    • Pulling the code and setting it up to run locally is poorly defined and often requires reaching out to the core team developers for help
    • Code Reviews are happening on demand
    • Contribution support is not planned and may require overtime from Trusted Committers
  • Level 1:

    • Code Reviews are required but scrutiny may vary between in-team and outside submissions
    • Capacity is allocated in sprint for Trusted Committer activities
  • Level 2:

    • Automated linters and style checks run on commit, so Code Reviews focus on design topics
    • Design reviews happen for large changes before coding begins, to ensure quality and minimize the amount of rework/frustration resulting from code reviews
    • Code review needs to be done to a certain standard, by independent (disinterested) parties.
  • Level 3:

    • Code Review process is universal for all submissions regardless of which team authored the code.
    • Code review is done by both, internal and external team members.
    • Issue prioritization is similar to open source process: backlog is open, such that anyone in org can view and add to it; process to add new issue documented; automated checking for similar issues in tooling. Project team is working on backlog (not just theatre).
    • Process maintainers use to decide which work gets done is transparent and contributors understand how that process works.
  • Examples:

Documentation, Standards, & Communication

Context for Implementation

  • Level 0:

    • Opportunity provided by central CI/CD implementation or code review
  • Level 1:

  • Level 2:

  • Level 3:

Roadmap

  • Level 0:

  • Level 1:

  • Level 2:

    • Open backlog/issue tracker
  • Level 3:

    • Forward looking roadmap is published for anyone in the organization
    • Meeting minutes from design discussions are published

Documentation & Standards: Contributing Process

  • Level 0:

    • Most repositories have non-trivial README files
  • Level 1:

    • Contributing guidelines are available in either the README or a separate CONTRIBUTING file
    • Each repository has a README outlining (a) user value, (b) how to run
  • Level 2:

    • SLAs for inquiry responses and code reviews
    • Documented contributing standards, including code style and test coverage requirements
    • Defined post-merge expectations from contributors (i.e., 90-day warranty)
  • Level 3:

Documentation & Standards: Preferred Idioms & Design Patterns

  • Level 0:

  • Level 1:

  • Level 2:

  • Level 3:

    • Document architecture (e.g. like architecture.md)

Community & Communication

  • Level 0:

    • Accepting contributions
    • Do you have multiple people contributing and using the like-minded projects?
  • Level 1:

  • Level 2:

    • Documented support channels.
  • Level 3:

State of the Code

State of the Code: Overview

  • Level 0:

    • Multiple code versioning systems
    • Significant percentage of legacy code without documentation, automated tests and deep SME knowledge
    • People refusing to share //rephrase and/or move to culture (how about: Code components tied to specific individuals)
  • Level 1:

    • Single code versioning system
    • An active effort is made to modernize some legacy code
    • Remaining legacy code continues to exist without documentation, automated tests and deep SME knowledge
    • Secrets/passwords are stored in the code, preventing it from being made public
  • Level 2:

    • An active effort is made to document legacy code while it exists
    • An active effort is made to remove secrets from the code
  • Level 3:

    • An active effort is made to modernize most legacy code and implement automated tests for the remaining parts
    • Passwords and keys are managed outside the code

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:

Leadership

Leadership: Overview

  • Level 0:

    • Grass roots efforts within the team with no leadership support (or potentially even awareness).
  • Level 1:

    • Grass roots within thte team with leadership knowledge and no-one impeding progress.
  • Level 2:

    • Leadership has stated their support of InnerSource efforts.
    • InnerSource is not the default, but a supported option. Choice of whether to InnerSource often dictated by other priorities (e.g. time to release).
  • Level 3:

    • Full support communicated by leadership for InnerSource initiative.
    • Participation and contribution to inner sourced projects, including and especially projects beyond one's core team, group, and/or business unit, can be accounted for in the company's performance management system and directly contribute to decisions about incentive compensation -- i.e., such "assists" are formally recognized as important work and rewarded as such; InnerSource goals are recognised by leadership in HR in annual reviews.
    • Policy to InnerSource by default (reuse first).
    • Regular reporting on business value delivered by InnerSource.

Culture

Culture: Overview

  • Level 0:

    • Accepting contributions from inside the team or within the org (ie they are all under my boss's boss)
    • Product owners are largely unaware of InnerSource
  • Level 1:

    • Accepting outside contributions after preliminary discussion
    • Double standards for inside-the-team and outside contributions
    • Escalations are normal and necessary for cross-org deliverables
    • Product owners may view InnerSource activities as impediments to feature delivery
  • Level 2:

    • Accepting contributions from anyone based on standard documented contribution process
    • Leaders reward reuse above writing brand new code
    • Product owners understand value of reuse and better documentation
  • Level 3:

    • Public credit is given to contributors by the code owners
    • Product owners and teams negotiate scope without leaders' involvement

Ownership

Ownership: Overview

  • Level 0:

    • It is not clear who is responsible and maintenance done on a best effort basis with no SLAs.
  • Level 1:

    • Have defined expectations of person contributing code in terms of code maintenance, often with an SLA for a defined period of time.
  • Level 2:

    • Have more than one department contributing.
    • Expectation that the team that nominally owns the area is responsible fo the code that others are contributing.
  • Level 3:

    • Have a clear adoption strategy (putting projects up for adoptions)
    • Have a clear maintenance / deprecation strategy.
    • Have at least 3 maintainers and at least 1 from different department or business group.
    • More than one department with decision making ability.
    • The people finding the issues are the ones fixing the code (as opposed to original contributor).