"Asset Specificity" and Open-Source Software
By MortazaviBlog on Feb 11, 2008
Despite some excellent coverage of issues related to transaction cost economics of Open Source Software in The Success of Open Source (Harvard University Press, p. 193, "Business Models and Law"), Steven Weber may have misapplied Oliver Williamson's concept of "asset specificity" as an attribute of transactions .
Weber seems to be saying that Open Source Software, by virtue of its openness, will reduce asset specificity for those (including enterprises) who consume or use software, releasing them from lock-in. While the effect might be true, the reasoning diverges from the original meaning of the concept of "asset specificity," as coined by Williamson.
In The Mechanisms of Governance (Oxford University Press, pp. 59-60), Williamson states that his concept of asset specificity refers to "the degree to which an asset can be redeployed to alternative uses and by alternative users without sacrifice of productive value."
To clarify matters further, Williamson notes that there are varieties of asset specificities, e.g. (1) site specificity, (2) physical asset specificity, (3) human asset specificity ("that arises in learning by doing fashion"), (4) dedicated assets, (5) brand-name capital, and (6) temporal specificity.
If I use some assets, say my Prius, to drive to the local supermarket to buy oranges, I have not used any assets specific to the transaction of buying those oranges. The transaction is a fully market-driven transaction. I could buy the oranges from a large number of groceries that do business near where I live.
Now, assume I'm an orange broker in Florida. I may station my operations site near the largest orange groves or near the largest auction market for oranges. I may buy some forensic equipment specific to orange analysis, and pay for membership dues in the orange auction market, etc. I may spend money to brand my brokerage service, calling it "Honest Oranges." Now, I've invested in assets that have a higher degree of specificity (in site, in physical nature, in brand capital, etc.) in order to carry on with the transactions I conduct as an orange broker in Florida.
Now, let's turn from oranges to software.
When it comes to software, we can have some in-dept discussion of each of the specificity types mentioned by Williamson and see if there are others. For example, the Internet, the digitalization of storage, content and distribution, has almost done away with "site specificity." You can consume software made in city A even if you live 12 time zones away in city B. On the other hand, some software must still be installed in a particular way and on particular hardware, generating a "physical asset specificity" effect.
The most important kind of specificity when it comes to software, however, is "human asset specificity."
When an enterprise uses open-source software, they still have this aspect of specificity to deal with. For open-source software, as for any software, human specificity arises in learning by doing fashion. In fact, human asset specificity governs the software transactions world much more deeply than many other product types.
Unless there is a backing from a supplier that has reduced the need for investments with high degree of "human asset specificity," the user of the open-source software will have to make such investments on its own.
This is exactly the reason why we see great consulting, services and integration businesses thrive around open-source software products.