NSF 26-506: Pathways to Enable Secure Open-Source Ecosystems (PESOSE)

NSF 26-506: Pathways to Enable Secure Open-Source Ecosystems (PESOSE)

This opportunity is a major U.S. NSF program for teams building or improving open-source ecosystems (OSEs) around research-derived tools, models, data platforms, hardware designs, or similar assets. It is especially relevant if your project depends on broad community participation, needs stronger governance and security planning, and needs a credible path to sustainable adoption.

NSF currently lists this as an active funding opportunity. The 1 September 2026 deadline has passed; the next full-proposal deadline is 2 March 2027, due by 5 p.m. in the submitting organization’s local time. The NSF program page also lists 7 September 2027 and says that a September deadline recurs on the first Tuesday annually. The current solicitation is NSF 26-506, posted February 19, 2026, and replaces NSF 24-606. Check the official pages before submission in case NSF posts a revision.

Key details at a glance

1) What this opportunity is for in practical terms

PESOSE is not a broad science call where any technical research concept can fit; it is a targeted mechanism for strengthening open-source ecosystems. A recurring failure is treating the opportunity as a standard software development grant without understanding that NSF is funding ecosystem capacity, not a one-off prototype.

The program has three core tracks:

• Track 1: Scoping and planning for an OSE. This is where teams focus on governance, licensing, community planning, and sustainability foundations.
• Track 2: Establishing and expanding a promising OSE. This is growth mode: community building, developer operations, maintenance, secure development, and evidence of long-term viability.
• Track 3: Improving safety, security, and privacy of an existing OSE. This is for teams with an identifiable, real vulnerability profile and a concrete remediation roadmap.

A strong way to think about eligibility is this: if your work is a one-off code artifact, this may not fit; if your work is a reusable ecosystem with distributed contributors, user retention, release management, and long-term stewardship, it likely fits.

This matters because NSF’s language on “sustainable OSE” is operational, not rhetorical. The solicitation asks for explicit governance and continuity planning, which means reviewers and NSF program officers want to see adoption and maintenance pathways, not just novel outputs.

2) Why this matters in 2026/2027 and where your proposal can stand out

The NSF framing links open-source systems directly to national competitiveness, workforce, and security goals. The solicitation notes that open-source ecosystems are now embedded in sectors including AI, cloud computing, healthcare, research infrastructure, and national security. That means this opportunity is relevant for teams that can describe external impact in a non-academic context.

Where applicants stand out is usually by showing a credible societal or national relevance claim with measurable outcomes. For example:

• Better governance allows faster and safer deployment by non-academic users.
• Security work lowers dependence on a single maintainer and reduces hidden risk.
• A stronger community model raises contributor quality and lifecycle depth.

Your proposal should not only explain what you will build, but why your ecosystem is the right abstraction for diffusion. A successful narrative typically maps:

1. technical artifact → 2) operational model → 3) community model → 4) sustainability model.

If your structure skips step 3 (community) or 4 (sustainability), reviewers often see short shelf-life potential.

3) Eligibility gates you must clear before writing the full narrative

The call restricts both the proposing organization and who may serve as PI or Senior/Key Personnel. Treat the categories below as a screening guide, then check the full solicitation and NSF PAPPG before committing proposal effort.

Eligible proposer types

The solicitation explicitly allows proposals from:

• U.S. institutions of higher education (accredited two- or four-year campuses, including community colleges) acting on behalf of faculty.
• U.S.-located independent museums, observatories, research laboratories, professional societies, and similar non-profit non-academic organizations directly associated with education or research.
• U.S.-based commercial organizations, including small businesses, with strong scientific or engineering research or education capabilities.
• State and local governments; federally recognized Tribal Nations; and other federal agencies or FFRDCs subject to PAPPG Chapter I.E.2 eligibility limits.

PI eligibility and participation limits

PI eligibility is not only “can submit” language. It also ties PI role and employment status to location and authority.

• For IHE settings, each PI, co-PI, and other Senior/Key Personnel must, by the deadline, hold a tenured or tenure-track role, a primary full-time paid research or teaching appointment, or a staff leadership role in an Open-Source Program Office or equivalent at a U.S.-based campus. The solicitation allows the submitting institution to determine exceptions for family or medical leave.
• People whose primary appointments are at overseas branch campuses of U.S. IHEs are ineligible. If project funding would go to an international branch campus, including through subawards or consulting, the proposal must explain the benefit and why the work cannot be done at the U.S. campus.
• For other eligible proposers, the PI must be the organization’s employee, normally reside in the United States, and act as its employee while performing PI duties; temporary time outside the country is allowed. People primarily appointed at non-U.S. nonprofits or for-profit organizations are ineligible. Foreign academic researchers may contribute as Senior/Key Personnel or collaborators but cannot receive NSF support under this solicitation.

