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.
There’s been a regrettable rise in the number of projects switching to “fauxpensource” proprietary licenses. In the main, this is the inevitable consequence of the rights-ratchet model running its course and reflects the growth of open source ten years or so ago, the model’s typical life-cycle. The rights ratchet model offers open source freedoms in the initial years of a product to secure adoption and market acceptance and then gradually removes their viability from customers as the company seeks to control their ecosystem and increase revenue.
So the license change that LightBend applied to its Akka product to end its open source status was in retrospect more probable than not given the available evidence that they were using a rights-ratchet business model, just like Elastic and other before them.
Signs that together seem a clear warning include:
VC backing includes VCs who have previously advised portfolio companies to ignore the community rather than leaving money on the table.
Seems obvious doesn’t it? They have to be a good thing surely? They are paying people to work on Open Source software – isn’t that increasing the sustainability of open source?
Stag beetle emerging from elder blossom
Except the money isn’t going to open-source development; it’s going to a cottage industry of hacking that will likely sell the defects to the highest bidder. Even if the highest bidder is part of a white-hat bug bounty program the community that owns the code may well not have members who can fix the problem readily. Even if the community has got commercial contributors they may not have the income necessary to fix all these bugs found by people who are not buying their product.
It’s good to have bug reports and know about defects, but there can be down sides. If the defects are exploitable vulnerabilities – CVEs – the reports are kept on a private security list until fixed to avoid informing black-hats. But in projects that can’t fix the defects fast enough they may well end up being disclosed before there is a resolution.
They also show up on CVE databases and become a cause for support calls and demands for resolution from volunteer community members, increasingly so as automatic scanning tools spread. Some of the bugs are rejected by the developers who own the software because in some cases being a bug or a feature is truthfully a matter of opinion, resulting in “will not fix” false positives.
A case can be made for bug bounty programs run for a company seeking low-cost penetration testing to be handled by their professional development team for a commercial product. It can also be made for an administration seeking community testing of public systems, like the Swiss government. But community-focussed programs like the European Commission’s Open Source bug bounty are well-meaning but surely miss their mark, creating work for communities and their commercial backers without generating donations or revenues to pay for bug resolution.
Who Can We Fund?
Specifically to that example, there’s nothing in the EU program that actually leads to any maintainers being paid, which is because that’s “software procurement” and has stringent rules. There’s a 20% uplift for bug reports who propose fixes for their bugs, but the on-ramp for maintainers of the targeted code is usually substantial and a 20% premium is unlikely to be enough to incent someone to come on board as a maintainer.
The EU has built outbound funding programs for Open Source at NL Net and NGI, but they are all earmarked for “the next big thing”, not for the boring job of keeping Open Source maintained. Edgy new features have indeed been paid for by them, but they have no regard for funding bug-bounty burdens. One fix would be to associate an earmarked grant with a matched bug bounty award so the maintainer could go claim it, giving a concrete incentive to invest the time.
Ideally, the grant to the reporter would be at least partly tied to the bug getting fixed as well. But even if the community has members able and willing to take on bounties, haggling with one or multiple unknown parties over acceptance of a solution after the investment has been made is huge risk for small rewards for implementors.
Conclusion
In the sense they reflect a growing realisation by software consumers that strip-mining Open Source is not sustainable, bug bounties are definitely welcome. But they are not the solution to creating sustainability. Open Source in the supply chain is not mainly or even largely about security. Rather, it has the same profile as Open Source elsewhere – a collaborative matter where beneficiaries share the sunk costs in proportion to the benefits gained.
Bug bounties prioritise the non-contributor’s worldview – the quality of the strip-mined commodity – and neglect the true community view – pooled innovation and shared costs. They are a good first step, but need to be rapidly followed by enlightened self-interest expressed by funding and enabling of the maintainers rather than just rewarding their users.
I’ve repeatedly heard lawyers arguing about whether Open Source licenses and FRAND terms are compatible. But ultimately it doesn’t matter, because the toxin remains whatever the answer – legal compatibility is the wrong lens. When developers come to an Open Source project, they need to find a level playing field, a uniform surface with no traps, a fully illuminated environment with no shadows. Without them, collaboration is compromised.
But the presence of a standard with embedded patents (standard-essential patents or SEPs) under so-called “Fair Reasonable and Non-Discriminatory” (FRAND) terms introduces inequality. Some developers believe they are unaffected, because their usage is purely personal or they are poorly advised. Others are unconcerned because their employer is part of a cross-licensing cartel with the patent holder. But the remainder must each go privately and under NDA to the patent holder(s) and negotiate individual terms to use the patents. They then can’t publicly share the exact arrangements — or possibly even the existence of the arrangement — because of the NDA. Individual terms and secret rights are the opposite of open collaboration and destroy trust.
It’s this inequality that is toxic, not the precise compliance with the legal terms in the Open Source license. Whether great legal minds find the presence of SEPs compatible or incompatible with the license, the inequality of the participants in the community is what makes it avoid SEP-laden standards. That’s why the Open Standards Requirement for Software says any SEPs have to be waived or freely licensed in advance – to restore the level playing field. It’s not because of ideology or an anti-patent agenda or an attempt at market manipulation. The open source network effect underlying the market depends on it.
So learned dissertations about the compatibility of FRAND terms with Open Source licenses may be academically interesting, but they aren’t relevant. All SEPs in standards intended to be implemented as Open Source must be waived or freely pre-licensed, or the standard won’t be implemented by open communities
The word “open” is overloaded. In the domain of standardisers, a process that permits any company to participate (even if doing so is punitively expensive) is considered “open” and the resulting deliverable is considered an “open standard” even if you have to pay to read it and negotiate patent licenses to implement it.
In the domain of software and APIs, it is the deliverable that has to be open – usable for any purpose without negotiation with its rights-holders. This overloading of the term is the origin of many of today’s issues, since – properly understood – Open Source and open standards are conceptually orthogonal.
This variation in how “open” is understood within linked and overlapping domains is why “Open Source” is treated as a term of art with a consensually-agreed meaning in the domain of technology – a noun – and not as a descriptive adverbial phrase. If you see a hyphen in the middle of open-source it’s about military/political intelligence and not technology.
The theme this week at Meshed was standards and open source.A recent post explained how open source and open standards are essentially unrelated, almost contrasting concepts joined philosophically by some based on their application in some industries. Two posts this took look at the consequences of that reality. To summarise the contrast in this context:
Why accommodating open source at a standards body is like growing blueberries.
Fresh-from-the-bush blueberries are one of the good things of life. When I set up my home office about a decade ago, I had to install an underground conduit to supply essential services — power, water, network — and dug a deep trench all along the path that leads there. When I refilled the trench I decided to plant a blueberry hedge so looked into how to grow good blueberries.
Corporate open source maturity may be better evaluated by considering the actions of individuals and small groups statistically rather than evaluating the stated corporate strategy
It’s easy to forget that corporations (and indeed large non-profits) are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, as well as the outworking of the processes and systems they devise to embody their vision. Things happen not because a faceless corporation somehow chooses to act in a certain way from a point in time, but because of the persuasive decisions of actual people, acting within their belief systems and directing the work of others.
Collective Behaviour
Every good – and bad – decision ultimately goes back to an individual somewhere, and corporate effects are in many ways emergent. So fitting a maturity model to a corporation may not be the best way to predict its future outcomes. That is a trailing indicator driven by the behaviours of the individuals within the company.
How similar are open source development and standards development? Not at all, and even the words they have in common mean different things in each.
It’s a traaap
It is often asserted that open source and open standards are in some way similar. For example, in the accompanying letter to a recent submission to the European Commission, a major European-based technology company that is very active is standardisation said:
It’s not new, even if each time it comes up people think it’s a new outrage.
Caged Bird of Paradise
One of the durable long-term strategies for software businesses in the era of open source was perfected by SugarCRM about a decade ago. I’ve described it as the rights-ratchet model. The “ratchet clicks” (not necessarily in exactly this sequence) are:
Meshed Insights Ltd 
