Stars, Forks, and Dependencies: What Open-Source Maintainers Can Honestly Claim in an EB-2 NIW Petition

Open-source software is one of the quieter pillars of modern infrastructure. A library maintained by a handful of volunteers can sit beneath hospital scheduling systems, payment processors, scientific pipelines, and government portals, often without most of those organizations ever thinking about who looks after it. The people who do that work frequently have influence far exceeding their visibility. Yet when they try to translate that influence into an EB-2 National Interest Waiver petition, many hit an unexpected problem: the evidence that feels most obvious to them is the evidence that officers find least convincing.

This article is about closing that gap. It explains what officers are really asking when they read an NIW petition from a software maintainer, which signals of adoption carry weight and which do not, and how to connect a technical project to the national importance argument the standard requires. It is educational and not legal advice. EB1 Mentor is not a law firm, and USCIS guidance can change. Verify current requirements and consult a qualified immigration attorney about your own case.

The Question Behind the Standard

The NIW framework asks three things, commonly described through the Dhanasar prongs: that the proposed endeavor has substantial merit and national importance, that the applicant is well positioned to advance it, and that on balance it would benefit the United States to waive the usual job offer and labor certification requirement. Our overview of how to frame your national importance argument goes through the first prong in detail.

For a maintainer, the endeavor is usually the continued development and stewardship of a project or a family of projects. The petition must show that this work matters beyond the maintainer's own circle, and that the maintainer is the right person to carry it forward. What the petition must not do is assume that the importance of open-source software in general makes any individual maintainer's work important. Officers read the endeavor as the applicant defines it, not the whole field.

Describe the endeavor in terms of what the software does for people and institutions, not in terms of how widely it has been starred or discussed online. A sentence such as maintaining a library that safeguards data integrity in clinical research pipelines is more useful than a sentence about community size.

Why Popularity Metrics Are Weak Evidence

Stars, forks, followers, and download counts are the first numbers most maintainers reach for. They are easy to retrieve and easy to display. They are also easy to misread, and an officer who does not work in software may be unsure how to weigh them.

Stars measure interest, not use. A repository can attract many stars from people who bookmarked it and never ran it.
Downloads can be inflated by automation. Build systems, mirrors, and continuous integration jobs can generate large counts without any distinct human adopter behind them.
Forks vary in meaning. Some forks represent active derivative work; many are passive copies.
Follower counts reflect personal visibility. They say little about whether the project is relied upon.

The same cautionary logic applies to citation counts in academic work, a point we developed in our article on what citation counts prove and what they quietly do not. Raw numbers can open a conversation, but they rarely close it. The petition needs evidence that explains who uses the software and what depends on it.

Signals That Carry More Weight

The table below compares common open-source signals by what they tend to show and how an officer might read them. It describes patterns; no single item decides a case.

Signal	What it can show	Limitations	How to strengthen it
Stars and followers	General interest	Easily inflated; not tied to use	Use only as background, never as the core argument
Download counts	Volume of installation activity	Includes automated and mirrored traffic	Explain how counts are measured and pair with named adopters
Dependency relationships	Other software packages that rely on the project	Needs context to show which dependents matter	Identify significant dependents and describe what they do
Named organizational adopters	Institutions that use the project in production	Requires evidence beyond a logo list	Obtain letters or documentation from the adopters themselves
Security or safety reliance	Use in sensitive or regulated settings	Must avoid unverifiable claims	Public advisories, audit reports, or adopter statements
Independent technical coverage	Recognition by the field	Needs to be substantive, not a passing mention	Include articles analyzing the project's role
Governance role	Leadership of a significant project	Needs evidence of the applicant's specific role	Commit history, maintainer documentation, foundation records

Colleagues mapping a branching dependency diagram on a glass wall with sticky notes

Dependency Evidence: The Underused Argument

Of all the signals above, dependency relationships are often the most persuasive and the most neglected. A project that other significant projects rely on has demonstrated influence in a way that is hard to fake. If a widely used framework imports your library, then everything built on that framework inherits a connection to your work.

The challenge is presentation. A list of thousands of dependents is meaningless to a non-technical reader. A useful petition selects a few categories of dependents and explains what each does. For example, it might identify dependents that serve healthcare data exchange, those used in public sector infrastructure, and those embedded in widely used scientific tools. It then supports each category with documentation: public repositories, official documentation of the dependent project, or letters from the maintainers or users of those projects.

A caution applies. Do not describe the dependents as relying on your work in ways you cannot verify. If you cannot show that a government agency uses a dependent project, do not say so. Claims that go beyond the documentation are the surest way to lose an officer's confidence.

Never attribute use to an organization, agency, or company unless you can document it. A named adopter you cannot substantiate can undermine the credibility of the whole petition. Obtain a letter or find a public source before including any name.

