Though I agree with [@GregBurghardt's answer][1] in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams which works with only a fraction of the effort. In case

- the group of people accessing a common library is small (5 to 6 persons at most)

- you have shared code ownership for the team (so anyone can fix bugs on the libs)

- you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

- "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

- ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

- if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

- more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list your team should already have, regardless wheter you develop common libs or not, so it is not some necessarily extra effort. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this should not cause too much extra effort.

The larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "commom library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

  [1]: https://softwareengineering.stackexchange.com/a/440398