Why “dependency management” isn’t enough anymore

Open Source and the Iceberg Theory

Think for a moment about the road you drive on every day. You don’t question whether the asphalt is stable, the bridges are inspected, or maintenance crews exist. You simply assume its function and reliability. Now, apply that same passive reliance to the 80 to 90 percent of your company’s production code that is open source.

Consider Ernest Hemingway’s Iceberg Theory (or theory of omission) of storytelling as applied to the open source ecosystem: Your application’s direct dependencies are the tip of the iceberg you can see, but the bulk of what you actually run is hidden beneath the surface in transitive dependencies. That submerged layer is where security, sustainability, and “Who maintains this?” risks accumulate—quietly, until those risks suddenly and loudly make themselves known.

This illustrates the silent agreement—and the massive systemic risk—of modern computing. Multitrillion-dollar digital infrastructures are being built on an information superhighway maintained not by a public works department with a guaranteed budget, but by a diffuse network of unseen volunteers, often working in their spare time. The immense success of “free” and open source software (FOSS)—which generates more than $500 billion in annual value in the U.S. alone³ and an estimated $8.8 trillion in total global value⁷—hides a dangerous truth: Technical longevity is inseparable from community health. If the community breaks, the code breaks.

(credit to William Christen)

The Anatomy of a Shared Scar: Why We Panic

To understand why open source stewardship is a fiduciary duty, we must examine some key moments in which the industry collectively held its breath. These shared scars reveal the deep fragility of the underlying software stack, demonstrating that architectural failures of the commons translate directly into severe measurable costs for organizations of all sizes. These events were not just security bugs; they were crises that exposed systemic flaws in security vulnerability, maintainer burnout, and effective end-of-life (EOL) management. All were consequential, costing organizations millions in immediate crisis response, reputational damage, and long-term remediation.

The following incidents highlight these three critical cost vectors—security, burnout, and EOL—which demand a shift toward more proactive stewardship:

- Heartbleed (2014)—security vulnerability. The shock revealed the open source paradox: Enterprise security, securing billions in global commerce, was built on a shoestring budget (at the time, OpenSSL was maintained by one full-time developer). Companies were forced to spend immense time and money on emergency patching, private key replacement, and mass certificate reissuance.

- Shellshock (2014)—EOL management. A flaw in Bash, ubiquitous since the late 1980s, proved that “just-working” legacy code is often the most neglected. Remediation required costly audits of decades-old systems, illustrating that a lack of eyes on ancient, invisible infrastructure can lead to major security liabilities.

- npm left-pad (2016)—maintainer burnout. The unpublishing of an 11-line utility “broke” the Internet for hours, causing global build failures for thousands of high-profile projects (e.g., React and Babel). This incident exposed the micro-dependency nightmare, costing engineering teams critical development time and forcing a painful realization of their reliance on thousands of single-purpose, unsupported libraries.

- Log4j (2021)—security vulnerability. The Log4j Christmas was the ultimate proof of the Iceberg Theory. The critical remote code execution (RCE) flaw was buried deep within many commercial enterprise products, crippling IT operations during the holiday period. Companies spent weeks—and millions of dollars—manually hunting down every instance of the library across their stacks, because you cannot manage what you cannot see.

- core-js (2023)—maintainer burnout. The maintainer of this library, which is downloaded billions of times monthly, faced financial ruin and legal troubles, forcing him to quit. This is the tragedy of the commons in its purest form: billions in corporate value extracted, while the person providing the value is left to burn out. Organizations face massive future remediation costs when these central components lose their maintainers.

- XZ Utils (2024)—security vulnerability/maintainer burnout. This incident proved that maintainer burnout is a vector for state-sponsored attacks. An entity used a multiyear effort to build trust, waited for the original, overwhelmed maintainer to burn out, and then injected a sophisticated backdoor. Its discovery—by pure chance over a 500ms spike in latency—averted a global catastrophe that would likely have cost organizations untold billions in breach remediation and recovery costs.

In practice, these incidents illustrate that organizations need more than vulnerability notifications and reactive patching sprints. Instead, they need a real expectation for how crucial open source projects are built and maintained.

The point isn’t perfection. It’s about driving toward frameworks that allow consumers to calibrate risk and maintainers to prioritize improvements that can measurably reduce downstream harm.

The Structural Challenge: The Public Goods Problem

