Infrastructure software, by its nature, is designed to power hundreds or thousands or millions of different needs. That suits an open source model. We tend to

Infrastructure software, by its nature, is designed to power hundreds or thousands or millions of different needs. That suits an open source model. We tend to inflate problems that touch us directly and deflate problems that we don't see very often. Consider if I am the government official responsible for making sure roads are paved. The roads that I use every day (to commute, to go to the grocery, etc.) are likely to be pristine. I will make sure of it. The roads I rarely see will be dealt with on their regular schedule, and maybe not at all if time runs out. However, if paving decisions were made by a large group of citizens, each of whom had the ability to just go out and pave the road themselves if they felt like it, the city would be much more paved. The same allegory works for closed versus open source. Consider if LinkedIn had left Kafka as closed source. If we looked at the code base, we would likely still find a pretty good message bus, but it would be optimized for the nuances of LinkedIn's system architecture and proclivities in passing messages. Once it became open source, developers from Facebook and Google and Startup #1 and Manufacturing Firm #2 and so on all jumped in to solve problems. They achieved consensus on how those problems should be solved and pushed forward. Two points on this allegory that are relevant to Andreessen's argument: everyone in the infrastructure committee had skin in the game (they wanted problems solved) and they had the capacity to go deal with the problems themselves. Andreessen argues we have a lot of the first already but we don't have nearly as much of the second as we need.