Supercharge your company’s internal collaboration with inner-source
In part 1 of this blog series, we made large organizations agile and efficient by developing business capabilities through vertically integrated teams and tech stacks of manageable size. Doing so reduces dependency gridlock, meeting time, and increases the agility and efficiency of the business. A challenge with this setup is that so much independence can compartmentalize the organization. Inner-source, another key ingredient of modern technology-driven organizations, takes collaboration, efficiency, as well as the collective IQ of your organization to unprecedented levels.
what is inner-source
Conventional corporate culture optimizes for control and predictability. Its tendency for top-down decision making can produce insufficiently challenged decisions because of reluctance to express conflicting opinions, centralization, and problems scaling leadership. If incentives are misaligned, an organization can experience substantial amounts of internal friction and competition. Know-how to maintain existing systems is often poorly documented and not widely shared, causing hit-by-bus problems. Such an environment often has low employee morale and requires high salaries to attract and retain talent.
Contrary to this, open-source projects optimize for collaboration and sharing. Out of necessity, they are so aligned and rewarding that many people and even entire companies contribute substantial amounts of value to them for free. Successful open-source projects create intelligent crowds that discuss issues openly and are thereby smarter than the smartest individuals in them. They maintain a high degree of quality, are resilient to the turnover of organization members, and can combine the firepower of multiple market participants to create solutions that exceed what a single company can achieve on its own.
Inner-source is a movement that applies best practices from the open-source world to the development of proprietary codebases inside commercial organizations. It originated in software development and is now inspiring similar trends in other practices like data science, product management, design, operations, and security. Inner-source has become a valued industry best practice that players like Google, Microsoft, SAP, PayPal, Capital One, Walmart, IBM, and thousands of Silicon Valley companies embrace. Compared to the relatively controversial micro-services, inner-source is pretty universally loved and appreciated. At this point, there are no publicly known failures or regrets around inner-source despite its widespread use.
effects
An immediate effect of inner-source is removing silos and breaking down walls between teams. Working productively together forges strong bonds between individuals, teams, and departments. Open, honest communication and decision making spread expertise, facilitate cross-pollination, and lead to a collective thought process that is sharper than the smartest individuals in it. Teams and code bases optimized for external contributions lead to resilient communities that allow more flexible utilization of developers. When collaboration happens more in code, design documents, tickets, and less in meetings, the overall productivity of the organization improves.
A more discoverable and hackable codebase leads to increased reuse of existing capabilities and less duplicate development, resulting in cost savings and faster time to market. Teams and departments can share their operations and risk budgets as well as the eyeballs of their members to develop shared infrastructure and get it to battle-tested production quality faster. Observing all the code and changes in the company in real-time, the security team can participate in code and architecture reviews and prevent the use of insecure components by submitting patches that update problematic code.
Software developers can learn by exploring the codebase. They see working examples of how components and APIs are used by others in production. This complements documentation and shortens the time to learn about them. Knowing that other people see their code, developers keep it cleaner and the company’s codebase — one of the most important business enablers in the 21st century — remains healthier. Collaboration across teams leads to more consistent coding conventions across the company, which makes people feel more at home in each other’s code.
Inner-source replaces complaining and demanding changes with an invitation to help fix problems. This attracts highly skilled technical talent that resonates with this work model and loves to help. Happier employees are more motivated, care more about the outcome, think along, and show higher loyalty. All these effects increase business agility: new ideas reach production faster.
challenges
Many leaders hesitate to adopt inner-source because it brings higher exposure: disgruntled employees can steal larger parts of the codebase. But this is often less of a problem than it seems. Your business secrets, including a lot of the company’s confidential data, are excluded from inner-source. The rest, especially modern code and infrastructure, are typically based on open source anyway, i.e. are for the most part already shared with the world. Unless you are Google or Amazon, proprietary platform technologies don’t provide business advantages anymore.
The business logic on top of your platform technology is custom-tailored to your company’s market position, culture, processes, and compliance structure. This code, especially in the form of an outdated and incomplete leak, is not particularly useful without the people, the know-how to operate and maintain it, the configuration data, passwords, and encryption keys.
Your business advantage comes from wise market positioning and skillful application of technology to your market segment and ecosystem, not from isolating all your technology.
how to create inner-source
Behaviors and culture develop in environments that encourage them and make them natural. If you want a culture of collaboration and sharing, you need a good collaboration and sharing platform like GitHub, GitLab, or BitBucket. Make all project artifacts (source code, documentation, tests, test data, infrastructure automation, and DevOps data, scripts, and tooling) available on such a platform, searchable company-wide, and work as much as you can on them. Make the codebase easy to explore by organizing it in a stable structure, for example by domain, product, or component. Don’t structure the code following the org chart since that changes too frequently. Give everybody in the organization access to almost all the code except the business secrets. Google, for example, keeps the formula for ranking search results secret, but most other code is shared internally, including the source code of the search engine itself.
The second step towards creating inner-source is lowering the barriers for entry: anybody must be able to build, test, and run any codebase in a few simple steps. Documentation how to do it should exist in the same repository as the source code. A README file in the root directory of the code base provides an overview, lays out the mission (the problem the code base is solving for its users), and points to further documentation files. A DEVELOPMENT file lists the steps to build, test, and run the codebase. A CONTRIBUTING file documents how to contribute to the code base. It contains the naming and formatting conventions and templates for idea and change proposals. A CODEOWNERS file lists the people who can review and approve changes to particular files and folders in the codebase.
Processes and workflows should be open by default. Most conversations should happen in the open, in public tickets, on mailing lists, or in chat rooms that anybody can join. Most decision processes should follow commonly defined and agreed-upon rules that are managed as code and enforced by a fair authority. This fair authority ideally includes highly respected individual contributors and not just managers. Decisions are made and can be challenged on open discussion platforms. Important decisions are documented, for example as Architecture Decision Records. External contributions should be treated equally to internal ones and go through the same review and testing process.
company > team > myself
But technology and processes alone are not enough to create a thriving culture of collaboration and sharing. You also have to create the right political environment. The final and most important step towards inner-source is removing economic incentives for hoarding code, data, and collaboration. Stop rewarding and promoting managers based on how much headcount or revenue they oversee. Measure the value they add to the business more directly. Celebrate and reward velocity, agility, cost efficiency, profitability, enabling others, sharing, and reuse. Enable those who complain about problems to help fix them. Enforce the inequation company > team > myself everywhere to prevent politics.
Inner-source is an essential tool that can help most commercial organizations reach their business goals faster by supercharging internal collaboration. In the next blog post, we will make inner-source the natural and economical choice with a mono-repository setup.
