This is an embarrassing confession when I think back on how little I knew and how much I thought I knew. At the height of the dot-com/Linux boom, maybe 1999, picture a restaurant in Palo Alto, one of the favored business dinner, super expensive, not-so-great Italian ones they have in the Valley. A group of men (the diversity of Silicon Valley) is discussing the possible acquisition of our infant business by a new start up that already had serious VC funding.
I was basically a technologist/academic and didn’t know, or even have a guess about the extent of my business ignorance. Everyone else at the table knew though. There was a lot of heady talk of big money and the usual Silicon Valley bombast about changing the world to go with the multiple bottles of wine and at some point, for no good reason that I can imagine now, I blurted out “I’m not primarily in it for the money“. Maybe it was just nerves. The primary VC looked at me, over the table, with an expression of great, vast, immeasurable, satisfaction and said something to the effect of, “Don’t worry, I will take care of the money” And I suddenly understood.
The Heartbleed bug was caused by a business model error. When we were in the real-time software business, our best customer was an old line manufacturing business that wanted to make sure before they qualified us as a vendor that we were making a profit from selling software to them. They did not want to depend on complex engineering products made by a company that would be unable to afford quality control process or that would not have a motivation to use quality control. This level of clarity is not all that common and the complexity of open source business models confuses people. Linux is a generally reliable system because RedHat is able to monetize the core business by virtue of being the “standard”, because a huge user base acts as first line testers, and because multiple other companies have clear business requirements that push them to invest engineering resources in the system. For example, the makers of network devices usually have professional engineering teams building and testing their drivers, so they can sell hardware. This testing, by necessity, also tests the network stack. But if you are not familiar with Linux development, and don’t see all the commits from people with email addresses in major technology companies, you might get the impression that this free software appears magically. That network of motivations is much weaker for a special purpose component like SSL code and the quality requirement is also higher. But the same problem can arise even without open source – where pricing for proprietary components is too low. The market involves multiple niches where open source economics or industry pricing assumptions cannot produce the required level of component engineering quality. Discovering and navigating those gaps may be the difference between success and failure.
Also posted on Linkedin and FSMLabs