7. Community-Created Software
Think Zen. The project belongs to no one and to everyone.1
Until the 1970s, being in the tech business meant selling hardware, including microchips, data storage, and computers. Then a contrarian idea2 popped into the head of a shrewd kid. What if software could be a good business? In fact, what if it could be a great business—even better than hardware? Compelled to test the theory, the guy abandoned plans for law school, dropped out of college, and founded Microsoft.
I’m talking about Bill Gates, of course. Gates recognized that operating systems for personal computers could accumulate immense power through the harnessing of network effects. He foresaw that consumers would flock to operating systems and software applications instead of the hardware underneath. Application developers would build for the most popular operating systems, not the best-selling machines. This would create a self-reinforcing platform-app feedback loop. Software would be king.
Incumbents had no idea what was about to hit them. In 1980, IBM agreed to license Microsoft’s early crown jewel,3 the DOS operating system, in a deal that allowed Microsoft to continue to sell the software to other manufacturers. IBM failed to appreciate its oversight. More PC makers were entering the fray, copying IBM’s designs, and turning computer hardware into a commodity. This was the context in which Microsoft flooded the zone, spreading its operating systems far and wide until they became the industry standard. For the next twenty years, software was the most lucrative business in technology.
But another turn of the tech cycle would arrive, and as Microsoft grew more powerful, a sect of programmer activists struck back by forming the open-source software movement. As Tim O’Reilly, the tech publishing magnate, described the situation in his 1998 blog post4 “Freeware: The Heart & Soul of the Internet,” “Despite all Microsoft’s efforts to convince the world that the capital city of the Internet is in Redmond, and Netscape’s rival claims that it’s in Mountain View, the real headquarters exist only in cyberspace, in a worldwide, distributed community of developers who build on each other’s work by sharing not only ideas but the source code that implements those ideas.”
The open-source movement would put downward pricing pressure on software. In particular, the movement would commoditize server-side software, the kind that runs in data centers—a shift that echoed the hardware-to-software upheaval Microsoft once led. Tech industry players responded by “moving up the stack,” focusing on services instead of software. A new buzzword—“software as a service,” or SaaS—soon took root.
Fast-forward to today and most tech companies are in the services business. They charge either for services or for advertising connected to services. Google, Meta, Apple, and Amazon are all in the services business. Tellingly, even Microsoft, the pioneer of the software model, now considers itself a services company.
In the 2000s, at the beginning of the read-write era, it seemed as if the shift to services might lead to greater openness and interoperability across the internet. APIs, which connect internet services, were all the rage. Developers were creating services that remixed, modified, and reused other services into so-called mash-ups. YouTube gained popularity as a video widget to be embedded in blogs and other websites. Early delivery and ride-sharing apps hooked into Google Maps. Blogs and social networks bolted on commenting apps like Disqus and showcased third-party photos from sites like Flickr. They did this all for free; no one asked for permission.
At the time, it seemed as if a spirit of interoperability5 might suffuse the internet forever. In a retrospective for The Atlantic in 2017, the journalist Alexis Madrigal captures the decade-earlier optimism:
In 2007, the web people were triumphant. Sure, the dot-com boom had busted, but empires were being built out of the remnant swivel chairs and fiber optic cables and unemployed developers. Web 2.0 was not just a temporal description, but an ethos. The web would be open. A myriad of services would be built, communicating through APIs, to provide the overall internet experience.
And then, in another turn of events, the iPhone debuted. The ground suddenly shifted with the rise of smartphones.6 Protocol networks lost their balance, and corporate networks gained the surer footing, as Madrigal relates:
As that world-historical explosion began, a platform war came with it. The Open Web lost out quickly and decisively. By 2013, Americans spent about as much of their time on their phones looking at Facebook as they did the whole rest of the open web.
Blame the cruel logic of corporate extraction for what went wrong. As we’ve covered, the attract-extract cycle arises, inescapably, from an inherent tension in the design of corporate networks. The path follows the tech adoption S-curve. After a certain point, what’s good for a network owner conflicts with what’s best for network participants. In the early 2010s, mobile phones catalyzed a platform shift that accelerated the rise of corporate networks. As corporate networks gained ground, their optimal business strategy switched from attract to extract. With so many corporate networks switching to extract mode at once, power rapidly concentrated. APIs withered, interoperability fizzled, and the open internet got packed away into silos.
Modding, Remixing, and Open Source
Interoperability still persists in some categories of internet services. It thrives, notably, in video games where users create “mods”: game remixes or DIY components that can consist of altered art, modified gameplay, randomized game elements, add-ons such as new weapons or tools, and other custom bits.
Modding has been around since the beginning of PC gaming in the 1980s. At the time, gamers were mostly programmers who liked to experiment with software—hackers, in other words. Game studios knew what their audiences craved and so embraced modding. id Software, maker of the hit first-person shooter game Doom, was perhaps the most famous example.7 In 1994, one Doom player went so far as to re-create inside the game the 1986 sci-fi movie Aliens, Xenomorph-grappling exoskeleton suit and all. The 1996 sequel to Doom, Quake, even included its own programming language to make modding easier.
Today, modding is mainstream in gaming on PCs, where the platforms tend to be more open than they are on consoles and mobile phones. The popular PC game store Steam8 has hundreds of millions of pieces of user-generated game mods and components. It’s not uncommon for hit games to begin as mods of other games,9 including League of Legends (an adaptation of a Warcraft III mod called Defense of the Ancients) and Counter-Strike (a mod of the first-person shooter game Half-Life). Most of the content in the popular game Roblox is generated by users who create and remix existing game content. Making and remaking things is a big part of the game’s appeal.
Many video games are playgrounds for modding, but the area where the activity has found the greatest success is open-source software. Contributors typically work as volunteers, often on a part-time basis. They’re loosely organized and scattered around the world, and they depend on remote collaboration and knowledge sharing. Anyone can reuse open-source code in their own software, free of charge, with minimal restrictions.
Open source began as a radical idea,10 part of a fringe political movement11 in the 1980s. Proponents opposed the idea of copyrighting code on ideological grounds, believing that anyone should be allowed to tinker with software as they please. The campaign became a more pragmatic technology movement in the 1990s, yet still remained mostly at the edges of the software industry. It wasn’t until the 2000s that open source started going mainstream, particularly following the rise of the now ubiquitous open-source operating system Linux.
Given open-source software’s humble origins, it might surprise you to learn that most software running in production around the world today is open source. When your phone connects to the internet, it talks to computers in data centers, most of which are running open-source software like Linux. Android phones run mostly open-source software, including Linux. Most next-generation devices like self-driving cars, drones, and VR headsets run Linux and other open-source code. (iPhones and Macs run a mix of open-source and proprietary software from Apple.)
How did open source take the world by storm? One of the main reasons the movement has been so successful is a feature of software known as composability.
Composability: Software as Lego Bricks
Composability refers to a property of software that allows smaller pieces to be assembled into larger compositions. Composability depends on interoperability, but it takes the idea further by combining systems the way one builds using Lego bricks, as mentioned in “Tokens.” Composing software is like making music or writing, where larger creations, like symphonies or novels, are composed of smaller parts, like strings of notes or words.
Composability is so central to software that most computers assume all code is composable by default. Computers enact this assumption via a two-step process when preparing to run code. First, a program called a compiler converts the software’s source code, written in a human-readable language, into a lower-level, machine-readable language. Then all the other composable bits of code referenced by the software are brought in by a program called a linker. The linker links—or composes—all the pieces of code into one big executable file. And so software is an art of composition.
Composability unlocks the best humanity has to offer. Almost every project on GitHub, an online code repository for open-source developers, contains references to other open-source projects hosted there. For most projects, the bulk of their code is new compositions of other code. The collective set of code repositories make up a branching tree of billions of interconnected ideas created by millions of people, most of whom have never met, yet who work collaboratively to advance the global store of knowledge. (And if you need more proof of open source’s mainstream arrival:12 GitHub is now owned, ironically, by the movement’s formerly biggest adversary, Microsoft.)
The power of composability is that once a piece of software is written, it never needs to be written again. If you browse GitHub, you’ll see free open-source code for almost anything you might want to do, from math formulas to website development to video game graphics. The code can simply be copied and reused as a component in other software. Then the other software can be copied and reused, ad infinitum. When this happens inside a company, it makes the company more productive. When this happens in open-source repositories, it speeds up software development everywhere.
Albert Einstein once purportedly said13 that compounding interest is the eighth wonder of the world. Whether or not Einstein actually said this (he probably didn’t),14 the wisdom holds true. Principal generates interest, which grows the principal, yields more interest, and piles up ever greater returns. The remarkable effects of compound growth are not limited to finance. Many things in the world that grow exponentially do so because of underlying compounding processes. For instance, exponential improvements in computing hardware are described by Moore’s law, as discussed in “Blockchains.” Composability is software’s version of compounding interest.
The reason composability is so powerful is that it combines multiple forces, each of which is powerful on its own:
- ▪ Encapsulation. One person can create a component and another person can use it, without understanding the details of how it’s made. This allows a software code base to grow quickly while the complexity, and likelihood for errors, grows much more slowly.
- ▪ Reusability. Every component needs to be created only once. As soon as something like a game element or open-source software component is created, it can be reused over and over without needing anyone’s permission. It becomes a building block, forever. When this occurs in permanent repositories on the open internet, collective software development advances through the contributions of a global hive mind.
- ▪ The wisdom of crowds. Recall Bill Joy’s quip that no matter how smart you are or how many smart people work for you, most of the smartest people work somewhere else. Reusing software means you can tap the intelligence of all those other people. There are tens of millions of smart developers with varied areas of expertise. Composability lets you absorb that expertise as much as you like.
For all its power, software composability hasn’t yet reached its full potential. It has been mostly limited to static code sitting in repositories as opposed to services in which code is live and running. The reason is that computation costs money. The contributor model that sustains open-source software—namely, reliance on charitable donations and ad hoc volunteers—doesn’t work so well for open-source services. Developers can lend time writing software, but they need financial resources to host and run the software. What’s missing is a business model that provides ongoing funding to pay for bandwidth, servers, energy, and other costs.
Composability for software services stalled out when corporate networks stopped interoperating. You can still find APIs for Big Tech corporate networks like YouTube, Facebook, and Twitter, but these APIs have restrictive rules and limited features. The providers decide what information they send, to whom, and on what terms. In the switch from attract to extract mode, corporate networks tightened their grip and left third-party builders in the lurch. Outside developers learned not to depend on them.
It’s worth noting there are still popular APIs in the business-to-business enterprise software space. Successful API providers include Stripe for payments and Twilio for communications. These APIs hide complex code behind simple interfaces, so they offer one benefit of composability, encapsulation. But they miss out on the other two benefits. The code powering the APIs is mostly closed source, which means it neither benefits from crowdsourced wisdom nor contributes back to the global knowledge base of coders everywhere. Moreover, these APIs can be used only with permission, and their providers can change the fees and rules at will. Permissioned APIs are useful in corporate contexts, but they don’t advance the vision of an internet built from open and remixable services.
Ideally, anyone building on other services and APIs will receive strong commitments that the services not only are open but will remain open, indefinitely, so they can be depended on. You can’t get guarantees of openness unless services are financially independent.
Where corporate networks failed, blockchains provide a solution. Blockchain networks make strong commitments that the services they offer will stay remixable, without needing anyone’s permission, in perpetuity. They do this in two ways. First, they provide strong, software-encoded assurances that their prices and access rules won’t change. Once the initial development team behind a blockchain network deploys its code, the services they push live are either fully autonomous or, in some network designs, amendable only by a community vote. The platform is dependable.
Second, blockchain networks fund hosting expenses through sustainable financial models that use tokens. Ethereum has tens of thousands of validators, or network-hosting servers, spread around the world. The network itself covers its own hosting costs—servers, bandwidth, energy—by distributing token rewards to validators. So long as there is demand for the Ethereum network, and users and applications pay transaction fees to use it, the validators get paid for the hosting services they provide. So the ground to build on isn’t just solid and stable; it’s rich in renewable resources.
The Cathedral and the Bazaar
Composability is a time-tested force that demonstrates its power again and again, most strikingly with the success of open-source software. Yet the vision for an open internet built from composable services has fallen short because corporate networks have always pulled back. As corporate networks grow, their interests shift away from being open to being closed. It’s naïve to count on a company not to be evil just because its motto is “Don’t be evil.” Companies will generally do whatever it takes to maximize profits. If they don’t, they won’t last long as they’ll fall behind other companies that do.
Blockchain networks turn “Don’t be evil” into “Can’t be evil.” Their architecture provides strong guarantees that their data and code will forever remain open and remixable.
The debate between the monolithic design of corporate networks and the composability-friendly design of blockchain networks mirrors a similar debate in the 1990s over the design of operating systems. In his famous 1999 essay, “The Cathedral and the Bazaar,” the programmer and open-source software advocate Eric Raymond contrasts two models of software development.15 In the first model, popularized by closed-source companies like Microsoft, software is “built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation.” In the second model, popularized by open-source projects like Linux, the community seems “to resemble a great babbling bazaar of differing agendas and approaches,” and the guiding philosophy is “release early and often, delegate everything you can, be open to the point of promiscuity.”
Raymond favored the promiscuity of the bazaar to the isolation of the cathedral. In an open-source community, “every problem will be transparent to someone,” and the crowd can work together to outperform centralized competitors:
The Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility which in the process produces a self-correcting spontaneous order more elaborate and efficient than any amount of central planning could have achieved.
Since the advent of computer programming almost eighty years ago, the pendulum has swung back and forth between these two modes of software development. Corporate networks are today’s cathedrals, and blockchain networks are the bazaars. Blockchain networks bring the power of software reuse and remixes to a modern form that can rival corporate networks. The networks of the future can be like great cities, built through the creative collaborations of millions of people with diverse skills and interests who share resources and work together, brick by brick, toward common goals.