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.

That unfortunate apathy notwithstanding, assertions that open source “doesn’t really matter” have never been any more defensible than saying climate change doesn’t matter because the average citizen pays it little mind. While the industry is undergoing tectonic shifts due to the incredible advances in AI, and there are multiple lines of potentially intractable questions about how open source licenses apply in this new era, the fact is that open source software is still being produced, and licensing decisions made around them are still being made strategically – see Swamp’s license choice, as but one example.

All of which means that it’s important to periodically take stock of the open source licensing landscape, to step back and evaluate its trends and tease apart what those might suggest about our industry and the choices its making moving forward. One of the last times we did this was in 2017, when the best available data was from Black Duck.

To bring that up to date, we’ve compared and contrasted historical data from sources no longer extant (Black Duck), sources that are still available but have undergone significant, disruptive transitions in the dataset (the GitHub Archive), and current, active sources (deps.dev – a superset of software package repositories). A few caveats before proceeding:

• As noted above, in the largest single source of this data, the overwhelming majority of projects – likely 80% or more – do not carry licenses and are thus not represented in this analysis. Given that the cost of producing software is approaching zero thanks to step function changes in code assist abilities, this delta will likely only increase.

• There is no single source of truth for the industry. Some datasets as mentioned are no longer available. Others like the GitHub Archive have undergone changes over the years making consistent measure hard to impossible. And none of them have insight into the full spectrum of software written and relied upon behind enterprise firewalls.

• Much like with RedMonk’s Programming Language Rankings, then, this analysis should be considered an evaluation of the data that’s available rather than a full fidelity representation of the licensing reality.

Those limitations acknowledged, there are nevertheless some interesting takeaways from the data that is available. Here are the key themes worth noting for open source licensing in 2026.

The Rise of Permissive Licensing

Noted here well over a decade ago, the industry has been amidst a long term shift away from more restrictive, copyleft-style licenses to more permissive alternatives. The precise ratio of copyleft to permissive licenses has depended on the year and the particular sample surveyed, but they all have shown a marked shift away from copyleft licenses.

It’s difficult to pinpoint the exact point in time that we moved from a copyleft majority licensing environment to a permissive one, but a reasonable estimate is that the industry unknowingly crossed that chasm at some point between 2014 and 2017.

To some degree, this was inevitable, as copyleft’s absolute dominance from a licensing standpoint can be appropriately understood as being at least in part an artifact of the overwhelming popularity of copyleft projects such as Linux and MySQL. Greater license diversity was always likely, if not inevitable.

One interesting question is whether, as so often happens in industry, the pendulum will begin to swing back towards copyleft. With the caveat that there are odd small sample size issues with recent GitHub Archive data, there is some evidence to suggest this. Permissive licenses have ticked down from a high of 82% in 2022 to 73% in 2025. Again, this could simply be a sampling issue – the packaging data from deps.dev indicates no similar shift – but it’s worth watching if only because of the recent return from a few major projects to the AGPLv3 in particular which will be discussed more momentarily.

License Distribution by Package Ecosystem

Before looking at license traction as a whole, it’s worth examining community-level differences and drivers. This is based on data extracted from deps.dev, and looks at the license distribution across seven major package repositories.

As is evident, these repositories – like the data more broadly – tend to skew permissive. There are notable issues with certain repositories – in NuGET, the .NET package repository, more than half the packages have licenses that don’t map to SPDX identifiers and are thus unclassifiable. The npm package repository, meanwhile, skews heavily towards the ISC license as npm init historically defaulted to it. Maven’s Java focus, meanwhile, left it solidly in Apache’s orbit.

It’s worth noting, however, that these packages generally reflect deployed code, and as will be shown momentarily, the deployed code shows higher rates of permissive license usage than copyleft. That being said, also as we’ll come back to, npm’s weight in this sample – being roughly 3X more than the other repos combined – is overrepresented.

Apache vs MIT

The two primary beneficiaries of the rise of permissive licensing have been the Apache Software License and the MIT. In part because of its patent termination provisions that attempt to minimize the possibility of patent infringement litigation, Apache has tended to be the preference for commercial open source usage versus the MIT license which does not mention patents at all.

Both licenses dramatically improved their share of usage over the past two decades, but following the creation of the CNCF which favored Apache licenses in 2015 and the introduction of popular Apache licensed projects like TensorFlow in the same year and PyTorch the year after in 2016, Apache’s share of distribution began climbing in 2017 to a peak in this dataset of around 30% in 2022. This corresponded with a slight but noticeable decline in MIT’s share over that time, suggesting that the growth of the one came at least indirectly at the expense of the other.

