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.

PESOSE is active for a 2026/2027 cycle and the full proposal deadlines include 1 September 2026 and 2 March 2027. The solicitation is identified as NSF 26-506, published February 19, 2026, and it explicitly replaced NSF 24-606.

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 has relatively strict submitter and PI eligibility logic. Use this as a pre-application checklist because mistakes here are fatal and often non-negotiable.

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.-based non-profit non-academic organizations linked to research or education.
• U.S.-based for-profit organizations, including small businesses, with relevant research or education capability.
• State and local governments, recognized tribes, and some federal agencies/FFRDCs within NSF rules.

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, PI/co-PI/ senior personnel generally need a tenured/tenure-track position, or a full-time paid research or teaching appointment, or an equivalent staff leadership role.
• International primary appointments at overseas branch campuses of U.S. institutions are not eligible in ordinary cases.
• For non-IHE proposers, PI must be an employee of the proposing organization and normally U.S.-based.

There are no stated proposal count limits per PI in the solicitation, but practical competitiveness still demands fit-specific targeting.

Important organizational eligibility nuance

For-profit and non-profit proposers must be U.S.-based and owned/controlled in line with NSF requirements. This matters for firms with complex ownership chains; if the ownership test is ambiguous, teams should resolve this before preparing final narrative content.

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

A realistic plan avoids underestimating document depth and coordination overhead.

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.

The 2026 deadline is explicit and near enough that a late registration to SAM.gov is a major delay. Build a hard internal deadline at least 10–14 days before NSF system close.

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 published full proposal deadlines are shared across the tracks for each cycle date in the solicitation extract, with no separate per-track publication line in this document.

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.