We will mostly just have to agree to disagree about what is best.
However, on this point I must clarify:
Finally, public good... in terms of actual economics, you are straight up wrong
No I'm not.
Go look at what I wrote (I just went back and double checked). I did not say that "the API" is not a public good, I said that "API service" is not a public good.
The API (specification) itself is a public good of course. Anyone is free to use "the API", it can not be "used up", etc.
But a server providing API service (which incorporates bandwidth, processing, and storage) is absolutely not a public good. It is rivalrous in that people must compete to use its finite resources. It can absolutely be "used up", as you put it, in the sense that too much usage will degrade the quality of service to unacceptable levels. It is excludable in that access can be easily restricted (using, for example, API keys).
I'd suggest reading https://en.wikipedia.org/wiki/Public_good#Examples for a good discussion as to what is or is not a public good in economic terms. The best examples are intangibles which share more with the abstract concept of "an API" and less with physical API servers:
defence, public fireworks, lighthouses, clean air and other environmental goods, and information goods, such as official statistics, open-source software, authorship, and invention
If I were to tell you "A blockchain is not a public good",
I was mistaken. I was thinking of read access to a blockchain, which is a public good in the same sense as many of the above information goods. Write access to a blockchain is not a public good. Indeed any blockchain which tried to be such would be spam attacked (as Steem was being when it didn't implement sufficient measures of exclusion pre-RC) and fail.
The wiki page you link to suggests "... quasi-public goods because excludability is possible", which in my opinion fits the bill for both read and write access to blockchains. They can, in the same was as roads, be blocked to poor overall usage.
But you are absolutely wrong about rivalrousness. A server providing readable data is infinitely renewable. It cannot be used up because the information is not deleted after being provided. You are confusing this property with excludability. It is a question of quality of service (which falls under the excludability property).
In this case, I would correct my definition to suggest that public APIs and public Blockchains, like roads and public libraries, are both quasi-public goods. Could we agree on that?
Not infinitely, no. Only up to the point where usage of the server reaches capacity to provide an acceptable quality of service, and even before that point, performance will degrade with more users, though perhaps imperceptibly at first. Being able to sequentually renew (i.e. not "use up") is not enough as you can see from the wikipedia page on rival goods
Again, I'm not talking about the information. The information itself is unquestionably a public good. A particular server (such as those proposed to paid for by this proposals) is not a public good. It has rivalrous physical resources such as processing power and bandwidth, and people compete to use those resources.
The reason that roads have historically been considered to be a quasi-public good is that it has been (and is still largely) impractical to infeasible to restrict access to most roads, making them effectively unexcludable. You aren't going to put up a toll booth on every corner, and if you try doing it on some and not others (apart from specific chokepoints such as bridges are certain limited access highways), the traffic will just move around it, making the scheme again impractical. This is somewhat becoming less the case technologically (due to automated toll transponders, automatic license plate recognition, GPS, etc.) and we are indeed starting to see more methods of exclusion such as express lanes, urban congestion zones, usage-metered registration fees, etc., making them even less of a public (or more precisely nonexcludable) good.
Anyway, back to servers. It is very practical to restrict access to servers with API keys. As I said earlier, I would support an SPS proposal to pay for servers which are restricted to limited-capacity use for developers and perhaps other categories of cost-sensitive users where there is a clear strategic reason to do so. I think that is a better use of limited resources than subsidizing profitable businesses (which experience has shown are highly prone to use free servers if they are available), opening the general floodgates, and discouraging (via a carrot, at least) people who can easily do so from running their own nodes (which leads to at least unnecessary centralization and fragility).
Did you finish reading the wikipedia page you linked?
In contrast to the hammer,
Can you and I both use the API at the same time? YES!
There's also this:
Your argument against roads applies directly as a metaphor to IP banning. Its the same principle.
Funny enough, one could make the argument that more usage of an API node increases efficiency of the access -- this is due to locality and caching behaviour. When two people access the same resource, the server only has to prepare that resource once before delivering it twice -- making it faster access for the second user. This is an anti-rivalrous property. :)
It's also possible to blow up a road. This doesn't mean a road isn't a quasi-public good anymore, it means you changed the underlying properties and thus changed the good. If you don't use API keys on a server, its not restricting access. Sure, I could change it to be a private good, but I'm not.
I'm willing to meet you half way here, but I'm surprised you're unwilling to move an inch. It's quite clear to me that this falls quite high on the spectrum of "public goodness" while being obviously not a puritan perfect one. But very few things are puritan perfect ones -- even a beautiful scenic view is worth shit if overcrowded or polluted. I don't think that you thinking in absolutes is a good way to approach this.
If you think that is a reasonable argument then it ought to be clear to anyone why I'm not meeting you "half way".
It is clear that API servers (not APIs) are not public goods because they are easily excludable (without requiring explosives), regardless of silliness over whether a server is more like "the internet" or a hammer. To be considered a public good requires that the good be both non-rivelrous and non-excludable. API servers are trivially excludable. Therefore not a public good. End of story.
Furthermore my opposition to unlimited free servers wide open derives mostly not from any economic definitions, but from how I've seen it have a negative effect on this particular ecosystem, as well as experience with a variety of blockchain projects. The healthiest and most robust ones have people running their own nodes, at least once their usage reaches the point when it is feasible to do so.
So, like I said, I think there is good that can come from making easy and cheap or free access to API servers available to small developers, just not wide open broadly to everyone on the internet who wants to use it.
That is my position on this proposal or ones like it.
It was an exaggeration, and sadly you've latched on to that rather than actually address my point. A better example could have been parking a truck in front of your garage door.
Just because something can be changed to become excludable, does not mean that it is therefore always excludable. Just because I could in the future gate a public road creating a private road, doesn't mean that that public road road is right now excludable.
There's no "end of story" here unless you are a puritan for public goods, which is completely ideological as one can trivially concoct ways to have excludability in just about anything. That is just silly, pedantic, and simply detracts from the point that something can be provided in a non-exclusionary way to be a quasi-public good.
Your other point -- a subjective viewpoint that public API's are a detriment or have a negative impact -- well, we will just have to agree to disagree here.
Your arguments are getting increasingly ridiculous. A garage is not a public good by any defintion, so the fact that one can exclude use of it by parking a truck in front of it (or with a door) does not mean anything at all.
The definition is non-excludable is that it isn't possible (or if you want to go with a sliding definition, less practical or feasible) to limit access.
That's just not the case for a server.
No that's exactly backwards! Just about anything can be provided in a non-exclusionary way if someone willing to pay to make it freely available.
The reason the category of public goods is important is because these are goods where it isn't practical or feasible to control access, therefore they must be funded by some sort of collective or public funding or they will not be provided or will be under-provided. This is a market failure.
Again, that isn't the case for servers, and especially not for nodes on a p2p cryptocurrency where you can get all the access you want or need by running your own. There is no market failure. (Except, arguably in the case of smaller developers, experimental use, etc. where the cost and difficulty of running a node might be a significant barrier).
I also get that running a Steem API node is a pain in the ass, so the barrier is somewhat higher than it might be. Nevertheless the barrier is not so high that profitable businesses and larger projects can't do it or hire someone to do it for them. We should also continue work to make it less of a barrier (as MIRA has started to do, somewhat, in a two-steps-forward, one-step-back sort of way). That's also work I'm more interested in supporting via SPS.
I'm obviously not arguing about access to ones own garage, I'm talking about access to the public road (which you were excluded from obtaining). Everything is excludable given some amount of effort, so a binary semantic don't make sense here.
Anyway, this is just getting extremely pedantic about semantics, and we're not making progress, so I suggest we stop here, and agree to disagree.