The most important thing to understand about an organization’s relationship with open source is that they have one whether they like it or not. Every organization large and small is operating in a world suffused with open source, so even those against it on principle – of which there are fewer today than a decade ago, to be sure – still by definition have a relationship with it.

The second most important thing to understand about an organization’s relationship with open source is that – unlike the licenses themselves – it is not binary. It is instead complicated and multi-faceted, and exists along a continuum. One part of an organization may be operating in service of open source while another opposes it. Decades ago, for example, in the days of the old Microsoft in which open source was a third rail issue with its former leadership, the company aggressively and publicly campaigned against open source even as it shipped permissively-licensed open source components in Windows. This apparent contradiction is not unusual, it is in fact arguably the norm.

These two factors play an important role in how organizations progress – or do not – towards greater embrace and utilization of open source. Organizations eventually must acknowledge that they have a relationship with open source, if only because they’re consuming it in ever greater amounts. That realization is then immediately followed by a decision tree: fight that adoption? Give quiet approval? Lean into and embrace it? Each decision made with respect to open source is driven by a mix of strategic factors such as the organizational philosophy and DNA and tactical concerns such as whether and how open source may advantage or disadvantage a given business unit. Each of these decisions may lead to events, events which can be mile markers on a journey across the open source maturity spectrum. Consider the following non-exhaustive list of open source-related datapoints for the selected vendor list.

There are several interesting takeaways from this chart, perhaps foremost among them the timeline implied. Some vendors have been actively learning about where and how open source can be best leveraged for nearly three decades. Others have less than three years of experience.

It’s also worth noting that in most cases, organizations start towards one end of the spectrum and gradually, over a period of years, progress towards the other. Some make it all the way to a strategic embrace; most do not. This is understandable for these commercial organizations because open source while offering massive strategic opportunities in achieving widespread distribution and growing community, those often come at the cost of significant challenges from a monetization and business model standpoint.

Which is a perfect opportunity to make clear that the embrace of open source by the commercial organizations depicted on this chart is not altruism. When IBM released the assets that became the Eclipse foundation or promised to invest $1B into the Linux ecosystem, it was as a strategic lever against a competitor in Microsoft. Likewise, when Google donated Kubernetes to a neutral foundation, it was to provide a layer of insulation between running workloads and the underlying cloud primitives of AWS. MCP, PyTorch, Valkey and hundreds of other projects all became open source because their authors believed it to be a strategically advantageous move – not because their authors wanted to do the world a good turn.

With that context, here is one take on the stages of open source adoption for commercial entities. This technically applies to both buyers and sellers of technology alike, but the latter are typically far further down this path than their customers and thus better highlight the spectrum.

These stages do not come with bright lines, and there is the potential for bleed between them. But there are also clear examples for each that can be illustrative.

• Stage 1: Hostility/Indifference: Ballmer-era (~2000) Microsoft’s verbal and legal attacks on Linux specifically and open source more generally
• Stage 2: Silent Consumption: virtually every large company on the planet at this point
• Stage 3: Disclosure: Google’s publication of the Google File System (2003) and MapReduce (2004) papers that ultimately culminated externally in the Hadoop project
• Stage 4: Release: then-Facebook’s 2008 release of the Cassandra assets
• Stage 5: Participation: IBM’s 1998 support for the Apache HTTP server
• Stage 6: Stewardship: Google’s 2015 donation of the Kubernetes project to the CNCF
• Stage 7: Strategic Identity: Microsoft’s 2018 acquisition of GitHub

None of the stages, notably, require an organization to become pure play open source, because that is an unrealistic goal. What this spectrum denotes instead is a gradual philosophical shift from regarding open source as a threat to useful tool to strategic pillar.

The simplest takeaway from the above is this: open source is a spectrum, and it’s important to understand where your organization – or the organization you’re buying from – sits along it. That position can only be relative, of course, because different parts of the same organization can be at different stops at the same time. But in the aggregate, an organization’s overall place on the open source spectrum is likely to determine their behavior moving forward, whether that’s in the commercial sense or the community, and thus is important to understanding how it will operate moving forward.

Disclosure: AWS, GitHub, Google, IBM, and Microsoft are RedMonk customers. Meta is not currently a customer.

Two decades ago this August, AWS – itself four years old at that point – launched the Elastic Compute Service, or EC2. Between that and the earlier March release of their Simple Storage Service (S3), Infrastructure as a Service (IaaS) – more commonly referred to as primitives these days – was born. Within a year it was an emerging force. Within five it was an eight hundred pound gorilla in market, reshaping the industry around it.

While it’s often forgotten now, there was a competing vision for the cloud almost from the start. Heroku was founded in July of 2007. Salesforce introduced Force.com in September of ’07, and Google followed with App Engine in April of ’08. These platforms and others that followed became a new category called Platform as a Service (PaaS). PaaS was positioned as a simpler alternative to IaaS. Instead of having to pick the building materials to host an application, one simply deployed it and left the rest to the platform.

Of these two potential approaches that emerged two decades ago, IaaS won.

There were many reasons for this. For one, IaaS looked much like what enterprises in particular were used to: compute instances were servers, storage was storage and so on. PaaS, by contrast, was somewhat alien. It didn’t look like what came before it. It was, instead, a black box that couldn’t be taken apart and inspected. Developers didn’t necessarily care about that opacity, but their employers did.

PaaS also necessarily involved tradeoffs. Building with the primitives of IaaS, enterprises could construct virtually anything from websites for strip mall petstores to high speed trading platforms. PaaS, by contrast, was only appropriate for a subset of workloads due to constraints either cost, technical or both. Being a general purpose platform in a world of highly specialized applications is a challenge.

The technology industry landscape, therefore, was dominated by primitives for nearly two decades. And from an adoption and spending perspective, it still is.

But the market has also changed in recent years. A few key factors:

• First: the number of available primitives multiplied. As such, it traced a parabola of utility. Initially, as the number of available primitives increased, the platforms usefulness increased in direct proportion. More primitives meant more possibilities. At some point in the last decade, however, it hit the down arc of that parabola and started declining in its appeal, with the ever expanding array of services transitioning from toolbox to burden. Six years in, the Developer Experience Gap remains an issue.

• Second: the PaaS core approach was reconsidered. If PaaS originally failed to achieve real scale in its adoption in part because of its general purpose focus, what if ambitions were narrowed and the platform were to target a particular workload or set of adjacent workloads? A specialized platform for a particular task is much more achievable than a Jack of All Trades. As expected (if not from the mentioned quarter), this realization has triggered a wave of market innovation in less generalized, and more specialized providers.

