Schools of Cohesionexploring the crosswise policy biases we learn from open software
There are two great schools of thought in open software policy. Based on early, formative, personal experience, participants tend to lean toward one or the other. All sharp, experienced minds recognize both, but everyone tends to favor their native mode in judgment calls.
Gravity Well
Early exposure to large, monolithic, centralized or hierarchical projects with millions of lines of code, like GCC and the Linux kernel, teaches that collaboration builds a breakaway project and identity that sucks in substitutes and forks.
The breakaway winner becomes a hotly contested singleton. That concentration of value and opportunity necessitates lots of structured governance. Participants learn to expect and tolerate the bureaucracy. They also learn to expect code that meets or exceeds the institutional standards to which they’re accustomed.
Velcro Field
Early exposure to highly modularized, small-component efforts coordinated only by interoperability standards, like GNU core or CPAN, teaches that collaboration builds a catalog that draws newcomers by meeting many small needs, such as by offering up prewritten libraries for specific functionality.
Rather than traveling in the orbit of a singular, definitive project, Velcro Field experiences is Brownian motion in a permissionless primordial soup. That experience conditions participants to tolerate a lot of thrash. It also hardens them to wide diversity in quality, with lots of one-off, throwaway noise to rummage through for high-quality signal.
Archetypes
These are seductive archetypes, highly prone to error. Nearly all Gravity Wells develop Velcro-like subsystems. For example, Linux kernel drivers. Conversely, nearly all Velcro Fields have Gravity Well-like constituents. For example, Babel in npm. There are no sharp lines.
But looking back, individually, we abstract the way that open software seduced us, brought us in, and developed us as programmers. The way we came up was right, and we long both to share that correctness with others, and to have it validated by them.
Intuitions
Copyleft as a tool, setting ideology aside, is ideologically neutral in the wild so far.
Copyleft correlates to Gravity Wells in popular perception, but only because GPL was effectively the default license at the time killer-app projects like GNU and Linux took off. Reality is trending relatively permissive, over time, with scale, though both copyleft and permissive continue to grow, in absolute terms.
Funding models, however, are bias-typed.
Gravity Well biases favor delayed release, open core, hosting, certification, and foundations. Velcro Field biases favor dual licensing, consulting, contracting, and loose consortia. Other models, like paid development, support, events, and merchandising remain largely neutral.
Worked Example
A Confession: My experience is broad, but all the most formative moments were decidedly Velcro. Those instincts are deeply imprinted. I’ve used this analysis to try to understand the differing biases of others. Having got somewhere with that, I turned the characterization around on my own biases, to see what I could reveal about them.
To test that analysis, I’d like to work a couple of examples, in the form of two controversial funding models: copyleft-based dual licensing, which I prefer to call public-private licensing, and copyleft core, or open core with a copyleft-licensed base project.
The crux of these models is the idea of an exception. If you come upon someone else’s code under a copyleft license, like GPL, you can’t build closed software with it without following its share-alike rule. But if you wrote the code and chose the license, you won’t be sued for not following your own rule for your own work. You can choose to sell exceptions to your own copyleft rule—that’s dual licensing—or keep it only to yourself, as a competitive advantage—that’s copyleft core. As the author of the software, you have those options, and others don’t. At least so long as you take licenses from contributors under more permissive terms, hire everyone who works on the project at one company, or remain the sole contributor.
I am a true believer and partisan guerrilla for copyleft core and especially dual licensing. Hence my commitment to License Zero. I’ll speak for my own tribe first.
From the Velcro Field point of view, copyleft exceptions, exclusive and for sale, are just an adoption trade-off. All else being equal, we expect copyleft licensed projects to see less adoption than permissively licensed projects.
Exceptions aren’t great, since by definition, they mean closed rather than open software is being made. But no project is ever worth that much, and no closed project ever costs that much. Churn ensures competition, especially permissive competition, unseats every category leader in turn, including copyleft projects from well financed developers.
I am far more interested in whether my projection of the Gravity Well point of view holds up:
From the Gravity Well point of view, copyleft exceptions are simply dumb, even for project-founding developers, because they reduce the chance of becoming breakaway winner. All else being equal, we expect more adoption of permissively licensed projects. If your project doesn’t win the adoption race, and become the breakaway winner, every other choice is for naught, when you get swallowed by the gravity of the more popular project.
Should you happen to emerge victorious despite leveraging exceptions, that asymmetry can only further destabilize inevitably contentious, high stakes governance drama. The more popular the project, the more its popularity amplifies the rub of just one party having the right to make or use exceptions.
Help
If you’ve reached the end of this post, and find yourself identifying with the Gravity Well point of view, I’d greatly appreciate a note. Does my attempt to read copyleft exceptions from that point of view check out? As usual, my e-mail and Twitter are open. Thanks!
Your thoughts and feedback are always welcome by e-mail.