AI was big in 2025, but so were many other developments and worries.

The biggest open source stories in 2025 clustered around AI, licensing/governance, security and the shift in the “commercial open source” business model. Let’s start, shall we?

1. Open Source AI Goes Big

While most of the money went to proprietary models, open source AI datasets, orchestration frameworks, evaluation tools and guardrail stacks have all seen gains.

Such open source AI efforts as Common Corpus, along with the dozens of AI projects hosted by the Linux Foundation’s AI & Data group are enabling us to use community infrastructure for generative AI rather than relying solely on proprietary APIs, making open AI stacks a serious option for businesses and users.

While the open source AI definition remains controversial, and very few AI projects fully qualify as open source by the strict requirements of the Open Source Initiative (OSI) AI definition, AI remains built on a foundation of open source software. The debate over open weights, data and training code will continue, but even the most proprietary large language models (LLMs) couldn’t exist without open source programs.

Agentic AI, owes everything to open source. To orchestrate our latest generation of AI agents, we’re using several programs.

The most important of these, at this early stage of the game, appears to be the Model Context Protocol (MCP). This is an open standard and open source implementation for uniformly connecting agents to tools, files, databases and other systems.

MCP is increasingly the “plumbing layer” under many agents and IDE assistants, and there are numerous open source MCP servers and toolkits that let any compatible agent framework plug into the same tools.

MCP isn’t the only agentic AI middleware that’s speeding up:

• In June, Google donated its Agent2Agent protocol, which standardizes how agents communicate with each other, to the Linux Foundation. Microsoft Agent Framework, an open source SDK and runtime designed for building, deploying and managing multi‑agent, MCP‑aware applications, is also gaining popularity.

2. Fights Over ‘Open’ vs. ‘Source Available’ Licenses Rage On

A Linux Foundation report released in August showed that venture capital‑backed commercial open source companies have outperformed comparable closed‑source vendors over the last 25 years.

That report, alongside open source adoption data from an April OSI survey, which from 96% of organizations are maintaining or increasing open source software use, has cemented commercial open source as the default way to build software.

Together, these reports are driving more funding, more mergers and acquisitions, and more “open core plus services” strategies around critical open source projects.

Of course, we knew that. After all, a 2024 Harvard Business School study already showed that 96% of commercial programs rely on open source and that the total value of open source code comes to a cool $8.8 trillion. That still doesn’t stop companies that made the mistake of confusing open source as a software development model with a business model; it never was. It never will be.

So it is that in 2025, we saw more companies move from open source to fauxpen source. For example, the ScyllaDBteam announced in December 2024 that it would move to a single “ScyllaDB Enterprise” stream under a source‑available license.

At the library level, there have been high‑profile examples of previously permissive projects switching quietly to source‑available, paid‑for‑commercial‑use terms, such as the Fluent Assertions .NET testing library moving, this past January, from Apache‑2.0 to a proprietary source‑available license with per‑developer fees.

Then, there’s the DevOps program Puppet. Although Puppet’s core codebase is still under the Apache 2.0 open source license, its commercial parent company, Perforce, has changed how official builds are distributed and licensed.

What changed is that new “hardened” binaries and packages built by Puppet/Perforce are now shipped from a private repository. The Puppet Core End User License Agreement (EULA) offers a free tier capped at 25 nodes, with commercial licensing required for additional nodes. Effectively, this makes Puppet a source-available program, even though the code is technically still open.

The result in Puppet’s case is the same as we’ve seen in other such attempts to close once open source projects: Unhappy programmers have forked the project. The fork is known as OpenVox.

These forked projects, which include Elasticsearch with its fork OpenSearch, Redis with the Valkey fork, and Terraform with the OpenTofu fork, have been somewhat successful. All four forks have achieved meaningful traction, but at different scales and under different definitions of “success.”

OpenSearch appears to be the most successful. It reports strong growth, including double‑digit, 78%, year‑over‑year download increases and a roster of major members such as Amazon Web Services, Canonical, SAP and Uber.

Valkey has also proven to be popular. The latest release, Valkey 9, is reported to be far faster than the newest version of Redis. In particular, Valkey users report that it’s consistently ahead of comparable Redis releases on raw throughput, especially on larger, memory‑heavy workloads where Valkey’s multithreaded I/O and cache‑prefetching kick in.

While OpenSearch and Valkey have both advanced beyond their parent projects, Terraform vs. OpenTofu is another story. People still see OpenTofu and Terraform as differing only in their licenses. Over the last few months, though, that’s been changing as OpenTofu, which joined the Cloud Native Computing Foundation in April, steers more of its own course. Latest releases now include state encryption, a feature the Terraform community has wanted for years, and early variable evaluation.

Finally, OpenVox continues to present itself as a “soft fork.” Its directors want it to stay 100% compatible with Puppet so it can serve as a drop-in replacement for Puppet deployments. That, however, appears to no longer be possible, as Gene Liverman, the leader of OpenVox, wrote, “We can no longer guarantee that our modules will work with Puppet Core or Puppet Enterprise.”

