Every attempt to score open source projects for criticality, risk, or funding need ends up built on roughly the same dozen signals, because those are the dozen signals you can get from a registry API and the GitHub REST endpoints in an afternoon. I wrote earlier this week about the 2015 CII census, whose formula scored xz-utils a 6 out of 13 and let it sink to row 254, and which nonetheless got more right than it’s usually given credit for. Ten years on there are several successor efforts running, from foundations, academics, and funders, and I’ve contributed data to most of them. With far more data and far more people working on the problem they are still largely built on the same inputs, so they inherit most of the same blind spots plus a few new ones, and I wanted to write those down in one place without picking on any single model. ## Missing read as zero The most consequential mistake is treating the absence of a signal as a low value of that signal. Go modules are fetched from version control via a proxy that publishes no per-module download counts. C libraries reach machines through apt, dnf, apk, vendoring, and static linking, none of which report to anyone. If a model’s entry filter is “top N by downloads”, or its importance weight is download-derived, both of these ecosystems are largely excluded before any risk scoring runs, and the output contains no indication that they were ever candidates. I mentioned Daniel Stenberg finding curl listed at ten thousand downloads a year, which is an accurate count of the channels that happen to be instrumented and bears no relation to the twenty billion or so installations curl actually has. Zero GitHub issues might mean zero users, or it might mean bugs are tracked in Bugzilla, a mailing list, Launchpad, or the Debian BTS. The absence of a `FUNDING.yml` could equally mean nobody is paying or that three full-time maintainers are on Red Hat’s payroll, and a missing OpenSSF Scorecard result tells you nothing about security if the project is hosted on cgit where Scorecard can’t run. Almost every model I’ve seen handles all of these cases by writing a zero into the cell, or by silently dropping the row, rather than by writing “unknown” and propagating the uncertainty. Once the dashboard renders, a null and a zero look identical, and the project that didn’t fit the schema is indistinguishable from the project that genuinely has nothing. The earlier, harsher version of the same failure is the entry filter that decides what gets scored at all. The scoring formula in a criticality model is the part that gets discussed, but the candidate set it runs over has usually made the bigger decision already. The 2015 census scored Debian packages above a popcon threshold, so sudo and polkit weren’t misranked by it, they were never in the input. Modern equivalents typically start from “top N% of registry downloads” or “packages with a resolvable GitHub URL”, and everything those filters exclude is excluded silently. There is no row in the output that says “not considered”, and a reader has no way to distinguish “scored as low risk” from “never entered the room”. ## Easy to collect, so it must mean something Availability gets mistaken for relevance: a metric is used because the API returns it, and the justification is worked out afterwards. This is the streetlight effect applied to software, with the GitHub and registry APIs as the lamp post and most of the actual risk lying out in the dark. Download counts are the universal example. The number an npm or PyPI API gives you is dominated by CI runners reinstalling the world on every push, with mirror traffic, bot scans, and the occasional human mixed in. It is not a count of users, or of installations, or of anything that maps cleanly to “how many people are affected if this breaks”. It correlates loosely with those things in the fat middle of the distribution and falls apart entirely at the edges, which is unfortunate because the edges are where you’re trying to look. GitHub stars measure the intersection of “people with GitHub accounts who clicked a button” and the project’s visibility in that demographic, which skews hard towards web frontend and developer tooling. ICU is linked into every browser, Android, the JDK, and Node, and has roughly 3,500 stars. c-ares does async DNS for curl, Node, and gRPC and has about 2,100. libxml2’s GitHub mirror has 735. Stars are also straightforwardly purchasable. He et al. identified around six million suspected fake stars on GitHub between 2019 and 2024, with the rate climbing sharply in the last year of that window, so any model weighting stars is partly weighting whoever paid for a campaign. CVE count is routinely used as a security signal and measures the opposite of what people assume. OpenSSL and the Linux kernel have hundreds of CVEs because security researchers look at them constantly, while an unfuzzed C parser that nobody has examined since 2014 has none and is more dangerous for it. Treated as a risk input the metric tracks audit attention received rather than vulnerabilities present, which rewards exactly the projects nobody has bothered to check. It also only counts the subset of fixed vulnerabilities where someone went through the CVE process. Plenty of maintainers find and fix security bugs and ship the patch in a routine release rather than spend a week arguing with a CNA about severity scoring, and none of that history shows up in the column. Code complexity metrics get used as a proxy for how hard a project would be to replace, but cyclomatic and Halstead scores count branches and operators, which is what a static analyser can see and only loosely tracks what a human would find difficult. Vlad-Stefan Harbuz pointed me at the regex engine he wrote for Hare’s standard library, which reads to any such tool as unremarkable loops over arrays. The loops are executing a virtual machine for pattern matching, and all of the difficulty is in the automaton they encode, where no metric is looking. Commit cadence and “last activity” penalise software that is finished. TeX is the canonical case, and bzip2, libogg, and a lot of format-parsing and crypto code that implements a frozen specification are deliberately low-churn because the format is stable and churn is itself a risk. The same metric is trivially gamed in the other direction by Dependabot and Renovate, which will happily keep a repository’s activity graph green for years after the last human stopped reading the notifications. That at least leaves a recognisable bot author in the log. Claude Code and similar coding agents now support scheduled and repeating tasks, so a repository can accumulate a steady stream of plausible-looking maintenance commits authored under a human’s name with no human in the loop, and commit frequency stops distinguishing maintained from automated entirely. I’ve been trying to count how often that Weekend at Bernie’s condition actually holds across the most-depended-on packages, and the bot-only category is large enough that any activity metric ignoring authorship is measuring the bots. ## One number, many units Comparing absolute values of any of these metrics across ecosystems produces nonsense, because the units are different even when the column header is the same. An npm “download” is mostly a count of CI cache misses, the Homebrew analytics equivalent is an opt-in ping from a macOS developer laptop, and a Debian popcon install is an opt-in report from a shrinking population that was never representative of servers or containers. Adding these together, or fitting a coefficient that converts one into another, puts a precise-looking number on a quantity that doesn’t exist. Dependent counts behave the same way: npm’s culture of tiny single-purpose packages means a string-padding helper can have tens of thousands of declared dependents. A C compression library that is statically linked into every browser, every database engine, and most games on the planet might have a few dozen, because C dependencies are expressed as `#include`, a vendored source file, a git submodule, or a line in a CMake script, none of which produce a manifest edge that a registry crawler can follow. Ranking these two projects against each other by dependent count tells you about packaging conventions in their respective ecosystems and nothing about which one matters more. Even within the set of things that do produce manifest edges, package granularity varies enough to break comparisons. A Rust workspace might publish forty crates from one repository and one team where a Python project of the same size would publish a single package, so the Rust project shows up as forty times as many nodes in the graph, internal edges between them inflate its PageRank, and the same handful of maintainers gets counted forty times in any bus-factor sum. ## GitHub as the visible universe Most models lean on the GitHub API for everything that isn’t a registry field: contributors, issues, stars, security policy, sponsors, Scorecard. By package count most open source is on GitHub, so this is a reasonable place to start, but the projects hosted elsewhere are disproportionately the old low-level infrastructure that the models exist to find. PostgreSQL, SQLite, GnuPG, glibc, FFmpeg, and most GNU projects run primary development on mailing lists, self-hosted cgit, Gerrit, or Savannah. Some have read-only GitHub mirrors, which is its own trap. The mirror has stars and a contributor graph, so the API happily returns numbers for it, but pull requests opened there go nowhere and the contributor graph reflects whoever pushes the sync rather than who writes the code. Nothing in the API response distinguishes a mirror from a primary, so the mirror gets scored as if it were the project. The GitHub `/contributors` endpoint only counts commit authors it can link to a GitHub account. curl’s own THANKS file lists over 3,600 contributors, but the API returns a few hundred, because most of the people in curl’s history sent patches from an email address that GitHub has never seen. Bus-factor formulas built on the same data then report curl as 1, since Daniel Stenberg has authored over half the commits, and the formula has no way to distinguish a prolific founder working alongside dozens of active people from a solo maintainer with nobody else around. The same endpoint misleads in the opposite direction by returning lifetime totals, so a project that had eighty contributors in 2012 and has one exhausted person today shows a reassuring headcount, and there is no field anywhere in the API or the registry metadata for whether that one person is close to walking away. OpenSSF Scorecard is widely consumed as a security score even though several of its checks (Branch-Protection, Token-Permissions, Dependency-Update-Tool, CI-Tests) detect GitHub features rather than security properties. A project with self-hosted Buildbot CI, mailing-list patch review, and twenty years of careful security process scores worse than a weekend template repo with the default Actions workflow enabled. In the other direction, a project that does tick every box comes out near ten, and that gets read downstream as “secure”, as though the checklist covered the whole of security rather than the slice of it a repository scan can reach. And once a score like this becomes an input to funding decisions, Goodhart kicks in: projects start enabling the checkboxes that move the number rather than doing the work the checkboxes were meant to proxy for. ## Which project is this Identity is harder than it looks, and almost every model gets it wrong in at least one direction, starting with the fact that the same code shows up under different names in different places. libcurl is `curl` on Homebrew, `libcurl4` on Debian, `pycurl` on PyPI, `curl-sys` on crates.io, and `curl/curl` on GitHub. A model that doesn’t unify these holds five separate low-scoring entries for one risk surface, and any funding or attention directed by the output gets split five ways or pointed at the wrapper instead of the thing being wrapped. The opposite mapping also breaks things, since LLVM, GCC, coreutils, util-linux, and BusyBox each ship dozens of separately-named artifacts from a single repository. A model that assumes one package maps to one repo either picks one artifact and ignores the rest, or counts the same maintainer team dozens of times. Several models I’ve looked at simply exclude these projects because computing complexity metrics over a repository that size times out, which means the criticality scoring has a hole exactly where the most critical projects sit. Forks confuse things further, because when a package’s listed repository URL points at a fork, or the original is archived and development has moved to a fork that the registry metadata doesn’t know about, every repository-derived metric is describing the wrong tree. ## Funding you can’t see Project health and funding models tend to look for GitHub Sponsors, `FUNDING.yml`, Open Collective, and foundation membership lists, because those are public and machine-readable. The most common funding arrangement for critical infrastructure is none of those. It’s a maintainer employed by Red Hat, Google, Intel, Canonical, or a hardware vendor, with the project as some or all of their job, and that arrangement leaves no trace in any file a crawler can fetch. The second most common is consulting and support contracts around the project, which is similarly invisible. Ben Nickolls and I gave a talk on this at FOSDEM 2025: when we tried to assemble a picture of where open source funding actually comes from and where it goes, the public tip-jar layer that everyone measures turned out to be a thin film over a much larger and almost entirely opaque body of corporate salary, foundation grants disbursed without public reporting, and support revenue. A model reading only the public layer will mark a project with a salaried team as unfunded while treating an enabled but barely-used Sponsors button as evidence of sustainability. ## The compound case Individually, each of these mismeasures some projects in some direction, and for the bulk of modern, registry-published, GitHub-hosted packages the errors roughly cancel out. The trouble is that the errors correlate, because a project old enough to predate GitHub is disproportionately likely to be written in C, distributed by vendoring rather than a manifest dependency, developed over a mailing list, funded through someone’s salary, and low-churn because the format it implements stopped changing years ago. So the same project gets undercounted on downloads, dropped from the dependency graph, nulled on contributor metrics, scored low on Scorecard, marked unfunded, and flagged as inactive, all at once, for six different expressions of the same underlying fact: it doesn’t look like an npm package. The quiet system library with one tired maintainer and no dashboard footprint is exactly what we built all of this tooling to find, and it remains the thing the tooling is structurally worst at seeing.