The solicitation states there are no limits on the number of proposals per organization or per PI/co-PI. That removes a numerical cap, but teams still need to demonstrate a convincing fit with one track and the program’s ecosystem goals.

Important organizational eligibility nuance

Nonprofit and for-profit proposing organizations must be based in the United States and meet NSF’s U.S.-ownership and control test. In general, more than half of equity must be directly owned and controlled by U.S. citizens or permanent residents, qualifying U.S. firms, or a combination; actual control must remain with that eligible ownership majority. The solicitation defines how to assess layered firm ownership and fully diluted equity. Firms with complex ownership should document the structure early and check the full rule rather than relying on a simple U.S. incorporation test.

Because this requirement is often a silent blocker, include a legal or admin owner-control confirmation step in your timeline.

4) Track selection: where your idea should go

Applicants fail when they choose a track by guesswork and then write the wrong evidence set. Use the track goals as your template.

Track 1: Scoping and planning

Use Track 1 if your ecosystem is promising but not yet at a stable growth phase. NSF describes this as planning-oriented: governance, dissemination, contributor acquisition strategy, security baseline, and long-term vision. Track 1 is a pre-growth track with smaller award caps.

Track 2: Establishing and expanding

Use this when an ecosystem already has traction and you need to expand it into a robust national-use model. NSF language expects:

• community and partner strategy,
• sustained licensing and governance,
• continuous secure development,
• active adoption and onboarding plans.

This track requires a strong operational plan, often heavier than Track 1.

Track 3: Improving safety, security, and privacy

Use Track 3 if the key problem is hardening and resilience. Review language emphasizes:

• vulnerability assessment,
• mitigation plan,
• build/test infrastructure,
• milestone-driven risk reduction,
• measurable security impact.

This is usually suitable when there is a defensible target ecosystem with concrete historical risk exposure and a clear technical roadmap.

5) Submission requirements that can disqualify you if missed

The PESOSE solicitation includes concrete formatting and document rules.

Non-negotiable form requirements

• Proposal title must begin exactly with PESOSE: , then Track X:, then your title.
• The last line of the Project Summary must contain 2–5 keywords prefaced by Keywords:.
• Proposal page limits:
  • Track 1: 7 pages max
  • Tracks 2/3: 15 pages max
• All proposals must include:
  • a pointer to the existing open-source product being translated into an OSE,
  • status of development and user/community profile,
  • problem definition,
  • team capability statement.

Mandatory supporting materials

The solicitation requires:

• Letters of collaboration: 3 to 5 letters from current users/contributors (outside proposers’ own team), describing active involvement and continued contribution potential.
• Project personnel and collaborators table: includes every PI/Key Personnel, consultant, collaborator, subawardee, and advisory participant.

Systems and registration mechanics

You can submit via Research.gov or Grants.gov for the full proposal. Collaborative proposals submitted as separate submissions from multiple organizations must go through Research.gov. Institutions need an active UEI in SAM.gov, and registration can take time, so this is a pre-submission risk item.

Although this call is not a letter-and-preliminary cycle like some NSF programs, all compliance and template details in the solicitation are binding.

6) Timeline strategy for a real winning workflow

NSF publishes recurring full-proposal dates for the program. The current solicitation lists 2 March 2027 and the first Tuesday in March annually thereafter; the NSF program page additionally lists 7 September 2027 and the first Tuesday in September annually thereafter. Both dates are due by 5 p.m. in the submitting organization’s local time. The earlier 1 September 2026 deadline is closed. Check the program page and solicitation again before planning a submission, because posted updates and the PAPPG version in force on the due date govern.

90-day preparation plan (recommended)

1. Weeks 1–2: Compliance screening
   • Verify proposer and PI eligibility.
   • Confirm UEI status via SAM.gov.
   • Verify ownership/control language for for-profit entities.
2. Weeks 3–4: Track selection and proof mapping
   • Finalize whether the proposal is Track 1, 2, or 3.
   • Map each required review criterion to evidence.
3. Weeks 5–6: Ecosystem evidence pass
   • Compile contributor/user metrics, existing release practices, security incident records if applicable.
4. Weeks 7–8: Draft core proposal sections
   • Title/keywords compliance,
   • project description scoped to track criteria,
   • budget plan aligned to allowed cap.
5. Weeks 9–10: Collaboration letters and partner records
   • Gather 3–5 letters early and cleanly.
   • Build complete collaborator table.
6. Weeks 11–12: Pre-submission technical review
   • Check page limits,
   • enforce language and formatting constraints,
   • verify submission form fields in chosen portal.

For any selected cycle, work backward from the applicable due date and set an internal handoff deadline well before the portal closes. SAM.gov registration can take several weeks, and an active UEI is required. Confirm Research.gov or Grants.gov access, the institution’s authorized-official workflow, and the correct PAPPG edition early; separate collaborative submissions by multiple organizations must use Research.gov.

7) Budget realism and what to include in the budget rationale

