Why didn't Agoric Computing become popular?

The limiting factor on a thing being charged as a utility is that it is evolved enough and understood enough that the underlying architecture won't change (and thus leave all the consumers of that utility with broken products). We've now basically gotten there with storage, and computing time is next on the chopping block as the next wave of competitive advantage comes from moving to serverless architecture.

Once serverless becomes the defacto standard, the next step will be to commoditizie particular common functions (starting with obvious one like user login/permission systems/etc). Once these functions begin to be commoditized, you essentially have an Agora computing architecture for webapps. The limiting factor is simply the technological breakthroughs, evolution of practice, and understanding of customer needshat allowed first storage, then compute, and eventually computer functions to become commodotized. Understanding S-curves and Wardley mapping is key here to understanding the trajectory. [LW · GW]

One obstacle has been security. To develop any software that exchanges services for money, you need to put substantially more thought into the security risks of that software, and you probably can't trust a large fraction of the existing base of standard software. Coauthor Mark S. Miller has devoted lots of effort to replacing existing operating systems and programming languages with secure alternatives, with very limited success.

One other explanation that I've wondered about involves conflicts of interest. Market interactions are valuable mainly when they generate cooperation among agents who have divergent goals. Most software development happens in environments where there's enough cooperation that adding market forces wouldn't provide much value via improved cooperation. I think that's true even within large companies. I'll guess that the benefits of the agoric approach only become interesting when large number of companies switch to using it, and there's little reward to being the first such company.

Note that market economies aren't pure in any other realm either. They work well only for some scales and processes, and only when there are functioning command or obligation frameworks that adjoin the markets (in government and cultural norms "above" the market, and in family and cultural norms "below" it, and in non-market competition and cooperation at the subpersonal level). We actually have well-functioning markets for compute resources, just at a somewhat courser level (but getting finer - AWS sells compute for $0.00001667 per GB-second, and makes it easy to write functions that use this compute resource to calculate whether to use more or less of it in the future) than Agoric Computing envisions.

I suspect the root cause is that many of the decisions are outside the modeling of the price/purchase system, and the inefficiency of actually having the market infrastructure (ability to offer, counteroffer, accept, perform, and pay, across time and with negotiation of penalties for failure) outweighs the inefficiency of a command economy.

I also suspect that the knowledge problem (what do participants want, and how to you measure the level of those preferences) is much reduced when the software doesn't actually have any preferences of it's own, only what the programmers/masters have specified.

Alternately, perhaps this is more integrated into current thinking than we realize, and we just didn't notice it because "the market" is bigger than we thought, and automatically incorporated (and was overwhelmed by) the larger sphere of human market interactions. Finding and tuning cost functions for algorithms to minimize is a big deal. However, there's so much impact from reducing cost on a macro scale, that reducing cost by making software calculations more efficiently is lost in the noise.

I don't think the features of the theoretical system were particularly relevant. I can see several reasons why this wouldn't take off, and no reasons why it would. For example:

Objects are assumed to communicate through message passing and to interact according to the rules of actor semantics [3,4], which can be enforced at either the language or operating system level. These rules formalize the notion of distinct, asynchronous, interacting entities, and hence are appropriate for describing participants in computational markets.

This part raises a few red flags. We were pretty terrible at asynchronous anything in 2001; the only successful example I know of is communication systems running Erlang, and Erlang is inefficient at math so cost functions would have had a lot of overhead. Further, in the meantime a lot of development effort was put into exploring alternatives to the model he proposes, which we see now in things like practical Haskell and newer languages like Rust or Julia.

Further, we've gotten quite good at getting the value such a system proposes, we just write programs that manage the resources. For example, I do tech support for Hadoop, the central concept of which is adding trade-offs between storage and compute, and Google used Deepmind to manage energy usage in its datacenters. Cloud computing is basically Agoric computing at the application level.

In order for Agoric computing to be popular, there would need to be clear benefits to a lot of stakeholders that would exceed the costs of doing a complete re-write of everything. In a nutshell, it looks to me like Drexler was suggesting we should re-write all software under a market paradigm when we can get most of the same value by writing software under the current - or additional - paradigm(s) and just adding a few programs which optimize efficiency and provide direct trade-offs.

Agoric Computing seems like a new name given to a very common mechanism employed by many programs in the software industry for decades. It is quite common to want to balance the use of resources such as time, memory, disk space, etc. Accurately estimating these things ahead of their use may use substantial resource by itself. Instead, a much simpler formula is associated with each resource usage type and that stands as a proxy for the actual cost. Some kind of control program uses these cost functions to decide how best to allocate tasks and use actual resources. The algorithms to compute costs and manipulate the market can be as simple or as complex as the designer desires.

This control program can be thought of as an operating system but it might also be done in the context of tasks within a single process. This might result in markets within markets.

I doubt many software engineers would think of these things in terms of the market analogy. For one thing, they would gain little constraining their thinking to a market-based system. I suspect many software engineers might be fascinated to think of such things in terms of markets but only for curiosity sake. I don't see how this point of view really solves any problems for which they don't already have a solution.