Stochastic Confidence and the Open Source Network Effect

What has powered open source to become part of almost all software and drive nearly €100 bn of GDP in Europe? Reuse, yes. But that was always possible. Collaboration, definitely. But repositories existed for years before open source was coined in 1998. The software freedom philosophy. Absolutely, but that went 15 years without triggering a software revolution. I suggest it’s something less measurable and observable — developer confidence — and that the effects involved are stochastic, not deterministic.

A bird soars above the greyness over water in the Everglades with the water, mist and sky creating bands of greyness as if devising a scale

No Confidence

As a result of the automatic global ownership of copyright by the authors of any software, no developer — even if supplied with the source code — may make much use of software written by others without being granted permission to do so. There are basically two ways such permission is granted:

  • With a 1:1 contract — usually connected to a license fee or ongoing subscription fee but sometimes formed through agreement with the terms of an End User License Agreement (EULA).
  • Through the terms of a general license available to the public at large, contingent on acceptance of the conditions in the license but without executing a contract.

Gaining the confidence to proceed in both cases involves studying the terms, understanding what is and is not permitted and understanding what duties must be performed. For most people, gaining confidence to proceed involves obtaining legal advice, which usually means paying for it. For most of us, that means not reaching a position of confidence.

It’s Software Freedom All The Way Down

In large part this is addressed by the philosophy of Software Freedom that evolved from Richard Stallman’s early experiences. Software Freedom ensures all uses are expressly permitted (with conditions) by having the author(s) grant permission in advance, with the goal of every recipient of the software being self-sovereign. But the philosophy needs a vehicle to become real.

The software license does that. It leverages the need for a copyright license to create an opportunity to deliver all the rights necessary to “enjoy” the software. By enjoy, I mean the rights to use, improve, share and monetise the software, for any purpose, in any place and in any combination, subset or superset. All necessary rights are assumed to be granted unless stated otherwise.

Uncertain About Freedoms

These freedoms definitely provided a foundation for developers to have confidence they had code they could reuse and collaborate over. But the freedoms were only definitely available under the GPL family of licenses – any others needed an opinion from a gatekeeper who worked opaquely. Using only the GPL family was controversial because of the “copyleft” provisions that seemed to some who had been working in the open for decades to force adherence to an ideology with which they did not identify. So people tried their hand at writing other licenses.

In the late 1990s, more and more products were claiming they were using “free software licenses” but there was no way to be sure they objectively delivered software freedom in your own circumstances, at least until the FSF had commented. Even then legal advice would likely be necessary given the monochrome view FSF tended to have. Worse, the “free software” term was being used casually in support of proprietary models accompanied by custom licenses, so the risks were not imaginary.

Grey Areas

What drove creation of new licenses? Every software project and its anticipated usage has its own context, so even the simplest licenses work in different ways for different people. In particular, some users prefer to take software that has been freely offered to them and use it as the basis of software that is offered restrictively to others, perhaps even avoiding attributing their work to its original authors. But away from that extreme, there are many dimensions to consider and, wise or not, there’s a license embodying each of them.

Having many licenses may be a source of choice and diversity, but in every case the key question a developer will ask is “can I use that code?” There are licenses that are highly burdensome to comply with, licenses that use copyleft in a way that is incompatible with the way it’s used by other licenses, licenses that lack clear patent grants, and many more. Which licenses deliver software freedom under conditions you can accept?

Not everyone has a lawyer (or easy access to a software freedom guru), and of course even people with a lawyer may not really want to ask every single time they see a new license. So, lacking confidence to proceed, developers avoid new licenses. This lack of developer confidence had a chilling effect and held back a wave of open collaborative development which in turn meant software freedom remained the privilege of an elite rather than a benefit for all.

Stochastic Confidence

Open source succeeded not by making things black-and-white but by clearing enough shades of grey to make things feel OK to the majority. It created stochastic confidence – enough confidence they had the freedom to reuse, collaborate and innovate for a critical mass of developers to gather and do so.

Collaborative evaluation against the Open Source Definition (OSD) was sufficient to give many people confidence there was a low probability of further permission-seeking. Crystalised and recorded by OSI, it created sufficient developer confidence to re-use code downstream from elsewhere. Yes, there were still uncertainties – but not enough to poison the network effect. OSI thus catalysed a network effect of collaboration and reuse by creating an open mechanism to create stochastic confidence in developer communities.

Compatible licensing also provides a vehicle for shared rights upstream. The level playing field of open licensing makes it possible to contribute improvements – making open source lower maintenance while remaining highly maintained collectively. Communities operating under a “license in = license out” basis see a free flow of code.

So the answer to why open source worked ultimately is a brew of factors that is hard to acknowledge for those with direct-causal minds – consensus on licenses, confidence about IPR grants, upstream contribution enablement and more. None of these factors alone is sufficient to trigger the network effect of open source development, reuse and collaboration. Neither is any factor alone sufficient to stop the effect if removed. Rather, it is a matter of moving members of the fourth sector from a fog of uncertainty to a point where they are confident to reuse, improve, contribute and innovate. Open source works via a stochastic effect that is hard to quantify yet undeniable.

Antipatterns

So what will break open source? Nothing so crude as a ban. Anything that lowers the stochastic confidence level below the point where the network effect works in a given context will do the job. Some causes of lower confidence/needing further permission:

  • The need to license patents, especially in relation to standards
  • DRM
  • Geographical embargoes
  • Contributor License Agreements (even a DCO will reduce adoption)
  • Uncertainty in the interpretation of a license
  • Licenses that have not been OSI approved
  • Restrictions in the license. Conditions may be problematic if you don’t want to comply with them but that’s not a restriction. All OSI-approved licenses are permissive. All have conditions. None require negotiation – that would be a restriction.
  • Compliance certification requirements
  • Developer certification requirements

This is not to say all these things are certain to prevent an open source network effect triggering. Rather, each thing reduces the average level of confidence of part of the potential adoption community. This is the reality overlooked by corporations following their usual path to optimising short-term gains.


Notes, Tags and Mentions

One thought on “Stochastic Confidence and the Open Source Network Effect

  1. Pingback: Fixing a gap in the SEP regulation - Voices of Open Source

Comments are closed.