The track-based financial caps are explicit:

• Track 1: up to 300,000 USD (up to 1 year)
• Track 2: up to 1,500,000 USD (up to 2 years)
• Track 3: up to 1,500,000 USD (up to 2 years)

Reviewers read budgets operationally. A strong budget rationale should connect requested resources to community impact and resilience outcomes, such as:

• infrastructure for secure release and quality control,
• governance operations,
• contributor onboarding,
• evaluation and impact measurement,
• any required experiential activities.

A hard rule: voluntary committed cost sharing is prohibited, so budget requests should stand on their own. Do not overstate non-NSF match unless justified as part of normal operations.

8) Evaluation criteria and how reviewers usually score proposals

PESOSE uses NSF’s standard Intellectual Merit and Broader Impacts framework plus track-specific criteria.

What reviewers test for in Track 1

1. Convincing evidence that the target issue is nationally significant and currently under-served.
2. Clear long-term vision.
3. Contributor recruitment and growth strategy.
4. Concrete milestones and an evaluation plan.

What reviewers test for in Track 2

1. Societal/national significance.
2. Long-term vision and sustainability.
3. Governance, contributor retention, and organizational structure.
4. Security-aware development and release process.
5. Clear licensing strategy.
6. Milestones and metrics.

What reviewers test for in Track 3

1. Significance of the vulnerabilities or privacy risks.
2. Technical clarity of threat model.
3. Practical security intervention plan.
4. Test/infrastructure quality.
5. Milestones and measurable outcomes.

Across all tracks, the strongest proposals explicitly show:

• why this OSE is not just useful, but essential,
• who adopts it and how success is measured,
• and how the project survives after NSF support.

9) Common mistakes and practical fixes

Mistake 1: Missing title/summary format rules

If the proposal title and project-summary keywords are not correctly formatted, that creates avoidable administrative burden. Fix with a strict pre-submission checklist.

Mistake 2: Treating it as a product grant only

This program is not just code funding; it is ecosystem funding. You need governance, community, and sustainability built into your design.

Mistake 3: Weak collaborator letters

Letters of collaboration must come from actual users/contributors external to your internal core. Weakly sourced letters or non-committed letters reduce reviewer confidence.

Mistake 4: Ignoring legal/ownership eligibility for firms

For-profit proposers in particular need ownership/control logic ready before proposal writing. If unresolved, do not assume NSF will resolve during review.

Mistake 5: Underspecified security plan

For Track 2 and 3, reviewers expect explicit quality assurance, threat posture, and measurable security tasks. Generic statements without operational steps are insufficient.

10) Practical fit checklist before you submit

• Confirm proposer category and PI eligibility.
• Choose the correct track and align every section to track criteria.
• Build a clean governance + lifecycle plan (community, licensing, security, sustainability).
• Prepare 3–5 valid collaboration letters from independent users/contributors.
• Ensure complete personnel/collaborator table.
• Register and test submission channel early (Research.gov/Grants.gov + SAM.gov UEI).
• Include a realistic, track-appropriate budget narrative and no voluntary cost share.
• Confirm I-Corps for PESOSE requirements for your selected track.
• Run an internal “format + compliance” pass before final submission.

11) Frequently asked questions

Is this only for software projects?

The solicitation focuses on open-source products, but these can include software, hardware, models, standards, and data platforms. The common requirement is the ecosystem concept, not only a code repository.

Can teams include non-U.S. experts?

Non-U.S. experts can contribute in supporting roles, but core PI eligibility and NSF funding requirements are constrained by organizational and legal rules. The solicitation also draws clear lines around legal work-rights and organizational control.

Are there separate deadlines for each track?

The solicitation lists full-proposal deadlines for the program rather than separate dates for each track. The currently listed next deadline is 2 March 2027; the NSF program page also lists 7 September 2027. Both are due by 5 p.m. in the submitting organization’s local time, and all tracks should confirm the latest posted schedule before submission.

Is multi-organization collaboration allowed?

Yes, collaborative submissions are allowed as multi-organizational proposals, but one organization must be the lead, and some ineligible organizations cannot receive subawards.

What is the most common disqualification cause?

Administrative non-compliance (title formatting, collaborator evidence, PI/organization eligibility mismatch, missing required letters, or incomplete portal registration) is common and avoidable.

12) Official links and where to confirm updates

• Program page and submission context: https://www.nsf.gov/funding/opportunities/pesose-pathways-enable-secure-open-source-ecosystems
• Active solicitation text: https://www.nsf.gov/funding/opportunities/pesose-pathways-enable-secure-open-source-ecosystems/nsf26-506/solicitation
• NSF proposal rules reference: PAPPG page on NSF.gov
• Program contact listed in the solicitation: [email protected]

The solicitation page itself is the source of record for authoritative requirements. For high-stakes applications, capture the version you draft against and avoid relying on screenshots, third-party summaries, or stale copies.