The open source war is over, however much some want to continue soldiering on. Recently Meta (Facebook) released Llama 2, a powerful large language model (LLM) with more than 70 billion parameters. In the past, Meta had restricted use of its LLMs to research purposes, but with Llama 2, Meta opened it up; the only restriction is that it can’t be used for commercial purposes. Only a handful of companies have the computational horsepower to deploy it at scale (Google, Amazon, and very, very few others).
This means, of course, it’s not “open source” according to the Open Source Definition (OSD), despite Meta advertising it as such. This has a few open source advocates crying, Rambo style, “They drew first blood!” and “Nothing is over! Nothing! You just don’t turn it off!”, insistent that Meta stop calling Llama 2 “open source.” They’re right, in a pedantic sort of way, but they also don’t seem to realize just how irrelevant their concerns are. For years developers have been voting with their GitHub repositories to pick “open enough.” It’s not that open source doesn’t matter, but rather it has never mattered in the way some hoped or believed.
A brief history of open source time
More than 10 years ago, the trend toward permissive licensing was so pronounced that RedMonk analyst James Governor declared, “Younger [developers] today are about POSS—post open source software. [Screw] the license and governance, just commit to GitHub.” In response, people in the comments fretted and scolded, saying past trends like this had resulted in “epic clusterf—s” or that “promiscuous sharing w/out a license leads to software-transmitted diseases.”
And yet, millions of unlicensed GitHub repositories later, we haven’t entered the dark ages of software licensing. Open source, or “open enough,” software now finds its way into pretty much all software, however it ends up being licensed to the end user. Ideal? Perhaps not. But a fact of life? Yep.
In response, GitHub and others have devised ways to entice developers to pick open source licenses to govern their projects. As I wrote back in 2014, all these moves will likely help, but the reality is that they also won’t matter. They won’t matter because “open source” doesn’t really matter anymore. Not as some countercultural raging against the corporate software machine, anyway. All of this led me to conclude we’re in the midst of the post–open source revolution, a revolution in which software matters more than ever, but its licensing matters less and less.
You don’t have to like this, but the data to support this position is rife through GitHub repositories or the open source licensing trends that have been underway for 20 years. Everything has trended toward permissive, as-open-as-possible access to code, to the point that the underlying license is a lot less important than the ease with which we are able to access and use software.
Source available? Whatevs
Too many open source warriors think that the license is the end, rather than just a means to grant largely unfettered access to the code. They continue to fret about licensing when developers mostly care about use, just as they always have. Keep in mind that more than anything else, open source expands access to quality software without involving the purchasing or (usually) legal teams. This is very similar to what cloud did for hardware. The point was never the license. It was always about access.
Back when I worked at AWS, we surveyed developers to ask what they most valued in open source leadership. You might think that contributing code to well-known open source projects would rank first, but it didn’t. Not even second or third. Instead, the No. 1 criterion developers used to judge a cloud provider’s open source leadership was that it “makes it easy to deploy my preferred open source software in the cloud.”
I’m not suggesting that contributions don’t matter, but they don’t matter for the reasons you might think. One of the things we did well at AWS was to work with product teams to help them discover their self-interest in contributing to the projects upon which they were building cloud services, such as Elasticache. We were not focused on earning kudos from “the community” (the most overused and underdefined word in all of open source), but rather on putting the product teams in a better position to support customers. Guess what? It worked. Although not perfect, a swelling population of AWS product teams is contributing in significant ways to open source projects.
For the developers who use those services, though, “open source” is a secondary concern to “It helps me be more productive, faster.” Which, again, is not to say that open source doesn’t matter in our cloudified software world, as I’ve noted. Open source is an efficient way to rally around standards, giving developers (and enterprises) easier access to common skills and common infrastructure.
But it’s not the end, and the open source Rambos among us need to realize this. The goal of open source, of cloud, of open APIs, of great documentation, etc., is to enable developers to build with less friction and more opportunity. Is Llama 2 open enough for 99.999% of the developer population to use it with unfettered access? Yes. Is it “open source”? The question doesn’t really matter.