In 2023, however, this trend reversed in dramatic fashion, and Apache usage dropped dramatically while MIT spiked. In all likelihood, this is an artifact of oddly smaller sample sizes post-2022, culminating in a dramatically smaller 2025 sample RedMonk is still seeking explanations for as we perform our regular biannual programming language ranking.

It’s also possible that it’s in part a reflection of the aforementioned outsized significance of JavaScript as a language and npm as a repository, as the latter favors MIT and hosts by far the most packages. Which brings us in turn to:

The Packaging Filter

One interesting exercise to consider is what deltas if any there might be between hosted source code and packaged code about to be deployed. In general, the differences tend to be minimal, but one obvious distinction is in the aforementioned outperformance of ISC. A historical default for npm, it is dramatically over-represented in the deps.dev dataset, being 31X more common there than on GitHub – a natural consequence of npm’s immense presence.

Both GPL licenses, for their part, are much more common on GitHub – 34X more common in the case of version 2 – than in deps.dev, which is predictable given the latter’s overwhelming preference for permissive rather than than copyleft licenses.

As a side note, while reading this chart: the “Unlicense” above is not a typo for “Unlicensed,” it’s an actual license that says, essentially, users can do whatever they want they want with the code. It’s more or less public domain for source code.

Source Available Licenses

One last question when surveying the state of licensing in 2026 is the degree to which non-open source, source available or hybrid licenses such as the BSL or SSPL are in circulation. The short answer to this is that these licenses are not measurable in a statistically significant way. They remain extremely uncommon and are not trending.

While they are not relevant statistically, however, they remain for the time being strategically relevant because of the projects that carry them (e.g. MongoDB, Terraform, etc). While there have been notable returns to open source licenses from source available alternatives – Elastic and Redis, for example, returned to an OSI approved license in the AGPL – the long term future of source available licensing will not be determined by a quantitative analysis such as this.

As the last digit on the calendar rolled over from five to six, it took less than a month to realize the coming year was going to be different than the year that preceded it. Arguably the stage was set late last year with the November “inflection point” but with open source AI projects becoming so popular overnight they caused runs on hardware and meaningfully moved the share price of public companies, 2026 is an unambiguously and unapologetically new world.

It can be difficult to recall now, but five years ago when Copilot made its debut, capabilities that now seem basic were mind blowing. Much as the iPhone we now take for granted was once an earth shattering technical achievement, the jumped up autocomplete that was the initial coding assistant tool gave way to models that progressed at shocking rates with capabilities that broadened just as quickly. Early, confident predictions that coding assistants were merely for scaffolding while actually creative code would always be the purview of humans were, in a word, wrong. We’re now living in a world in which a growing number of legitimate developers are discussing and in many cases shipping code that has never been reviewed by a human.

In 2026, coding assistance agents – the software manifestations of coding assistance models – are extraordinarily capable, and only growing more so by the day. Attitudes towards them have therefore been forced to evolve. There is still a wide spectrum of viewpoints on AI, of course, ranging from they’re useless and evil to they’re gods among us.

The baseline assumption from here though is that as of 2026, agents are real and capable of tasks we could not have foreseen even a year or two ago. Capable to the point that they are changing how software development is done, almost certainly permanently.

As Adam Jacob said about using these tools:

If you’ve been reading what I write, it’s not like I’ve been a believer the whole time. But I am today. Because I’m doing it. It’s amazing. We will never go back, as an industry. We will simply use this capability and catapult forward.

The step change in functional ability from the agents of 2021 to the agents of 2026 is worth taking a step back to appreciate, because it represents nothing less than a siege. Or more accurately, multiple, ongoing sieges. Here is a non-exhaustive look at a few of the impacted targets.

Individuals

Long promised to reduce or even eliminate work, recent research from the Harvard Business Review argues that it does the opposite. This assertion, notably, was quickly seconded by everyone from the industry’s most comprehensive AI researcher to one of its best psychologists. While the article doesn’t cite Jevon’s Paradox, it might well have. As AI has made its capabilities more efficient to use, consumption and resource demands have risen as the theory predicts. The import of which is that far from transitioning into an environment in which working hours are reduced due to time saving AI tools, workers instead have, if anything, taken advantage of the time saved not by taking time off but by taking more work on. That is going to require a societal-level adjustment and recalibration.