The acceptance of open source as critical infrastructure compels us to confront a fundamental failure of modern software engineering: the lack of structural mechanisms for shared accountability. As Nadia Eghbal established in her seminal “Roads and Bridges” report, the digital foundation is maintained by unseen labor, creating a classic public goods problem where everyone benefits but nobody wants to pay for the upkeep.⁵

Quantifying the iceberg

To manage this risk, we must first grapple with the staggering depth of our dependency. While organizations often cite that 70 to 90 percent of their codebase is open source, this reliance is a massive, complex iceberg. Research, such as the Linux Foundation’s Census III, doesn’t just show market share; it maps thousands of widely used application libraries that form the actual digital bedrock.⁸ This sheer volume means that the health of even a single, obscure library translates instantly and directly into systemic business risk, threatening the stability of the entire superstructure above it.

The failure of stewardship manifests as the sustainability and EOL crisis:

- Security vulnerabilities. A flaw in any of the thousands of deeply embedded open source components can immediately trigger catastrophic security events worldwide, as demonstrated by the Log4j incident. The systemic nature of this vulnerability proves that organizations cannot simply isolate risk; we must proactively address the health of the entire ecosystem.

- Maintainer burnout. The core problem is human, not technical. The overwhelming burden placed on small, often unpaid teams leads directly to maintainer burnout. This human-centric failure precipitates EOL scenarios, abrupt project abandonment, and the decay of security stewardship.^6,7 The end of the popular open source library “left-pad” because of a maintainer dispute is a classic example of how human factors translate into critical business risk.

- EOL management. When foundational projects are abruptly abandoned or reach their end of life, organizations face massive, unplanned costs associated with emergency migration, vendor lock-in, or continued risk exposure. This was evident when the EOL of Python 2 forced numerous companies to undertake costly and time-consuming migrations to Python 3.

The need for organizational frameworks

These acute challenges—security vulnerabilities, maintainer burnout, and costly EOL—demonstrate that dependency management focused solely on tactical, reactive responses such as basic vulnerability scanning is critically insufficient. The crisis demands a strategic, systems-level organizational response capable of enforcing proactive stewardship and accountability across the entire open source supply chain.

This need is recognized globally: The OpenSSF Security Mobilization Plan⁹ was created specifically to define the industrywide actions required to address this shared risk. The pressure to adopt such frameworks is increasing as a result of regulatory expectations such as those being defined by the EU Cyber Resilience Act (CRA) and guidance from entities such as the U.S. Cybersecurity and Infrastructure Security Agency (CISA).⁴ This elevates open source health from an engineering preference to a compliance and fiduciary imperative.

Risk management in practice: Shifting from reaction to prediction

Responsible stewardship requires organizational structures to systematically measure, report, and manage this dependency risk. Due diligence must shift from solely tracking known vulnerabilities (reactive) to tracking predictive indicators of project health and stability (proactive).

Security Floor

Establish a baseline instead of relying on vibes. Reactive vulnerability scans can let you know what’s already known to be broken; it does not tell you whether a project is run in a way that prevents the next incident. Organizations must commit to adopting and enforcing industrywide baselines such as the Open Source Project Security (OSPS) Baseline.¹⁰ This provides a pragmatic, auditable security floor and aligns internal practices with frameworks such as the National Institute of Standards and Technology’s (NIST’s) Secure Software Development Framework (SSDF). Even at level 1, the baseline suggests basic safeguards that reduce an enterprise’s exposure level, including requiring multifactor authentication (MFA) for repository actions, preventing direct commit access to a project’s primary branch, and preventing unintentional storage of secrets in version control. Tools such as the OpenSSF Scorecard serve as a quantitative mechanism to recognize critical security hygiene⁹ signals and enable companies to plan for remediation where necessary.

Adopting the OSPS Baseline shifts security from a one-off audit to a shared roadmap. Projects can climb baseline adoption levels incrementally, and consumers can invest in raising the floor instead of reacting to surprises.

Community Health

Technical risk is predicted by community stability. Organizations can integrate Community Health Analytics for Open Source Software (CHAOSS) metrics² to assess project resilience. Metrics such as Contributor Absence Factor (how many people hold critical knowledge) and Contributor Activity provide essential signals about the long-term viability of a dependency before it impacts the business.

These frameworks and models move the conversation from “Is this component safe today?” to “Is this project healthy enough to sustain our business for the next decade?”

Bloomberg’s Strategic Approach to Sustaining Open Source

