From Citations to Utility: Tracking the True Ripple Effect of FOSS and Basic Mathematics

Getting your Trinity Audio player ready...

A tiny open-source repository may receive few stars and no academic citations yet quietly become a dependency of software used by major banks, cloud providers, hospitals, and technology companies. Likewise, an abstract mathematical discovery may remain obscure for years before becoming essential to cryptography, artificial intelligence, network optimization, or formal verification.

Traditional research metrics struggle to detect these indirect effects. The h-index measures citation accumulation, not practical utility, intellectual necessity, or downstream economic value. A more accurate system would use artificial intelligence to construct a continuously updated graph connecting mathematical concepts, research papers, software packages, technical standards, products, and organizations.

Such a system could identify not merely what is popular, but what the modern technological economy actually depends on.

What Is Wrong With the h-Index?

A researcher has an h-index of h when h of their publications have each received at least h citations. The metric was designed to combine publication volume and citation impact into one number.

Its simplicity is also its main weakness.

The h-index cannot reliably distinguish between:

• a foundational theorem and a fashionable survey;
• a necessary citation and a ceremonial citation;
• independent recognition and coordinated self-citation;
• intellectual influence and membership in a large publication network;
• a genuinely useful result and a frequently discussed error;
• recent work and work that has had decades to accumulate citations.

Citation performance is also a lagging indicator. The San Francisco Declaration on Research Assessment warns that quantitative indicators such as citation counts and the h-index provide only a limited view of research performance and require disciplinary and career-stage context. The Leiden Manifesto similarly argues that quantitative evaluation should support—not replace—expert qualitative judgment.

More seriously, citation metrics can be manipulated. Strategic self-citation can raise an author’s h-index, while citation cartels and manufactured documents can inflate citation counts without creating corresponding scientific value. One experiment involving fabricated documents reportedly produced 774 artificial citations across 129 papers, demonstrating how vulnerable automated indexing systems can be.

This does not make citations useless. Citations remain evidence that one document has acknowledged another. The mistake is treating that evidence as a complete measurement of value.

A citation graph records attention. A utility graph should record dependency, use, validation, and consequence.

The Invisible Value of Free and Open-Source Software

Free and open-source software, or FOSS, exposes the limitations of citation-based evaluation particularly clearly.

Software developers rarely cite every library that makes their application possible. A commercial product may depend on hundreds or thousands of open-source components, including dependencies that its own developers never selected directly. These transitive dependencies enter the product because another package requires them.

GitHub’s dependency graph already maps direct and transitive relationships across supported package ecosystems. It can show which packages a repository uses and which public repositories depend on it. This is a primitive but important form of utility measurement: it follows executable dependency rather than academic acknowledgment.

The economic stakes are enormous. Research from Harvard Business School estimated the supply-side replacement cost of widely used open-source software at approximately $4.15 billion, while estimating its demand-side value at $8.8 trillion. The same study found that firms would need to spend approximately 3.5 times more on software if open-source alternatives did not exist.

This disparity reveals a structural problem:

1. A relatively small number of developers create critical components.
2. Thousands of other projects incorporate those components.
3. Corporations build profitable services on the resulting software stacks.
4. Most of the economic value appears far downstream.
5. The original maintainers may receive little money, recognition, or institutional support.

OpenSSF’s Census III analyzed more than 12 million observations of FOSS libraries used in production applications at over 10,000 companies. Studies of this type demonstrate that software importance can be estimated from real production use—not merely repository stars, social-media attention, or academic citations.

Why Repository Stars Are Not Enough

GitHub stars are useful as signals of interest, but they are poor substitutes for impact.

A developer might star a repository and never use it. Conversely, a package may be downloaded automatically millions of times without most users ever visiting its repository. A small low-level component can also be hidden beneath several layers of dependencies.

Other familiar software metrics have similar limitations:

Metric	What it measures	What it misses
GitHub stars	Expressed interest	Production use and transitive dependencies
Forks	Copies or development interest	Whether the fork is active or economically important
Downloads	Package retrieval	Duplicate downloads, automated builds and unused installations
Contributors	Participation	Dependency criticality and code quality
Commits	Development activity	Whether the changes are useful or necessary
Citations	Academic acknowledgment	Commercial and infrastructural use
Direct dependents	Declared reuse	Hidden, vendored and transitive reuse

