HOSTED BY Corporate Open Source Anti-patterns: A Decade Later Bryan Cantrill CTO, Oxide Computer Company

OXIDE A decade ago…

OXIDE A decade ago… WTF?!

OXIDE A decade ago…

OXIDE A decade later • In the FISL talk, I outlined the corporate open source anti-patterns that I had seen up to ~2012, vowing to come back a decade later to describe any new mistakes made in the next… • Good news: there are many new mistakes to talk about! • …but between open source going mainstream and the decline of in-person conferences, venues like FISL and OSCON have disappeared • It feels especially fitting to give this update at the online conference of a company built around an open source database!

OXIDE The singular importance of open source • The innovations that have the greatest leverage are those that enable further innovation – Steve Jobs’s “bicycles of the mind” • Software is magical: it is at both information and machine • When combined with the Internet and distributed version control, open source became the great engine of software innovation • By allowing us to meaningfully collaborate across distance and time, open source ranks as one of humanity’s most important developments • Open source is software’s Moore’s Law

OXIDE The last decade: Shifting anti-patterns • Over the last decade, where an established company engages with or creates an open source community, the behavior has vastly improved! • The new anti-patterns that have emerged have been in those companies built around open source • These companies have an increasingly complicated relationship with open source because it is very intertwined with their business!

OXIDE Open source as social contract • Open source is not merely an artifact, and its developers and community around it – it is also a social contract between those that construct it, those that use it, and those that build upon it • That this social contract has become the bedrock of our information infrastructure is extraordinary – few would have believed that a free market and enlightened self-interest would lead to such a construct! • The anti-patterns around the last decade largely consist of losing sight of that social construct while also failing to build a healthy business

OXIDE Anti-pattern: Conflating users with customers • The road to ruin for open source projects begins with conflating popularity (downloads, GitHub stars, etc.) with product/market fit • This is compounded by software companies being (historically) high gross margin/high growth businesses – and therefore catnip to investors • Investors implicitly and explicitly encourage the wishful thinking that a popular project can become a profitable business! • But in open source, popularity may in fact be an anti-signal: it may be the market telling you that the software is not monetizable at all!

OXIDE Anti-pattern: Conflating gross margin with net margin • Investors love software because of its high gross margin – they often ignore net margin, leaving that as a problem for future generations • Investors will not only enthusiastically capitalize a company, they will encourage behavior that also ignores net margin • This effectively forces a 1990s-era proprietary software playbook upon a company that is built around open source, which is unsustainable • It is tempting to “blame VCs” but in fact entrepreneurs are every bit as much to blame for this anti-pattern!

OXIDE Anti-pattern: Relicensing • A decade ago, I identified demanding copyright assignment as an anti-pattern, and very much stand by it: new projects shouldn’t do this • When copyright has been assigned, however, copyright owners must be wary of that social contract of open source • Copyright owners have a moral responsibility to their contributors! • Sublicensing or licensing to a third party is understandable, but relicensing a project to a less permissive license is wrong

OXIDE Anti-pattern: Anti-competitive licensing • Companies that relicense often justify their actions by conjuring selective grievance, usually from public cloud companies • To prevent these companies from developing services based on their software, they adopt licenses that restrict use • Licenses that restrict use are not open source! • This has become fashionable in the guise of the Business Source License (BUSL), which is parameterized with an open source license that the software reverts to over time

OXIDE Anti-pattern: Non-specific anti-competitive licensing • In the worst implementations of the BUSL, the language is left entirely vague: “You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with my products” • This is terrible because it leaves nothing but questions: what do any of these words in fact mean?! • “Products” and “competitive” are particularly load bearing; does this apply to future products? What about the products of an acquirer?

OXIDE Anti-pattern: Extra-license licensing • Because non-specific anti-competitive licensing raises many questions, those introducing such licenses have attempted to answer with a list of Frequently Asked Questions (?!) • It apparently needs to be said: a FAQ is not a license! • To anyone risk averse who is trying to understand the license, it really doesn’t matter what your FAQ says: put it in the license • This seems to be occurring when relicensing is happening with total disregard for the community

OXIDE Anti-pattern: “Freeloaders” • While the conjured grievance that serves as a casus belli for relicensing often involves public cloud companies, this is not always the case… • Sometimes, (even) smaller companies are blamed • …and in the worst cases, the community itself is blamed for taking advantage of perceived corporate largesse – they are “freeloaders” • This is absurd; if a company perceives itself as losing to its own community, it should (in the words of Laurie Bream) look inward

OXIDE Anti-pattern: Demanding trust after violating it • You cannot rip up one end of a social contract • When companies have disregard for their obligations under the social contract of open source, they should not expect the community – which presumably includes their customers! – to adhere to theirs • Trust builds slowly and is destroyed quickly: if companies destroy trust, communities should not be expected to assume positive intent • If trust is destroyed completely or wantonly, the source will be forked and the community will leave

OXIDE Learning from anti-patterns • These (still!) aren’t hard-and-fast rules – local conditions will vary! • Building a sustainable company around open source is really hard • You need to ask the question: what do customers want to pay for? With a popular project, you will likely find lots of answers to this question – support and services are not dirty words! • Remember: your business is not the community’s problem • Come back in 2033 when we try to prevent our paper clip-hungry AGI overlords from announcing that they are relicensing humanity!

Bryan Cantrill [email protected] @bcantrill https://oxide.computer