• Third: the rise of coding assistants is dramatically accelerating the number of applications created, and as a consequence, lines of code being deployed. It is at the same time gradually putting more distance between developers and the construction and deployment of the application itself. Not just with code creation – which will at times involve programming languages the developer has never learned – but from the underlying infrastructure. In more and more cases, technology selection is being delegated to coding assistants, and left to their own devices those coding assistants have a preference for abstract platforms, platforms that might once have been termed PaaS.

Given these and other factors, the market for abstractions that sit above the original primitives of IaaS has both fragmented and grown. To be clear, IaaS – or primitives, today – remains the dominant approach and will for the foreseeable future.

But the more complicated infrastructure becomes, the more appetite there is for simpler alternatives. Especially if the virtual, 24/7 pair programmers ubiquitous today are putting their proverbial fingers on the scale in favor of abstractions because they’re easier to programmatically manipulate and require less explanatory context (and thus fewer tokens).

All of which explains the great unbundling. In response to developers and enterprises seeking abstractions but frustrated with limitations of general purpose platforms for their workload of choice, a diverse array of different tools emerged to attack different problems via specialized abstractions sitting above primitives. A few rough categories have emerged.

• AI app builders (“vibe coding”): (e.g. Bolt.new, GitHub Spark, Lovable, Replit Agent , v0). App writes the code, and increasingly determines the hosting and backend too.
• General-purpose PaaS (“Heroku-like”): (e.g. Cloud Run, Fly.io, Render, Railway). Code written independently, deployed to abstract servers/containers/scaling.
• Front End: (e.g Cloudflare Pages/Workers, GitHub Pages, Netlify, Vercel). Code written independently, abstracted hosting/CDN/edge.
• Backend-as-a-service: (e.g. Convex, Firebase, Supabase). More than just DBaaS primitive: abstracted DB + auth, storage and other pieces.
• Internal Developer Platforms: (e.g. Backstage, Crossplane, Humanitec, etc). Highly specialized, internal developer-focused platform.

There are caveats to the above categories, of course. Some products belong in multiple categories. In other cases the lines in between individual categories can be less than distinct, as with the app centric examples. The reverse can be true as well, with some categories having little in common: see IDPs vs BaaS as one example.

But in an effort to understand how, where and how quickly the market for abstractions above underlying primitives is growing, we’ve been tracking over 70 projects – a number which will undoubtedly grow by the week, if not day. Their breakdown is here:

Unsurprisingly, the second largest category, and category with the longest history, is general purpose app PaaS platforms, topped only by – what else? – AI. The list makes rough subjective judgements about which are core to the market, somewhat adjacent, possibly dead (watching) and excluded (dead or disqualified for one reason or another). From a macro perspective, however, what the list demonstrates – along, arguably, with Heroku’s deprecation – is that the days of a one size fits all abstraction are over for the time being.

The unbundling has inevitably come for PaaS, just as it once did for databases in the first decade following the millennium. What’s equally inevitable – again, just as it was with databases – is that the unbundling will ultimately give way to bundling. Bundling which arguably has already started. A few examples:

• Convex Chef: from BaaS to app builder
• GitHub Spark: from front end to app builder
• Lovable Cloud: from app builder to PaaS
• Replit Agent: from PaaS to app builder
• Vercel v0: from front end to app builder

This is a market at work. Bundled product limitations are identified, unbundled products tactically attack them. The survivors then turn their eyes towards adjacent unbundled markets in search of growth. Normally this is a process that takes time; it took the database market well over a decade to fragment with the rise of NoSQL only to return to the multi-workload databases in demand today. It’s not clear that timeframe will hold here, though.

Consider the list of collisions above. It took seven plus years for Vercel (née Zeit) to introduce v0. It took Replit a little over 8 years to get to Agent, and GitHub over 15 to get to Spark. But those were companies founded, at the latest, in 2016. The newer market entrants tell a different story. Convex reached out of market in a little less than three years; Lovable took ten months.

Perhaps most importantly, in the aggregate, all of the above transformations took place within a 25 month window.

Between this re-bundling of previously distinct workloads, then, and the pragmatic reality that market will not support near two dozen large platforms let alone the new options arriving by the day, it seems reasonable to expect consolidation in the market for abstractions, and soon. The growth opportunities for the winners, however, should be substantial.

Disclosure: Cloudflare, GitHub, Google (Cloud Run/Firebase), Heroku (Salesforce) and Render are RedMonk clients. Bolt, Convex, Crossplane, Fly.io, Humanitec, Lovable, Netlify, Railway, Replit, Spotify (Backstage), Supabase and Vercel are not currently customers.

In addition to being an important specialty runtime for enterprises, then, it was load bearing infrastructure for AI companies large and small.

Load bearing or no, its commercial prospects at the time of the acquisition – like so much of the open source the industry relies on, unfortunately – were less than clear. This Q&A from Jarred Sumner’s acquisition announcement was blunt:

Q: Is the same team still working on Bun full-time?
A: Yes. And now we get access to the resources of the world’s premier AI Lab instead of a small VC-backed startup making $0 in revenue.

On the whole, the acquisition was fairly straightforward for both parties. Bun receives an immediate capital return and a viable, long term path for support, while Anthropic gains direct control of a project strategic to their offerings. By going the inorganic acquisition route, it spent money to save time in a market with plenty of the former but precious little of the latter. Curious about how the project has fared post-acquisition, we’ve evaluated some of its metrics.

The high level takeaway is that the acquisition does not appear to have slowed the project. The below chart drawn from npm is merely a subset of Bun installs, and doesn’t reflect those installed directly, via Homebrew, binary or otherwise. Even the subset we’re able to access here tells a clear story however.

It is necessary to caveat the above and similar charts by observing that it’s difficult to precisely tease apart Bun’s success from that of projects that leverage it like Claude Code. Still, growing 16X from 445K/month to 7.3M in less than 30 months is impressive for a runtime in a field full of them. And if the runtime growth sounds impressive, the TypeScript type definitions for it are even more impressive – bun-types (the first party native definition) grew at 53X while its TypeScript wrapper jumped 234X.

Bun is growing, in other words. It may even be growing faster post-acquisition. But the question is: how sustainable is that growth? To answer it, it’s necessary to look under the hood at how the project is being built, by whom and how that’s changed over time. There are many different conclusions to be drawn from the resulting datasets, but there are two particularly worth highlighting.

AI and Bun

As has been discussed elsewhere, the most obvious takeaway in looking at Bun’s commit data is the glaring transition from primarily human to primarily AI contributions. This is certainly no secret; a month ago, Sumner said on Twitter:

“We haven’t been typing code ourselves for many months now. Even pre-acquisition this was pretty much accurate.”

The commits chart confirms this.

As early as last August, over half of the project commits at a given time were authored by a bot. Post-acquisition, it’s rarely less than that, and has peaked north of 80%.

Here are the total commits per month, AI vs human.

The trend line here is unambiguous: in approximately 12 months, Bun has transitioned from a project maintained by humans to one primarily authored by machines. To break that out in a little more detail, here are the commits per contributor: AI, but splitting up internal and external contributors.

