This is not correct. It's the "organization" features which are going away. That is the feature which lets you create teams, add other users to those teams, and grant teams access to push images and access private repositories. Multiple maintainers can still collaborate on publishing new images through use of access tokens which grant access to publish those images. It's kind of a hack, but it works. You would typically use these access tokens with automated CI tools anyway. This will require converting the organization account to a personal user (non-org) account. (Interesting note/disclosure: I was the engineer who first implemented the feature of converting a personal user account into an organization account some time around 2014/2015, but I no longer work there.)
For open source projects which are not part of the Docker Official Images (the "library" images [1]), they announced that such projects can apply to the Docker-Sponsored Open Source Program [2].
I would also heed the warning from the author of this article:
> Self-hosting a registry is not free, and it's more work than it sounds: it's a proper piece of infrastructure, and comes with all the obligations that implies, from monitoring to promptly applying security updates to load & disk-space management. Nobody (let alone tiny projects like these) wants this job.
Having most container images hosted by a handful of centralized registries has its problems, as noted, but so does an alternative scenario where multiple projects which decided to go self-hosted eventually lack the resources to continue doing so for their legacy users. Though, I suppose the nice thing about container images is that you can always pull and push them somewhere else to keep around indefinitely.
[1] https://hub.docker.com/u/library [2] https://www.docker.com/community/open-source/application/