In specific domains, such as within the narrower scope of developers, AI has had a similarly outsized impact as they are being forced to rethink their role in the grand scheme of things. One of the best working analogies is home construction. Historically, developers have been builders: framing out walls, cutting stringers for stairs and so on. Today, many developers see themselves as more akin to architects, not framing the walls but deciding where they get placed, not stringing the stairs but deciding how high they go. For some, this is enormously empowering. Others are experiencing a profound sense of loss, as the uniqueness and inaccessibility of their skillset is eroded. As one Tweet put it:

I don’t know why this week became the tipping point, but nearly every software engineer I’ve talked to is experiencing some degree of mental health crisis.

Maybe there is no better evidence of a siege than Evan Ratliff’s Shell Game podcast, however. In it, the journalist unleashes a sea of AI bots trained on his own voice and to impersonate him, leveraging the same techniques that scammers and spammers are adopting to attack us. Opportunity and threat are on equal display as we’re besieged by AI clamoring for our attention while we feel pressure to use AI for our own ends, whatever those might be.

Communities

Communities and more particularly open source communities are grappling, meanwhile, with the inevitable implications of AI and its lowered friction to code creation and an inevitably higher volume of traffic from it. Projects are flooded with requests, contributions and issues generated by AI systems, some of which are legitimate and useful, most of which are not. Which is not too different that normal OSS project inputs except in their increase (Mitchell Hashimoto estimates it’s a 10X difference).

This has led some projects like Ghostty above to limit AI-driven contributions, up to and including a ban on would be contributors that don’t respect the policy. Others like Liz Fong-Jones and Adam have considered the possibility of eliminating external contributions entirely. Mitchell has tried to implement a less drastic approach by systematically restricting who can contribute via the Vouch project. For her part, however, Angie Jones argues that such policies are overkill, and instead it’s incumbent on OSS projects to prepare and provide a path for responsible AI-driven contributions.

In any event, there’s little debate that communities are under siege.

Applications

As are applications. Specifically, they’ve been hammered by public markets convinced AI has made them irrelevant. The essence of the trend is summed up by the headline, “‘Get Me Out’: Traders Dump Software Stocks as AI Fears Erupt.” The drivers of this panic are myriad, but most ultimately boil down to the same issue: if code becomes fungible, what are companies that sell code – i.e. software vendors – actually worth?

This whole line of thinking isn’t new. For example, in comments on a podcast in December of 2024, Satya Nadella said:

The notion that business applications exist, that’s probably where they’ll all collapse, right in the agent era.

His actual argument was more nuanced than the “SaaS is Dead” headlines made it seem, but the core hypothesis was clearly and unambiguously bearish for SaaS vendors. An argument that many of today’s sellers of SaaS stocks would understand and agree with, and one that makes sense if you believe that SaaS vendors are primarily selling software. Anyone who has spent any time as a systems integrator, however, would almost certainly argue that software is just part of what is being sold, and in many cases a small part. A few examples:

• As others have observed, if you’re buying HR software, you’re also buying domain expertise – and arguably more importantly, liability mitigation – across the globe. Same with accounting, CRM, ERP and more. The app that is built from software is not the real challenge.

• That point, as noted, is reasonably well understood and articulated. Less mentioned is the talent pool. If you run packaged applications like Salesforce or Workday, you can hire experienced resources to administer and use that software. If you’ve built your own, as many financial institutions have discovered after building their own internal developer platforms rather than using platforms such as Cloud Foundry or Open Shift, your new hire’s first day will also be their first with your software. That makes hiring more challenging and onboarding and ramp up less efficient, which implies that the operational benefits have to be extensive to offset the HR costs.

• Speaking of operations, one of the questions facing those who would replace off the shelf alternatives hasn’t changed in spite of AI’s dramatic reduction in development time: is investing in non-differentiating software worth the opportunity cost that could be spent on software that is differentiating? Is an organization better off recreating a CRM system, in other words, or creating something new for their organization that doesn’t exist? It’s a complicated equation with many variables, obviously, not least of which is the cost of SaaS applications. But on balance, it’s also self-evidently not a simple win for AI.

While the enterprise application market may be besieged, then, it seems just as likely AI is more likely to settle into an Amdahl mug role than blow it up entirely. Investors, however, are currently seeing it differently.

Infrastructure