Letters From Adopters, Not Just Fans

Letters of support from users of your software can be some of the strongest evidence you have, if they are written by the right people about the right things. The most useful letters come from engineers or leaders at organizations that use the project in production. They describe what the organization does, how the software fits into it, what would happen without it, and how the writer came to know the project.

Letters that merely praise the maintainer's skill, or that come from close collaborators, are less persuasive on the question of national importance. They may still help on the well positioned prong. For an overview of how independent perspectives can support a case, see our article on how industry practitioners build an NIW case without a research record, which covers a closely related problem for people whose work lives in deployment rather than publication.

Connecting the Project to National Importance

Software importance is global by nature, which sometimes tempts applicants to describe the benefit only in international terms. The NIW standard asks about importance to the United States. A petition should explain the connection: which U.S. sectors, institutions, or public interests the work serves.

There are several credible routes for making that connection.

Sector relevance. Show that the project supports a U.S. sector with documented national significance, such as healthcare data systems, energy infrastructure, public sector services, or scientific research, using authoritative government or academic sources to describe the sector's importance.
Security and resilience. If the project affects the security of widely used systems, document it through public advisories, audit documents, or independent security researchers, without exaggerating.
Federal priorities. Where the work genuinely aligns with publicly stated federal priorities, cite the priority documents. Do not stretch to force a match. Our article on what STEM and critical technology considerations really add explains why alignment helps but does not substitute for the standard itself.
Economic or public benefit. Where credible sources exist, explain how the software reduces costs or risks for U.S. organizations, using documented examples rather than estimates you cannot support.

The Well Positioned Prong for Maintainers

The second prong asks whether you are well positioned to advance the endeavor. For maintainers, that evidence tends to be rich but needs careful organization. Useful material includes your commit and review history in the project, maintainer or committer status, design documents you authored, releases you managed, security issues you resolved, and the presence of others who rely on your judgment. A foundation or governance record that names you in a stewardship role is stronger than a repository page alone.

It also matters to describe what comes next. An officer reading the petition wants to understand what you plan to do and why you can do it: the roadmap, the problems left to solve, and the resources or relationships that make it feasible. Our article on the overlooked prongs and the related one on the trajectory the second prong turns on are worth reading together.

Three Hypothetical Scenarios

These examples are illustrative and hypothetical. They simplify real situations and do not describe actual EB1 Mentor clients.

Scenario One: The Data Validation Library

A maintainer of a data validation library had a large number of stars and downloads and planned to lead with them. After review, the petition was reorganized. It identified three categories of dependents: clinical research tooling, public health reporting software, and a widely used open scientific framework. For each, it included documentation of the relationship and a letter from a user of the dependent project. The star count moved to a single sentence in the background section. The petition now argued that the maintainer's work protected data quality in systems that serve U.S. research and public health institutions.

Scenario Two: The Cryptography Contributor

A contributor to an open-source cryptographic library had made critical security fixes but was not the lead maintainer. The petition did not overstate her role. It documented the specific vulnerabilities she resolved, public security advisories crediting her work, and independent security researchers who confirmed the significance of her fixes. Her well positioned evidence showed a record of sustained contribution, and the national importance argument rested on the library's use in secure communications infrastructure, supported by public documentation of its adoption.

Scenario Three: The Infrastructure Tool for Small Utilities

An engineer maintained an open-source monitoring tool used by small water and power utilities that could not afford commercial systems. Download counts were modest. The petition did not apologize for that. It explained that the tool's importance was in who used it: letters from utility engineers described how it replaced manual processes and improved reliability, and public sources documented the infrastructure challenges small U.S. utilities face. The narrow adopter base became a strength because each adopter could be documented and tied to a public interest.

An engineer in a utility control room reviewing a monitoring display beside a printed support letter

Mistakes Maintainers Commonly Make

Leading with vanity metrics. Opening the argument with stars and downloads instead of what depends on the work.
Claiming adopters without proof. Listing logos or organizations without letters or public documentation.
Treating global importance as U.S. importance. Failing to show the connection to U.S. interests.
Blurring personal and collective credit. Describing the project's success without explaining your own role in it.
Ignoring confidentiality constraints. Naming employer-related deployments without permission. Our article on documenting contributions you are not allowed to describe covers how to handle that.
Underexplaining the technical terms. Assuming an officer understands package registries, dependency graphs, or continuous integration.

Avoid statistics you cannot source. If you quote a percentage of the internet that depends on your project, a number of organizations that use it, or an economic value, make sure you can point to a credible, verifiable source. Unsupported figures are more damaging than no figures.

Projects With Many Contributors: Explaining Your Share

