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 the benefits of inner sourcing that can be presented to prospective executive level sponsors and what potential gotchas you should be aware of.
What are the benefits of Inner Sourcing? How can I pitch this to our execs?
There are a number of the large benefits that come from developing a more open source culture.
Team benefits
Decentralization of expertise
When someone leaves the company or the team, expertise is lost. By having more people involved in your project, you decentralize that expertise. Decentralizing expertise helps to safeguard against hidden, escalating costs due to phenomenal ramp-up time needed to execute changes to a body of code.
Less effort redundancy
With increased visibility into what other teams are working on and the problems they solved, there will inherently be less time spent rebuilding wheels. Code can be reused, shared, and modified by multiple stakeholders. In a culture of modularity, sharing and reusability, there’s inherently less duplication of effort. There’s an increase in the awareness around what problems other teams with comparable tech stacks are solving.
Shared resources on project goals
What better way to achieve better feature throughput of your project than to be in a position where you can receive contributions from other teams? With a low barrier of entry and shared best practices, others within organizations will be encouraged to contribute as there is no significant overhead — and many benefits — in doing so.
Unblocking
By encouraging others to contribute to your project, you empower them to decouple themselves from your team’s scheduling. Enabling those with the ability to solve their own problems by using your code is a powerful thing.
Modularity and code reuse
When writing code to solve a very specific problem, the code is generally not factored into its own set of libraries and instead rests within the parent project. A good deal of time is spent copy/pasting and refactoring code to meet new requirements. Most if not all of this time could be alleviated if a more generalized approach had been taken from the project’s inception.
Breaking down walls
What better way to get people talking than working on projects together? There’s always something to be said for happy hours and such, but real bonds are forged in the trenches of actually writing code, design discussions and code reviews.
Individual benefits
Cross pollination
How can you better progress your career than to become more influential across multiple projects? By spending time contributing to projects outside of your specific domain, you’ll learn about facets of your organization that otherwise would have been opaque, opening doors to opportunities for trying something new.
More “big picture” insight
A side effect of cross pollination is embracing a more holistic view of the architecture within your organization. You may often find that you had completely misunderstood or had an incorrect assumption about something before digging through code.
Great exposure to other teams
What better way to get involved with other teams than to contribute to their projects? If your organization supports cross-team migration, this gives you an excellent opportunity to learn their tech stack, review processes and personalities on the team. It also gives them exposure to you, which is invaluable if you’re considering interviewing with them.
Exposure to OSS practices
If you’ve never done any open source work, don’t worry, there are tons of people who haven’t. Get ready for a slight culture shock! Transparency and communication is key in both inner and open source. As initial exposure to this culture is internal to your organization, you reduce the scope of interaction from complete strangers in the open source world to vetted colleagues you either know personally or by reputation. You’ll generally be more likely to ask questions of people you know rather than from complete strangers.
Caveats
As with anything else, there are always potential gotchas and things to think about when beginning to build an inner source culture.
One shoe does not fit all
Just because an open source community does something does not mean that it will suit your team or organization as a whole. In fact, open source communities all work differently based on their specific community needs. Choose what works best for you and others within your organization.
Culture shift
If you’ve been at an enterprise company for some time, chances are that documentation isn’t always super high on the priority list. It can also mean that you’re used to working within the confines of your team or a very small subset of teams within the company. That you’re used to invisible political barriers between teams and technology. When these kinds of development practices are common within an enterprise company, collaborative development is largely stifled. Practices that do not lend themselves well to collaborative development need to be identified and somehow need to change in order to really foster an inner sourcing model. How that change is made is entirely up to you and the teams within the company. The amount of shift required will vary drastically by company. Likewise, the pace of change will vary. It’s important to not be discouraged so long as progress is being made.
Managing scope creep
As your projects gain traction and others begin contributing to them, you may start taking on more features than you ever anticipated. This is where the importance of the lead and maintainers being on the same page becomes critical. If a feature doesn’t fit into the overall project vision, the lead or maintainers should have no qualms about rejecting a feature proposal, and communicate why the feature did not fit into the project’s vision.
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 now have an idea of some of the tools and practices needed in order to achieve an inner source culture. You also have some ammunition to help drive the adoption and implementation of some, if not all, of the tools and practices. Develop some new ones as well that will help solve problems specific to your organization. Let’s start breaking down these walls and start working together. Let’s establish a collaborative culture that can far exceed the total output generated from team-centric, classical enterprise software development companies!
Follow us on Twitter: @SalesforceEng
Want to work with us? Let us know!
