When I was at the BBC one of the goals of the Datalab was to look into embracing a ‘weak code ownership’[1] or ‘inner source’[2] model for our work. Broadly this meant working according to open source principles by allowing other teams to use and contribute to your code as long as they abide by some general rules of engagement set out by the Datalab team.
This essentially would have positioned the Datalab team as the ‘maintainers’[3] in the open source leadership model with other teams acting as ‘contributors’. The Inner Source model builds on the most successful attributes of open source projects → teams can share their work with a wider audience rather than just themselves or their ‘customers’.
While in most open source projects, anyone in the world is free to view the code, comment on it, learn new skills by examining it, and submit changes that they think will improve it or customise it to their needs in this case anybody with appropriate access to a Github organisation (in this case it was the BBC) can collaborate on the project.
New code repositories (branches) based on the project can be made freely, so that teams with unanticipated uses for the code can adapt it. There would be rules and technical support for re-merging different branches into the original master branch. People at large geographical distances, at separate times, can work on the same code or contribute different files of code to the same project. Communication will be written and posted on appropriate channels (Github, Confluence, Slack or elsewhere) instead of shared informally by word of mouth, which provides a history of the project as well as learning opportunities for new team members.
Writing unit tests becomes a key task. In open source and inner source, testing is done constantly as changes are checked in, to protect against failures during production runs.
Companies that operate in this way include giants like PayPal[4] and Salesforce[5] as well as start-ups like TransferWise[6] and O’Reilly have published a free ebook on the topic[7] TransferWise have helpfully blogged a little bit about their approach including their own ‘rules of engagement’ →
Before taking on any major change, the team making the change must go through a design discussion on said changes with the owning team.
The team making the change has to follow certain design patterns
No code will be accepted without adequate test coverage
All changes have to go through peer-reviewed pull requests
While I doubt any internal team would be overwhelmed with pull requests from other teams this does represent a potential burden and needs to be considered alongside the potential benefits.
[1] https://martinfowler.com/bliki/CodeOwnership.html
[2] https://en.wikipedia.org/wiki/Inner_source
[3] https://opensource.guide/leadership-and-governance/
[4] https://paypal.github.io/InnerSourceCommons/
[5] https://engineering.salesforce.com/inner-sourcing-whats-this-ef2220ae59ec
[6] https://medium.com/transferwise-ideas/product-engineering-principles-attransferwise-46a12a47e758
[7] https://www.oreilly.com/programming/free/getting-started-withinnersource.csp
