Most companies, big and small, have some code that is shared by many but owned by few. It may be in the form of useful libraries for common tasks like logging and configuration. It may be in the form of internal services that cross business functions. Managing these libraries and services often falls onto the teams that originally created them, or on a core tech team that owns all shared software. This model has many drawbacks; slow changes, a lack of transparency for users, and a tendency to cause bottlenecks for other developers.

The modern enterprise has fully embraced OSS, but there is still an opportunity for us to learn from the processes used to create that software and apply it to our internal shared software. Encouraging shared contribution across teams to these code bases, with a “committer group” that ensures quality and stability, solves many of the challenges of shared software. It’s also a great opportunity to give developers exposure to code they may otherwise not have the time to examine, and increases shared knowledge across the company.

I will give two examples of implementing this process, in a very large enterprise and a small but growing startup, and some of the challenges and benefits realized.