Outer Sourceopen software by closed methods
Open Source suggests that we can separate Free Software method and Free Software quality from Free Software ethos, by leading with method and quality, and going light on ethos in its pitch. That suggestion contradicts Free Software’s thesis that method and quality flow out of the shared community ethos, and that ethos comes first, anyway. So Open Source threatens Free Software rhetorically. And tells us so.
Inner Source delivers on the threat, transposing Free Software method into closed environments to produce closed software of high quality. That transposition rejects the Free Software thesis that Free Software quality flows from Free Software ethos. It shows Free Software methods in action alone. Moreover, the “Inner” in “Inner Source” bespeaks a closed environment, a barrier between “Inner” and “Outer”, impermeable to Software Freedom and unpierced by copyleft. Inner Source frees those within, and subjugates those without, trampling the ethical proposition that all software should be Free.
Merely suggesting the separability of method, quality, and ethos that Inner Source stands for allows Open Source proponents to maintain that Open Source and Free Software mean the same thing. They describe Open Source statically, as a mere rebranding of Free Software, a marketing reboot, without acknowledging the directionality inherent in their effort. Activists among them hold out hope that exposure to Free Software method and Free Software quality will guide newcomers back to the Software Freedom ethos, without loud preaching.
Inner Source contradicts that theory of Software Freedom ministry. If Free Software method in a closed environment can produce Free Software quality on its own, even to a lesser extent than in open community, then Free Software ethos loses any essential part to play when quality drives decision-making. The leap from conviction in software quality to conviction in Free Software ethos can happen only spontaneously, by reading the right sermons to those already predisposed to believe.
Short on options, Software Freedom activists succumb to the same limited approach. The Free Software Foundation maintains developer tools as useful to non-Free Software developers as Free Software developers, despite preaching exclusion via copyleft. Software Freedom activists compromise their principles, and make exceptions to their copyleft licenses, to preserve the popularity of those projects as soap boxes. In doing so, Free Software activists themselves lead with method and quality, instead of ethos, and suggest the same challenge to their own core thesis as Open and Inner Source.
Addicts come to twelve-step programs for sobriety, not religion. But the higher power is step two. Developers come to Open Source for software quality and method. But the Software Freedom lede is buried, and not essential to the program. There’s no necessary step from belief that software should be good to belief that software should be Free.
Many a software developer’s interest in method and quality starts and ends with their desire to build and sell non-Free Software for money. That motive directly contradicts the ethos Software Freedom activists preach: non-Free Software is evil. For commercially-motivated developers, converting to Software Freedom activism through Free Software method makes about as much sense as getting sober by turning will and life over to Bacchus.
Splitting method and quality from ethos via Inner Source leaves a yawning conceptual gap. Inner Source, using open software development methods to make closed software, implies Outer Source, using closed software development methods to make open software. The idea that commerce-evolved, institutional, “corporate” software development methods can produce high quality, publicly licensed software under generous terms lingers latent in developer consciousness, just as Inner Source did.
Symptomatically, lasting attempts to demarcate Free Software and Open Source focus entirely on rights granted for software once it’s produced, ignoring production method. What is Free Software?, the Debian Free Software Guidelines, and the Open Source Definition assess not what method produced a given work of software, but whether others got source source and a sufficiently generous license. No organization promulgating a definition requires that contributors welcome outside patches, solicit outside bug reports, publish their revision-control history, or maintain any public governance structure. Development method and development tooling don’t register.
Every developer holds process opinions. Some development methodologies surpass language communities in their tribalism. But no self-identifying movement could coalesce by inviting development creeds to clash for title of the One True Methodology. Only by reducing the scope of agreement to a low, common denominator—source availability and license terms—could anyone pretend to any stable consensus.
Commentators still delight in Linux’ semi-anarchic, piece-part, Brownian motion mode of evolution. Contrast with waterfall-model planning, corporate hierarchy, and public capital—emblematically, Microsoft Windows—makes high drama, as drama about software goes. Naturally, the anti-establishment narrative elided a great many uninteresting facts. Facts, for example, about the lone-hacker origins of many components of distributed projects, like the GNU core. Facts about the development of banner Free Software projects by corporate teams, largely along “traditional” industry development lines, before widespread Internet penetration and process standardization on services like Freshmeat, SourceForge, and now GitHub. Substantial parts of the Free Software bequest have always come about as non-Free Software did before them.
We see Outer Source assert itself mostly in quiet corners. My favorite tidbit comes from SQLite:
Open-Source, not Open-Contribution
SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons.
All of the code in SQLite is original, having been written specifically for use by SQLite. No code has been copied from unknown sources on the internet.
The exception to Outer Source quietude is Outer Source licenses, which always bring a storm. Many companies give away software developed primarily in-house: because they hire developers and put them to work on the project, because they habitually hire any outside developers who demonstrate interest, or both. When those companies propose new licenses, usually strong copyleft licenses, to protect themselves strategically and financially—Sleepycat, Q, RPL, SSPL—they face a few classes of criticism.
I recently described one such class. Software Freedom activists, prioritizing ethos, criticize new strong-copyleft licenses that they see as overreaching, as by requiring contribution of private changes. They also criticize strong-copyleft licenses that apply copyleft’s requirements selectively, allowing specific uses that deprive users downstream of Software Freedom. They criticize giving different users different rights.
It’s easy to recriminate, to blame the Free Software Foundation for failing to maintain strong-copyleft licenses with strong dual-use potential for business, when it desperately needs allies. But the wiser, constructive approach emphasizes the opportunity to puruse that project together. The FSF facilitated the Affero license for a company, Affero, and it was another private company, not the FSF, that took the new license across the aisle for approval.
Software Freedom ethos won’t align with every business plan. But sharing license tools in common brings Software Freedom the benefit of company resources, and companies the benefit of activist experience and support. When that coalition breaks down, both activists and companies find themselves beset on both sides by BSD school hackers and incumbent firms, united as ever in displeasure with copyleft and its complexities.
Outer Source developers also face criticism from process partisans. New licenses from Outer Source companies facilitate, and therefore threaten to promote, Outer Source development methods, at the presumed zero-sum expense of community-driven mindshare. For example, strong-copyleft licenses that facilitate dual-licensing business models catch heat, not just from those who dislike copyleft in general, but from those who criticize contributor license agreements and other policies that place Outer Source developers in privileged positions. Even when the only effective privilege is selling copyleft exceptions and maintaining closed forks, extensions, applications, and services.
The strong retort to process-based criticism emphasizes the common-denominator nature of Free Software and Open Source, as well as the history of diversity in its development methods. As Rich Hickey put it most cogently, late last year:
Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of ‘community-driven-development’ are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.
Rich Hickey’s best-known project, the Clojure programming language, requires a contributor license agreement, based on Oracle’s form, but tweaked to consolidate intellectual property rights with Rich personally, rather than to a corporation. Clojure receives outside contributors, but Rich’s company, Cognitect, pays the developers who drive development.
Opinions vary. Personally, I’ve heard Clojure held out as a paragon of design and quality as often as any other active project. Clojure needn’t apologize for its product, or for its process. Which I take as the larger point of Rich’s piece.
I have my own opinions on process. I have my own taste in software design. But my role as lawyer exposes me to far more projects than I could ever contribute to by coding. As I constantly remind myself, no one sees the whole of free or open software. But I have seen enough to appreciate its diversity, and expect an exception to every tempting rule. When it comes to my clients, I don’t judge, constrain, or prescribe. I listen, accommodate, and advise.
Outer Source has nothing to be ashamed of, and more to be proud of than it knows. Its methods can and do produce quality software. Generous public licenses apply to that software, as well as to any other. Among those licenses, some happen to protect both team within and Software Freedom without.
Let there be Outer Source.
Special thanks to Benjamin Mako Hill for the diagram at the top.
Your thoughts and feedback are always welcome by e-mail.