When it comes to software engineering, we often want to break the pattern where many people are all encountering similar problems. Teams are building software faster than ever and it’s a great deal of effort to keep track of compliance, security, and duplication, especially at the scale.
Within a large organization, you must define your technology strategy and spend engineering effort wisely otherwise the scale of waste and duplication will be significant. Both centralized (multi-tenant platforms) and decentralized (you built, you own it) approaches have some tradeoffs. After all, you have to ensure teams are collaborating, use common API standards, their technology stack is pretty much aligned.
All that brings us to the definition of Inner Sourcing:
“InnerSource takes the lessons learned from developing open source software and applies them to the way companies develop software internally.” by InnerSource Commons
Usually, when you start working at a large organization one of the first observations is people working in silos and duplication of effort among different technology areas.
Adopting Inner Sourcing practices can transform your ways of working drastically towards:
- Collaboration and faster software delivery.
- Breaking down silos and encouraging more people to contribute.
- Contributing software back to the open-source ecosystem.
- Common coding standards, tools, and libraries.
Of course, this situation might not exist in the company of ten developers where everyone knows each other. However, in a large organization, it’s likely people struggle to recognize what’s being developed among different business units.
So how to encourage people to contribute to others’ code and solve problems once in an open-source fashion?
- The codebase must be open to external contributions.
- It needs to be testable.
- The complex domain code is written once and re-used.
- A model without forking and customizing.
Open codebase encourages people to contribute and work towards a common governance model. Automated testing and review as part of your continuous integration pipeline help to ensure code quality. When the code is written only once and re-used, more people are inclined to use a single source of truth and stop maintaining their own fork which leads to wider standardization.
That’s the most important element of your success. Without an active community, you can’t get enough early adopters and invaluable feedback to make sure you spend your engineering effort wisely.
It usually requires establishing a common platform where people can easily exchange ideas and develop their products, this commonly involves:
- Common GitHub Organization — to host codebase in a single place where the internal security team can keep track of potential vulnerabilities or lack of compliance. Keep all discussions on GitHub to facilitate input from people outside of the team.
- Landing page and documentation — to share overall vision and mission statements for others to contribute. As well as some general standards and complete project’s documentation.
- Company engineering blog and public presence — to cultivate the culture of speaking at conferences and writing technical blog posts. Stay on top of current technology trends.
- Communication channel — depending on what products your company currently use, it might be Slack, MS Teams, or others. You need to keep people on the same page, give them frequent status updates, and offer help.
It’s crucial to incorporate the concepts below.
1. Fully automated release management and versioning. Use semantic versioning which is the best way to track what is going on with the software, especially if you want to prevent developers from using preview features. Advise them to use a fixed version. Keep the changelog clean and notify people about any backward-incompatible changes when doing a version upgrade.
2. Avoid code duplication and keep reusable codebase like bash wrappers, plugins, or test utilities in the common repository. It can vastly reduce the number of activities related to bumping versions of components, updating code examples, etc.
3. Introduce end-to-end tests as part of your development process. You want to make sure everything works as expected, all pull requests are free from bugs before you start reviewing them. Make sure all components work together, it’s crucial to connect dots before you release it to a wider audience.
4. Publish the contribution model early. The main purpose of this is to create guidelines on how people should contribute to your project including:
- Maintainers etiquette
- Onboarding and required access
- Organization standards and policies
- Testing environments for developers
- Definition of done and quality standards
5. Write a developer guide for every project. This is a starting point including all configuration steps in order to run and test code locally. It often consists of the following sections:
- Prerequisites — preferred IDE, tools, versions.
- Dependencies
- How to run and test code locally
- How to release code
- Self-learning
6. Have common technology standards. Ofc. treat it as a rule of thumb 👍 not necessarily hire Enterprise Architects in your organization from day one.
Below you can find a list of patterns that have been proven to be effective at scale 100+ devs. You may also need to establish other patterns depending on your organization’s standards.
Common Requirements — Common code in a shared repository isn’t meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring. Align requirements and roadmap to the technology standards in your organization.
InnerSource Portal — Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience. Consider GitHub static pages e.g. with Hugo.
Praise Participants — Thank contributors effectively to engender further engagement from them and to encourage others to contribute. Often status updates and announcements, don’t forget to praise all contributors.
Include Product Owners — Key Performance Indicators (KPIs) for Product Owners are primarily product-focused and don’t consider areas such as collaborative development. This results in a lower level of engagement with inner source projects. Keep your Product Owner in a loop, task him to gather requirements and influence the roadmap.
Issue tracker use cases — The InnerSource host team fails to make not only plans and progress but also the context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design. Maintain transparent roadmap and issues board e.g. GitHub Projects Board.
Change the Developers Mindset — Inner Sourcing is a culture mind-shift, and you have to invest your effort to build a culture and increase awareness about it. Take a look at An introduction to innersource by GitHub. Think about regular community calls and office hours.
Introducing Metrics in InnerSource — Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of the health and performance of the InnerSource initiative. Measure current adoption and contribution, e.g. GitHub Insights.
Find more at InnerSourceCommons / InnerSourcePatterns.
