There is no general solution to this problem. Welcome to approximately every organization that develops software. In many ways this is precisely the problem that the open source community has, as well.
Some person writes something useful. A few other people use it, too. Then a few more. Soon bugs are discovered and enhancements are requested, but the original maintainer is off doing something else. Copy and paste was your only recourse, until GitHub came along.
IMSoP definitely alludes to something important in their comment on your question. The obvious problem is managing dependencies, but this is only part of the solution. The organization needs a large amount of automation as well, otherwise distributing and testing these libraries becomes prohibitively labor-intensive.
At a high level, these libraries need:
- Excellent automated test coverage.
- An automated build system.
- A system to run automated tests.
- A system that empowers collaboration, so the original maintainers can retain veto power over changes, but are not solely responsible for implementing those changes (think: code reviews or pull requests).
- A centralized package management system.
- The ability to push new versions of packages to the package repository.
- To use Semantic Versioning, which allows you to communicate bug fixes, versus feature enhancements, versus breaking changes using version numbers.
- A hosting solution for developer documentation that integrates with existing continuous integration/continuous delivery pipelines (CI/CD), so documentation changes can be deployed automatically.
- A good distributed version control system that allows people to fork code repositories, and collaborate on writing code.
- This allows for customizations that the original maintainers reject, but your project finds useful.
- Some tool that allows the organization to identify and change the maintainers of these libraries.
And all of this will likely need to exist in a walled garden, of sorts, that is only available for authorized developers with your organization. Perhaps even within your organization's internal network.
You basically need to replicate the open source community inside your organization (along with similar collaboration tools) — an internal developer ecosystem. Implementing this is no small feat.
If your organization already uses a tool like GitHub, GitLab, Jira, Azure DevOps, etc, look at the features and components it supports. You might already have all the tools necessary to implement this, and your organization only needs a champion for the cause.
After this is all put together, maintainers spend time reviewing bug fixes and feature enhancements instead of writing them. You spend time fixing bugs and adding enhancements to the libraries as part of your regularly scheduled work (you just work in multiple code repositories), so management might not even care that you are spending time doing that. The CI pipeline performs all necessary testing. The CD pipeline packages things up and pushes them to the central package repository (including documentation changes). And when maintainers do not want to incorporate your change, you can fork their repository and implement the change yourself, and create your own package. Breaking changes can be introduced more safely when using a proper package manager and Semantic Versioning.