At Bloomberg, we realized that traditional dependency management—essentially patching artifacts—was like trying to fix a leaky faucet while the house’s foundation was crumbling. We needed a model that moved beyond reactive maintenance.

To address this need, we developed a strategic framework that integrates technical rigor with social contribution. We believe that recreating the software that underpins modern infrastructure would be prohibitively costly, so investing in its long-term resilience is the only practical choice. This requires a two-pronged strategy: We don’t just secure the code; we sustain the community behind it.

Pillar 1: Technical Responsibility (How We Build)

Technical responsibility focuses on raising the floor for everyone by making security and health auditable.

Frameworks for Holistic Evaluation

Our ingestion evaluation process combines long-term health metrics alongside immediate security scans. Our model incorporates predictive indicators of project health from sources such as the OpenSSF Scorecard and internal tools. This is rooted in the belief that accountability for critical, long-lived dependencies must be solved organizationally, not just by individual developers. When analyzing project indicators organizationally, our teams are able to develop programs and policies to address risk programmatically, which is a more effective approach to remediation than single-project maintenance tasks.

The OSPS Baseline as Stewardship

The adoption of the OSPS Baseline serves as a concrete example of technical stewardship. This initiative defines a pragmatic, auditable “security floor” for projects, aligning internal practices with major global frameworks such as the EU Cyber Resilience Act (CRA). By contributing to these shared baselines, we accelerate compliance alignment within Bloomberg while simultaneously raising the security and compliance floor for other organizations that use the same standards.

What This Looks Like Operationally

By treating the OSPS Baseline as a shared task list that we want our own published projects to meet, we create a structured lens for upstream risk conversations. Each category helps teams avoid security tunnel vision: Access control and branch protections are important, but so are documented contribution paths, secure releases, and well-understood and responsive vulnerability reporting practices.

The shift from “Did we scan it?” to “Is this project run in a way that can withstand pressure?” reframes the investment, transforming funding maintainers, improving continuous integration (CI) and release processes, and strengthening disclosure channels into first-class risk mitigations.

Pillar 2: Social Responsibility (How We Sustain)

The hard truth of engineering is that you cannot have sustainable code without sustaining the humans who write it. We approach open source engagement as a form of social responsibility that strengthens technical stability over time.

Foundation Engagement

Our first strategic investment is at the governance level. Open source foundations provide the vital resources, coordination, and long-term stewardship that critical infrastructure requires. By actively supporting and participating in foundations, we promote stability and help ensure the long-term viability of the open source technologies Bloomberg relies on. This engagement fosters a collaborative environment that extends beyond the repository, emphasizing shared problem-solving and knowledge transfer.

Foss Contributor Fund

We democratize our open source funding process by providing our engineers a direct role in deciding where support is most needed. Each quarter, our developers nominate and vote on open source projects to receive financial grants. This approach helps direct funding toward widely used but under-resourced projects that are critical to the ecosystem, including libraries that might lack the visibility or institutional backing of larger well-known projects such as Linux or Kubernetes.

Open Source Dollars for Your Hours

We recognize upstream contribution as a high-impact form of professional community service. By allowing employees to convert time spent contributing to open source into charitable dollars donated to nonprofit organizations they care about, the program creates a clear and intentional connection between technical work, volunteerism, and broader social impact.

Deep Dive: The Sustaining Open Source Series

The most ambitious evolution of our social pillar is a two-year pilot focused on sustained upstream engagement called the Sustaining Open Source Series. We recognized that drive-by patches—fixing a single bug that affects your internal stack and then disengaging—don’t actually solve for the long-term health of a project. Open source requires more than just code contributions; projects need consistent contributor presence. The Sustaining Open Source Series focuses on foundational maintenance, including testing, triage, documentation, and other ongoing responsibilities that are essential to project continuity but often difficult for maintainers to prioritize alongside feature development. By supporting this work, the program helps strengthen project resilience and reduce the risk of stagnation.

Over the past two years, we have made this model operational in close partnership with NumFOCUS and the pandas project. Pandas is the undisputed bedrock of the data-science ecosystem, used by everyone from university students and researchers to the world’s largest financial enterprises. The scale and range of its user base is reflected in its massive issue tracker—the thousands of open issues that represent not just accumulated technical work, but also the wide range of use cases and edge conditions the library must support across industries and disciplines.

What we did

These efforts created a long-term engineering commitment. Through a structured mentorship and collaboration model, we designated teams of engineers to spend 10 percent of their time (roughly a half day per week) over a three-month rotation, working directly on the project’s upstream backlog:

- Backlog grooming at scale. Bloomberg engineers spent weeks triaging hundreds of stale or duplicate issues. Sorting through this volume gave the teams a unique perspective on how pandas is used in the wild and helped the core maintainers reduce their cognitive load so they could focus on high-level architecture instead.

- Testing as a stability insurance policy. Stability is the primary requirement for a library this foundational. We focused heavily on updating and expanding the pandas testing suite. By catching regressions and hardening the codebase against edge cases, we provided the necessary insurance that allows the project to continue evolving without breaking the mission-critical pipelines of its millions of users.

- The AI frontier (AGENTS.md). We looked ahead at how pandas must evolve to thrive in an era of AI-assisted coding. We collaborated with the community to introduce an AGENTS.md¹ file—a strategic roadmap defining how pandas should interface with large language models (LLMs) and AI agents. As AI starts generating more data-science code, this will help ensure it does so using the most idiomatic, performant, and safe patterns of the pandas ecosystem.

The result: A two-year impact study

By moving from passive consumption to active stewardship, the pilot delivered measurable value to the project and our own engineering department’s culture. The results over the course of the two-year engagement:

- 1,500+ hours of contribution. We provided consistent, structured engineering support of the kind that projects often struggle to secure from corporate contributors, particularly for ongoing maintenance and support work.

- 100+ participating engineers: More than 100 engineers across Bloomberg contributed directly to the project, building deeper technical expertise while developing leadership and mentorship skills. This work also strengthened internal familiarity with the libraries our teams rely on, creating long-term benefits for both individual contributors and the organization.

- Nearly 100 specific pandas improvements. From subtle bug fixes in the core engine to systemic improvements in documentation and testing, these contributions strengthened the library for the entire global community.

- Reduced maintainer burden. By supporting tasks such as issue triage, testing, and documentation, the program helped alleviate some of the ongoing operational load carried by core maintainers, allowing them to focus more effectively on project direction and long-term sustainability.

This pilot demonstrates that open source stewardship is not charitable in name only. It is a practical, strategic investment in the resilience of the digital infrastructure on which organizations depend.

A Practitioner’s Framework: From Theory to Action

Stewardship is not a matter of budget; it is a change in principle. Whether you are a two-person startup or a global giant, the goal is the same: Move from blind consumption to active stewardship. Here is a blueprint for how any company can build a more resilient relationship with its digital supply chain.

Step 1: Know your dependencies (The Technical Arc)

You can’t manage what you can’t see.

- Establish an inventory. Invest in visibility by generating comprehensive software bills of materials (SBOMs) for all first-party code. Use industry standards such as CycloneDX or the System Package Data Exchange™ (SPDX®;

https://spdx.dev/

). For a small team, this might be a simple step in a continuous integration/continuous delivery (CI/CD) pipeline; for a large company, it’s a foundational requirement for security. The point is to stop treating your package manager as a black box and start treating it as a supply chain.

- Make artifacts useful. An SBOM shouldn’t be just a file you store for compliance; it should be the basis of an internal software catalog. By integrating security and compliance checks early—shifting left—you can prevent the ingestion of unsafe software before it ever reaches production. The goal is to create a paved path for developers, facilitating risk management without adding friction to the engineering workflow.

- Apply posture to inventory. Now that you can see the entire iceberg, your next move is prioritization. Classify your dependencies by criticality (business impact) and exposure (the depth to which the dependency is deployed), and then overlay that classification with project posture signals. The goal should not be to demand perfection from your dependencies. Instead, it’s meant to identify the bridges to your infrastructure and ensure you have an explicit strategy to reduce risk where it can be systematically identified technically.

Step 2: Align strategy (The OSPO As a Function)

Raw technical data must be turned into organizational insight.

- OSPO as a mindset. An Open Source Program Office (OSPO) isn’t necessarily a department; it is a function. In a small company, this “office” is a mindset held by a senior lead or CTO who can explain to the business side why spending four hours on an upstream patch today saves 40 hours of maintenance debt next year. It’s about being the translator between kernel-speak and business strategy.

- Build the health dashboard. Use metrics—such as the CHAOSS framework—to translate raw code activity into consumable risk scores. Does a project you rely on have a bus factor (measurement of risk) of one? Has the lead maintainer stopped responding to pull requests (PRs)? This dashboard provides the traceability needed to justify where you spend your time and money.

