Evidence Building
How to Document Open-Source Software Library Authorship as Original O-1A Contributions
A widely used software library can satisfy the original contributions of major significance criterion—but only if the evidence shows field impact, not just authorship. Here is how to build a convincing evidentiary record from dependency data, expert letters, and academic citations.
The original contributions criterion and what it demands in software
The original contributions of major significance criterion under 8 C.F.R. § 214.2(o)(3)(ii) requires the petitioner to demonstrate not merely that they created something new, but that their creation has had major significance in their field. For researchers and engineers who have authored widely used open-source software libraries, this criterion can be the strongest in their O-1A petition—but only if the evidence is structured to show significance, not just authorship. The distinction matters because USCIS adjudicators assess contributions by their impact on the field, not by the ingenuity of the underlying work. A technically elegant library used by few practitioners carries less weight under this criterion than a simpler library adopted across an industry.
Open-source software authorship presents a documentation opportunity that many petitions underuse. The public repositories where such libraries live—GitHub, GitLab, PyPI, npm, CRAN, and similar platforms—generate objective, machine-readable records of adoption, dependency, and community engagement. These records can be marshaled to show that a library is not merely publicly available but is actively depended upon by a measurable portion of the practitioner community. The challenge is translating those metrics into terms that a non-technical USCIS adjudicator can understand and that the petition brief can connect to the regulatory standard of major significance.
The field in which the contribution is claimed matters enormously. A machine learning library used by tens of thousands of practitioners in AI research represents a different significance claim than a utility library for a narrow data format. The petition must locate the library within the practitioner landscape clearly enough that the adjudicator can assess whether its adoption is remarkable. This typically requires a brief technical explanation of what the library does, why the problem it solves was difficult or unsolved before its creation, and how the field's practice changed after its introduction. That contextual framing is the attorney's job, and it often distinguishes petitions that succeed on the original contributions criterion from those that fail.
What the regulation actually requires and how it applies to software
The regulatory text at 8 C.F.R. § 214.2(o)(3)(ii) specifies 'evidence of the alien's original scientific, scholarly, or business-related contributions of major significance in the field.' USCIS policy guidance, including the O-1 Policy Manual, notes that 'major significance' requires showing that the contributions have substantially impacted or influenced the field—not merely that they represent novel technical work. For open-source software libraries, this means the petition cannot simply establish that the library was published and is open-source. It must establish that the library has been adopted in ways that changed how practitioners in the field operate, what they can accomplish, or how they approach standard problems.
USCIS has approved O-1A petitions citing software libraries as original contributions, but the field of petition review is not uniform, and adjudicators vary in their familiarity with software development culture. Some adjudicators will not intuitively understand that a GitHub repository with 50,000 stars represents exceptional recognition in a software field—the petition must explain this explicitly. The brief should describe what the star count represents, how it compares to comparable libraries in the same category, and what it indicates about the breadth of the practitioner community that has found the library valuable enough to bookmark. Context that is obvious to a software engineer must be made explicit for a general adjudicator.
Dependency data is often more persuasive than star counts because it reflects active technical reliance rather than passive interest. When a downstream package lists a library as a dependency in its package manifest—whether through PyPI's dependency graph, npm's dependency tracking, or equivalent systems—it means that the downstream package cannot function without the library. A library on which tens of thousands of other packages depend is not merely popular; it is structurally embedded in the ecosystem. The npm or PyPI dependency pages generate this data automatically, and a screenshot or export of the dependency count at the time of petition preparation is concrete, verifiable evidence of the library's field significance.
Evidence that routinely satisfies the original contributions criterion for library authors
The most effective evidence packages for open-source library authorship combine download and dependency data with expert testimony that contextualizes those metrics within the field. Expert letters from credentialed practitioners—faculty members who teach with the library, engineers at prominent companies who have integrated it into production systems, researchers who have published work using it—are among the strongest evidence available. These letters should be specific about what the library does, why existing alternatives were inadequate, what the letter-writer's professional assessment of the library's importance is, and how they became aware of it. A letter from a professor at a research university who teaches the library in a graduate course carries different weight than a letter from a junior engineer who uses it occasionally.
Peer-reviewed publications that adopt or build upon the library are another category of strong evidence. When academic researchers publish work in conferences like NeurIPS, ICML, ICLR, ACL, or ACM and cite the library as a core component of their methodology, those citations establish that the library has penetrated into scholarly practice. Citation counts for the library itself—if it has been described in a published paper—can be obtained through Semantic Scholar, Google Scholar, or Scopus. A library that is both widely deployed in industry and cited in academic literature presents an unusually strong original contributions claim because it demonstrates impact across the full practitioner spectrum.
Press coverage and industry recognition can supplement the technical evidence. Articles in publications like IEEE Spectrum, ACM Communications, Wired, MIT Technology Review, or The Verge that discuss the library by name and describe its influence on the field contribute to the press criterion as well as contextualizing the significance of the contribution. Awards and recognition from technical foundations—Linux Foundation membership, Apache Software Foundation incubation, or similar institutional endorsements—signal that the relevant professional community has formally recognized the library's quality and importance. Inclusion in curated lists published by influential organizations, such as CNCF Graduated Projects or SciPy Ecosystem packages, also speaks to field adoption in a documented and verifiable way.
Evidence USCIS regularly discounts or finds insufficient
A common petition weakness is relying primarily on self-reported metrics and documentation generated by the petitioner. When the GitHub repository README, the library's documentation website, and the petitioner's own CV are the primary sources of evidence for the original contributions claim, adjudicators have few independent sources to evaluate. USCIS is not required to accept a petitioner's characterization of their own work as extraordinary, and petitions built around materials the petitioner controls are vulnerable to RFEs questioning the independence and objectivity of the evidence.
Download counts presented without comparative context are frequently discounted. An adjudicator seeing that a library was downloaded ten million times last year has no basis for assessing whether that figure is remarkable without knowing what comparable libraries in the same category show. Similarly, GitHub star counts presented without explanation of what they represent in the context of the field may be treated as vanity metrics by adjudicators unfamiliar with software culture. The petition brief must provide the comparison population and explain why the petitioner's library occupies a high position within it.
Expert letters that are generic in content—describing the field broadly, praising the petitioner's technical skill in general terms, and concluding that the petitioner is extraordinary—provide limited evidentiary value even when signed by prominent figures. An adjudicator who reads five such letters gains no new information from each additional one. The problem is not the number of letters but their lack of specificity. Letters that describe what the library does, what problem it solved, how the expert's own practice or institution uses it, and what the expert's independent assessment of its field impact is will carry far more weight than five letters praising the petitioner's general brilliance.
How to present borderline or mixed evidence for library contributions
Some petitions involve libraries that are genuinely significant within a narrow technical subfield but are not broadly known across the broader discipline. A library for parsing a specific file format used in geophysical data analysis may be indispensable within that subfield but have download counts that appear modest compared to general-purpose scientific computing libraries. In these cases, the petition must argue field-specific significance rather than absolute scale. The evidence should establish the size of the relevant practitioner community, the adoption rate within that community, and why adoption at that rate represents remarkable penetration given the community's size.
For library authors who are also academic researchers, it can be strategic to foreground peer-reviewed publications and grant records in the original contributions section and treat the open-source library as corroborating evidence of the contribution's significance—showing that the research has been implemented and adopted—rather than as the primary evidence. This framing works well when the petitioner has publications in top-tier venues and the library is a direct implementation of the research. It avoids the adjudicator's potential skepticism about software as scholarship and positions the contribution in terms the O-1A framework evaluates most clearly.
When the library was developed within a corporate context and the employer owns the intellectual property, the petition should clarify the petitioner's specific authorship contribution and, if possible, obtain a letter from the employer confirming the petitioner's central role. USCIS will not credit a contribution to the petitioner if the evidence suggests it was a team product to which the petitioner contributed incrementally. The brief should explain the petitioner's specific technical decisions, the portions of the codebase they authored, and any public records—commit histories, changelog entries, conference talks—that corroborate their authorship of the portions that drove the library's adoption.
Building and auditing the complete original contributions file
A well-constructed original contributions file for a library author typically contains five to seven exhibits: a download or dependency data export from the relevant package repository, a comparative analysis showing the library's ranking among comparable packages, two to four expert letters with specific field impact testimony, one to three peer-reviewed citations or conference references, and a petition brief section that synthesizes these exhibits into a clear argument under the regulatory standard. The brief should quote the regulatory text, state the standard, describe each exhibit, and explain how each contributes to meeting the standard. Do not assume the adjudicator will make the connection between a dependency graph and the concept of major significance—the brief must make that argument explicitly.
Before filing, audit the file against the most likely RFE scenarios: lack of independent expert testimony, insufficient comparative context for quantitative metrics, failure to explain technical concepts in lay terms, and reliance on evidence controlled by the petitioner. Each of these weaknesses appears in RFE issuances for O-1A petitions, and addressing them in the initial filing avoids the delay and additional cost of a formal response cycle. A petitioner who has authored a genuinely significant library should be able to assemble this evidence without inventing facts or overstating their role. If the honest evidence does not yet support a strong original contributions claim, it is better to wait and build additional adoption evidence than to file a petition that is likely to receive an RFE.
For petitioners who have authored multiple libraries over a career, the petition should identify the one or two most significant contributions and develop the evidence for those in depth, rather than presenting a broad catalog of projects with thin evidence for each. Depth of evidence on two significant libraries is more persuasive under the major significance standard than shallow coverage of ten. The petition brief should explain the relationship between the libraries if they are connected—for instance, if successive libraries built on earlier work and collectively transformed a subfield—because this narrative of sustained original contribution can satisfy the criterion more convincingly than a single-project argument.
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.
See if you qualify
Lando reviews your background against the O-1 visa criteria and tells you honestly where you stand. Free, no commitment.