From the project maintainers’ viewpoint, Perforce is breaking compatibility. For now, though, OpenVox is essentially a healthy, community lifeboat rather than a full‑scale Puppet replacement ship.

3. Open Source Projects Are Starved for Funding

Despite the simple fact that we all depend on open source, all too many projects remain underfunded. Others, such as NET 6, are still popular, but their maintainers have quit supporting them. What’s a user to do?

This isn’t a new problem. Back in 2021, Tidelift, a security company that also financially supported open source maintainers, found that 46% of open source project maintainers received no pay at all. Almost as bad, even those who were paid, a mere 26% earn more than $1,000 per year for their work.

Things have not improved. In fact, they’ve gotten worse. In 2024, Tidelift’s latest results showed that now 60% of open source maintainers are unpaid.

As an open letter signed by 10 open source foundations and published in September pointed out, “Most of these [open source] systems operate under a dangerously fragile premise: They are often maintained, operated, and funded in ways that rely on goodwill, rather than mechanisms that align responsibility with usage.”

So it is that, according to the open letter, “a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extract economic value, consume these services without contributing to their sustainability.”

A specific example that I’ve been covering is howFFMpeg, which is used by everyone who watches videos over the Internet, is horribly underfunded, even as major companies such as Amazon, Google and Netflix depend on its code. There are many other such projects. This can not continue.

The answer is that companies must — Must — start financially supporting mission-critical open source projects. The cost to do this is minute compared to the damage they’d suffer if these projects folded or were hit by a major security problem.

4. The Open Source Supply Chain Is More Vulnerable Than Ever

In 2024, the xz data compression library code, which had been deliberately infected with malware, came close to inserting a backdoor into Fedora, Red Hat’s community Linux. Had it been successful, it might have ended up in Red Hat Enterprise Linux (RHEL) and its clones.

This would have led to the greatest Linux security disaster to date. We dodged a bullet.

Unfortunately, the open source software supply chain security is under sustained, high-volume attack, with npm- and PyPI-focused campaigns escalating.

Several high-impact campaigns in 2025 centered on compromising open source package ecosystems, especially npm.

In November, researchers from Wiz, Aikido, and others detailed a “Shai-Hulud 2.0” wave of trojanized npm packages that exfiltrated developer and CI/CD credentials from environments using popular libraries tied to major Software as a Service and cloud tooling.

Tens of thousands of malicious repos were spun up as part of the campaign. GitLab’s vulnerability research team also reported a separate widespread npm supply chain attack that harvested credentials for GitHub, npm, and major clouds and propagated by infecting additional packages owned by victims.

These are not one-off instances. Industry threat reports in 2025 describe a surge in software supply chain attacks overall, with October setting a new monthly record, and open source ecosystems featuring prominently among the targets.

Analysis from Palo Alto Networks’ Unit 42 and other research teams notes that attackers increasingly prefer compromising maintainer accounts and publish pipelines rather than core source repos, because this path can silently poison trusted packages at scale.

A study by ReversingLabs, released in March, reported that, while observed open source malware packages have declined somewhat, the risk has shifted toward leaked developer secrets and build-time exposures.

Researchers examining popular npm, PyPI, and RubyGems components continue to find hard-coded credentials, weak application hardening, and exposed data inside widely used binaries deployed in enterprises. That kind of mistake was stupid back in the ’80s, when I first encountered it in production software, and it’s unforgivable today.

Making matters worse, security companies such as JFrog and Veracode report that exploding dependency graphs, faster release cycles, and heavy reuse of open source libraries mean a single malicious or vulnerable package can ripple through thousands of downstream applications in days.

This dense interconnection makes the blast radius of attacks like the npm-focused campaigns in 2025 significantly larger than that of many earlier open source incidents, especially when the target libraries appear in 20 to 30% of scanned cloud environments.

What can we do about it? We must more broadly adopt software bills of materials (SBOMs), Supply-chain Levels for Software Artifacts (SLSA)-style attestations, and tools from the Open Source Software Foundation ecosystem to track provenance and integrity of open source components.

OpenSSF and its partners highlight initiatives such as Sigstore for keyless signing, Scorecard for automated project risk assessment, and the Open Source Project Security Baseline, which aim to give both maintainers and consumers clearer security expectations.

Every year, I tell people that they must take security more seriously. Lately, as open source supply chain violations become ever more common, I’ve been saying you must ensure the code in your supply chain is both safe and written by someone trustworthy.

Looking ahead, I can only redouble these warnings. Now we’ve already had serious security breaches in the last few years. You remember: Solarwinds, JetBrains TeamCity, andApache Log4j should all come to mind quickly. As bad as those were, worse security disasters lie ahead if we don’t take open source supply chain security much more seriously.

TRENDING STORIES