We’ll get to the secondary trend there momentarily, but again, the conclusion is unavoidable. Just as Bun is core AI infrastructure, AI is now the core contributor to Bun.

This raises a host of questions that for the most part can’t be answered yet. How maintainable will the project be over the long term? What if any tech debt and learned helplessness is being accrued by the Bun team by relying so heavily on AI? Will AI continue to increase its percentage of code committed at the expense of humans, or will a natural equilibrium evolve over time?

It’s been barely a year of AI contributions, and half that as employees of one of the most visible and important AI companies on the planet. We won’t and can’t know the answers to these questions for some time, because the sample is insufficient.

But it seems clear that when looking at how core infrastructure products might be impacted by rising AI contributions, Bun will be an important datapoint to monitor.

Open Source and Bun

Arguably more interesting than “project includes more and more code written by machines” is what the acquisition means for Bun as an open source project. Bun was and is MIT licensed, and the acquisition announcement made four related promises around the project:

• Bun stays open-source & MIT-licensed
• Bun continues to be extremely actively maintained
• The same team still works on Bun
• Bun is still built in public on GitHub

Three of those promises have undeniably been kept. Bun remains open source and MIT licensed. It is actively maintained, and built on GitHub. The team, on the other hand, appears to have gone its separate ways.

First, let’s look at a macro picture of the number of human contributors to the project, total, in the wake of the rising AI contributions.

That number is roughly half of what it was. The number of external contributors, for its part, has dropped off significantly.

Just as the number of human developers big picture has declined, so too has the number of external developers.

To put that in context, however, while their numbers appeared to be more robust, the actual code contributions from external contributors has always been relatively modest – even acknowledging the problematic nature of measuring actual contributions by commits.

After dipping immediately post-acquisition, internal commits have climbed back into the same rough number they occupied prior. External commits, however, have not. Their contributions have significantly declined. This is unsurprising. Contributing to a project maintained by a small, independent startup is a different matter than one maintained by a large, well capitalized AI juggernaut.

Getting back to the original promise of keeping the team together, we can see the above metrics manifested in a detailed list of the original committers.

Of ~7 identifiable pre-acquisition Oven employees, at least 4 have clearly departed or at least stopped contributing. Another active committer went from 745 pre-acquisition commits to 1 post-acquisition. There are many potential reasons for this mini diaspora, and they may have little if anything to do with the project, AI, the acquisition or any of the above. The motivation, interest – or permission – to work on a large open source project can change for a variety of reasons.

But it is certainly not the same team that originally built Bun. Humans left, AI has moved in – whether that replacement cycle was deliberate and intentional, or not.

The Net

The fact that the number of human contributors to Bun is down while the number of machine contributions up would be less interesting if it wasn’t a relatively high profile open source infrastructure project. It’s unclear how Anthropic will navigate its stewardship of the project moving forward, or whether in fact they care about their role as project steward. Bun is an opportunity to ask questions of Anthropic: how does it value open source? What are its intentions for the project?

Consider the case of another open project out of Anthropic, MCP. First launched in November of 2024, consensus within three months was that it was a clear industry standard – which is an absurd, unprecedented timeframe. It was difficult, even shocking, to be told by competitive vendors that they were effectively granting this status to MCP the January after a November release.

In spite of this early and unprecedented success, it took another ten months for it to be donated to a neutral foundation. For the unfamiliar, this is a necessary step for standardized technologies that will be jointly developed by otherwise fierce competitors. Few if any commercial organizations will contribute to a project solely owned by a third party because it’s tantamount to subsidizing their development with your labor.

To be fair, this timeframe is not totally unreasonable. Kubernetes likewise took thirteen months from initial release to donation. But Kubernetes was also one amongst multiple competitive container orchestration projects, and very far from an obvious industry standard at the time. The delay and ultimate donation, then, was appropriate and strategic. MCP was a much more obvious candidate for standardization, however, earlier even than Docker, the most rapidly adopted technology we’d seen up until MCP. But it still took over a year for an obvious open source standard to be permitted to ascend.

Which begs the question: where is Anthropic, and its counterparts like OpenAI, on the corporate open source maturity curve? Startups understand open source code as consumers because they are built on it. They generally understand contributions, governance and the like because they have to. But as a rule, startups focused on moving as quickly as possible are far less familiar with how open source works on a corporate or enterprise level.

Not that Anthropic stands out in this regard. Microsoft spent decades verbally assaulting open source. Google’s early years were marked by publishing open papers about software without releasing the code behind them. And AWS’ reputation amongst open source communities was arguably worse than Microsoft’s until relatively recently when it learned to more peacefully coexist and contribute back.

These vendors and those that preceded them have had to learn about open source on a macro, rather than micro-scale. About license choices, the role of foundations and how to run open source projects that encourage rather than discourage external contributions – as well as the benefits of same.

An argument that could be made is that Anthropic won’t have to learn these lessons because it doesn’t need to standardize Bun. Certainly any flow of would be external contributions to the project from competitors is arguably now coming from AI. Why bother amortizing development costs across competitors and giving up control of a project to a foundation when the project’s owner has a bunch of software genies in a bottle that it can release at any time?

That assumes, of course, that the primary value resulting from the standardization of a project is code contributions. Which is a fundamental misunderstanding of the purpose of standardization. External code contributions are not the primary incentive to donate a project to a foundation: preventing needless and unproductive market fragmentation is. As is reassuring potential users. Enterprises, for one, do not embrace software from a foundation because it’s written more quickly. They do so because they prefer their key infrastructure not be controlled by a single vendor.

In any event, those curious about whether and how well Anthropic understands open source would be well served by watching their stewardship of Bun and how it evolves over time. The project, to its credit, is growing apace even as it’s hosted at a non-neutral single party. But assuming it’s a priority, and that Anthropic has ambitions for Bun to be more than a project that just undergirds Claude Code and its offerings, that growth is likely to be challenged by questions about stewardship and long term project futures. If that growth, meanwhile, is not a priority, and Anthropic has no intentions for the project to be more than just a piece of internal infrastructure, it will have negatively impacted its open source reputation as a poor steward of a popular project. Does Anthropic and their highly capable software creation machine, then, take on the world alone? Or do they trade some control for wider, swifter adoption?

How that question is answered, and whether Anthropic carries forward Bun’s wider mission or abandons its external users and turns inward, will tell us much about how quickly Anthropic is moving along the open source learning curve, and how much it has learned from the companies that have gone before it.

Disclosure: AWS, CircleCI, Docker, GitHub, Google, Microsoft and Salesforce (Slack) are RedMonk customers. Anthropic, Cursor, Figma, Lovable, OpenAI, The New York Times and Windsurf are not currently customers.