As discussed previously, Gas Town (and now Claude Code, natively) mean that one developer can now magically become 10-20 virtual developers. We know from our experience with open source communities that projects are absolutely not equipped to handle that increased scale. The next question is, is our developer infrastructure?

As it turns out, the answer is no. Our infrastructure is not prepared for that.

Witness, for example, this open letter from eleven open source foundations or package repositories. It documents the “Tragedy of the Commons” problem typical of open source infrastructure, and then goes on to blame AI for making it worse:

The rise of Generative and Agentic AI is driving a further explosion of machine-driven, often wasteful automated usage, compounding the existing challenges.

What was already a problematic situation, in other words, has been made more challenging by the sea of agents currently arriving at their gates.

Economics

Arguing that public markets have been besieged by AI isn’t particularly challenging. Consider the massive capital investments currently being poured into AI related infrastructure, over the rising objections of investors losing patience. Or the fact that AI is massively overrepresented in public markets broadly. And that’s without even getting into the Three-card Monte math of some of the investments in the space. Objectively the industry is in a bubble, and bubbles have only one fate.

But even on a micro, individual scale, the economics are starting to pinch, and that is likely to get worse before it gets better. And to judge by industry chatter and recent vendor briefings, that will be happening soon. For all of the abilities of tools like code assistance, the market realities are beginning to hit home.

This process arguably began this past summer when, in an attempt to control costs, Cursor adjusted its pricing and faced a wide scale backlash. From the conversations RedMonk has been having this year, there’s more of this coming. Companies that focused strictly on capabilities – “free during preview,” expenses be damned, are now facing something of a reckoning.

The economics, meanwhile, are equally problematic for individuals. Much as households are facing multiple bills for different streaming services from Disney to Netflix, many developers feel compelled to subscribe to higher cost models, or even multiple high cost models. Case in point is this developer who was repeatedly locked out because he was consuming $2600 worth of tokens per month; he managed to get it down to ~$100, which incidentally is $100 per month more than developers would have spent on their tooling in the pre-AI world. Here, meanwhile, is someone in management spending $200 per month and budgeting $1-$2K per month per dev on their team. A developer in a local Slack went even further, reacting just this week to a Software Factory post by saying:

The $1k/day/person number jumped out at me, but I suspect that’s going to sound quaint before too long.

AI is a different world, and a much higher cost one at that.

Conclusions

The above, as mentioned, are just a few examples of impacts to this industry. The real world implications are much broader, hence the anxiety, apprehension and fear associated with increased use of AI. Understandably so.

Is the ongoing AI siege all bad, though? Is this likely to end as medieval sieges did – poorly?

First, it’s worth pointing out that new developments in automation, however, are rarely linear or entirely predictable. This chart of bank teller employment pre- and post-ATM introduction from Dr. James Bessen would have been very counter-intuitive at the time. It is only in retrospect that it’s easy to see that with the introduction of new ATM fees and automating mundane, low value tasks like cash dispensing would allow banks to open many more branches, thereby boosting overall employment for a role whose putative function had been automated out of existence.

Perhaps more importantly, however, for all of their costs, these tools are, or can be, powerful accelerants and enablers for people that dramatically lower the barriers to software development. They have the ability to democratize access to skills that used to be very difficult, or even possible for some, to acquire. Even a legend of the industry like Grady Booch, who has been appropriately dismissive of AGI claims and is actively disdainful of AI slop posted recently that he was “gobsmacked” by Claude’s abilities. Booch’s advice to developers alarmed by AI on Oxide’s podcast last week? “Be calm” and “take a deep breath.” From his perspective, having watched and shaped the evolution of the technology first hand over a period of decades, AI is just another step in the industry’s long history of abstractions, and one that will open new doors for the industry.

Lastly, whether one wants those doors opened or not ultimately is irrelevant. AI isn’t going away any more than the automated loom, steam engines or nuclear reactors did. For better or for worse, the technology is here for good. What’s left to decide is how we best maximize its benefits while mitigating its costs. AI is the epitome of “two things can be true.” On the one hand, the economics of AI are likely to get ugly in the near term and as for digesting these tools, as the conclusion of the quote from Adam above that was withheld put it, “It’s going to be an absolute mess while we sort it out.”

On the other, much like the internet before it, the technology has crossed a threshold from “intriguing toy” to “world changing evolutionary wave.” This industry will never be the same.

