Crowdmatching & public goods vs common pool resources

This is from an email I wrote last year answering questions from the Free Network Foundation (an entity that doesn’t exist in its original form but which is getting publicly documented and the mission wrapped into new efforts to revitalize the vision). The core point is: crowdmatching stops making sense when rivalry for resources comes up. But just because rivalry is possible (e.g. congestion on a bike path), that doesn’t mean it’s a practical issue — until it is.

Not totally sure what the context is for putting that quote here. That said, I have a comment:

There is an implication here, critical to the correctness of the argument, that “more donors means more users”.

I know this seems intuitive, because the network effects and outreach efforts that get a free project more donors are also just getting it more attention in general - and thus users. But I believe your statement “…encouraging more users, [but I don’t want to] match them all” is a mistake, because you don’t actually match users, you match donors. That’s still working on the assumption (like Patreon et. al) that donors are rare among users - we’d need, for example, 100 new users for each new donor we want to recruit (using Wikimedia’s numbers).

But that’s without the extra incentive that comes from matching, which should specifically target an increase in the number of people who donate, especially among existing users. It has far less of an impact on the number of users, it’s more about asking existing users to step it up.

So considering the converse, “no more donors means no more users”, Does it really make sense? The way I see it, it doesn’t matter whether a project gets more funding or not - as time goes on and this (newly-funded) project continues to grow, users will continue to flock to it!

Donors know this. (Heck, if they’re in the top 1% most passionate about this project, they probably want it to have more users!) So if they’re interested in the continued success (not just one-time success) of the project, they should also be interested in the next most critical thing to that success: helping it keep up with the influx of new users. While there’s plenty of great reasons for a donor to not increase their contribution, withholding an increase solely with the hope that the user count will stop growing would just be shooting one’s self in the foot. Would it not?

Further: I suggest this is why we need multiple funding goal levels, which can be modified post-launch. The higher goals might not make much sense to us in the beginning, but once we’ve achieved the first few levels, it makes a lot of sense to have an “upgrade our infrastructure to comfortably handle Y users” level. When we get to the point where your “my bandwidth is hurt by the presence of more users” statement is increasingly believed - or even felt - by the donors, they certainly will want to contribute to that next level, no?

2 Appreciations

Well put. In the case of a co-op ISP with a mesh-network (the FNF vision), there’s a question about using crowdmatching as a form of paywall or light-paywall, as in crowdmatching determines the fee to access the mesh network. So, the context here is about complex edge cases that aren’t straight-forward public goods. What if the network is open to anyone? Etc. is there a per-user added cost to the network?

But your distinction between patrons and users (even to the extent of more patrons who are themselves not very active users) is an additional twist.

The core point is about noticing the fuzziness in the definition of public-goods and the question of what scope of projects are good-fit for crowdmatching.

1 Appreciation

Ah! So it’s not. I never would have thought to assume otherwise, so thanks for adding the context I was missing.

I was assuming the standard client-server model, in which case there certainly is. But with a mesh network, it could be the opposite - more users means a higher quality network for free - like bittorrent!

So yeah, that’s complex.
User ≠ ISP customer ≠ patron necessarily.

2 Appreciations