Find your Just Noticeable Difference in colour perception. How small a colour difference can you actually see?

**FOR IMMEDIATE RELEASE** **Contact:** [email protected] **Subject:** Open Source Foundations Consortium Announces Seven New Working Groups **Embargo:** None The Open Source Foundations Consortium (OSFC) has formed seven new working groups for open source ecosystem governance. The working groups were approved by the OSFC Steering Committee following a six-month consultation period during which fourteen comments were received, twelve of which were from bots. Each working group operates under the OSFC Charter and reports to the Technical Advisory Board, which reports to the Governing Board, which reports to the Executive Director, who reports to the Steering Committee, which chartered the working groups. * * * ### Supply Chain Health Assessment and Monitoring Entity SHAME is chartered to develop a standardized scoring methodology for open source project health, producing a single numeric score between 0 and 850 that reflects a project’s maintenance status, security posture, community governance, and bus factor. Each project’s SHAME score will be published to the registry alongside package metadata. Projects scoring below 300 will receive a yellow banner in package manager search results. Projects below 150 will receive a red banner and a recommendation to “consider alternatives.” SHAME scores are updated weekly and there is no appeals process, though an appeals process working group has been proposed and referred to YAGNI. Early drafts of the rubric weight “time since last commit” heavily enough that finished software may be penalized, a concern that has been noted for a future meeting. * * * ### Package Availability Notification and Incident Coordination PANIC coordinates the ecosystem response when a package maintainer goes silent, mass-transfers ownership, or mass-deletes packages. PANIC maintains a 24/7 hotline staffed by volunteers in compatible time zones, though the hotline number is not yet public because the voicemail system requires a procurement decision that has been deferred to the next Governing Board meeting. In the interim, incidents can be reported by opening a GitHub issue on the PANIC repository, which is monitored during business hours, Pacific time. The working group is developing a taxonomy of maintainer disappearance events, ranging from Level 1 (“maintainer is on vacation and will return”) through Level 5 (“maintainer has mass-transferred all packages to an unrecognized account”). Most incidents are Level 1, but the ecosystem’s response to all levels is currently identical. * * * ### Barely Resourced Open-source Kind Enthusiasts BROKE represents the interests of unfunded open source maintainers within the OSFC governance structure and has no budget, which is consistent with standard OSFC working group policy. Members serve on a voluntary basis. The working group is producing a report on open source sustainability titled “The State of Open Source Funding,” which is also the title of four previous reports by other organizations that reached similar conclusions. The report was not commissioned and has no designated audience. BROKE meetings conflict with SHAME meetings on the calendar, and a scheduling request has been filed. * * * ### Cross-Upstream Registry Security Evaluation CURSE conducts security evaluations across package registries. Unlike existing advisory databases, which are voluntary, CURSE findings are binding and can result in package removal, credential revocation, or formal censure. Once a CURSE evaluation is opened, it cannot be closed without a finding, as there is no “no issue found” outcome in the current process. Evaluations are conducted by a rotating panel of three auditors who are required to have published at least one CVE or to have been the subject of at least one CVE, as both qualifications are accepted. Evaluations take between three weeks and fourteen months, during which the package is listed as “under CURSE review” in registry metadata. Packages under review have seen a measurable decline in downloads, which the working group considers outside its scope. CURSE has completed nine evaluations and issued findings against all nine. An early draft advisory recommending the removal of all packages matching the regex `is-[a-z]+-[a-z]+` from npm was tabled after it was determined this would affect 14,000 packages. * * * ### Best-practice Initiative for Kubernetes, Engineering Standards, Habitual Endless Discussion BIKESHED is the OSFC standards body, responsible for defining best practices across the open source ecosystem, and has been in formation since 2023 while its charter remains under review by BIKESHED. The format for BIKESHED standards documents was drafted in Markdown, but a motion was raised to use AsciiDoc, which led to a six-month evaluation period that concluded both formats were acceptable, after which a motion was raised to define “acceptable” more precisely. BIKESHED currently has 340 open issues, 12 approved standards, and one published standard, which is the standard for how to propose a standard. That standard is under revision because it references itself and the self-reference creates an ambiguity in section 4.2 that three members have filed competing amendments to resolve. * * * ### Yet Another Governance & Naming Initiative YAGNI is the meta-governance working group, overseeing the creation, naming, and dissolution of all other OSFC working groups. YAGNI voted to establish itself in a unanimous vote from which several members abstained. YAGNI also approves working group names, evaluating proposed names for “clarity, professionalism, and alignment with OSFC values.” All seven names announced today passed the naming review, though YAGNI does not evaluate acronyms. * * * ### Label Governance and Trust Marks LGTM administers a trust mark programme for open source packages. Packages that complete the LGTM review process receive a trust mark displayed in registry search results and CI output, confirming that the package has been reviewed per the criteria in LGTM Standard 001. To date, all packages that have applied for a trust mark have received one, which the working group attributes to the quality of applicants. Three PRs have been accidentally merged as a result of discussions about LGTM governance in code review threads, and a proposal to rename the working group was submitted to YAGNI and rejected. * * * ### Getting Involved Working group meetings are open to OSFC members at the Contributor tier and above. Meeting times are listed on the OSFC community calendar, which is hosted on a shared Google Calendar. Non-members may observe working group meetings but may not speak, vote, or appear on camera. Written comments may be submitted to the working group mailing list, which is moderated. Moderation turnaround is approximately three weeks. * * * _The OSFC is a 501(c)(6) trade association incorporated in Delaware. The consortium’s mission is to promote the sustainability, security, and governance of open source software through multi-stakeholder collaboration, working group formation, and the publication of standards, reports, and other deliverables that the ecosystem may find useful._

