Evidence Building
How to Document GitHub Star Counts and Open-Source Project Adoption as O-1A Original Contribution Evidence
GitHub stars are a starting point, not a conclusion. For O-1A petitions, open-source contribution evidence must show major significance through named adopters, production use, and academic citations. This guide explains what USCIS accepts, what it discounts, and how to frame borderline records.
The original contributions criterion and open-source careers
The O-1A original contributions criterion under 8 C.F.R. § 214.2(o)(3)(iii)(C) requires that the beneficiary has made original scientific, scholarly, or business-related contributions of major significance in the field. For software engineers and computer scientists whose primary professional output takes the form of open-source code hosted on platforms such as GitHub, GitLab, or similar repositories, the challenge is translating those contributions into evidence that USCIS adjudicators — trained in immigration law, not software development — can evaluate as meaningful proxies for field significance. A repository with substantial adoption, active downstream use in production systems, and documented reliance by the broader developer community represents a genuinely significant contribution, but that significance must be made explicit through carefully assembled evidence and a well-contextualized brief.
The challenge is compounded by the fact that public repository metrics — star counts, fork counts, contributor counts, and download statistics — are visible numbers that can be misread in either direction. A project with 50,000 GitHub stars is clearly popular, but an adjudicator without software industry context may not know whether that number is typical for any competently built utility or exceptional for a project in a narrowly defined technical niche. Conversely, a project with 2,000 stars serving a specialized systems programming audience may represent a more significant field contribution than a general-purpose library with ten times the star count. The petition brief must contextualize adoption metrics with reference to field-specific benchmarks, the narrowness of the target audience, and evidence of downstream use in significant production systems.
The most persuasive original contributions evidence for open-source software practitioners is not the repository metrics themselves but the documented downstream impact: adoption by major technology companies, incorporation into production systems serving tens of millions of users, reliance by other significant projects, citations in academic literature, reference in standardization documents, or deployment by government or critical infrastructure operators. GitHub stars are most persuasive as the opening exhibit establishing the project's prominence, followed by more specific documentation of how the project is being used and by whom. Metrics without context are easily dismissed; metrics anchored by named adopters and verifiable production use cases are much harder to discount.
What the regulation requires for original contributions of major significance
The regulation requires two distinct showings: that the contribution is original and that it is of major significance in the field. Originality is generally easier to establish for open-source projects — the public commit history, the repository's founding date, and the original technical design documented in the project's README, technical whitepaper, or academic companion paper demonstrate that the code is the beneficiary's independent creation. The major significance element is more demanding and requires more than showing that the project is popular or widely used. USCIS policy guidance, including the relevant provisions of the USCIS Policy Manual, indicates that significance in the field means the contribution has had a demonstrated impact on how practitioners approach problems, design systems, or conduct research.
The AAO has articulated what it means for a contribution to be of major significance in the context of O-1A petitions. Evidence that practitioners have adopted the beneficiary's methods, frameworks, or tools as part of standard practice — replacing prior approaches or enabling work that was previously impractical — supports a finding of major significance. Evidence that the contribution provides a convenient alternative to existing tools, without demonstrating that it has changed how practitioners work or has been adopted at scale in significant production contexts, is unlikely to satisfy the criterion. The petition brief must explain not only that the tool exists and has users, but what specific technical problem it solved, why existing solutions were inadequate, and how the field's practice has shifted as a result of the project's adoption.
One useful framing is to document the counterfactual: what would practitioners be doing without this project, and how does its existence change what is now possible or practical? For a database query optimization library adopted by multiple major cloud providers, the counterfactual framing would describe the performance characteristics of prior approaches, the specific bottleneck the project addressed, and the performance improvements or cost reductions that adoption has enabled at scale. This kind of before-and-after technical narrative, supported by declarations from engineers at adopting organizations, makes the significance concrete and accessible to a non-technical adjudicator who must make a legal judgment about the contribution's impact.
Evidence that satisfies the criterion
The most direct evidence of major significance for an open-source project is documented adoption by major technology companies, federal agencies, or recognized research institutions. Evidence of this kind takes the form of publicly available acknowledgments — dependency listings in major company open-source repositories, mentions in company engineering blog posts, citations in technical conference proceedings from premier venues such as NeurIPS, ICML, ICLR, OSDI, SOSP, or SIGCOMM, and entries in the CNCF Landscape or similar authoritative ecosystem registries. Each of these forms of documentation demonstrates that the project has been specifically adopted and relied upon by organizations in positions to evaluate its technical quality, and that the adoption decision was made by engineers with professional accountability for the production systems that depend on it.
Academic citations provide another strong evidence category because they simultaneously support the scholarly articles companion criterion while reinforcing the original contributions argument. When the petitioner's project is cited in peer-reviewed conference proceedings or journals — particularly in leading venues such as the ACM Digital Library, IEEE Transactions journals, NeurIPS, or OSDI — those citations demonstrate that the research community has treated the project as a technical reference point. Google Scholar citation counts for academic papers associated with the project provide a quantified record that can be contextualized with reference to citation benchmarks in the relevant research area, allowing the adjudicator to assess whether the project's academic engagement is exceptional or ordinary for the discipline.
Package manager download statistics — npm downloads for JavaScript packages, PyPI downloads for Python packages, Maven Central downloads for Java packages, crates.io downloads for Rust packages — provide objective, audit-traceable evidence of adoption scale maintained by independent registry operators rather than by the project's creator. For packages with hundreds of thousands or millions of monthly downloads, those statistics establish widespread adoption across the professional developer community. The petition brief should supplement raw download numbers with context: whether the package is a direct dependency or a transitive one, whether it is used in production environments or primarily in development tooling, and what classes of applications commonly include it in their dependency graph.
Evidence USCIS regularly discounts
USCIS adjudicators regularly discount GitHub star counts presented without contextualizing evidence of the kind described above. Stars function as a social bookmarking mechanism that many users activate without ever deploying the project in production, and an adjudicator who has seen multiple petitions relying on star counts as primary evidence of significance may apply heightened skepticism. Star counts alone, without downstream adoption evidence, adoption by named major organizations, or citations in professional and academic literature, are unlikely to satisfy the criterion even if the numbers are large in absolute terms. The petition should treat star counts as an introductory signal that prompts the reader to look at the rest of the evidence, not as primary proof of major significance standing on its own.
Evidence that a project is widely forked without documented production use of those forks is similarly weak as a standalone showing. Forks of a repository include forks created to propose pull requests, forks created for educational exercises, forks created by developers who intended to build on the project but did not proceed, and forks created for archival purposes. A high fork count does not establish that the project has been adopted in significant production systems. The petition should distinguish between the total fork count and the subset that represents active downstream development, documented by the existence of derivative projects that have themselves been deployed at scale or adopted by recognized organizations.
Self-published blog posts by the petitioner, no matter how technically detailed, do not satisfy the published material criterion and do not provide independent expert recognition of the project's significance. A project's own documentation, the creator's personal blog posts about the project's architecture, and the project's README file are all documents controlled by the petitioner and reflect the petitioner's own assessment of the work's significance. The original contributions criterion requires evidence that the field — meaning independent actors including employers, researchers, and practitioners — has recognized and relied upon the contribution. First-person accounts of the project's significance, unsupported by third-party adoption evidence or independent expert declarations, are the weakest category of evidence for this criterion.
How to frame borderline open-source evidence
When the project has strong adoption metrics but limited documentation of named major adopters, the petition can argue the original contributions criterion under the comparable evidence doctrine. Under 8 C.F.R. § 214.2(o)(3)(iv)(C) for O-1A petitions, a petitioner may present comparable evidence when the standard criteria do not readily apply to the occupation, and the totality of that evidence demonstrates extraordinary achievement. For software practitioners whose work is primarily recognized through community adoption rather than formal awards or editorial publications, a strong package download record combined with testimonials from senior engineers at adopting organizations — even organizations that are not household names — can constitute comparable evidence of community recognition that reflects extraordinary achievement.
Expert declarations from technical professionals who can independently evaluate the project's significance carry substantial weight precisely because they supply the qualified practitioner judgment that the adjudicator cannot form independently. Appropriate declarants are software engineers or computer scientists with recognized standing — faculty at research universities, senior engineers or engineering directors at significant technology organizations, recognized contributors to related open-source projects with their own documented adoption records — who can explain the technical problem the project addresses, the state of prior solutions, and why the beneficiary's approach represents a contribution of major significance in the discipline. The declaration should analyze the project's position within the technical landscape, not simply praise it.
For projects incorporated into major open-source foundations or ecosystems — the Apache Software Foundation, the Linux Foundation, the Cloud Native Computing Foundation, the Python Software Foundation, or the OpenJS Foundation — the foundation membership or graduation status provides institutional recognition that the project has met independent governance and quality criteria. CNCF graduation requires a documented project health evaluation, sustained adoption by production users, and a security audit conducted by foundation-appointed reviewers. That institutional vetting process, conducted by foundation technical oversight committees composed of recognized engineers from major member organizations, represents a form of peer review analogous to the evaluative process that satisfies the judging criterion within the broader O-1A evidentiary framework.
Building and auditing your evidence file
The complete evidence file for an open-source developer's original contributions claim should contain: the repository page showing creation date, star count, fork count, and contributor count; package manager download statistics for the most recent twelve-month period; documentation of adoption by major organizations including dependency listings, engineering blog posts, conference acknowledgments, or CNCF Landscape entries; academic citations or download records for associated technical papers; and expert declarations from two to four qualified practitioners. The brief should open the original contributions section by explaining the technical problem the project addresses, then walk through each evidence category in decreasing order of institutional authority — named major adopters first, then community adoption metrics, then expert declarations — so that the strongest evidence establishes the framework within which the other evidence is read.
Before filing, audit the evidence file against the denial risk factors identified above. Specifically: does every major adoption claim have supporting documentation, or are any claims resting on the petitioner's own assertions without independent corroboration? Do the expert declarations specifically explain why the project is of major significance in the field — not simply that it is well-built or that the petitioner is skilled — or do they only generally commend the petitioner's technical abilities? Is the raw metrics data supplemented with field-specific context that makes the numbers legible to a non-technical adjudicator? An evidence file that answers each of these questions affirmatively is substantially more likely to survive first-level adjudication without an RFE.
For open-source developers whose most significant project is still developing its adoption record — technically strong with a growing user base but not yet at the threshold of documented major-company adoption — filing the O-1A petition may be premature. The petition should be filed when the evidence of major significance is robust rather than still developing. A denial based on insufficient original contributions evidence is significantly harder to address in a subsequent petition than a first filing with a complete record, because the subsequent petition must demonstrate both that the project has grown and that the earlier record was genuinely inadequate rather than merely thin. Timing the filing to coincide with a significant public adoption announcement, a major conference presentation, or a foundation graduation milestone is a practical and well-established strategy.
What we typically gather for this kind of case
| Document | Where to source | Why it matters |
|---|---|---|
| Peer-reviewed publications | Web of Science / Scopus exports | Anchors original-contributions and authorship criteria |
| Citation analysis | Google Scholar profile + ESI top-1% data | Quantifies major significance in the field |
| Salary benchmark | BLS OEWS for SOC code + locality | Documents high-salary criterion at 90th-percentile or above |
| Critical-role letters | Direct supervisor + program director | Establishes role's importance, not just title |
What we see go wrong, again and again
- 01Treating extraordinary ability as a credentials checklist rather than a story of field-wide impact.
- 02Submitting bibliometric data (h-index, citation counts) without explaining what makes those numbers high relative to peers in the same sub-field.
- 03Relying on letters from collaborators or co-authors rather than independent experts who can speak to influence.