Dirk Hohndel writes

Over the last three decades, open source software has evolved from a niche development model into critical infrastructure underpinning nearly every modern software system. While open source projects emerged throughout the 1980s and early 1990s, the rise of the LAMP stack in the late 1990s marked a visible turning point in enterprise adoption. Since then, open source components have become part of virtually every software stack imaginable, and their importance to today's digital infrastructure can hardly be overstated.

While flagship projects such as Linux, Kubernetes, and PyTorch benefit from substantial institutional support and funding, the broader open source ecosystem remains heavily dependent on unpaid maintainers. That is not to say these contributors are hobbyists or amateurs. Most arehighly skilled professional software engineers. The difference is simply that maintaining these projects is often not their primary job, and often they receive little or no compensation for work that millions of users and countless businesses depend upon.

The sustainability of this model has been a concern for years. Maintainer burnout has become a recurring topic throughout the open source community and much has been written about the imbalance between volunteers doing the work and commercial organizations benefitingfrom the results. Smaller companies have repeatedly launched innovative open source projects, only to see larger vendors and hyperscalers build profitable services on top of them with limited contributions back to the communities that created them.

By the mid-2020s, generative AI intensified the problem. LLM-assisted vulnerability discovery lets researchers (and threat actors) scan codebases and surface flaws in minutes rather than weeks. A capability that can help defenders, but that also floods maintainers with AI-generated bug reports and security findings, many of which are of low quality, and which are often rated too highly as far as criticality is concerned. Additionally, there is significant duplication in these submissions, all adding to the incremental effort required from the project maintainers. Even well-funded projects struggle to absorb this additional workload while maintaining quality and security standards. As a result, many communities are actively debating how to manage this influx of contributions and how to address the technical, legal, and ethical questions surrounding AI-generated code.

These pressures are not limited to project maintainers. Organizations that rely extensively on open source software are increasingly feeling the consequences as well. Security vulnerabilities in widely deployed components continue to create operational and business risk, while many engineering teams face growing challenges simply tracking and evaluating the updates required to maintain a secure software supply chain. At the same time, some projects are falling behind on addressing reported issues, and others are losing momentum or being abandoned entirely as maintainers struggle to keep pace with growing demands.

Taken together, these trends create a challenge for both open source communities and the companies that depend on them. Organizations across the industry are stepping in, some seeking to address immediate business concerns, others investing in the long-term health of the ecosystem. Initiatives such as the Linux Foundation's Project Akrites aim to help coordinate vulnerability reporting and support critical projects facing unprecedented operational pressure. Yet the fundamental question remains largely unanswered: how should companies respond to the problems faced by the open source projects on which their businesses depend?

Consuming versus engaging

The era of simply consuming open source and assuming enterprise-grade software will materialize at no cost is coming to an end. In fact, the term "consuming" is part of the problem. We consume commodities: interchangeable products where the source matters little to the consumer. Open source is fundamentally different. The community is every bit as important as the code.

In many ways, open source is first and foremost a social experiment, and only then a software development methodology. Successful adoption therefore requires more than downloading code and integrating it into a product. It requires understanding the community behind the project, its norms, governance, priorities, and long-term goals. The term "engaging" with open source better captures that reality.

Yes, organizations use the code, but they must also understand how the project operates: how security vulnerabilities are disclosed and addressed, how API compatibility is managed, how releases are planned, what standards are applied to contributions, and what level of support can be expected from maintainers. Organizations that fail to understand these aspects often find themselves exposed to avoidable operational and security risks.

Every organization must develop a strategy for securing its infrastructure and products while contributing to the sustainability of the software it relies upon. That means moving beyond a purely transactional relationship with open source and becoming active participants in the communities that drive innovation throughout the industry.

Addressing these challenges requires a new model of engagement, one built on collaboration, shared responsibility, and long-term investment. Organizations that depend on open source must help fund, maintain, secure, and strengthen the projects that form the foundation of their products and services.

Ericsson's approach

Ericsson has embraced this approach for many years. Through Ericsson Software Technology, we contribute engineering expertise, security knowledge, bug fixes, and upstream improvements across hundreds of open source projects that are critical to our products and services. These projects form the foundation of every nation’s critical networking infrastructure. We are actively involved in projects like Akrites or OpenSSF, securing foundational projects and implementing security best practices. We actively work on key projects from the Linux kernel to the Yocto project all the way to large parts of the cloud native ecosystem building these technologies to fit zero-trust environments and as part of critical infrastructure.

As the demands placed on open source continue to grow, active participation is no longer optional. It is essential to the health of the ecosystem and to the success of every company that depends on it.