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
It all adds up to the conclusions outlined here in this blog post.
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:
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?
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.
Start with a strong core team of people who are capable to build a solid foundation and establish clear standards for other developers to continue contributing. It’s especially important at the early stage when you are not sure about the final shape and technical difficulties along the way.
One of the key principles of Inner Sourcing is collaboration and software reuse.
It usually requires establishing a common platform where people can easily exchange ideas and develop their products, this commonly involves:
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:
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:
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.
After you successfully landed a new initiative within your organization, it’s worth to start exploring other interesting concepts. The tailored service template pattern integrates nicely with inner sourcing.
By adopting this you can potentially build a common pattern like reference microservices architecture on Kubernetes which people from the community can re-use and actively maintain.
The technology landscape will be constantly changing with time, but the initial approach stays the same:
To build a community platform where people can collaborate, exchange ideas, deliver solutions for customers, colleagues and it’s a joy to use.
Bartek Antoniak | Cloud Engineering Manager
Nowadays, the way we talk, issue a pull request has fundamentally changed with more remote ways of working, we need to be conscious and collaborate more than ever — inner sourcing might be an answer here.