The root of the problem is that open-source donations are made on a per-project basis. To support a project via GitHub Sponsors or OpenCollective, you must create hyet another auto-renewing monthly subscription for each project you want to support.
I don't think the author's description of GitHub Sponsors is exactly correct. Technically, the sponsorship is at the user/organization level, so if you make a donation it goes to the organization/user, which may have MULTIPLE projects going on. This is the way I have set it up for our company Plyint (https://github.com/sponsors/plyint).
Although I would very much like GitHub to implement a pool of organizations/users, which is maybe what the author meant?
Good point, that characterization isn't exactly accurate. Though the first-order point is that you have to go through a separate "checkout process" each time you want to sponsor a new thing.
I actually think it's important that the pools themselves contain projects not users/organizations. There are definitely complications I hadn't considered if multiple entities/organizations are listed as maintainers of a particular project. Presumably the set of maintainers would have a way to "split" the incoming donations among themselves as they see fit.
I don't think the author's description of GitHub Sponsors is exactly correct. Technically, the sponsorship is at the user/organization level, so if you make a donation it goes to the organization/user, which may have MULTIPLE projects going on. This is the way I have set it up for our company Plyint (https://github.com/sponsors/plyint).
Although I would very much like GitHub to implement a pool of organizations/users, which is maybe what the author meant?