Case Study: How Open Source Packages Power the World

The Scenario

When you type pip install requests and it works in under five seconds, something remarkable has happened. You've reached across the internet to the Python Package Index (PyPI), downloaded a package that hundreds of thousands of developers use daily, and installed it on your machine — for free. No purchase, no license agreement, no subscription.

Behind that effortless command is an ecosystem of open source software that underpins nearly every application you use — from Instagram (built with Django, a Python web framework) to scientific research (powered by NumPy and SciPy) to the AI revolution (built on PyTorch and TensorFlow).

This case study explores how that ecosystem works, what happens when it breaks, and why understanding it matters for every programmer.

What Is PyPI?

The Python Package Index (PyPI, pronounced "pie-pee-eye") is the central repository for Python packages. As of 2026, it hosts more than 900,000 projects with billions of downloads per month.

When you run pip install requests:

1. pip contacts PyPI's servers at pypi.org
2. PyPI sends back the list of every released file for the package named "requests"
3. pip picks the newest version that's compatible with your Python version and operating system
4. pip downloads the package (usually a .whl file — a "wheel")
5. pip installs the package into your Python's site-packages directory
6. pip also downloads and installs any dependencies — packages that requests itself needs to function

That last step is where things get interesting.

Dependency Trees: It's Packages All the Way Down

The requests library is one of the most popular Python packages. But requests doesn't work alone. It depends on other packages:

requests
├── charset_normalizer
├── idna
├── urllib3
└── certifi

Each of those dependencies might have its own dependencies. This creates a dependency tree — a hierarchy of packages that all need to be present for the top-level package to work.

You can see this yourself:

# Show what requests depends on
pip show requests

# Show all installed packages
pip list

# Generate a complete dependency snapshot
pip freeze

For a small project, the dependency tree might include 5-10 packages. For a large data science project, it can easily reach 100+. A typical web application using Django might pull in 50-80 packages.

Here's what happens when you install a small data analysis stack (pandas 3.0 and matplotlib 3.11, the current versions in 2026):

pandas
├── numpy
├── python-dateutil
│   └── six
└── tzdata          (Windows only)

matplotlib
├── contourpy
│   └── numpy
├── cycler
├── fonttools
├── kiwisolver
├── numpy
├── packaging
├── pillow
├── pyparsing
└── python-dateutil
    └── six

Notice that numpy shows up three times and python-dateutil twice. pip is smart enough to install each of them only once and share it. Dependency lists also change between versions: pandas used to require pytz as well, until pandas 3.0 switched to the standard library's zoneinfo module and made pytz optional.

The left-pad Incident: When a Tiny Package Breaks the Internet

