How to organize multiple customized projects around a shared and evolving codebase?

This very much depends on what exactly those about 20 repositories contain, their dependencies, reasons for evolution and development, and what you mean by "used by one group of developers" (that was written before the edit, so some of that is cleared up now).

With a complex codebase you will need to employ stabilization mechanisms.

• Determine owners (or owning teams) for each repository who ultimately decide what goes into each. They may use inputs in the form of new requirements for the next major version, or pull requests for suggested fixes or minor additions, but they need to set the direction of development.
• Use stable dependencies (for example, based on semantic versioning) to clearly communicate which version of a repository is needed by others, and have clear rules for backward compatibility, depreciation, etc.

Customization is a difficult issue. Better think of projects based on suggested templates. If different applications/projects can have different database schemas, domain objects etc. it might be best to develop a stable framework or language in which these can be described so that a schema can be migrated to a new version of the underlying libraries easily.

As a model, consider libraries that are available in common large ecosystems such as Python, Javascript, Rust, etc. All of these allow applications or libraries to depend on specific versions of other libraries to prevent surprises. Semantic versioning provides mechanisms to communicate which versions of libraries are expected to be backward compatible to others.

When considering microservices, having different forks within the various projects will likely lead to incompatible evolution. I would either use microservices as-is with a defined functionality (closed), or libraries which can be wrapped if you need additional project-specific functionality.

Each of those dozens of repos should have clear ownership: owned by Team-A, or B, or shared. If you own it, then you need only coordinate within your own team.

recommendations on how to organize collaboration

Sharing code is good: we get new feature benefits. Sharing code is bad: your developer's edit can crash my microservice.

In the latter case, we want edits from Team-A to anticipate objections from Team-B, to avoid stepping on B's toes. One way to accomplish that is by ensuring each PR pull request code review needs sign-off by both A and B developers. A better / faster / supplementary approach is to ensure that everyone runs automated unit tests written by A folks and also tests written by B folks. Since it's automated, the communication turnaround is much faster than the PR process, which also has a role to play.

It's likely that some of the tests will appear in A-owned or B-owned repositories, and then the editing team will read / execute those "foreign" test suites. This implies that, in addition to the usual SemVer 1.2.3 version numbering, you will need "rc1", "rc2" release candidate versions which foreign repos can easily pull in. This should give a developer on the editing team some confidence in their proposed edits, prior to inviting members of the other team to review and approve their edits.

In a situation with this constraint

The 2 groups are from differents organization.

there can be a point where the DRY principle hinders your teams more than they will benefit from it. When one team needs an urgent change for their project, but for the other team this change is too much effort or their project has other priorities, this can too easily lead to delays and conflicts. Hence, copying certain repositories and having each team maintaining their own fork should be definitely considered as an option - something you try to avoid for a single team. But with the resources of two teams it can be less effort to let each team maintain their own version than trying to sync the development of two different projects artificially.

Of course, that does not mean you should fork every single repo. If you can establish an ownership for certain services, similar to what Hans-Martin Mosner wrote, you may keep shared services existing in only one version line, where all customization is done by a small, maintainable amount of parameters and configuration options. The ownership might be placed at a sub-team with developers from both organizations, at least for the period while the collaboration lasts.

Unfortunately, services which depend on the structure of domain objects are IMHO not good candidates for staying shared when this structure differs from one project to another. In my experience, services which are independent from that structure have better chances to be developed in an unforked manner. In the end, only you can decide which services to fork and which one not, and which ones may be redesigned to make them reusable across different projects.