Learn more about the world of InnerSource, and why applying the open source working model internally is vital to your organization's future.
- 1. The InnerSource working model defined
- 2. InnerSource and current business challenges
- 3. Our mission
- 4. Strategy and Roadmap
- 5. Deliverables
- 6. Benefits
- 7. Support
The InnerSource working model applies the open-source product delivery model to private, internal IT teams. Like open-source, InnerSource is a decentralized product delivery model based on open and transparent collaboration. InnerSource relies on peer production to deliver features and fixes to consumers. InnerSource also depends on lightweight documentation in order to market to consumers and encourage community contributions.
InnerSource is a:
- Decentralized product delivery model
- Peer production network of self-organizing communities of interest and practice
- Community-driven enterprise aimed at converting users into contributors.
InnerSource depends on:
- Documentation to share knowledge efficiently
- Community contributions for product development and delivery
- Continuous testing and integration to support voluntary changes
- Transparent and measurable objectives
InnerSource product delivery is a simple, five-step process.
- 1. Issues
Issues allow InnerSource teams to propose and track features and defect fixes.
- 2. Pull Requests (PRs)
Pull requests automatically announce whenever Issue assignees push changes to Git.
- 3. Merges
Add approved PR changes into the product.
- 4. Releases
Deliver value-added changes to consumers.
- 5. Support
Improve the product with defect fixes and refactorings (formal design improvements).
IT Rationalization provides a framework for managing and monitoring our investment in existing (and proposed) software applications predictably and efficiently, to ensure that IT assets are effective in their role of realizing business strategy.
IT Rationalization and Moderation manages applications from development and acquisition to retirement and removal based on strategic alignment with predictable risk and financial reduction.
 |
 |
 |
 |
 |
|---|---|---|---|---|
| Security | Legal | Cost reduction | Modernization | Reuse |
| Standardization + Risk Reduction | Consolidation | Innovation | Distribution | |
InnerSource product delivery is self-directed The InnerSource working model requires openness and transparency
-
Software product retirement trends
How:
Track internal and vendor software product retirments over time, starting with
- Enterprise Decision Records with the status EDR: Retire
- Time to deprecate those products.
- Time to take those products "offline."
-
TechStack formation and adoption
How:
- Full technology stacks—with managed, security-approved dependencies—are readily available to engineers.
- The number of software products deployed based on approved TechStacks.
Agile software development approaches product development iteratively and incrementally, resulting in products that evolve over time. Agile stresses the importance of co-located, cross-functional teams in order to communicate and collaborate quickly.
Agile, when properly executed, can delivery value to consumers quickly and inexpensively.
Agile does not, however, address the problem of business silos.
Moreover, optimal agile product delivery requires co-located team members in order to communicate and delivery quickly.
Product delivery teams are rarely co-located, which can result in "geographic silos."
The InnerSource working model applies to all product delivery strategies, including Agile and waterfall. How teams collaborate is up to each team. InnerSource complements Agile teams:
The InnerSource working model is based on the open-source model, in which geographically dispersed teams are the norm, not the exception.
To communicate effectively and asynchronously, InnerSource delivery teams rely on:
- Simple documentation like README files to help users install and use their product.
- CONTRIBUTING documents to help users become contributors to product development and delivery.
- Test and quality assurance automation.
- Tools like GitHub and GitLab for version control with enhanced collaboration features.
-
Issues worked from submissions outside a product's organization
How:
Track issues submitted by contributors outside of the organization that supports a product. Track whether those same issues resulted in changes to the product.
percentageOutsideEngagement = ( issuesWorked / issuesSubmitted ) * 100
-
Outside contributions merged and released
How:
Track pull requests (PRs) from contributors outside of the organization that supports a product. Track whether those same PRs were merged into the product and released.
percentageOutsideContributions = ( pullRequestsSubmitted / pullRequestsMerged ) * 100
Siloed teams neither record nor share knowledge beyond their immediate teams.
 |
 |
 |
|---|---|---|
| Access to documentation is either restricted... | ...or simply doesn't exist. | This makes searching for knowledge nearly impossible. |
The success of InnerSource product delivery depends on sharing information openly and transparently.
-
Track the number of software repositories with standardized READMEs.
How:
percentageOfReposWithReadmes = ( numberOfReposWithReadmes / totalNumberOfRepos ) * 100
-
Score READMEs for quality.
How:
-
Adopt the CoCoPods ReadmeScore calculation
-
Provide badges for display, e.g.,
-
Let's break the mission statement down and explain why it's significant.
InnerSource (and Open Source) products are developed, maintained, and delivered based on voluntary contributions from virtual strangers.
Consequently, InnerSource product delivery teams rely on automated CI services like:
- Builds
- Code quality assessments and relentless refactoring
- Dependency drift management
- PCI data violations
- Published (and automated) code style guidelines
- Unit testing and code coverage on target platforms
- Vulnerability detection
Moreover, InnerSource teams "sell" their products in order to compel their peers to adopt their software. This requires teams to:
- Architect and design products that are modular enough for parallal work
- Comply with open source licenses
- Distribute (or divest) software
- Limit product complexity
- Manage intellectual property issues
- Manage risk
- Manage security updates
- Plan for support
From dashboards to keyboards.
Automated product documentation assessments and tools.
Automated license scanning and decision support.
Automated source code quality assessment and repair.
Automated vulnerability checks before code merges.
From statues to TechStacks.
Harnessing the power of our Engineering and Design Community.