Inner source is the use of open source best practices inside companies to develop shared components for use in the company’s products. Inner source software doesn’t have to become open source (but might). Like open source software development, inner source software development is inherently asynchronous, distributed, and multi-timezone.
Inner source is a match made in heaven for the new world of work-from-home.
All signals are clear: Many people love working from home, and developers are no exception. They will only return to the office, if forced, and it will come with a price for the company. Hence, those companies will be better off which can make work-from-home work out for their developers. This is in clear conflict with agile methods practices of co-location, regular stand-ups, etc.
Consider your average development shop: It is stuck somewhere in agile transformation hell. Developers are doing Scrum, or Scrum-but, or something-similar-but-not-quite Scrum and often hating it. Scrum and similar agile methods have put devs into a strict delivery corset, loved by many managers, and loathed by many more developers. (Whether this is true Scrum then or not is not my point here; reality is.)
In a better-than-average Scrum shop, developers will work in feature teams to deliver business value by implementing a feature across all layers of the chosen technology stack. In a feature team, different people work on different aspects of the feature (usually tech layers), matching their interests, capabilities, and experience. This is already a step up from expecting one developer to know the full stack so well that they can implement a feature alone. It also opens the door to architectural integrity and inner source.
The ubiquitous drive for business-value-first often leads to neglecting quality of code and integrity of architecture. If a single person drives a feature from the UI into the database, not looking left or right, they are inevitably going to create a mess, increasing technical debt, and ruining the software long-term. Features teams help a bit, because now the competence of the people working on a particular layer of the stack increases.
Inner source helps even more. Inner source leads to the creation of cross-organizational-unit teams working on shared components. Their focus is on building-out high-value (reusable) components for the firm while maintaining the software’s integrity. Inner source project communities are complementary to feature teams, creating a matrix where people from different feature teams who work on the same part of the stack connect with each other to not only form communities of practice but of actual software: The reusable libraries, components, and frameworks that applications and services are built on.
In the new world of work-from-home, developers will meet inner source (if they don’t know it yet) and love it even more, because it fits the new work style. This new style isn’t really new, but is what developers have always preferred; it had just been buried under Scrum requirements for in-person meetings, daily stand-ups, pair programming, and co-location in general. How Scrum will adjust, I don’t know (I’m sure it will), but I know that developers will take to inner source like ducks to water, because it was their past, got buried in the present, and will be their future again.
Leave a Reply