The term “open source” was coined in 1998, at least in part, because the term that preceded it was unclear and required explanation. Free software was descriptive and understood within technical communities familiar with it, but misleading to newcomers who understood free in commercial rather than philosophical terms. It was clear, in other words, that a new descriptor was required, and open source was the result.

Two years after the introduction of a proposed definition for open source AI, adoption has been minimal and there is an increasing awareness that unlike with pure source code, the assets that make up an AI model cannot be reduced to a single, binary open and closed definition.

It’s not that the licenses and promises of open source as they pertain to source code are simple. They can be complex, nuanced and difficult to explain. But they are, at least, that binary. Code is either open source or it’s not. By contrast, it’s now clear that open source AI – of which code is only a small part – is going to have to be defined along a spectrum from closed to open.

The G7 nations – with input from parties like the OSI – apparently concur. Their paper published this week, “G7 Vision on AI openness opportunities and shared language,” has several important takeaways. Among them:

• First, it clearly and unambiguously states that both open source and AI openness have immense societal benefits. It calls the latter, in fact, “an essential contributor to our economies.”

• Second, it acknowledges the risks and potential future harm that can result from the lack of clear, consistent definitions. “This lack of clarity in the field of AI tends to cast doubt on the degree of openness of such technologies, thereby undermining their benefits.”

• Third, it explicitly rejects a strict open or closed definition – “the openness of an AI is not binary.”

• Fourth, it implicitly rejects existing definitions – “the meaning of Open-Weight or Open Source AI remains contested.”

• Lastly, it proposes a four tier system for categorizing AI projects that sit along a spectrum of open.

The proposed classifications are similar in some respects to existing attempts like the Linux Foundation’s Model Openness Framework. Both are built for a landscape in which projects will differ in what specifically is made available, the terms its made available under and what restrictions, if any, are placed on use. But where the MOF is quite granular, grading projects around 17 components across an entire development lifecycle, the G7 vision is simpler. It defines four tiers based on five components (weights, deployment code, training code, training data and use restrictions).

In rough terms, those tiers can be described as follows ranging from most open to least:

• Open Source AI with Open Data: everything is open and under an OSI license – code, data, weights, every asset.
• Open Source AI: what’s available is open, but it may or may not include training data, though it must include full training code.
• Open Weights AI: weights and code are available and under an OSI license, but nothing else.
• Weights Available AI: weights and code are available and open for inspection, but are released under a license which cannot be called open source due to use restrictions or other prohibited limitations.

It remains to be seen whether or not the industry can adapt to a definition of open that depends on a sliding scale rather a fixed yes/no. But it also doesn’t have a choice. Two years of development and discussion and two years of living with a proposed definition have gotten us no closer to an industry consensus. Subtly, however, what the G7 nations have done with this document intentionally or unintentionally is to both acknowledge that fact, make it irrelevant and implicitly propose their alternative.

The challenge for any single definition of open source AI is that it is not possible to please both definition purists and definition pragmatists. The former point out that any definition that allows for any omission of training data is effectively granting the term open source to a project that cannot ever be independently replicated. Which is legitimate. The latter, on the other hand, point to issues with datasets ranging from the byzantine nature of data licensing to the sheer impracticality of the size of these datasets. Which are also legitimate. You can please one of these groups about an open source definition, but not both.

What the G7 is proposing serves as a recognition that that debate is a lost cause. Instead, for all intents and purposes, the G7 is proposing to deprecate the term open source AI in favor of open weights.

It is true, on the one hand, that there are not one but two different tiers in the G7’s framework that explicitly cite the term open source. So the deprecation is not literal. There is a definition of open source AI in existence.

But if no major competitive models can satisfy that definition, does the definition matter?

Two weeks ago, we surveyed a large, representative sample of relevant models. Since then we’ve added a few new models to track. A quick survey of the licensing terms for this sample are suggestive. 28 of the surveyed models are closed, and thus irrelevant in a discussion of openness. Of the 40 remaining in our sample, half are Weights Available AI (non-OSI license) and half are Open Weights AI (OSI license). Which in turn means that none are Open Source AI and none are are Open Source AI with Open Data.

To be clear, there are borderline cases: IBM publishes detailed training documentation and methodology, but not the code. Meta has released fine-tuning recipes and scripts (llama-recipes) alongside Llama, but again not the code. Deepseek, meanwhile, arguably went furthest, providing reinforcement learning training code and distillation scripts – but not the full pipeline. None of these, therefore, are considered open source AI by the G7’s definition.

Outside of our sample, meanwhile, there are models that provide data, code and weights: AI2’s OLMo and EleutherAI’s Pythia most notably. But they aren’t particularly competitive with the selected open and closed models tracked here and thus are not considered.

Put simply, the G7’s proposal at once codifies the open source AI definition while simultaneously making it irrelevant. Open weights becomes the de facto term of art, then, by default – at least until such time in future that truly open source models become more competitive. Instead of blurring the definition of open source AI to meaninglessness, a new, more descriptive term in open weights seeks to mitigate the shortcomings of its predecessor – much as open source itself once did for free software.

It is not clear whether even an august body like the G7 can compel adoption of their proposed framework, and there are questions about who should be defining industry terminology: governments, or industry bodies? But if this effort is successful, and the term open source is effectively relegated to just describing source code, that could be the best possible outcome. Vendors who wish to benefit from the halo of open can do so with a term separate and distinct from open source, and thus one insulated from contamination from use restrictions, lack of training data and other issues that would violate the original spirit and intent of the open source definition.

In past debates between open source purists and pragmatists, the latter would frequently argue that a definition of open source that was too strict would never be used.

The mistake all along may have been assuming that that was a bad thing.

Disclosure: neither the G7 nor the OSI are RedMonk clients.

In the wake of O’Reilly’s decision to exit their events business, including OSCON, a void was created. Among its other functions, OSCON served as the de facto annual gathering of forces within open source. While it’s distinct in some critical ways and can’t necessarily replicate the traction of its spiritual ancestor (in part because of OSCON’s densely packed venue), the Linux Foundation’s (LF) OSS Summit is arguably the best approximation of OSCON that exists in 2026. It transcends product categories, corporate boundaries and seniority levels to attract a mixed audience of young, old and everything in between.

It also, as mentioned, serves as a nexus for various powers within open source to meet – often accidentally – and exchange notes. It is, in the words of several open source people this week, a “favorite event.”

It’s also, by virtue of its attendees and focus, a valuable vantage point for observing macro trends and issues across open source at scale. Here are five takeaways from this year’s event.

AI and Data

When the OSI and other parties attempted to determine how and whether the term open source should be applied to AI models, data inevitably was the sticking point. The relationship of open source licenses to the source code components of the models was well understood. With data, not so much. Data licensing, unfortunately, is fractally more complex than for mere code.

