The narrative fallacy is that past events prefigure the future. It is especially common in biographies, where the subject’s early life is reduced down to a collection of events that suggest that their future path was obvious, if you only knew how to look. It ignores all the other people who did almost the same thing, and ended up somewhere else entirely.
The term “open source” was officially adopted in 1998, fifteen years after Richard Stallman began the “free software” movement, which itself was built upon a long-standing tradition of open collaboration in the academic programming community.
Eric Raymond’s The Cathedral and the Bazaar was published a year earlier, and shaped the open source narrative. It guided the reader through the lifecycle of an open source project, which first “[scratches] a developer’s personal itch”, and then accretes contributors until it becomes world-class software. This was undeniably possible; the Linux kernel existed (as did Raymond’s own fetchmail project, which he never failed to mention in the same breath).
For Raymond, however, this progression wasn’t just possible; it was the natural, inexorable outcome. All the eyes upon an open source project would smooth away the rough edges, like stones beneath a river. Even at the beginning, with Torvald’s first post about his “hobby” operating system, the seeds of greatness were there, if you only knew how to look.
Manifest Destiny was the belief that America had a duty to expand its boundaries, spreading its ideals. The term was coined in 1845, forty years after the Louisiana Purchase and only five years before California was granted statehood, by a columnist living in New York.
According to its believers, families uprooted their lives and traveled thousands of miles because democracy abhors a vacuum, and their hardship was small when weighed against the growing reach of America’s great experiment. The first settlers on the banks of the Mississippi not only prefigured the city of St Louis, they pined for it. They knew how to look.
These were simplistic narratives, written at the periphery, layered atop the complex and diverse forces that drove people to explore. Both suffered from an obvious flaw: many pioneers didn’t welcome civilization once it caught up.
Consider this excerpt from John Mason Peck’s A New Guide For Emigrants to the West, written almost ten years before “manifest destiny” was invented:
First comes the pioneer, who depends for the subsistence of his family chiefly upon the natural growth of vegetation, called the “range,” and the proceeds of hunting. His implements of agriculture are rude [and] chiefly of his own make…. He builds his cabin, gathers around him a few other families of similar tastes and habits, and occupies till the range is somewhat subdued, and hunting a little precarious, or, which is more frequently the case, till the neighbors crowd around, roads, bridges, and fields annoy him, and he lacks elbow room. The preëmption law enables him to dispose of his cabin and cornfield to the next class of emigrants; and, to employ his own figures, he “breaks for the high timber,” “clears out for the New Purchase,” or migrates to Arkansas or Texas, to work the same process over…. [T]he real Eldorado is still farther on.
A similar pattern can be seen in the open source community. There has been, for instance, a consistent migratory pattern from Ruby to node.js to Go, Rust, and Elixir. At first, each community is defined by its potential. But as that potential is realized, the community begins to be defined by its compromises. That change is felt most keenly by the people who were there first, who remember what it was like when anything seemed possible. They feel fenced in and so they move on, in search of their golden city.
This isn’t the behavior of people who want to collaborate towards world-class software. This is the behavior of people who want ownership. They want to build something lasting, something which holds its shape even as the world around it changes. They want to force the world to conform to their sensibilities, rather than the other way round.
This won’t be surprising to anyone paying even a little attention to the open source ecosystem. The sheer profusion of frontend frameworks, each trying to differentiate itself in the least possible kilobytes of gzipped Javascript, makes this an obvious conclusion. But the framework for our discussions about open source, introduced by Eric Raymond and unchanged in the ensuing decades, barely acknowledges this reality. We tell ourselves we live in a geocentric universe, even as we use navigational charts that tell us something else entirely.
A more charitable interpretation, perhaps, is that “open source” and “manifest destiny” don’t speak to the motivations of anyone involved, just the emergent result of their actions. Whatever the reasons, the Linux kernel and St Louis exist, that much cannot be denied. But if we use this interpretation, we acknowledge that these narratives have no predictive power. They are, at best, existence proofs that such a thing can be created under these circumstances.
Indeed, any model constructed using the narrative fallacy lacks predictive power. A similar criticism can, and has, been leveled at Christensen’s theory of “innovative disruption”. They provide a neat narrative arc for the past few decades, and continually point to their ability to explain the past even as they’re confounded by the future.
This disconnect means that we have a very limited vocabulary for discussing the goals of an open source project. According to the mythos of open source, a log cabin in the wilderness is just a city that suffers from poor stewardship. If the cabin’s creator had only engaged the community, we’re told, they too could be administrating a huge, vibrant city.
Of course, an administrator is just that. Very little real ownership is possible; they have to balance many needs, often sublimating their own. This change occurs slowly, one pull request at a time. Each outside contribution cedes a little ownership to someone else, giving them more reason to contribute to the project in the future. The value of this is obvious: the capabilities of the project will grow, and its direction will represent a more diverse set of needs. It will, in short, become more useful software.
The cost of this, however, is more subtle. For some people, creating widely used software is highly rewarding, and the administrative responsibilities it introduces are a small price to pay. For others, especially those who chase the frontiers of open source, loss of ownership leads to a loss of interest. By letting a project grow too large, they effectively chase themselves away.
As potential users of an open source project, we want to know if our needs matter to the maintainer. As potential contributors to an open source project, we want to know if our changes will be welcomed, accepted resentfully, or just ignored. Unfortunately, since everyone pays lip service to our idealized vision of what open source should be, it’s impossible to tell. Creators should be able to be honest, to themselves and others, about what really motivates them.
Another problem with the open source mythos is that we’re told communities just happen. If we write it, they will come. But left alone, a community will be shaped by whoever shows up first, and most of the early adopters will be people looking to leave their mark. Their chief values will be autonomy and productivity, and the culture they create will reflect that.
Typically, this results in a small inner circle, often sharing the same physical location. Conversations will be informal, unrecorded, and highly productive. Decisions will have a clear rationale to everyone within the circle, and seem arbitrary to everyone else. This circle is typically composed of the people who showed up first. Anyone showing up too late, trying to claim their own sliver of ownership, will be rebuffed without any clear recourse. These latecomers will typically move on, in search of something less populated.
This can be a very effective way to build software, until the inner circle starts to move on. At that point, the informal processes have to be formalized. Disagreements will have to be settled using something other than strength of personality. Most projects never achieve this, and simply fall into disuse.
If we hope to build a project with a growing community and renewable leadership, we can’t allow a community to simply happen. It has to be planned.
The need to create, and own, something lasting is part of every creative endeavor. It’s neither bad nor surprising to find it in the open source community. It is, however, harmful to pretend it doesn’t exist.
If we don’t change how we talk about open source, creators will continue to burn themselves out chasing an ideal they don’t really care about. New projects will continue to be excoriated for lacking novelty. We will continue to build the same ad hoc culture atop every greenfield we find.
We should create a shared vocabulary for how projects will handle contributions, scaling from “no, thank you” to ZeroMQ’s optimistic merging strategy. We should give the techniques for deliberately building a community as much critical attention as our techniques for building software.
Most importantly, we should understand that when someone shares their source code, they didn’t necessarily make it for us.
This essay was originally published on Medium.