Give a shared library to a platform team when many teams use it and it is core infrastructure. Give it to the product team that built it when it serves a narrow domain and few consumers. Either way, the owner needs time budgeted for upgrades and security fixes, not just goodwill.
The two models
Platform ownership. A central team owns common libraries such as logging, authentication helpers and service clients. Benefits: consistent quality, one place for security review, clear contact. Costs: the team can become a bottleneck, and it may lack domain knowledge.
Product team ownership. The team that wrote a library for its own needs keeps it and others consume it. Benefits: close to the domain, fast changes. Costs: the library competes with the team's roadmap and often loses.
Decision table
| Factor | Points to platform | Points to product team |
|---|---|---|
| Consumer count | Many teams | One to three teams |
| Sensitivity | Authentication, crypto, untrusted input | Domain logic only |
| Change rate | Slow, stable API | Fast, tied to a product |
| Capacity | Platform has an on call and a roadmap slot | Product team can commit hours each quarter |
| Alternatives | Could be replaced by a standard package | Unique to your domain |
Count how many fall on each side. A clear majority decides it. A tie goes to platform for sensitive libraries and to the product team for the rest.
Make either model work
- Name the owning team and a second maintainer.
- Give it a service level. See security fix service levels for an internal library.
- Fund the time. Reserve a percentage of capacity for upkeep, or the library will decay.
- Allow contributions. Consumers send pull requests, and the owner reviews. Backstage frames an owner as the entity that has the authority and capability to develop and maintain a component, so check capability, not only willingness.
- Review each year. Ownership can move as the library becomes more or less central.
Warning signs
A platform team that owns forty libraries and cannot say what any of them does. A product team that says "it is not our job" about a library others rely on. A library that sits in a repository nobody has opened in a year.
Where security fits
Security teams should not own the libraries, but they should set the minimum rules for them: review depth by tier, required approvers on sensitive code and the patch service level. The map from dependency ownership map template gives them a view of which libraries sit in which tier.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Can we change owners later?
Yes. Use the handover checklist so permissions, tokens, alerts and consumer notice move with the code.
What if neither team has capacity?
Then decide whether the library should be frozen or retired. An unfunded owner is not an owner.
Sources
Last reviewed: 19 October 2026.
