Inner Sourcing: The Ups and Downs

Photo by Jason Rosewell on Unsplash.

Part 3 of 3 of a blog series about Inner Sourcing which discusses what it is, how to go about implementing it, and what the benefits and potential gotchas are. In part 3, we look at benefits that can be presented to prospective executive-level sponsors and potential gotchas to be aware of.

What are the benefits of Inner Sourcing? How can I pitch this to our execs?

There are a number of large benefits that come from developing a more open-source culture.

Team benefits

Decentralization of expertise

When someone leaves a company or team, expertise leaves with them. Involving more people in a project decentralizes that knowledge and reduces the hidden, escalating ramp-up costs of making changes to a codebase.

Less effort redundancy

Visibility into other teams’ work and the problems they solve means less time rebuilding wheels. Code can be reused, shared, and modified by multiple stakeholders. A culture of modularity and reuse reduces duplicated effort and raises awareness of comparable problems across teams.

Shared resources on project goals

Projects gain feature throughput when other teams can contribute. Low barriers to entry and shared practices encourage people to participate without significant overhead.

Unblocking

Encouraging contributions lets consumers of a project decouple themselves from the owning team’s schedule. Giving people the ability to solve their own problems using and contributing to your code is powerful.

Modularity and code reuse

Code written for one specific problem often remains embedded in a parent project. Teams then copy, paste, and refactor it to meet new requirements. A generalized approach from the beginning can avoid much of that work.

Breaking down walls

Working together on projects creates stronger relationships than social events alone. Real bonds are forged through code, design discussions, and code reviews.

Individual benefits

Cross-pollination

Contributing outside a specific domain increases influence across projects and reveals parts of an organization that would otherwise be opaque. It opens doors to new opportunities.

More big-picture insight

Cross-pollination encourages a more holistic view of an organization’s architecture. Digging through code often reveals that an earlier assumption was incorrect or incomplete.

Great exposure to other teams

Contributing to another team’s projects teaches their technology stack, review processes, and team dynamics. It gives them exposure to you as well, which is valuable when considering a move between teams.

Exposure to OSS practices

People without open-source experience can use inner sourcing as a lower-risk introduction. Transparency and communication are central to both inner and open source. Starting with colleagues rather than complete strangers makes people more likely to ask questions and learn the culture.

Caveats

Inner sourcing has potential gotchas that should be considered while building a collaborative culture.

One shoe does not fit all

An open-source community’s practice does not necessarily fit every team or organization. Communities differ based on their needs; choose what works for your organization.

Culture shift

Enterprise organizations may prioritize documentation poorly, work within small team boundaries, or maintain invisible political barriers between teams and technologies. Those practices stifle collaboration. Teams must identify what needs to change and make steady progress at a pace appropriate to their company.

Managing scope creep

As projects gain contributors, they may gain more features than anticipated. The lead and committers must agree on the project vision. When a feature does not fit that vision, maintainers should reject it clearly and explain why.

Next steps

By now you should have a sense of how implementing a collaborative development culture within your organization can benefit the company as a whole. You have an idea of some tools and practices needed to achieve an inner-sourcing culture, and some ammunition to help drive adoption and implementation. Develop new practices that solve problems specific to your organization as well. Let’s start breaking down these walls and working together. A collaborative culture can far exceed the total output generated by team-centric, classical enterprise software development companies.