Dennis Ritchie (standing) and Ken Thompson with a PDP-11, circa 1972
(Source: Dennis Ritchie homepage)
Years ago, I was shocked to discover a young developer friend had never heard of BEA, JBoss, or app servers at all. Growing up with virtual machines and distributed systems, he couldn’t be bothered to look back 10 years to understand how we reached this “cloudy” present. But understanding the basics of our computing past helps us appreciate our present.
Similarly, many developers are so immersed in open source that they have no conception of how we got here or what made it possible. In overlooking this past, they may misunderstand how best to invent the future, as articles from open-source luminaries Eric Raymond and Tim O’Reilly indicate.
Learning from UNIX
As Raymond posits, UNIX was important not so much because of its invention of the first non-assembler language — but rather, by “creat[ing] the modern idea of software systems that are cleanly layered and built from replaceable parts, and of re-targetable development tools.”
Otherwise stated, the UNIX hackers gave us the concept of modular source code, the principle upon which Linux, the web, and so much that we take for granted today is built.
Presented with a choice between open software or modular systems, the latter takes clear precedence. After all, in the early days of computing, “Not only was portability across architectures a near-impossible dream, you often couldn’t port between instances of the same machine without serious effort.” Software was hard-coded to the hardware on which it was intended to run. UNIX changed all that:
“Without the UNIX-spawned framework of concepts and technologies, having source code simply didn’t help very much. This is hard for younger hackers to realize, because they have no experience of the software world before retargetable compilers and code portability became relatively common.”
This isn’t really a matter of history, however. It introduces a fundamental principle for building successful ecosystems.
The architecture of open
As Tim O’Reilly comments, “The reason open source culture grew from Unix was not political, it was architectural.” In other words, rather than get caught up in a somewhat pointless declarations of rights, we should instead focus on more fruitful architectures of openness.
Speaking of one particular industry trend, O’Reilly goes on to argue:
“Will the Internet of Things be proprietary or open? It seems to me that the best way to ensure that the answer to that question is ‘open’ is not to wave banners saying ‘open data’ or to try to create open versions of successful proprietary products but to work assiduously to find ways in which open data and cooperating systems create more value than closed, proprietary data.”
This is absolutely correct. Too often we make a fetish of openness for openess’ sake. Open-source software is not interesting just because it’s open. It’s interesting because it’s portable, as Raymond said, or interoperable, as O’Reilly extends his argument.
In other words, it’s not the source that matters — it’s the ability of that source to move between systems that counts.
Opening up the future
This is why I’m bullish on Google long term. Yes, Android is open source — and yes, that sort of matters. But the real value of Google is how much of its software runs on others’ platforms.
Dismissing King Digital Entertainment (maker of the popular Candy Crush game) as a “one-hit wonder,” Michael Cusumano, a professor at the M.I.T. Sloan School of Management, argues that “Typically, companies will have…one big product, and…unless they manage to become the center of an ecosystem, over time they tend to weaken and disappear.”
To thrive, products must foster ecosystems around them.
By definition, a company or product can’t be the center of an ecosystem that it controls top-to-bottom. Ecosystems grow up around products and companies that foster third-party innovation that interoperates with a core. The company that must control everything is like early software development: heavily proprietary software hard-coded to a specific type of hardware, or even a specific computer.
Apple is like this in some ways: it likes to control the overall experience for consumers, from hardware to software to cloud services. But Apple has also opened up to a considerable degree, fostering a vibrant developer platform on its iOS devices.
Still, long term I’d bet on Google, because Google doesn’t hard-code its software to perform solely or even to perform better on its own hardware/software platforms.
Those developers looking to build a successful product have much to learn from both Apple and Google, of course. But the key lesson is that which UNIX taught us so long ago: open-source code is nice, but portability of code is critical. Otherwise stated, those developers who foster open, permeable ecosystems that encourage modular design and interoperable systems have a far better chance of succeeding than those that insist upon end-to-end control.
Just ask the original UNIX hackers.