It was not surprising, therefore, to see data singled out as one of the last holdouts to an open AI landscape. The LF has targeted this as an area of research and investment, with its CDLA family of licenses as one example.

There is, however, no consensus around data licenses, or even which entity should be the arbiter of same. The LF is appropriately focused on this as an area of necessary attention and investment, but how data licensing does or does not progress will certainly not be up to them alone.

Open Models

Research from the LF has apparently reached a similar conclusion to RedMonk’s own analysis: specifically that open models not only continue to compete with their closed, frontier counterparts, but that the gap between the two is closing over time.

This is interesting in the abstract, because having open alternatives to closed products has generally been beneficial to users. But it is of particular interest because of the stakes involved. Building and advancing frontier models, to date, has been fantastically expensive, and pushed startups in the space to pursue private capital investments in amounts previously unheard of. The return on these investments is predicated on several expectations, among them that the private models will become so indispensable that not paying the cost – even as costs rise – is unthinkable.

Open models that are becoming aggressively more capable at faster and faster rates introduce questions around these valuations, and the expectations of return. It will be interesting to monitor the tension between open and closed models in the year ahead, because it’s possible there’s a threshold of capability at which users individual and enterprise alike regard as “good enough,” and that that threshold may be met by open models soon.

Security

Casting a pall over the success of open source more broadly were questions of security. As Jim Zemlin’s keynote quoted, the bill for deferred security investments for the industry as a whole is coming due. And we are not collectively prepared to pay it.

AI is both sides of the blade here. Via Project Glasswing, enabled by early access to Anthropic’s most capable model, security researchers are attempting to stay one step ahead and identify and patch vulnerabilities faster than they can be exploited.

But that is not scaling across the industry. AI is being used and used well by attackers, who are able to dial back the cost of creating exploits to near zero and – coupled with decades of social engineering expertise – to attack broadly, at scale and with velocity.

This has led to fundamentally misguided efforts like that of the NHS to close source hundreds of open repositories in an effort to protect them. Notwithstanding the fact that this type of action both doesn’t work and has no defensible academic foundation underneath it, it is inevitable that we’ll see more of it.

Open source is likely, in other words, to have to prove its security bona fides all over again.

Maintainer Burnout

One popular topic of conversation at this event was maintainer burnout. From user entitlement to security worries to infrastructure not built for the volume of inbound AI contributions, life for project maintainers has never been more challenging. Asked if AI was helping to mitigate that, one maintainer bluntly answered, “No.”

Maybe it will in time, or perhaps other process and infrastructure adjustments will ultimately result in improvements, but for now maintainers are faced with an increasing number of challenges with no commensurate adjustments in the resources at their disposal. The number of would be contributors has skyrocketed in many cases; the number of maintainers has not.

This isn’t an LF problem, or at least it’s not strictly their’s to solve, but it is and remains very much an industry problem. One that does not get nearly the attention it deserves.

Who is the Next Generation of Open Source Defenders?

For decades, open source has found for itself new generations of advocates and defenders. Drawn to it by different paths, whether that was personal benefit, commercial opportunities or garden variety idealism, generations of technologists metaphorically handed off the responsibility for actively protecting open source to those coming up behind them who shared their sentiment.

It’s not clear, however, how much longer that shared responsibility can be sustained.

Open source has become, to a degree, a victim of its own success. Its ascension and then dominance made it something to take for granted, not something that needed to be cared for, nurtured and actively defended. Many developers today cannot remember a world not only in which open source didn’t exist, but one in which it wasn’t the dominant approach to building software. As a result, things like the ardent and assiduous defense of the literal definition of the term open source itself seems quaint at best and pedantic at worst. ”Ok, boomer,” is one common response.

As those who have been around long enough to understand that, like democracy, open source needs to be guarded with vigilance age out and retire, the question is who will step up to take their place? The OSS Summit didn’t provide many answers in that regard, but if would be defenders are out there, it’s presumably where they will first appear.

And if they don’t, maybe the event will have to recruit them more actively.

Ever since, software has been in constant tug of war between open and closed. With operating systems, virtualization software, mobile and other categories, closed software led the way and open gave chase. For big data, containers, programming languages and web servers, the roles were reversed. Open source typically led, while closed and proprietary models have had to keep up.

Models, for all that they are built and utterly dependent on a foundation of open source, are very much in the former camp. What began open became closed. “Frontier” models – which is to say models that push the “frontier” – are universally proprietary or closed, OpenAI’s name notwithstanding.

Ever since Chat-GPT was unleashed on the world on the 22nd of November, 2022, however, there have been – inevitably – efforts to counter the dominance of proprietary models with “open” alternatives (we’ll come back to what open means in this context). The technology industry has a long history of both dominant players, and federated resistance to those dominant players.

At a recent industry event, an AI executive likened the open models chasing their closed frontier counterparts to a “pack of wolves.” Casual observers of the industry could be forgiven for not knowing open alternatives existed, because almost all of the media’s attention is consumed by coverage of Anthropic and OpenAI’s latest achievements – though arguably that is in part because of the latter’s notable tendency to strategically time its releases around Google AI announcements to minimize their impact.

Whether open will compete with closed, then, is not the interesting question. It always has, it always will. The question to ask is instead: how well? Put another way, will the “pack of wolves” ever catch their prey, and if so, how quickly?

Evaluation of AI models is challenging for many reasons. Anecdotal experimentation is useful – anyone who used models before and after November of last year would be struck by the difference in capability – but it obviously doesn’t scale. The only real standardized quantitative measurement available, however, is industry benchmarks.

Given that benchmarks were gamed almost to the point of irrelevance decades ago during the TPC-C wars, they would not otherwise be the first choice for evaluation, but at this point they are the least worst method of measuring performance model vs model.

That being said, there are many other specific concerns for benchmarks generally and those selected here. Among them:

1. Contamination: models can be trained on data that includes benchmark test questions, either accidentally or deliberately.
2. Self-Reporting: models are typically self-reported by the labs that created them.
3. No Standardized Approach: benchmark scores can vary widely depending on scaffold, prompt, number of attempts, etc, and benchmarks typically don’t standardize the approach
4. Specificity: as will be seen momentarily, benchmarks typically have a specific area of focus. None can adequately cover or represent the breadth of actual real world use cases, and notably the benchmarks here are text in, text out – not multi-modal.
5. Difficulty: to measure progress over time, the benchmarks selected for this analysis had to have actual history. This means that more difficult or challenging benchmarks that have emerged more recently and may be more strenuous tests of ability are not represented here because they would not reveal any real trendlines worth noting.

In addition to those caveats, it’s important to note that there are dozens of potential benchmarks – some general, some specialized – that could be used. The selection process here prioritized consistently available scores across a wide variety of models and a reasonable history to evaluate. This, in other words, is a snapshot of benchmarks and other selections might produce different results.