How well and efficiently it and the society around it decides to balance the costs and benefits, however, will determine how long the siege will carry on, and what’s on the other side.

Disclosure: GitHub (Copilot), Oxide, Red Hat (Open Shift) and Salesforce are RedMonk customers. Anthropic (Claude) and Workday are not currently customers.

Many years ago, a large European bank spoke to analysts after its first transition from purely physical hardware into virtual machines. While expressing overall satisfaction with the move, its enthusiasm was clearly tempered. When pressed on the hesitant endorsement, the bank’s representative stated that virtual machines had, in fact, accomplished all of the desired goals: their infrastructure and usage were far denser, utilization was up, stand up and instantiation times were down and so on.

All of which led to a natural response: “it sounds like there’s a ‘but’ coming.”

To which the executive replied, “virtual machines have been good for us. It’s just that going from managing 500 physical machines to 5,000 virtual machines has been…a challenge.”

This pattern, in which a given unit of technology is decomposed into smaller units of a technology, is one that has played out repeatedly over the last few decades in this industry. One of the more recent examples of this was the trend towards microservices, in which larger APIs were deconstructed into multiple smaller component services in search of more granular control and development velocity.

In every case, this leads to a management challenge. What makes sense on paper and may indeed make sense in practice does not come without an offsetting cost. Just as there an array of benefits to virtual machines and its successor, containers, or to microservices, it’s important to consider not just the short term advantages to decomposition but the longer term implications of it on a going forward basis. How do you manage thousands of VMs when your existing infrastructure was designed to manage hundreds or even dozens of physical machines? How does your network cope with an exponential increase in the number of active services and endpoints?

These questions seem particularly important in 2026. Last year was in effect the year of the agent. The industry had begun to digest the abilities – and shortcomings, importantly – of existing models and related technologies, and had followed the typical industry progression from a given monolith – all encompassing AI models – to its logical conclusion, decomposed, individual AI services, or agents, that were the functional equivalent of a microservice. Small, independent and with some degree of autonomy, what ultimately came to be described as the “agentic” vision of AI was one describing fleets of individual AI agents operating in concert with one another and various third parties both human and otherwise.

All of which means that the next challenge in front of the AI market is management.

This is already evident to an extent in the domain of code assistance. As code assist progressed from enhanced autocomplete to the autonomous generation that is vibe coding, developers have gradually transitioned from builder to architect. At which point, people began to ask a logical question: if agents are as easily spun up as VMs could be once upon a time, what would happen if we added more builders?

Rather than one agent building code, then, they began deploy larger and larger numbers of them, with a primary gating factor of token costs. Referred to by many names, “swarm coding” among them, the practice has become increasingly common as developers and their employers deploy teams of coding agents in an effort to improve overall velocity, code quality and to leverage the differing strengths of varying models.

The obvious problem, then, was how to manage these swarms of autonomous coding agents. Enter Gas Town. Written by Steve Yegge (that Steve Yegge) and billed as a “new take on the IDE for 2026,” Gas Town is a way to manage and orchestrate swarms of code assistant agents – up to 20 to 30 of them – much as Kubernetes does the same for fleets of containers.

It’s overkill for many, Gas Town is merely one initial stab at this problem and Yegge himself goes out of his way to dissuade anyone using less than ten agents from using it. And swarms are not the only option for those seeking greater speed and refinement – Ralph Wiggum is an iterative, looped single agent alternative that has proven very popular with developers.

But it’s clear within the specific domain of code assistance that swarm coding is going to be a primary if not default approach, and it’s equally clear that swarms of agents are going to be deployed across multiple domains in the quote unquote agentic future. If you’re looking for 2026 trends to track, then, how the industry is going to manage the flood of AI agents is a critical question. If it’s not solved, as Yeats said, the blood-dimmed tide will be loosed, and everywhere the ceremony of innocence will be drowned.

GitHub Copilot was originally released in October 2021, four years ago. So much has happened since, it can be challenging to remember what a revelation it was. As has been discussed previously, it wasn’t that the idea itself was without precedent, but the capabilities, the scope and the scale were without peer. Though the concept of a pair programmer that is available 24 hours a day, seven days a week is table stakes in 2025, in 2021 it was, for many developers, mind blowing.

A little over a year after that, however, OpenAI introduced ChatGPT, the interface to its generative model that could produce code like Copilot, but handle a nearly unlimited list of other tasks – if often imperfectly. Thus opened the era of Large Language Models (LLM), the mercurial era we continue to speedrun through today.