A repository with 50 stars may therefore be more consequential than one with 50,000 stars.

The correct question is not simply, “How many people noticed this repository?” It is:

Which systems would become more expensive, insecure, inaccurate, or impossible to maintain if this repository disappeared?

Basic Mathematics Has the Same Attribution Problem

Pure mathematics often produces value through long causal chains.

A theorem may influence another theorem, which enables an algorithm, which is implemented in a library, which is incorporated into a commercial platform. By the time the platform creates economic value, the original mathematics may be invisible.

The path may resemble this:

Abstract definition
        ↓
Structural theorem
        ↓
Computational method
        ↓
Published algorithm
        ↓
Open-source implementation
        ↓
Developer framework
        ↓
Commercial product
        ↓
Economic and social value

Traditional citations usually capture only the upper part of this chain. Software manifests and dependency graphs capture parts of the lower chain. Neither system alone connects the entire sequence.

This particularly disadvantages unconventional or highly abstract research. A niche mathematical framework may initially have:

• few researchers capable of evaluating it;
• no established journal category;
• no immediately obvious application;
• terminology different from adjacent fields;
• a long delay before implementation;
• influence transmitted through concepts rather than formal citations.

The result is a measurement paradox: the more foundational a contribution is, the more deeply it can disappear into later work.

A basic mathematical discovery should therefore not be judged solely by its direct citation count. Evaluation should also examine whether its definitions, proofs, constructions, or algorithms reappear downstream—even when terminology changes.

How AI Can Construct a Utility Graph

An AI-based impact system would combine several graphs rather than calculate one universal popularity score.

1. The scholarly graph

This layer would connect:

• papers;
• books;
• datasets;
• theorems;
• definitions;
• authors;
• institutions;
• citations;
• replications;
• corrections;
• formal proofs.

Unlike ordinary citation indexing, the model would classify the role of each reference. It would distinguish between background citations, methodological dependencies, criticism, replication, direct theorem use, and incidental mentions.

A paper that uses a theorem essentially should carry more evidential weight than one that merely lists it in a literature review.

2. The software dependency graph

This layer would map:

• package manifests;
• lock files;
• container images;
• imported modules;
• build systems;
• public repositories;
• package releases;
• direct dependencies;
• transitive dependencies;
• copied or vendored code.

Research on software citation graphs has already proposed integrating software dependencies into scholarly attribution and using transitive credit to recognize indirect contributions.

AI could extend this approach by resolving package renaming, repository migration, forks, code copying, rewritten implementations, and dependencies that are absent from standard manifests.

3. The conceptual lineage graph

Mathematical influence cannot be detected through literal text matching alone.

Different authors may express the same structure using different notation. A concept may be generalized, restricted, translated into category-theoretic language, or embedded into an algorithm without retaining its original name.

A conceptual-lineage model would compare:

• definitions and axioms;
• theorem structures;
• proof strategies;
• diagrams;
• equations;
• pseudocode;
• formalized statements;
• relationships among mathematical objects.

The AI would not declare two ideas equivalent merely because their wording resembles each other. It would produce an evidence-based similarity claim that experts could inspect and challenge.

4. The deployment graph

Public repositories do not reveal every real-world use. A stronger system would also accept privacy-preserving evidence from:

• software bills of materials;
• enterprise dependency scanners;
• public procurement records;
• cloud images;
• mobile applications;
• operating-system distributions;
• package registries;
• technical standards;
• security advisories;
• reproducible-build attestations.

This layer would reveal whether a package is merely available or genuinely deployed.

5. The outcome graph

The final layer would connect research and software to observable outcomes, such as:

• reduced computation time;
• improved security;
• lower infrastructure costs;
• successful experiments;
• verified proofs;
• new products;
• technical standards;
• patents;
• medical or engineering applications;
• avoided duplication of work;
• increased reproducibility.

The objective would not be to assign ownership of an entire product’s value to one upstream theorem or package. It would estimate marginal contribution under uncertainty.

Measuring Dependency Centrality Instead of Popularity

Once these layers are connected, the system can calculate forms of impact that citations cannot represent.

Downstream reach

How many distinct projects, products, institutions, and users are reachable from a contribution?

A package used directly by ten frameworks that each support thousands of applications may have greater downstream reach than a package with many direct but insignificant dependents.