One last necessary clarification before proceeding is the definition of “open.” This analysis includes both closed and open models. Closed is closed, but open includes two distinct subsets of models: open weight, and fully open. Fully open refers simply to models that are licensed according to a known and OSI-approved open source license: Apache, MIT, etc. “Open weight,” on the other hand, refers to the emerging industry consensus term for models that are mostly open, but include some restrictions on use that prevent them from being called open source – the most common example of which in this dataset is Llama.

With that context out of the way, let’s start with a simple glossary of the benchmarks selected.

Notably, the benchmarks here are arranged in an order of most to least “saturated.” Saturated refers to benchmarks that have effectively been solved by all or most models, and thus are no longer useful at measuring relative capabilities. In spite of their lack of utility today, saturated benchmarks are included in this analysis because they demonstrate the historical progress open models have made in catching up with their proprietary counterparts.

We’ll begin by examining one of these fully saturated benchmarks, GSM8K.

From GPT-3.5’s performance in December of 2022, within 16 months GSM8K’s grade school math problems were effectively solved. And importantly, by both open and closed models. By late 2024, fully open Deepseek effectively matched Claude Sonnet’s ~96% score. It’s also notable that the 7B Llama released in July of 2023 was basically guessing at 15%, but the 8B Granite model released in May of 2026 was at 93% – meaning that even small models performance was improving rapidly.

Next, we’ll look at a slightly less saturated benchmark, HumanEval.

The “Pass@1” in the above means the model only gets one shot at the question, and it’s excluding other related benchmarks like LiveCodeBench. Again, we see the same pattern playing out, with both open and closed models alike largely solving HumanEval, though the scores are slightly lower than GSM8K.

Also worth noting is that the 30B Granite 4.1 matches the 405B Llama 3.1 from two years ago, proving that open but restricted license models are not outperforming purely open alternatives – regardless of size.

Slightly less saturated than HumanEval is MMLU.

Smaller models aren’t faring as well with the broader set of 14,000 questions: 7B Mixtral represents the peak a bit over 70% and that hasn’t been exceeded since. The larger tier, 70B+, has for its part stalled around a GPT-4o level of capability. The larger open models like Deepseek have peformed well, though nothing close to the closed Opus 4.6.

It’s also worth noting while open weight models lead the way performance-wise, fully open models follow quickly after and now claim the highest scores.

Next up, MATH.

This is whether things begin to separate. The frontier models score around 90%, while the best open models tap out at 83%. Some of this admittedly might be an artifact of the fact that newer models are more commonly reporting against the AIME and MATH-500 benchmarks rather than classic MATH. Two other things to note: model size doesn’t seem to play a major role in performance, and the older fully open Qwen model still outperforms newer open weight Llama alternatives.

Now we’ll see even more separation in GPQA Diamond.

There are a number of interesting takeaways here.

For one, Deepseek R1 was ahead of all models, open or closed, when it debuted. But closed models made a big jump in the form of Gemini a few months later, and it took almost a year for open models to close the gap. Earlier this year, Deepseek, GLM, Kimi and Qwen have approached the performance of Anthropic and OpenAI, but not quite matched it.

Lastly, let’s look at SWE-bench Verified – 500 human-validated real GitHub issues.

From May of last year through early this year, all progress came from closed models. In February, however, things began to speed up. Both open and closed – Gemini, GLM, Kimi, MiniMax, Opus, Sonnet, etc – models all landed within 73-81%. Opus 4.7, for all of its other launch issues, jumped to ~88%, while the Deepseek V4 Pro leads the open contingent at ~81%.

The pattern here is clear and consistent: closed leaps forward, open is hot on its heels. And the cycle appears to be getting faster.

To explore that, let’s look at the time it took open models to match the capabilities of saturated benchmarks we examined earlier.

It took 18 months for Qwen to match GPT-4’s capabilties within the MMLU benchmark, and 13 months for Llama to do the same for HumanEval and MATH.

The longest it took an open model to match GPT-4o’s capabilities on any of those benchmarks, however, was seven months, and Llama matched its peformance on HumanEval in two.

But what about the harder, non-saturated benchmarks?

It’s more of the same. Deepseek caught up to Opus 4.6’s capabilities on GPQA in three months, and MiniMax did the same on SWE-Bench in one. None have matched Opus 4.7 as yet, but it’s been less than a month.

Takeaways

There are any number of different conclusions to be drawn from this dataset – with the caveats noted above – but here are five that stand out.

1. Closed models are setting the pace of innovation, and constantly breaking new ground from a capabilities standpoint.
2. Open models are chasing them, and the cycle times seem to be getting shorter. There are no clear capability moats, and what is frontier today is table stakes tomorrow.
3. Closed beats open today, but there is effectively no advantage to restricted open weight vs fully open models.
4. Small models are extremely competitive in specialized disciplines, but lag behind on general performance.
5. The United States has the largest contingent of surveyed models (42), and the largest proportion of closed models (64%). China, by contrast, features 17 models, and every single one is either open weight or fully open.

Having performed this base level analysis, it will be necessary to track how these models continue to evolve and how the benchmarks evolve with them.

Disclosure: Amazon (Nova), Google (Gemini, Gemma) and IBM (Granite) are all RedMonk clients. 01.AI (Yi), Alibaba (Qwen), Anthropic (Opus, Sonnet), DeepSeek, Mistral (Mistral, Mixtral), Meta (Llama), MiniMax, Moonshot (Kimi), OpenAI (GPT) and Zhipu (GLM) are not currently RedMonk customers.

Unless and until that occurs, then, it is useful to understand how open source licenses are being applied to models and in what proportions. To do this, inspired by a conversation on this subject yesterday, the approximately ~2.9M existing Hugging Face models were scanned for license information. There are some interesting takeaways from the data, but first it is worth noting that there are inherent issues with it.

• First, this analysis cannot account for licensing issues like an illegally licensed project. There are models, for example, that apply an Apache license but trained using Llama. That is not permissible, as you may not convey rights you yourself do not have – particularly if you’re performing actions a given license specifically and explicitly prohibits. This analysis would consider the project Apache-licensed, when in reality that license cannot not be applied.

• Second, this analysis can’t meaningfully discuss every one of the new licenses here, some of which were written by professionals and some of which were self-evidently not. Given the scale, it cannot guarantee that there are no falsely categorized licenses. The some Kimi and Mistral projects, for example, use a “Modified MIT License,” but the modifications make the project neither open source nor MIT. The good news is that projects using this license are typically categorized as “Other,” and are therefore properly not counted as open source here. The bad news is that we can’t guarantee that there might not be exceptions.

• Lastly, as will be discussed in more detail shortly, there is a rather large hole in the data.

With those warnings out of the way, we’ll start with the Top 20 licenses on Hugging Face.

