The open source world thrives on a model where distributed parties contribute to software. In this post-Github world, many of these contributors get involved with projects by submitting pull requests, which are in turn vetted by a core set of contributors. If the change is acceptable, then the pull request will be merged in. This model can help us inside companies too.

Within organisations, we often face the problem of how to make changes to IT assets which are not directly owned by a team. This can happen a lot where teams are brought together for a project purpose and disbanded when the job is done (or the budget runs out). With a microservice architecture, this can occur more frequently as the individual services are in an of themselves small, and more likely to only be developed for a short period of time.

If no ownership is provided, they can become Orphaned , which can lead to challenges later on. Alternatively, you could maintain a set of people who are responsible for gatekeeping changes to the service, even if they don't happen to be in a team together - instead they could be spread all across the organisation.

To make a change to a service being managed using a Roving Custodian model, you would then need to find one of these gatekeepers, or perhaps make use of an internal open source model where you could submit a pull request, and have one of the custodians vet the change.

This isn't free. The custodians are in other teams, but it needs to be accepted that part of their responsibility is going to be to look after these services. They'll need time to meet up and discuss things if required, view pull requests, work with people making changes. You may also have to look at tooling, not only to enable the gatekeeper to vet changes (where a system like GitLab could work), but you'll also need to record somewhere who owns what. Inside Google for example, each source code directory contains an OWNERS file which records who the owners for that code is. Their code review system is built to ensure that someone in this file has to approve a change to code in the directory before it can be submitted. In the case of service ownership you won't need as fine a grained system, but you'll need to capture this somewhere, perhaps simply by giving the custodians commit access to the appropriate repository.

Ensuring that custodians exist is a good way to ensure that even if not directly assigned ownership that the service itself doesn't atrophy too much. With an Open Service Ownership approach, you'll sidestep the need to keep a list of custodians and avoid the need for tooling to manage controls to the source, but you'll also open up the possibility that inconsistent changes may be made impacting the quality and maintainability of the service.

See more patterns.