Every product your organization ships runs on code nobody on your payroll wrote. Thirty-three of those pieces sit under nearly every phone, browser and server on Earth. Twenty are kept by two people or fewer, the median has not risen above two in a decade while the devices depending on them tripled, and the people doing it have carried the work for decades around day jobs. This note lays them out as elements, shows which of them your products are compounds of, and names what holds each one up.
The original count of 23 libraries, their device inventory and funding notes are from The people holding up the internet by sheets.works, published with its data and script.12 This note re-ran their count on the code, extended it by ten libraries and thirty years, and gives the maintainers the credit the numbers imply.
I came across the sheets.works piece by way of a comment underneath it: hard to read, even for an experienced IT pro, but some great insights. That comment is the brief for this page. The original is a fine piece of counting, and it tells its story one maintainer at a time, which is how the people deserve to be told. It also assumes you already know what libxml2 is. Most of the people who sign off on software risk do not, and they are the ones who need the count.
The parallel I keep coming back to is the public library. A library lends one copy of a book to a whole town; a software library lends one piece of code to every program that asks. In both cases the borrower pays nothing at the counter, the collection has to be kept current by someone, and almost nobody who uses it knows the keeper's name. We fund the first kind as a public service because its value is spread across everyone and no single reader would pay for it alone. The second kind has the same economics and no tax base. It is kept, for the most part, by volunteers, and its borrowers number in the billions.
Where the parallel breaks is the scale of failure. A library that closes affects a town. One of these closing affects every phone at once. That is what load-bearing means here, and why the people in this note are listed as staff rather than as a warning. I re-ran the count on the code, added ten libraries the original did not cover, and traced the staffing back to 2000. Where my numbers differ from theirs, the page shows both.
and why these thirty-three
A library is a block of code that does one job well enough that thousands of other programs call it instead of writing their own. Open a JPEG. Compress a file. Check a certificate. Work out what time it is in Winnipeg. Your engineers add a line that calls the library, and the job is done. Libraries are how software gets built at all, and also where responsibility goes thin, because the people who call one rarely know who keeps it.
Take the time zone database. Every clock rule any government has ever announced lives in one text file, from wartime offsets in the 1940s to Manitoba's decision this year to stop changing its clocks. Every Android phone and every iPhone reads it, at least four billion devices before counting servers, Macs and laptops. The file is kept by Paul Eggert, a lecturer in computer science at UCLA, in his spare time, and has been since 2012. He made 218 of its 251 changes in the past year.15
"In case I am no longer available due to retirement or whatever."
Paul Eggert, asking the tz mailing list to make Tim Parenti his backup, 20 May 2020
I have mythologized Paul Eggert's job for years. It is my favorite slightly spooky fact to hand to people: every clock on every phone you have ever owned takes its orders from one text file, kept by one lecturer in California in his spare time, and it has worked the whole time. My business partner has brought it up more than once after hearing it from me, which is the only measure I keep of how far an idea travels. Spreading that one warms my heart. The rest of this note is an attempt to turn that fact into a line item.
That is one library. sheets.works set out to measure the rest.1 They took 23 libraries that phones, browsers and servers depend on, downloaded each one's full history, and counted everyone who made ten or more changes in the year to 7 October 2026, leaving out merges and bots. Then they checked what is actually installed: the system libraries of an Android 16 image, Apple's iOS 26.2 developer kit, and Windows with the Edge browser it ships with. Each library ends up with two numbers. How many devices it is on, a floor. And how many hands are under it.
This note re-ran that count on the same code and got the same answer on 19 of the 22 projects it could reach; the other three differ by one person.3 It then added ten more libraries the original did not cover, counted the same way: the command-line tools inside every Android phone, the audio codec inside every voice call, the archive reader inside Windows, the C library inside most containers, and six others. None of the 33 is a random pick. Each is in the base image of an operating system or browser almost everyone uses, or in the standard toolkit of almost every server, which is what makes them load-bearing: a flaw or a gap in any one of them reaches billions of devices at once. Laid out by what they do, they look like this.
elements and compounds
Columns group the libraries by job. Each tile is one library. Tap a tile to read what it does, why it matters and who keeps it. Pick a compound to see which elements one everyday action is made of.
Reach is the floor that could be seen: Android 3.0 bn active devices (Google, 2022), iPhone 1.0 bn (Apple, 2021), Windows 1.6 bn monthly (Microsoft, 2026). n/c means not counted on those platforms, not unused: bash, sudo, OpenSSL, OpenSSH, musl, chrony and ncurses live on servers, containers and Macs, which the count leaves out. Compounds are a typical path through one action, drawn from the vendors' own source trees (see Method), not an inventory.2 The symbols are the author's, and Cu is deliberate; open that tile for the editor's note.
| Symbol | Library | Group | Devices (bn) | Platforms | Regular people | Re-count | Authors | Changes | Top author | Top share | Funding as recorded | Counted by |
|---|
Three things stand out once the 33 share one grammar.
The people cluster. Five projects hold 117 of the 172 regular-contributor seats. FFmpeg has 41, OpenSSL 35, BIND 16, libarchive 14 and curl 11. The other twenty-eight libraries, between them on every phone in the world, share 55 people.
The widest-shipping row is the thinnest. libxml2, zlib and SQLite are on all three platforms, at least 5.6 billion devices, with one, two and three regular contributors. libjpeg-turbo, which opens every JPEG on Android and in Chrome and Edge, is one developer who wrote 98% of its changes. libxslt, its sibling, is shipped in iOS and bundled in Chromium, and nobody made ten changes to it this year. Reach does not predict staffing: the rank correlation between devices and hands is about zero, and section 09 says what that rests on.
Your products are compounds. Pick "A Python script runs" above. One ordinary script touches seven of these elements, four of them kept by two people or fewer. A photo arriving in a chat on an Android phone passes through six. A deploy to a Linux server touches eleven.
a labor of love, counted by the year
The count can read as an indictment. It reads better as a credit list. The people under these libraries have been doing the work for decades, most of them around a day job, and they are still shipping. Lasse Collin, whose project was the target of the most sophisticated supply-chain attack in open source history, removed the backdoor, audited the project and wrote 97% of the next year's changes. Thomas Dickey has released a patch to ncurses most weeks for thirty years. Mark Adler wrote the compression inside every PNG on Earth and, in his other job, got a rover to Mars.
One book per year as maintainer or coordinator of the library, to 2026. Start years are from the projects' own histories; three are approximate and marked in the table.
| Person | Library | Since | Years | Basis |
|---|
"It's also good to keep in mind that this is an unpaid hobby project."
Lasse Collin, xz mailing list, 8 June 2022. The hobby project ships in every iPhone.
Two of these people have asked, in public, for a sponsor. Todd Miller's note in February 2026 brought sudo an Open Collective budget of about $61,700 a year and thirty GitHub sponsors, the best funded one-person project in the count.15 Denis Pushkarev's appeal in 2019 raised $57 a month.14 Paul Eggert, Lasse Collin, DRC and Mark Adler do not have a sponsor page at all. The difference between those outcomes is not the importance of the work. It is who happened to hear about it.
hands, commits and load, 2000 to 2025
The count above is one year. The histories go back further, so this note asked the same question of every full year since 2000: how many people made ten or more changes to each library, how many changes there were, and who wrote most of them. Thirty-two of the 33 could be traced (bash publishes its history in batches, outside git). The averages are in Fig 03, and the shape is the point.
Each year, across every library that existed by then. Top: regular contributors per library, mean and median, with any one element overlaid. Middle: the share of libraries with two or fewer, and how much of the work the top author did. Bottom: active Android devices, as Google announced them, for scale.
Regular contributor = ten or more non-merge, non-bot changes in the calendar year, counted by author name in each project's public history. A library joins the average in the first year its history shows a change; the count of libraries in each year's average is printed above the top panel. Android device counts: Google I/O announcements of one, two, two and a half and three billion active devices, 2014, 2017, 2019 and 2021.23 2026 is excluded as a partial year.
| Year | Libraries | Mean regulars | Median regulars | Share with 2 or fewer | Mean top-author share | Mean changes |
|---|
The average grew, then stopped. In 2000 the typical library here had two regular contributors and the average was just over two. By 2015 the average had reached five. It has not moved since: between 4.1 and 5.3 in every year from 2014 to 2025. Overlay OpenSSL and the reason is visible. Its bench went from six to fourteen in the Heartbleed year and then kept climbing to over thirty. Overlay FFmpeg, curl or BIND and you see the same thing on a longer curve. Those four projects are the growth.
The median did not move at all. Take the four away and the picture is a flat line at two. Overlay tz, xz, libjpeg-turbo, chrony, ncurses or libsodium: one or two people, every year, for as long as the history runs. The share of libraries with two or fewer regular contributors was 72% in 2000 and 56% in 2025, and most of that fall is the big four leaving the group, not the small ones gaining help.
Meanwhile the load went vertical. There were no Android phones in 2007. There were a billion by 2014, two billion by 2017 and three billion by 2021. Over the same years the median library under them gained nobody. Concentration eased slightly, from the top author writing three-quarters of the changes on average to about two-thirds, which is real but is again mostly the big four. For the typical element the person who wrote it in 2010 is still writing most of it.
three patterns, and who fixed each one
A thin project is not a broken one. Most of these have run for decades without incident. Thinness changes the shape of failure, and the public record sorts into three shapes. The bar in each row is the time between the weak point entering the code and someone finding it. The line under each row is what happened next, which is the part the famous stories tend to leave out.
Hollow book: the weakness enters. Solid book: it is found, or the gap closes. Year axis 1985 to 2027, to scale.
Dates: Shellshock line committed 5 Aug 1989, disclosed 24 Sep 2014;10 Heartbleed code committed 31 Dec 2011, disclosed 7 Apr 2014;11 Log4Shell lookup shipped Sep 2013, disclosed 9 Dec 2021;13 first Jia Tan change to xz 28 Jan 2022, backdoor found 29 Mar 2024;78 core-js maintainer absent Jan to Oct 2020;14 tz lawsuit filed Sep 2011, dropped Feb 2012;6 libxml2 maintainer stepped down Sep 2025, handover Dec 2025.1
| Pattern | Incident | Library | Enters | Found / resolved | Span | What happened next |
|---|
Latent. A mistake sits in plain view because few people read the code closely. The line behind Shellshock went into bash in 1989 and was reported in 2014, on a project with one author. Heartbleed sat in OpenSSL for two years and then let anyone read memory from about 17% of trusted secure web servers.11 In both cases the maintainers had fixes out within days of the report.
Captured. A tired maintainer gives access to a helpful newcomer. In 2022 Lasse Collin was fielding mailing-list pressure about slow progress while a contributor called Jia Tan sent useful fixes. Jia Tan got commit access, out-committed Collin in 2023, and in February 2024 released versions carrying a backdoor into SSH logins on Linux servers. Andres Freund, an engineer at Microsoft, caught it on 29 March because his logins were using too much processor time, before it reached most Linux systems.78 Collin removed it and has run the project alone since. Nobody has identified Jia Tan.
Absent. The one person stops, for reasons that have nothing to do with code. core-js went nearly silent for ten months in 2020 while Denis Pushkarev served a prison sentence after a fatal car accident; downloads nearly doubled in the meantime, and he was back at work the month he was released.14 A 2011 lawsuit over the time zone database's historical entries took its site and mailing list offline until IANA took over hosting.6 libxml2's maintainer announced in September 2025 that he was stepping down and handed over in December; new maintainers were added within a day. That handover went well. The xz handover is what the same moment looks like when it does not. And libxslt, which lost the same maintainer in the same month, shows the quiet version: eight changes by three people in the year since, and 2.6 billion devices still shipping it.
where public money went, and when
Germany's Sovereign Tech Agency is the largest public funder of this kind of work, with 118 technologies supported since 2022.19 Five of the 33 hold its grants. Line those up against the libraries where no funding was found at all, and the order looks less like a map of load than a map of headlines.
Bars: Sovereign Tech Agency grants, euros, to scale. Then libraries with other funding, then those where none was found. Each row ends with reach and regular contributors.
"None found" means nothing from the Sovereign Tech Agency, Alpha-Omega, Open Collective or GitHub Sponsors, checked by sheets.works for the original 23. For the ten added, the only check was the commit addresses, which is how the employer rows were found; the rest are marked not checked and left out of this figure, as are the six the original did not check.2
| Library | Group | Public grant | Funding as recorded | Devices (bn) | Regular people |
|---|
The largest grant, €596,160, went to log4j, which the world met through Log4Shell in December 2021. OpenSSL holds the third largest. The six libraries with no funding found reach 5.6, 5.6, 4.6, 4.0, 1.0 and an uncounted number of billions of devices, and are carried by thirteen regular contributors between them. Two of the added elements show something the grant lists cannot: an employer. chrony's commits come from a Red Hat address and most of Opus's from a Google one, which is the arrangement that keeps a one-person library from being a one-person risk. Put the money and the incidents on one line and the order is hard to miss.
One row per year. Left: incidents in this note's elements. Right: public money arriving, with the mark sized by amount on a log scale. Read down the page and watch which column moves first.
Grants from the Sovereign Tech Agency are placed at the midpoint of their stated investment years.19 The Core Infrastructure Initiative pledge is the Linux Foundation's May 2014 announcement.24 GnuPG's 2015 donations are as reported after press coverage of its one-person funding.25 The xz backdoor in March 2024 is the one incident on the line that brought no public money to the project involved.
| When | Kind | Event | Amount |
|---|
OpenSSL is the case where money did arrive, and it worked. In the week Heartbleed went public, the foundation's president wrote that it received about $2,000 a year in donations and had one person working on it full time.12 Within two months technology companies had pooled $5.4 million through the Linux Foundation, and OpenSSL got paid developers and an audit. Its bench has more than doubled since. xz had its own near miss ten years later.
Each book is one person making ten or more changes that year. OpenSSL before and after Heartbleed; xz before and after its backdoor.
Counted from the projects' public histories for this note; OpenSSL's 2013, 2014 and 2025 calendar years and xz's 2023, 2024 and 2025. In 2023 Collin and Jia Tan both cleared ten changes. No new public funding for xz was found after March 2024.
| Library | Before | Incident year | After |
|---|---|---|---|
| OpenSSL | 6 (2013) | 14 (2014) | 32 (2025) |
| xz | 2 (2023) | 3 (2024) | 1 (2025) |
the thought experiment, run on the release calendar
Suppose every regular contributor in this table stopped tomorrow. Not a backdoor, not a bus: they simply never commit again. This is the scenario the comic is about, and it is worth running properly, because the intuition most people have about it is wrong in both directions. Nothing would break on day one. A great deal would be unfixable by day ninety.
Day one is uneventful because the code is already on the devices. A library is a book that has been lent out four billion times, and the librarian leaving does not recall the copies. Phones would ring, pages would load, logins would work. The absence only shows when the world asks for a change, and each project's release calendar says how soon that is. Fig 08 uses the typical gap between releases over the last three years as the clock: once a typical gap has passed, a release that would normally have shipped has not.
Drag the months forward. A tile goes dark once a typical gap between that library's releases has passed without one. Tap a tile for its gap.
Gap = median days between release tags, 7 October 2023 to 7 October 2026, from each repository's tags on 11 October 2026; same-day tags collapsed, pre-release tags excluded by name. bash's gap is from its two releases on gnu.org. libyaml has had no release since 2020 and a release candidate in April 2026, so it never darkens: it is already in this state. The consequence column is this note's judgment, by the kind of input each library handles.
| Symbol | Library | Releases, 3 yrs | Per year | Typical gap, days | Kind of failure |
|---|
Within a month, ten of the 33 have missed a release. Most of the misses are silent: ncurses' weekly patch, SQLite's point release, sudo's. Two are not. FFmpeg ships a fix every nine days on average and HarfBuzz every two weeks, because fuzzers find bugs in decoders constantly, and the first decoder bug found after the vanishing is a permanent way into every device that renders untrusted images, fonts or video, with no upstream fix coming.
Within three months, 24 have missed a release, and the time zone database is among them. Eleven releases in three years means that by its typical 77-day gap some government has changed its clocks and no phone has been told. Google and Apple would patch their own copies; they have the engineers. Nobody would be keeping the shared copy, so two phone makers could disagree about what time it is in a country, which has never happened and only has to happen once.
By the end of the first year, 29 of 33. The encryption and transfer layer stops moving at the moment it most needs to: the migration to post-quantum key exchange is under way in OpenSSL and OpenSSH now, browser vendors are shortening certificate lifetimes, and HTTP keeps gaining versions. Clients that cannot be updated start failing handshakes, or keep accepting what they should not. The three that would not miss a release for two years, zlib, musl and bash, are the reason this scenario is hard to see from outside: a library that ships once every two years looks identical whether it is well or abandoned.
Two things leave with the people that are harder to replace than code. The first is keys. Releases are signed, and distributions verify them against the maintainer's personal key; a new steward has to issue a new key and persuade every distribution to trust it, which is precisely the moment an attacker would choose, as the xz episode showed. The second is addresses. Five of the ten added elements are developed from the maintainer's own domain, as are tz's mailing list and xz's download site. A domain that is not renewed goes to whoever registers it next, and a dead project's download page in a stranger's hands is a supply-chain attack waiting for its first visitor.
What would not happen is data loss. PNG, JPEG, SQLite's file format, tar and gzip are documented and stable; the books stay readable. What is lost is the ability to change, and the people who knew why the code is the way it is.
The repair bill is smaller than the scenario suggests. Two full-time engineers for each of the 33 elements is 66 people, roughly $16.5 million a year at a loaded cost of $250,000 each; that is copper.vision arithmetic, and the loaded-cost assumption is the whole estimate. The five Sovereign Tech Agency grants in Fig 05 total €1.83 million across four years, and the 2014 Core Infrastructure pledge was $5.4 million over three. Public grants to these 33 have never approached the repair figure in any year, and the scenario is already real for libxslt, which has had no regular contributor since its maintainer stepped down and still ships in every iPhone and every copy of Chrome.
three rules and one checklist
None of this is an argument against using these libraries. There is no alternative to most of them, and the people keeping them are better at it than anyone you could hire to replace them. It is an argument for knowing which of your products are compounds of which elements, and for putting a small amount of money in front of the incident instead of a large amount behind it. Section 07 is the repair plan in reverse; this is the version you can start on Monday.
| Field | Where it comes from | Flag when |
|---|---|---|
| Regular contributors, last 12 months | git log, authors with 10+ non-merge commits | 2 or fewer |
| Top author's share | same log | above 80% |
| Trend, last five years | same log, by calendar year | falling, or flat at 1 |
| Funding found | STA, Alpha-Omega, Open Collective, GitHub Sponsors, project site | none, with reach above 1 bn |
| Last maintainer change | MAINTAINERS file, release signer, mailing list | within 12 months, or to an unknown name |
| Named backup | project governance page or list archive | none named |
each claim, its evidence, and what would break it
how it was counted, and by whom
Source of the original count. For the 23 libraries sheets.works counted, the regular-contributor, author and change figures in Fig 01 are theirs, re-read on 11 October 2026.2 Their window is 7 October 2025 to 7 October 2026; merges and bots are excluded; a person counts as a regular contributor with ten or more changes.
Re-count and extension. On 11 October 2026 copper.vision cloned the public history of 32 of the 33 libraries from GitHub (official repositories or mirrors; bash's mirror ends in 2017 and was not used), excluded merge commits and authors matching bot patterns, and counted by author name after normalizing case and accents. The same window reproduced sheets.works' regular-contributor count on 19 of 22 projects; curl, FreeType and OpenSSH differ by one. The ten added libraries were counted the same way. Per-year figures in Fig 03 and Fig 07 use calendar years. The script and per-project outputs are available on request.
Devices. For the original 23, a library counts on a platform only where sheets.works saw it in a compiled image or SDK. For the ten added, presence is taken from vendor source trees and announcements, which is weaker, and six of the ten make no device claim. Bases: Android over 3 billion active devices (Google, 2022), iPhone over 1 billion (Apple, 2021), Windows 1.6 billion monthly (Microsoft, 2026). Macs, iPads, servers, cars and TVs are left out, so every device number is a floor.
Compounds. Membership follows the vendors' own source trees: Chromium's third_party directory for the browser compound, the Android 16 and iOS 26.2 system libraries for the phone compounds, CPython's build dependencies for the script compound, Alpine's base image for the container compound, and the standard tooling of a Debian or Red Hat server for the deploy and login compounds. Each is a typical path, not an inventory.
Added here. The grouping into eleven columns, the element symbols, the compounds, the years-on-the-shelf count, the trend series, the money-and-incidents line and the rank correlations (Spearman, scipy, on sheets.works' 23 rows) are copper.vision's. Start years in Fig 02 come from the project histories cited; three are approximate and marked.
Release cadence (Fig 08). Release tags were read from the same repositories on 11 October 2026, all branches. A tag counts as a release if its name does not mark it as a candidate, alpha, beta, snapshot or similar; tags on the same day are collapsed to one; the typical gap is the median of the days between consecutive release days from 7 October 2023 to 7 October 2026. bash's gap is the interval between its 5.2 and 5.3 releases on gnu.org. The repair arithmetic in section 07 assumes two engineers per library at a loaded cost of $250,000 and is not a quote from anyone.
Discrepancies kept visible. OpenSSL shows 35 regular contributors in sheets.works' window, 36 in the re-count, and 32 in calendar 2025; the page labels each. The table records expat as "none found," but its maintainer has been funded by the City of Munich since August 2026; the page shows the Munich contract. SQLite is listed with four authors and three regular contributors. The GitHub mirror of zlib begins in 2011 and of SQLite in 2000, so their lines in Fig 03 start there.
Encoding. Dark green marks a counted quantity; in dark mode the fill is light grey on green. Red marks an incident. A dashed outline marks none. Color is never the only carrier: counts, outlines and labels repeat every distinction, and every figure has a data table.
Facts re-read 11 October 2026. Corrections will be listed here with dates. Report an error to optic@copper.vision, or reach the author through his name in the footer.