This is a classic long tail distribution, but it is notable just how popular the Apache license is with ~2.5X more licensed projects than its nearest competitor, the MIT license. The next most popular licensing family, perhaps not surprisingly given its Hugging Face pedigree, is Open & Responsible AI Licenses (OpenRAIL). It is the largest single non-OSI, non-model-specific license category in this dataset.

Next, let’s look at the distribution of projects by category.

This is the hole in the dataset mentioned above. Just as GitHub historically reported that the overwhelming majority of repositories are unlicensed, almost seventy percent of Hugging Face models carry no license at all. This means that the data represented here about licensing distribution covers only a third of the models, though at almost a million the sample size is still large enough to be meaningful.

To better understand the distribution, let’s strip out the unlicensed projects and look at only those with one.

Notably, as was seen in our recent look at the state of open source software licensing, Hugging Face is displaying a systemic preference for permissive licensing models. If anything this data is under-representing the preference for permissive-style licenses, because while OpenRAIL licenses cannot be considered Permissive in the OSI-approved sense, in spirit they embody many of the same values.

Lastly, given the OSI context above, was to look at the specific breakdown of licensed projects carrying an OSI license vs an unapproved alternative.

Happily, among licensed projects, better than two thirds carried an OSI-approved license. We may not yet understand the exact role that open source will play within AI, but until there’s clarification a license style with a clear and unambiguous definition is proving to be the most popular choice – in spite or perhaps because of the contrasting styles of licenses that category contains.

For most of the conversation’s participants, however, it had been some time since anyone – us included – had examined the numbers in detail, both for the slope of the trajectory and for the context around the spending itself.

While any analysis of this type is limited by the data that’s available – large important players like Anthropic and OpenAI for example are, for now, private companies and therefore don’t report their metrics publicly – it is nevertheless worth looking at the investments large cloud players have made in recent years, and how they might compare to non-infrastructure centric technology vendors like Apple.

For starters, then, here is the Plants, Property and Equipment (PP&E) spend for the selected vendors over the past decade. As a side note, these PP&E figures exclude operating lease right-of-use (ROU) assets because the point of interest here is actual capital build out.

Of note here are the relative rankings in PP&E spend of the investments, as well as the slope pre- and post-ChatGPT release. Additionally, as has been well documented elsewhere, Apple has not felt compelled to respond to this cycle’s frenzied wave of datacenter construction and its PP&E spend has remained static while that of its industry peers has soared.

Next, here’s a look at the changes in PP&E spend per company year on year.

The most important note here is to ignore the 2023 spike in Oracle’s PP&E; that’s an artifact of its 2022 $28B acquisition of the electronic health records company Cerner, with its datacenter, infrastructure and facilities hitting Oracle’s books in the following calendar year.

Other than random spikes in investments from Amazon, Meta and others, the only significant takeaway from this chart are the slopes again pre- and post-ChatGPT. Year on year growth in PP&E spend had plateaued and arguably declined heading into 2022, which is appropriate as the cloud market was maturing six years in. But these trends took an about face in the wake of ChatGPT’s breakout success, and increases in PP&E spend immediately accelerated.

Arguably the most startling chart, however, is that of PP&E spend as a percentage of annual revenue.

Apple and Meta bookend this chart as the opposite ends of the spending spectrum. But it’s notable how close the trajectories of Amazon and Google, and later Microsoft and much later, Oracle are as a percentage of revenue. It is eye opening that all but one of these companies – Apple being the notable exception – are spending at least half of their revenue figure, and most well north of that, on new infrastructure.

That level of investment would have been unthinkable a decade ago. Today, the chart suggests it’s table stakes unless you’re a commercial device retailer.

While PP&E spend is too blunt an instrument to perform a much more detailed analysis, it both points to the extreme level of investment required to be regarded as a credible player and raises significant questions about where, when and how the return on these outsized investments will arrive.

Disclosure: Amazon, Google, Microsoft and Oracle are RedMonk customers. Apple and Meta are not currently customers.

This iteration of the RedMonk programming Language Rankings is brought to you by Amazon Web Services. AWS manages a variety of developer communities where you can join and learn more about building modern applications in your preferred language.

This edition of the RedMonk Programming Language Rankings is either three months late or two months early, depending on whether you go by the calendar year or when we have been dropping our Q1 results lately. In any event, we have been hard at work not only compiling the latest rankings for your inspection, but also grappling with anomalies both transient and existential.

The latter issue, as my colleague discussed in detail here, is well understood. With the rise of ever more sophisticated coding assistance tools, Stack Overflow’s relevance to a generation of developers has been in decline, with the result being that its tags which make up part of half of these rankings are growing more slowly and are therefore less representative. And thus Stack Overflow’s position and prominence in our rankings has also come into question. Should it still be one axis of our rankings? And if not, what might replace it?

As obvious as that question might have been, however, the one that has more recently thrown us for a loop is an anomalously low second half’s worth of pull requests from GitHub. We’re honestly not sure what to make of a decline in the volume of PRs in a time when the velocity of code creation is rising due to coding assist tools. It’s possible that this is an artifact of bad or missing data from the GitHub Archive. Or it could be that while code creation is accelerating, the percentage of code committed to open repositories is declining. We’ll continue to explore the question, but as you consider this iteration of the rankings it’s important to note that there are not just questions about one axis this run but two.

In the meantime, however, as a reminder, this work is a continuation of the work originally performed by Drew Conway and John Myles White late in 2010. While the specific means of collection has changed, the basic process remains the same: we extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction. The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends.

Our Current Process

The data source used for the GitHub portion of the analysis is the GitHub Archive. We query languages by pull request in a manner similar to the one GitHub used to assemble the State of the Octoverse. Our query is designed to be as comparable as possible to the previous process.

• Language is based on the base repository language. While this continues to have the caveats outlined below, it does have the benefit of cohesion with our previous methodology.
• We exclude forked repos.
• We use the aggregated history to determine ranking (though based on the table structure changes this can no longer be accomplished via a single query.)
• For Stack Overflow, we simply collect the required metrics using their useful data explorer tool.

With that description out of the way, please keep in mind the other usual caveats.

• To be included in this analysis, a language must be observable within both GitHub and Stack Overflow. If a given language is not present in this analysis, that’s why.
• No claims are made here that these rankings are representative of general usage more broadly. They are nothing more or less than an examination of the correlation between two populations we believe to be predictive of future use, hence their value.
• There are many potential communities that could be surveyed for this analysis. GitHub and Stack Overflow are used here first because of their size and second because of their public exposure of the data necessary for the analysis. We encourage, however, interested parties to perform their own analyses using other sources.
• All numerical rankings should be taken with a grain of salt. We rank by numbers here strictly for the sake of interest. In general, the numerical ranking is substantially less relevant than the language’s tier or grouping. In many cases, one spot on the list is not distinguishable from the next. The separation between language tiers on the plot, however, is generally representative of substantial differences in relative popularity.
• In addition, the further down the rankings one goes, the less data available to rank languages by. Beyond the top tiers of languages, depending on the snapshot, the amount of data to assess is minute, and the actual placement of languages becomes less reliable the further down the list one proceeds.
• Languages that have communities based outside of Stack Overflow such as Mathematica will be under-represented on that axis. It is not possible to scale a process that measures one hundred different community sites, both because many do not have public metrics available and because measuring different community sites against one another is not statistically valid.

