This article was an excellent read. Like other commenters, it reminded me of Clemens Szyperski's "Component Software" book. While a component model of software

This article was an excellent read. Like other commenters, it reminded me of Clemens Szyperski's "Component Software" book. While a component model of software production has succeeded in some niches, it has (so far) failed to become a central organising principle for large scale software production. The article suggests that new micropayment mechanisms such as blockchain might enable Brad Cox's vision of pay-as-you-use software components. But I think this misses the point. I would argue that software differs from physical goods in important ways that make it a poor fit for this model. In particular, software is cheap to modify, evolve and customise, but expensive to specify independent of implementation (cf. Refactoring, Agile processes versus ISO Standards Development.) One issue that Szyperski's book examined was the composition model (i.e. object model: COM, CORBA, JavaBeans, etc) used for defining interfaces between software components and how those interfaces can be composed. The idea of standardizing interfaces and composition mechanisms does not get so much attention today. It seems that things are currently balkanized into language communities, each doing their own thing. The industrial manufacturing concept of "interchangeable components" comprises of two things: (1) standardized specifications, (2) multiple independent manufacturers who are able to independently implement specifications. We do have this kind of practice in, for example, the specification and implementation of the C++ standard library. But that's not how most software is developed, and it is commonly held that it is not how most software should be developed. On the other hand, we do have "component reuse" in the form of software libraries -- but the interfaces are unique and idiosyncratic to each library, not standardised, and there is usually a single "manufacturer".