Dependency depth

How far downstream does the contribution travel?

A library can be economically important even when no final application depends on it directly. Its influence may travel through five or ten intermediate packages.

Structural criticality

How difficult would the contribution be to replace?

A popular package with several compatible alternatives may be less critical than an obscure package implementing a unique algorithm or protocol.

Counterfactual replacement cost

What would users need to spend if the contribution did not exist?

This could include:

• redevelopment costs;
• migration costs;
• additional computing resources;
• security auditing;
• licensing expenses;
• research delays;
• opportunity costs.

Knowledge acceleration

How much earlier did later work become possible?

A mathematical result that saves other researchers from recreating a theory may produce substantial value even before commercial deployment.

Validation strength

Has the contribution survived serious testing?

Relevant evidence could include independent reproduction, formal verification, test coverage, successful deployment, adversarial review, issue resolution, and stability across versions.

Maintenance burden

How much continuing work is required to preserve the contribution’s value?

Maintenance is itself a public good. Patching vulnerabilities, reviewing contributions, updating dependencies, preserving compatibility, and answering technical questions should count as measurable output.

A Possible AI Utility Score

The system should not compress every form of value into one opaque number. It could nevertheless calculate an interpretable composite score for funding decisions:

[
U(x)=w_rR(x)+w_cC(x)+w_vV(x)+w_aA(x)+w_mM(x)-w_qQ(x),
]

where:

• (R(x)) is verified downstream reach;
• (C(x)) is structural criticality;
• (V(x)) is independently validated utility;
• (A(x)) is knowledge or development acceleration;
• (M(x)) is continuing maintenance value;
• (Q(x)) is uncertainty, manipulation risk, or evidence weakness;
• the (w)-terms are transparent governance-defined weights.

Each component should be separately visible. A researcher or maintainer must be able to see why the system assigned a score, inspect the underlying evidence, and contest incorrect relationships.

That is essential because an AI-generated metric can become just as harmful as the h-index if institutions treat it as an unquestionable oracle.

Preventing the New Metric From Being Gamed

Replacing citations with an AI score does not automatically solve manipulation. It merely changes the attack surface.

Developers might create artificial dependency chains. Researchers might generate superficial references to favored work. Bots could inflate downloads, stars, issues, or code reuse. Companies could exaggerate deployment claims.

A credible utility system therefore requires several safeguards.

Evidence must have different trust levels

A declared dependency is weaker evidence than a reproducible build demonstrating that the dependency is used. A repository star is weaker than a package installation. A textual mention is weaker than an implementation of a theorem.

Circular influence must be discounted

Closely connected groups can cite, fork, depend on, or endorse one another. Graph algorithms should detect dense reciprocal clusters and reduce the weight of circular signals.

Independent paths should count more

Ten downstream uses originating from ten unrelated organizations provide stronger evidence than 100 repositories generated from one template.

Economic claims require attribution limits

A tiny library inside a billion-dollar product did not necessarily create billions of dollars of value. The system should estimate contribution using replacement cost, substitutability, criticality, and marginal dependence—not assign the product’s entire revenue upstream.

Negative evidence must remain visible

Abandoned releases, unresolved vulnerabilities, retractions, failed replications, broken builds, and unused code should affect evaluation.

Scores must be auditable

The system should show:

• the evidence used;
• the provenance of each relationship;
• the scoring rules;
• confidence intervals;
• known missing data;
• detected conflicts;
• the model version;
• the date of calculation.

An unexplained AI score would reproduce the same institutional opacity that made simplistic metrics dangerous.

From Measurement to Funding

Better impact measurement is valuable only if institutions act on it.

A utility graph could support retroactive funding: researchers and developers receive resources after their work demonstrates verified value. This differs from conventional grant allocation, where applicants must predict impact before producing the result.

The AI Internet Meritocracy model proposes evaluating visible contributions across science and free software and allocating funding according to measurable merit. Instead of asking only whether a researcher belongs to a prestigious institution or writes a persuasive proposal, such a system could ask:

• Did the work solve a real dependency?
• Did other projects build upon it?
• Was it independently validated?
• Did it reduce costs or accelerate discovery?
• Is continued maintenance necessary?
• How much downstream activity would be disrupted without it?