With that, here is the first quarter plot for 2026.

1 JavaScript
2 Python
3 Java
4 PHP
4 C#
6 TypeScript
7 CSS
7 C++
9 Ruby
10 C
11 Swift
12 Go
13 R
14 Shell
14 Kotlin
14 Scala
17 PowerShell
18 Dart
18 Objective-C
20 Rust

We have become accustomed to little movement within our top 20 over the last few years – see my colleague’s top 20 historical rankings here – and this quarter’s run is no exception. We had one slight change within the top five languages, as we’ll discuss shortly, and some movement in the back half of the top 20, but overall, the rankings tend to have a great deal of inertial weight. As we’ve acknowledged previously, some of this stasis is an undoubtedly a function of Stack Overflow’s declining relevance.

But we’ve also been waiting to see what impact coding assistant tools might have on language usage. In theory, given that coding assistants make developers’ familiarity with a language less relevant and the tools’ propensity to reflect the biases inherent in their training data, it would be logical to expect some meaningful change in language usage and distribution patterns. To date, however, these have not manifested themselves in the data we can see, though it’s worth noting that we have a limited sample of data from the post-Open 4.5 inflection point in late November. The next quarter’s run should therefore be interesting; when more and more developers are outsourcing not only the act of coding but language choice to models, what does that mean for language adoption? We’ll hopefully have more to say on that next run.

For now, here are a few results of note:

• C# (6): language movement in our top 20 is, as noted above, relatively rare. Shifts within our top 5 are even more so, as these rankings are accretive and thus resistant to transient shifts. But C#, a relatively unheralded language in 2026, moved up one spot from #5 to #4, putting in a tie with the giant of the web, PHP. It’s unclear what’s driving this increased traction, or even if it’s an improvement on C#’s part or a modest decline on PHP’s part. If it’s the latter, it will be interesting to follow Cloudflare’s Emdash product. If the “spiritual successor” to WordPress gains traction, its base language – TypeScript – could benefit at the expense of PHP.

• Dart (18) / Rust (20): speaking of unexpected results, Dart’s rise from the bottom of our top 20 to #18 is something of a surprise. Not because the language doesn’t have fans or that it’s a huge jump, but rather because to get to #18 it had to pass the developer darling, Rust (#20). This is particularly notable because coding assistance tools, in theory, should be lowering some of the barriers to entry with Rust. If that’s happening, however, it’s not observable yet.

• Objective-C (18): when we first started these rankings in 2012, Objective-C was a steady ninth or tenth for years. A few years after the spectacular rise of Swift, however, Objective-C entered a slow, measured decline phase. This iteration’s rankings list it at #18, and based on its trajectory as well as that of languages around it, it’s plausible that Objective-C – its one-time iOS primacy notwithstanding – may make a permanent exit from the top 20.

• Ballerina (74) / Bicep (66) / Grain / Moonbit / Zig (82): among the “languages we’re paying attention to” set, there was some movement, but that’s to be expected from the back half of the top 100 where even differences at the margin can prove to be meaningful in ranking. First up is Ballerina. One quarter after dropping from 61 to 64, Ballerina slid another ten spots down to 74. Bicep, for its part, bucked its recent decline and shot up to 66 from 79. Grain and Moonbit were still not ranked, but Zig continued its deliberate ascent up the rankings from 86 to 82. It’s worth noting however, as we have previously, that Stack Overflow’s general malaise is likely disproportionately impacting these would be growth languages. Zig, for example, is up to 58 on GitHub – meaning actual code contributed – but is 83 as measured by Stack Overflow tags. Its performance and that of its peers will be factored in as we consider what to do with Stack Overflow moving forward.

Credit: My colleague Rachel Stephens wrote the queries that are responsible for the GitHub axis in these rankings. She is also responsible for the query design for the Stack Overflow data.

First up, we’ll compare the non-merge commit velocity.

Unsurprisingly, Valkey’s velocity surges in the wake of the original fork. That peak is not maintained, but it is notable that with the exception of two months last year, Valkey has sustained a slightly greater commit velocity than Redis.

Next, here are the Active Contributors over time.

As a federated, multi-party project versus the generally single entity Redis, Valkey inevitably shows a larger number of active contributors. Notably, however, the delta at any given point does not tend to be massive – typically in the single digits.

As a complement to active individual contributors, here is the organizational diversity as inferred from domains (and in the case of GitHub, where possible user profiles were used to assign company).

Given the project structures, approaches and governance, this chart plays out as expected, with Valkey demonstrating a marked advantage in the number of distinct organizations contributing to the two projects.

Breaking that down in more detail, here are the top organizations by domain (and with a subset, GitHub profile employment information providing inferred employment).

Long the bane of analysts trying to accurately assign contributions to corporate employers, the quite understandable decision of individual developers to contribute code using their own personal identity rather than corporate credentials is clearly on display here with Gmail addresses representing the largest body of committers for both projects. Also of note, as could be predicted by the previous chart, Valkey features a longer list of substantial committers than Redis, who dominates its project and has a longer, thinner tail of external contributors.

While the chart above looks at organizational project contributions as measured by commits, here is the organizational breakdown by actual contributors.

Amazon dominates this chart for Valkey with 30 measured contributors, but Aiven, Alibaba, ByteDance and Google all have at least three different Valkey contributors while Percona checks in with two. Redis’ chart reads like strategic upstream contributions from large users of the project. And as a side note, est.tech (Ericsson)’s two contributors have an outsized impact per the chart above.

Lastly, here are the top individual contributors to each project.

The most notable takeaway here is that antirez, AKA Salvatore Sanfilippo, the original author of the Redis project, appears to have had no issues stepping back in as a key contributor to the project he founded.

tl;dr

As noted above, the limitations of commit data do not allow any conclusions to be drawn about market traction and directional shifts in usage patterns. But the available evidence does suggest that two years in, Valkey is not behaving like most forks and declining in interest, commits and project traction. Instead, it seems to have found a level of sustainable development velocity that shows no signs of stagnation, one enabled by a relatively diverse set of project backers. It remains, therefore, a project RedMonk is tracking with interest.

Disclosure: Amazon, Google and Percona are RedMonk customers. Aiven, Alibaba, ByteDance, Ericsson and Redis are not current customers.