Open Source Policy Summit 2026: That's not a good idea

The trend can improve the air quality of your home

1h 49m | 16

Smarter Shopping, Better Living! Aliexpress.com

<p>Like so many other software projects the curl project has copyright mentions at the top of almost every file in the source code repository. Like</p> <pre class="wp-block-preformatted">Copyright (C) 1998 - 2022, Daniel Stenberg ...</pre> <p>Over the years we have used a combination of scripts and manual edits to update the ending year in that copyright line to match the year of the latest update of that file.</p> <p>As soon as we started a new year and someone updated a file, the copyright range needed update. Scripts and tools made it less uncomfortable, but it was always somewhat of a pain to remember and fix.</p> <h2 class="wp-block-heading">In 2023 this changed</h2> <p>When the year was again bumped and the first changes of the year were done to curl, we should then consequentially start updating years again to make ranges end with 2023.</p> <p>Only this time someone asked me <em>why?</em> and it made me decide that <em>what the heck, let’s completely rip them out instead!</em> Doing it at the beginning of the year is also a very good moment.</p> <h2 class="wp-block-heading">Do we need the years?</h2> <p>The <a href="https://en.wikipedia.org/wiki/Berne_Convention">Berne Convention</a> states that copyright “must be automatic; it is prohibited to require formal registration”.</p> <p>The often-used copyright lines are not necessary to protect our rights. According to the Wikipedia page mentioned above, the Berne Convention has been ratified by 181 states out of 195 countries in the world.</p> <p>They can still serve a purpose as they are informational and make the ownership question quite clear. The year ranges add questionable value though.</p> <p>I have tried to find resources that argue <strong>for</strong> the importance of the copyright years to be stated and present, but I have not found any credible sources. Possibly because I haven’t figured out where to look.</p> <h2 class="wp-block-heading">Not alone</h2> <p>It turns out quite a few projects run by many different organizations or even huge companies have already dropped the years from their source code header copyright statements. Presumably at least some of those giant corporations have had their legal departments give a green light to the idea before they went ahead and published source code that way to the world.</p> <h2 class="wp-block-heading">Low risk</h2> <p>We own the copyrights no matter if the years are stated or not. The exact years the files were created or edited can still easily be figured out since we use version control, should anyone ever actually care about it. And we give away curl for free, under an extremely liberal license.</p> <p>I don’t think we risk much by doing this move.</p> <h2 class="wp-block-heading">January 3, 2023</h2> <p>On this day I merged commit <a href="https://github.com/curl/curl/commit/2bc1d775f510196154283374284f98d3eae03544">2bc1d775f510</a>, which updated 1856 files and removed copyright years from almost everywhere in the source code repository.</p> <p>I decided to leave them in the <a href="https://github.com/curl/curl/blob/master/COPYING">main license file</a>. Partly because this is a file that lots of companies include in their products and I have had some use of seeing the year ranges in there in the past!</p> <h2 class="wp-block-heading">Bliss</h2> <p>Now we can forget about copyright years in the project. It’s a relief!</p>