Open-source work is collective by design, which creates a presentation problem that solo researchers rarely face. A project may have hundreds of contributors, and an officer reading a petition will reasonably ask which part of the success belongs to the applicant. If the petition is silent on that point, the reader may either credit the applicant with everything, which invites skepticism, or with very little, which undersells the record.

The better approach is to be specific and modest. Describe the areas of the codebase you designed or rewrote, the releases you coordinated, the reviews you performed for other contributors, and the decisions the community deferred to you. Where possible, support each description with public records such as merged change histories, release notes, design proposals, or governance minutes. Then let independent voices confirm it: a co-maintainer or an adopter can explain that a particular capability exists because of your work, in a way your own description cannot.

Be equally careful with the passage of time. A project that was influential five years ago but has changed hands raises the question of whether the endeavor is ongoing. The petition should show that your stewardship is current, that you have a credible plan, and that the work will continue in the United States. Evidence from recent releases, active maintenance, and upcoming milestones helps establish continuity, and it addresses the forward-looking nature of the standard directly.

Making Technical Evidence Readable

Even strong evidence loses force if the reader cannot follow it. A few habits help.

Open each technical section with a plain-language sentence stating what the software does and who it helps.
Use a short glossary for terms such as package, dependency, release, and maintainer.
Prefer diagrams that show the relationship between your project and its dependents, with a short caption in ordinary language.
Explain exhibits in the text. State what each exhibit proves and why, instead of expecting the officer to infer it.
Keep screenshots purposeful. Include only those that demonstrate a point, with annotations.

Organization matters as much as content. A clear index and consistent labeling, the principle behind our article on the exhibit index, helps an officer find the exhibit that supports each claim quickly.

Where the O-1A and EB-1A Fit

Some maintainers will find that their records fit another category better, or that a parallel strategy makes sense. The O-1A, for instance, has criteria around critical roles and contributions that may suit certain profiles. Our article on the O-1A for AI engineers and software professionals discusses how software careers translate into those criteria. The right choice depends on the whole record and the applicant's goals.

Checklist: Strengthening an Open-Source NIW Record

Is your endeavor described in terms of what the software does and who benefits?
Have you moved vanity metrics to a supporting role?
Have you identified and documented significant dependents?
Do you have letters from organizations that use the software in production?
Is every named adopter backed by a letter or public source?
Have you connected the work to specific U.S. sectors or interests?
Have you documented your own role through commits, reviews, releases, and governance records?
Have you described your plan and why you can carry it out?
Are technical terms explained and exhibits clearly indexed?

Frequently Asked Questions

Do GitHub stars count as evidence for an EB-2 NIW?

They can be included as background, but they are weak evidence on their own. Officers are generally more persuaded by documented use and dependency relationships.

Can I use download statistics from a package registry?

You can, with context. Explain how the numbers are collected and note that automated traffic may be included. Pair them with named adopters.

Do I need to be the lead maintainer?

Not necessarily, but you need to document your specific role and contributions. Overstating a role is risky.

How do I show national importance for a global project?

Connect the project to U.S. sectors, institutions, or public interests, supported by credible sources and adopter documentation.

Are letters from other maintainers useful?

They help on the well positioned prong, particularly if they are independent. For national importance, letters from adopters tend to carry more weight.

What if my project is used by companies that will not provide letters?

Look for public documentation, such as official project pages, engineering blog posts, or published case studies. Do not claim use you cannot support.

Does contributing to someone else's project count?

It can, if you document the significance of your contributions and how they affected the project and its users.

Should I file NIW or O-1A or EB-1A?

It depends on your record, goals, and timing. Consider an evaluation of the whole profile before choosing.

Does a foundation affiliation help?

A documented governance or stewardship role in a recognized foundation can support well positioned evidence, provided the role is clearly described.

Can I rely on a statement that the project powers a percentage of the internet?

Only if you have a credible source and can describe how the figure was derived. Otherwise, leave it out.

References and Further Reading

Guidance and standards can change. Verify current requirements with official USCIS sources and qualified immigration counsel.

Conclusion

Open-source maintainers frequently do work that quietly supports large parts of the economy, but the metrics that make that work look impressive online are often the least useful in an immigration petition. The stronger approach moves from popularity to dependence: who relies on the software, for what, and what would be harder without it. Add documented adopters, a clear connection to U.S. interests, an honest account of your own role, and a credible plan for what you will do next, and the petition begins to read as an argument about national importance instead of a tally of attention.

Every case is unique, and the right framing depends on your project, your role, and your goals. If you maintain software that others depend on and want help turning that influence into a clear record, EB1 Mentor can help you plan. Learn about our EB-2 NIW services, request a profile evaluation, or contact EB1 Mentor to discuss your portfolio.

Maintain software others depend on? Contact EB1 Mentor to turn real adoption into a clear NIW record, or start with a profile evaluation.