Commentary: Bryan Cantrill has been helping to shape open source for decades, and he now feels it has become too rules-based and not principles-based. Image: iStock In open source, we Continue Reading
Commentary: Bryan Cantrill has been helping to shape open source for decades, and he now feels it has become too rules-based and not principles-based.
In open source, we spend so much time talking about licensing that it’s easy to overlook the reality that open source really isn’t about licensing at all. Not the heart of open source, anyway. At its best, open source is about community and shared mores that prompt us to contribute toward common goals. At its worst open source is about micromanaging and enforcing the behaviors we, as the original author of the software, may desire.
In a recent podcast, Oxide Computer cofounder and longtime open source executive Bryan Cantrill called this a conflict between rules-based open source and principles-based open source. The former encourages legalistic approaches to open source license compliance; the latter fosters communal creation of great software. Which does he think is the best approach? “As much as possible, I think you want to be principles-based about things.” How would taking that approach affect some of our current open source debates?
If you spend much time in open source, sooner or later you will hear someone refer to “The Community.” It’s a bit overused and often is just an excuse to be hand-wavy about who will care about the software. But at its best, real community can form around open source projects. Some members of that community contribute code–others improve documentation. Some people merely use the software but help to build interest in a project by talking about it with peers, sharing comments on Twitter, etc.
SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)
In Cantrill’s world, for those developers who are contributing code, their membership in the community may enjoin a deeper connection:
[In open source] the principle should be [that] you have…a social contract….Not a legal contract, but a social contract: if you use this software and it’s valuable to you, instead of sending [someone money], which is what you would’ve done in the early ’90s [with shareware. Instead of doing that,] if you find a bug, contribute that bug back. That is the principle. The principle is that you have a social contract and a moral obligation to assist the thing that assisted you.
By contrast, he said, many single-vendor open source projects have eschewed principle-based open source for a rule-based approach: “Like, ‘No, no, I’m going to find all the loopholes, and I’m going to prevent you from…compet[ing] with me. So I’m going to put all these stupid— riders in this license to try to prevent that.'” For those like Cantrill who have been involved with open source for a long time, however, this approach is unlikely to succeed: “What you’re doing is not going to work, because we [grew] up in the era of proprietary software. We watched open source software take over the world, and if you think that you, [open source vendor] are going to prevent [a cloud company] from using [an open source project] with a license, you’re out of your mind.”
Not that Cantrill allows those cloud companies (and others) off the hook: If “you are using the software and you are not contributing back, you are violating that social contract.” The problem, he went on, is that by fixating on a rule-based approach, open source companies “incentivize [others] to find ways where they are abiding by your rules and not actually abiding by the broader social contract. So congratulations on screwing yourselves.”
But what if we collectively got back to that social contract? That ethos of open source that encourages community and punishes miserly contributions back with criticism, not legalese? Would it work?
Developers caught in the cross fire
Honestly, I don’t know. But it feels like companies are in a better position to expect good behavior from downstream beneficiaries if they’re taking a principles-based approach to open source, rather than a rules-based approach. The latter, as Cantrill suggested, encourages companies to do the minimum required by the license. And it removes the ability for the licensor to appeal to the social norms of open source when they aren’t abiding by them. Hence, GitHub’s policy team can write things like this, advising developers to avoid single-vendor open source projects:
So what’s the lesson for developers choosing their stack? Understand that project ownership and diversity in the contributor base matter. Open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors are less likely to face pressures to relicense. Projects that are the main revenue generator for a ‘single source’ for-profit company have different dynamics. Any for-profit company needs to make a profit. If you take a dependency on such projects, you may face the for-profit company relicensing to protect its business.
The former (principles-based open source) exerts much more pressure on individuals and companies to act in community-friendly ways. It’s a “carrot”-based approach, rather than a “stick,” but that’s what has made open source thrive for so long, anyway. Community, not coercion.
Disclosure: I work for AWS, but the views expressed herein are mine.