No, contrary to common belief, coordinating with multiple client projects to release features simultaneously etc, is not easier. The number of meetings does not drop, the quality will not improve if you now have to check that multiple clients are safe. You won't magically get more eyes on your code, when people are working on their code, not yours. And at that point you now have to deal with people who think they have as much say as you have because their fork is "equally important". And trying to explain to a non-cryptographer hobbyist why some change needs to be done, or why some feature can/should not be implemented, is not speeding things up.

Could you explain what Signal is doing to discourage contributions?

By not allowing 3rd parties apps to coexist with official signal app. (Using same servers)

Signal placing restrictions on who can use their service has nothing to do with whether or not people can contribute to the codebase.

It does. There is less incentive to work on a Signal client fork if it can't be used to interoperate with the Signal service.

That's a bit like saying there's less incentive to work on (for example) Elasticsearch, because you can't deploy your fork on Elastic Co's official managed service. It's nonsense.

There's a difference here between Elasticsearch and Signal, namely that that network effect is a very important factor with messaging apps.

Nor when they've received millions in grant money.

Not true