On March 22, 2016, a developer named Azer Koçulu unpublished a tiny JavaScript package called left-pad from npm (JavaScript's equivalent of PyPI). The package was 11 lines of code — it did one thing: pad the left side of a string with spaces or zeros.

When left-pad disappeared, thousands of packages that depended on it (directly or indirectly) could no longer be installed, including hugely popular tools like the Babel compiler and the React framework. Projects at companies such as Facebook, PayPal, Netflix, and Spotify were caught in the blast radius. For about two and a half hours, until npm took the unprecedented step of restoring the package itself, a significant portion of the JavaScript ecosystem couldn't build — because of an 11-line function.

What Went Wrong?

The incident exposed several systemic vulnerabilities in package ecosystems:

1. Deep dependency chains. Major packages depended on left-pad through chains of intermediate packages. None of the developers of those major packages had any idea they depended on it. The dependency was invisible.

2. Single point of failure. One developer controlled a package that thousands of projects relied on. When that developer decided to remove it, there was no safety net.

3. Trivial dependencies. left-pad was 11 lines of code. Many developers argued that such trivial functionality should be written inline rather than imported as a dependency. Every dependency is a risk — a risk of breakage, a risk of the author disappearing, a risk of the package being compromised.

4. No local copies. Nearly every project downloaded its dependencies fresh from the npm registry on each install, with no fallback. Even projects that had pinned an exact version of left-pad broke, because every version had been removed. Only teams that kept their own copies of dependencies ("vendoring") or ran a private mirror of the registry kept building.

Lessons for Python Developers

While the left-pad incident happened in the JavaScript ecosystem, the lessons apply to every package ecosystem, including Python's:

1. Understand your dependencies. Run pip freeze and actually look at what's installed. Do you know why each package is there? Which ones are direct dependencies (you chose them) versus transitive dependencies (pulled in automatically)?

2. Pin your versions. Instead of pip install requests, use pip install requests==2.31.0 for reproducible builds. Better yet, use pip freeze > requirements.txt to lock every dependency to a specific version. Pinning wouldn't have saved anyone from left-pad's total removal, but it protects you from the far more common problem: a new release of some dependency quietly changing behavior and breaking your code.

3. Evaluate before you install. Before adding a dependency, ask: - How many lines of code would it take to write this myself? - Is this package actively maintained? - How many downloads does it have? (Widely used packages are less likely to vanish.) - How many dependencies does it pull in?

4. The standard library is your safest dependency. Standard library modules will never be unpublished, they're maintained by the Python core team, and they're guaranteed to be compatible with your Python version. When the standard library can do the job, prefer it over a third-party package.

The Economics of Open Source

Here's a fact that should make you think: the requests library has been downloaded from PyPI more than 30 billion times. It's used by virtually every company that writes Python code. Its creator, Kenneth Reitz, first released it in 2011 as a free, open source project; in 2019 he handed it to the Python Software Foundation, and today it's kept going by a small team of maintainers.

This pattern repeats across the open source ecosystem:

• NumPy, the foundation of scientific Python, was maintained for years by a tiny team of volunteers.
• OpenSSL, the cryptography library that secures a huge share of the internet's HTTPS connections, had just one full-time developer and about $2,000 a year in donations when the devastating Heartbleed vulnerability was disclosed in 2014.
• cURL, used by virtually every networked application on the planet, is primarily maintained by one person: Daniel Stenberg.

The packages you install with pip install are overwhelmingly created and maintained by people who aren't paid for that work. They do it because they believe in open source, because they want to give back to the community, or because they started a useful project and people started depending on it.

This creates a tension: the world's critical infrastructure depends on code maintained by volunteers. When those volunteers burn out, change priorities, or simply move on, the packages they maintain become vulnerable — to bugs, security flaws, and abandonment.

What You Can Do

As a new Python developer, you're joining this ecosystem. Here are ways to be a responsible participant:

1. Report bugs. If you find a bug in an open source package, report it on the project's issue tracker (usually on GitHub). Even if you can't fix it, a clear bug report helps maintainers.

2. Read the documentation. Before asking questions, check if the answer is already documented. Maintainers spend significant time answering questions that are covered in the docs.

3. Contribute back. Even small contributions matter — fixing a typo in documentation, adding a test case, or improving an error message.

4. Respect maintainers' time. Open source maintainers are doing unpaid work. Be patient, be polite, and don't demand features or fixes.

How Python's Ecosystem Compares

Different programming languages have different package ecosystem cultures:

Python's "batteries included" philosophy — the rich standard library — means you need fewer third-party packages for common tasks. This naturally reduces dependency risk.

Discussion Questions

1. The left-pad package was 11 lines of code. At what point is a piece of functionality "too small" to be a package? Where would you draw the line?

2. If a critical open source package is maintained by volunteers, and the world's infrastructure depends on it, should companies be obligated to fund its development? Who should pay for open source software?

3. You're starting a new project and need to parse CSV files. You could use Python's built-in csv module, or you could pip install pandas (which is much more powerful, but brings along NumPy and several other dependencies and is a far bigger install). What factors would influence your decision?

4. Run pip list on your Python installation. How many packages are installed? Pick three that you didn't install yourself (they were pulled in as dependencies). Look them up on PyPI. What do they do? Who maintains them?

5. The requests library is so popular that some people think it should be added to Python's standard library. What would be the advantages and disadvantages of including it?

Mini-Project

Dependency Audit: Choose a popular Python package (e.g., flask, django, pandas, fastapi). Perform a dependency audit:

1. Install it in a clean virtual environment: python -m venv audit_env, then audit_env/bin/pip install <package> on macOS/Linux or audit_env\Scripts\pip install <package> on Windows (Chapter 23 explains virtual environments properly)
2. Run that environment's pip freeze (for example, audit_env/bin/pip freeze) to see all installed packages
3. Count the direct and transitive dependencies
4. Research the maintainers of the top-level package: How many contributors does it have? How often is it updated? When was the last release?
5. Identify the smallest dependency by code size. Could its functionality be easily replaced with standard library code?

Write a one-page report with your findings and an assessment of the package's dependency health.

References

• The left-pad incident is extensively documented. npm's own post-mortem, "kik, left-pad, and npm" (March 2016), gives the timeline and the unpublishing policy changes that resulted: https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm. (Tier 1 — primary source)
• Package dependency lists are shown on each project's PyPI page; pandas 3.0's switch away from pytz is described in its release notes at https://pandas.pydata.org/docs/whatsnew/v3.0.0.html. (Tier 1)
• Eghbal, N. (2020). Working in Public: The Making and Maintenance of Open Source Software. Stripe Press. Chapters on maintainer economics and sustainability. (Tier 1)
• Python Package Index usage statistics are publicly available at pypi.org and through the pypistats API. (Tier 1)
• The Heartbleed vulnerability (CVE-2014-0160) and OpenSSL's understaffing prompted the Linux Foundation to launch the Core Infrastructure Initiative in April 2014 to fund critical open source projects; the initiative's history, including OpenSSL's single full-time developer and roughly $2,000 a year in donations, is summarized at https://en.wikipedia.org/wiki/Core_Infrastructure_Initiative. (Tier 2)
• PyPI download counts: recent figures at pypistats.org, all-time totals at pepy.tech. The requests library's cumulative download count passed 30 billion by 2026. (Tier 2 — publicly available data, may change)
• Package registry sizes are shown live at https://pypi.org/ and https://crates.io/; npm's package count is from https://en.wikipedia.org/wiki/Npm. crates.io's 2025 deletion rules are described at https://blog.rust-lang.org/2025/02/05/crates-io-development-update/. (Tier 2 — figures change constantly)