- Define strategic risk profiles. Move the conversation beyond just scanning for known Common Vulnerabilities and Exposures (CVEs). Use your data to measure long-term sustainability. If a project is strategically vital to your product but technically stagnant, it is a high-risk profile that requires active intervention, not just a patch.

Step 3: Invest Holistically (Pay the Rent)

If you live in the house, you help fix the roof. This is the transition from passive reliance to active engagement.

- Fund the foundations. Groups such as the Apache Software Foundation (ASF), the Linux Foundation, and NumFOCUS provide the legal, administrative, and social pavement that keeps projects moving. Supporting them is an efficient way for a company of any size to support the open source ecosystem at scale.

- Allocate time. Give your engineers the mandate to contribute patches back upstream. This isn’t corporate charity; it’s a tactical move to reduce your own internal maintenance debt. Every local patch you carry is a tax you pay every time you upgrade. By upstreaming your fixes, you enable the community to maintain your code for you.

- Monitor and recalibrate. Treat your open source strategy as a subscription model for ongoing data curation and updated risk insights. As projects evolve, fork, or fade, shift your resources to where the cracks are starting to show. Active stewardship is a continuous process of recalibration.

This holistic approach will transform an organization of any size from a passive consumer into a strategic steward. By securing the health of the commons, you are ensuring the longevity of the very infrastructure your business is built on.

Conclusion: The New Fiduciary Reality

The choice facing the modern enterprise is clear: Continue managing artifacts in isolation and hope the highway stays paved, or take the long view of risk.

The traditional model of passive consumption is fundamentally unsustainable. In an era of AI-generated code and increasing supply-chain attacks, stewardship is now a fiduciary and societal imperative. Embedding a stewardship mindset into core strategy is not a matter of goodwill; it is an investment in the resilience and long-term viability of the systems your company relies on.

Responsible participation is no longer optional; it is the essential new component for the continuity of the shared digital infrastructure. If you want your highway to be there tomorrow, you need to help the crew that’s fixing the potholes today.

---

Alyssa Wright helps lead Bloomberg’s Open Source Program Office, which is the center of excellence for Bloomberg’s engagements with and consumption of open source software. In this role, she applies the principle of “be curious, solve problems, do good” to drive sustainable open source impact. Her experience spans the World Bank, Samsung Research, and board roles with Open Source Collective and OpenStreetMap US. An MIT grad based in Brooklyn, she loves exercise, good food, and witty banter.

Stephen Augustus is a Black engineering and community leader in open source based in New York City. He co-leads the Open Source Program Office at Bloomberg. Stephen is currently a Governing Board and Technical Advisory Council member for the Open Source Security Foundation (OpenSSF), a Steering Committee member for TODO Group, and one of the chairs responsible for releasing Kubernetes. He also serves as an advisor and investor for startups in the open source ecosystem. When he’s not behind the keyboard, you’re likely to find him playing billiards games or rocking the mic at karaoke.

---

References

1. AGENTS.md; https://agents.md/.

2. CHAOSS. Community Health Analytics in Open Source Software (CHAOSS);

https://chaoss.community/.

3. Chesbrough, H. Measuring the economic value of open source. Technical Report. The Linux Foundation (2023); https://www.linuxfoundation.org/research/measuring-economic-value-of-os.

4. Cybersecurity and Infrastructure Security Agency (CISA). Securing the open-source software ecosystem. White House Report (OS3I) (2024); https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/01/Securing-the-Open-Source-Software-Ecosystem-OS3I-End-of-Year-Report-MASTERCOPY.pdf.

5. Eghbal, N. Roads and bridges: the unseen labor behind our digital infrastructure. Ford Foundation (2016); https://www.fordfoundation.org/learning/library/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/.

6. Eghbal, N. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press (2020).

7. Hoffmann, M., Nagle, F., and Zhou, Y. The value of open source software. Harvard Business School Working Paper 24-038 (2024); https://www.hbs.edu/faculty/Pages/item.aspx?num=65230.

8. Nagle, F., Powell, K., Zitomer, R., and Wheeler, D. A. Census III of free and open source software: application libraries. Technical Report. The Linux Foundation (2024). https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_censusiii_120424a.pdf?hsLang=en.

9. OpenSSF. The open source software security mobilization plan. Technical Report (2022). https://openssf.org/oss-security-mobilization-plan/.

10. OpenSSF. Open Source Project Security (OSPS) Baseline; https://baseline.openssf.org/.

Originally published in Queue vol. 24, no. 1

---