The best models I’ve seen are ones where anyone can contribute to the library, but there is a custodian (a person or a team) who is responsible for ensuring the quality, consistency and validity of those contributions. The job of maintaining the shared library requires strong technical skills, but also the people skills necessary to cultivate collaboration across many teams.
One of the easiest things to get wrong is to create too many of these components, too early. It is tempting to create a foundation framework, with all of the common visuals that will be needed across all applications. However, experience tells us that it’s difficult, if not impossible, to guess what the components’ APIs should be before you have real-world usage of them - which results in a lot of churn in the early life of a component. For that reason, I prefer to let teams create their own components within their codebases as they need them, even if that causes some duplication initially. Allow the patterns to emerge naturally, and once a component’s API has become obvious, you can harvest the duplicate code into a shared library and be confident that you have something proven.