“Crack cocaine […] was a highly innovative product in the 1980s, which involved a great deal of entrepreneurship (called ‘dealing’) and generated lots of revenue. Innovation! Entrepreneurship! Perhaps this point is cynical, but it draws our attention to a perverse reality: contemporary discourse treats innovation as a positive value in itself, when it is not.”
“High uncertainty tolerance requires you to develop analytical skills. High ambiguity tolerance requires you to develop insight skills. […] The risk of uncertainty wrangling is being wrong. The risk of ambiguity wrangling is seeing something where there is nothing, or vice versa.”
If we roll with Rao’s implied definitions, uncertainty is being unsure about facts, whereas ambiguity is being unsure about interpretation. (This is perhaps beside the point, but I’m not sure the distinction between the words “uncertainty” and “ambiguity” is actually so clear-cut.)
My guess is that most of Rao’s readers work in tech and probably a high proportion of them are aspiring startup founders (I’m not excluding myself from either of those categories). I can easily see how this uncertainty and ambiguity matrix applies to either investing or entrepreneurship.
Let’s say you’re examining a market. You don’t know how many people have XYZ characteristic. That’s an uncertainty problem. Or maybe you do know how many people have XYZ characteristic, but you don’t know what to do about it. That’s an ambiguity problem.
Rao’s proposed solution is free-form intellectual play — he encourages, “it’s not wasted effort because there is no concept of waste in true play.”
Disclaimer: I’m open to disagreement that is expressed respectfully. If you have an argument against my interpretation, please share it. (Of course, I can’t guarantee that I’ll agree with your critique.)
“I think that’s demonstrably untrue — open source and free software has had a massive economic and cultural impact with precious little of that originating from the involvement of business people or community leaders. (For instance, the GNU project or the linux kernel — not to mention how many commercial products must use zlib). Business support almost always comes after the value has been created.”
I disagree. There are two threads here that I want to tease out:
Writing and testing code on the scale of a project like Linux or Ruby requires a community. Some people in the community, even if they are adept programmers, will be needed to support the project in other ways.
Once a program / framework / whatever is ready, it can’t promote economic growth unless it’s deployed by a business. In other words, software for its own sake is economically pointless. (By the same principle, outside of the open-source world, managers, salespeople, and marketers exist for a reason.)
People who make things tend to underestimate the importance of middlemen. I mean “middlemen” broadly — anyone in between production and consumption. In this case, programmers are production and regular end-users are consumption. However, before any product can be consumed, you need distribution.
Prior to the internet, distribution was limited by physical location and thus geographically specific. Particular companies controlled particular regions; they maintained relationships with individual stores. On the internet this dynamic is fundamentally different because the cost of distribution is negligible. Digital goods are effectively free to replicate, meaning there is no marginal cost. (Ben Thompson’s “Aggregation Theory” describes the consequences: value comes from being the layer that users interact with, which compels suppliers or advertisers to use your platform.)
When it comes to software, distribution is simple but difficult. It consists of two crucial functions:
Making people aware of the software’s existence.
Convincing them to use it by providing a compelling value proposition.
For the most part, those things don’t happen spontaneously. You need evangelists (as much as I hate that word). And those evangelists need incentives. The creators and proponents of open-source software are usually not paid directly for their labor (there are exceptions) but they are rewarded with social capital that can be leveraged into professional remuneration. You need people to write documentation and blog posts, organize / host meetups, and generally nurture the project’s ecosystem. This is the “community” part of the “business and community management” that I cited as being vital.
Even more saliently, free and open-source software projects only have an economic impact when businesses exploit comparative advantage by using them. For example, Super Body Fuel’s online store was made with WooCommerce, which sits on top of WordPress. The owners didn’t have to hire a developer to build a site for them. Using PayPal  as their payment processor also lowered the up-front cost and hassle.
Because of this, businesses like Super Body Fuel need less capital to get started. The owners can spend more time focusing on factors that differentiate their business (in SBF’s case, formulating a healthier and less expensive competitor to Soylent). In terms of investment and payoff, growing their business is a higher-return activity than setting it up in the first place. Efficiency increases, which result from technological innovation, are the only impetus of non-zero-sum economic activity. In a word, growth.
Of course, none of this could happen if the Super Body Fuel owners didn’t know about WordPress and WooCommerce, or if they didn’t have access to the intermediary tools necessarily to deploy them. Some amount of information seeps around without anyone making an effort, but awareness and resources that will reach thousands of people almost always require intentional promotion. Thus, coding is not enough to propel the open-source world. Other types of labor are needed to keep attracting more contributors and users.