The LLM era has seen models embedded in every software and hardware format in existence, and now is increasingly flowing the other way with software being embedded into models. The large frontier models remain almost infinitely versatile, capable of handling almost any conceivable workload from full real-time speech inputs to text-to-video outputs. The narrower domain of coding assistance, however, opened up widely by Copilot years ago, has likewise evolved rapidly. As it’s evolved, it’s upended core assumptions about the development tools market, most obviously that such tools must be free and would command the loyalty of their users.

The promiscuity of developer tool adoption, in fact, has led to short, accelerating cycles in which a new tool with differentiated capabilities emerges, only to shortly be eclipsed by another new tool with new capabilities and approaches. Copilot had its year before ChatGPT (Nov 2022), which had its year before Cursor (Oct 2023), which had its year before Windsurf (Nov 2024). And that’s without getting into the literally dozens of other tools and approaches on the market, a non-exhaustive list of which would include Aboard, Bob, Bolt, Cline, Claude / Code, Gemini / Jules / CLI, Factory, Kiro, Lovable, Poolside, Replit, Same.dev, vibes.diy, v0 and the list goes on.

Each new tool that has its moment in the sun, however, seems to fly a bit too close to it and inevitably, if potentially temporarily, fall back to earth. Sometimes it’s because of the introduction of another breakthrough tool. Sometimes it’s because the team you’re competing against is working their team to death. And sometimes it’s because the bill for tokens comes due. Regardless, it makes for a market about as predictable as the weather in New England.

Which brings us back to this year’s GitHub Universe, though the event was held on the opposite, and much warmer, coast. There was no launch the magnitude of Copilot at Universe this year. Though the company behind the scenes is thinking hard about what the future of development looks like, this year’s announcements – from Agent HQ to Code Quality to Mission Control to Plan Mode – were more about raising the capabilities floor than its ceiling. And for those expecting a new Copilot, this might have been a let down. That simple conclusion can obscure some subtle, more important takeaways from this year’s event, however.

• First, it’s clear that seven years into its acquisition, Microsoft and GitHub are becoming more closely intertwined. Arguably the clearest sign of this was when CEO Thomas Dohmke departed in August and was not replaced, but even at Universe Microsoft personnel were much more visible and tightly integrated into the event than in years past. A greater Microsoft presence does not come without risks, but it also brings immense resources, operational capabilities and – as always – nearly unlimited enterprise account access. In a market that is moving from FOMO to ROI, those things matter. Early signs as well are that as much as Microsoft is integrating with GitHub, GitHub is likewise integrating with Microsoft.
• Second, GitHub is shipping again. Team after team, product after product, GitHub has shifted from a cycle of refinement to one of shipping at velocity. The list of features and enhancements announced at Universe numbered in the hundreds. Some of this is driven by competition with the aforementioned competitors actively unconcerned about burning out their teams, but in many cases it’s simply an executive mandate to ship and ship often. Every software company cycles through periods where they ship and periods where they polish, and in the wake of Universe it’s clear that GitHub is in the former.
• Last, there is the landscape. The years since Copilot debuted have been something akin to an industry fever dream, in which an unending flow of seemingly magical new capabilities let loose vast spigots of capital investment. Developers flitted from tool to tool with Bohemian abandon. Enterprises said get AI and we’ll figure out what to do with it later. Looking around at the market, however, it is now later. Budgets matter suddenly. Buyers are shifting their gazes from potential to measurable impact. Procurement is pushing for vendor consolidation. In such a climate, the combination of GitHub and Microsoft not only represent a wide range of technical capability, but predictability and stability from an enterprise perspective. Frothy, bubbling markets have a tendency to benefit the incumbents, and in the developer tools space no one is more incumbent than GitHub.

GitHub Universe 2025 may not have broken much new ground from a product standpoint, then, but it was nevertheless a crucially important event for understanding where the company and its parent are headed, and as a consequence, where the industry around them is headed. As for Copilot more specifically, you can’t call it a comeback because it’s been here for years, but if GitHub can keep shipping, the code assist landscape will get a lot more interesting, and soon.

Disclosure: AWS (Kiro), GitHub, Google (Gemini et al), IBM (Bob) and Microsoft are RedMonk customers. Aboard, Anthropic, Bolt, Cline, Cursor, Factory, Lovable, OpenAI, Poolside, Replit, Same.dev, Vercel and vibes.diy are not currently customers.