This model is especially relevant to independent scientists and maintainers who produce useful public goods without conventional academic credentials, institutional employment, or professional fundraising teams.

It also complements decentralized science by giving transparent funding systems a richer evidential basis than token voting, popularity, or citation counts alone.

Why Basic Mathematics Must Be Included

Funding systems focused only on immediately measurable deployment would systematically neglect basic science.

Mathematics frequently creates option value: it expands the set of things society may be able to do later. That option may remain unused for years because the necessary hardware, adjacent theory, data, or engineering does not yet exist.

An adequate AI evaluation model must therefore distinguish among:

• current direct utility;
• current indirect utility;
• demonstrated scientific utility;
• enabling or infrastructural value;
• plausible future option value;
• unsupported speculation.

The model should not pretend to know the future. Instead, it should record the properties associated with future usefulness: generality, novelty, explanatory power, formal correctness, connections to unresolved problems, computational implementability, and the number of previously separate structures it unifies.

This prevents “utility” from becoming a synonym for immediate commercial profitability.

Basic mathematics is infrastructure for possibilities. Its value includes not only what currently depends on it, but what it makes logically and technically possible.

Limitations of AI-Based Impact Mapping

Even a sophisticated utility graph will remain incomplete.

Private companies may not disclose their dependencies. Mathematical influence may occur without citation or textual resemblance. An algorithm may rediscover a concept independently. Public package downloads may be distorted by automated systems. Proprietary implementations may hide their intellectual lineage.

Causal attribution is also difficult. A product usually results from many complementary contributions. Removing one component may lead to substitution rather than complete failure.

For these reasons, AI should provide:

• ranked evidence, not absolute verdicts;
• confidence intervals, not false precision;
• multiple dimensions, not one universal score;
• explanations, not unexplained classifications;
• expert appeal procedures;
• regular recalculation as new evidence appears.

The correct role of AI is not to eliminate human judgment. It is to process dependency networks too large for unaided committees while making the resulting evidence inspectable.

A New Definition of Research Impact

Citation metrics ask:

How often did academics mention this work?

A utility-based system asks broader questions:

What knowledge, software, infrastructure, and economic activity became possible because this work existed?

That shift matters for both FOSS and basic mathematics. Their greatest contributions frequently operate below the visible surface. They become protocols, libraries, abstractions, algorithms, conventions, and assumptions upon which later systems are built.

AI can help reveal these hidden chains by connecting research literature, source code, software dependencies, deployments, standards, and real-world outcomes. The result would not be a perfect measurement of merit. No such measurement exists.

It would, however, be substantially closer to the truth than counting citations alone.

For funding institutions, corporations, donors, and decentralized communities, the practical conclusion is direct: trace dependencies, verify utility, reward upstream contributors, and finance maintenance before invisible infrastructure fails.

Researchers and developers who want to support this transition can explore the Science DAO approach to merit-based funding or support independent science and free software.

Frequently Asked Questions

Can AI determine the economic value of an open-source repository?

AI can estimate a range rather than determine an exact value. Relevant evidence includes downstream dependencies, production deployments, replacement cost, alternatives, maintenance requirements, security criticality, and the revenue or infrastructure supported downstream.

How can AI measure the impact of a mathematical theorem?

It can map citations, conceptual reuse, proof dependencies, implementations, algorithms, formalizations, standards, patents, and software whose operation depends on the theorem. Conceptual claims should remain reviewable by mathematical experts.

Is the h-index useless?

No. It provides a limited summary of citation accumulation. It becomes misleading when treated as a complete measure of research quality, originality, practical utility, or individual merit.

Can dependency metrics also be manipulated?

Yes. Artificial repositories, fake downloads, circular dependencies, copied packages, and coordinated endorsements can distort them. Reliable systems must weight evidence by provenance, independence, deployment verification, and manipulation risk.

Why should companies fund upstream FOSS maintainers?

Companies receive economic and operational benefits from shared open-source infrastructure. Funding upstream maintenance can reduce security risk, prevent abandonment, improve compatibility, and preserve components that would be expensive to replace.

Should basic mathematics be funded before practical applications appear?

Yes, but it should be evaluated differently from deployed software. Basic mathematics creates knowledge, unification, rigor, methods, and future option value. Immediate commercial adoption should not be its only criterion.