NSF Renamed Its Open-Source Program and Added One Word. PESOSE's First $40 Million Deadline Is September 1.

The National Science Foundation's Pathways to Enable Open-Source Ecosystems program — POSE — has been running since 2022, funding the unglamorous work of turning research code into things other people can actually depend on. As of the FY2026 cycle it has a successor solicitation, NSF 26-506, and a new name: Pathways to Enable Secure Open-Source Ecosystems, or PESOSE.

One word. Up to $40 million. 40 to 60 awards anticipated. And a first deadline of September 1, 2026 — which, if you are reading this the week it published, is under two weeks away.

The word is "Secure," and it bought a whole new track.

What the three tracks fund

Track 1 — Scoping and Planning. Up to $300,000 for up to one year. Roughly 30 awards anticipated. This funds the work before the ecosystem exists: community discovery, governance design, licensing decisions, figuring out whether there is a community around your research product at all.

Track 2 — Establishing and Expanding. Up to $1.5 million for up to two years. Roughly 10 awards. This is the build track — standing up a sustainable open-source ecosystem around a product that already meets an emergent societal or national need, with real governance and an active contributor base.

Track 3 — Improving Safety, Security, and Privacy. Up to $1.5 million for up to two years. Roughly 10 awards. This is the new one. It funds remediation of technical and socio-technical vulnerabilities in an ecosystem that already exists — hardening infrastructure rather than creating it.

Note the award-count distribution: roughly half the awards are Track 1 at $300,000, and the two $1.5 million tracks split about 20 slots between them. If you are calibrating expectations, the modal PESOSE award is a one-year planning grant, not a build grant.

Track 3 is the strategically interesting addition. NSF has spent four years funding people to create open-source ecosystems; the security track is an acknowledgment that the resulting infrastructure is now load-bearing enough to be a liability. Erwin Gianchandani, NSF's assistant director for Technology, Innovation and Partnerships, framed the June 9 announcement in translational terms — enabling "another translational pathway for the outputs of basic science" — but a dedicated vulnerability-remediation track is a maintenance line item, and federal science agencies rarely create those before something has become critical.

The eligibility rule that disqualifies more people than you expect

Eligible organizations are broad: U.S. institutions of higher education, nonprofit research organizations, U.S.-based and U.S.-owned or controlled for-profit companies, state and local governments, Tribal Nations, federal agencies and FFRDCs.

The PI requirement is where it narrows. At an institution of higher education, the PI must hold a tenure-track position, a primary full-time research or teaching appointment, or a staff leadership role in an Open-Source Program Office.

That third clause is deliberate and underused. Many of the people who actually run university open-source ecosystems are staff — research software engineers, OSPO directors, infrastructure leads — who are structurally ineligible to PI most NSF solicitations. PESOSE names them explicitly. If your institution has an OSPO and its director has been the de facto steward of a project for years, they can lead this proposal. If your institution does not have an OSPO, the staff engineer who knows the codebase best probably cannot PI, and you will need a faculty PI who can credibly speak to the ecosystem.

Sort that out before you write anything, because it determines whose name goes on the project.

Requirements that fail proposals on submission

Several PESOSE requirements are mechanical, non-negotiable, and easy to miss under a two-week clock:

The title format. Project titles must begin with "PESOSE: [Track number]:". Compliance-checked, not judgment-based.

Page limits. 7 pages for Track 1, 15 pages for Tracks 2 and 3. The Track 1 limit is genuinely tight for a project that needs to describe an existing product, a target community, and a year of discovery work.

A pointer to an existing open-source product. Every track requires it, including Track 1. PESOSE does not fund the creation of a new open-source product from scratch — it funds building an ecosystem around one that exists. If your software is a private repository with three internal users, you are not yet a PESOSE applicant.

Three to five letters of collaboration from current users or contributors. This is the requirement most likely to break a rushed submission. These letters must come from people already using or contributing to the product — not aspirational future partners, not co-authors. Collecting five of them from external contributors takes longer than writing the proposal. Start today.

Two to five keywords in the Project Summary, and a full list of personnel and partner organizations.

No cost sharing is required or permitted. All direct and indirect costs must fit inside the stated ceilings — the $300,000 and $1.5 million figures are total award, not direct cost. For an institution with a 55 percent negotiated rate, a $300,000 Track 1 ceiling is roughly $193,000 of actual project spend. Build the budget backwards from the ceiling.

The I-Corps commitment is a real obligation

All Track 1 and Track 2 awardees must participate in mandatory "I-Corps for PESOSE" experiential activities covering ecosystem discovery, governance, and sustainability practice. Track 2 awardees who already completed it as Track 1 recipients may request a waiver.

Treat this as a genuine cost, not a checkbox. I-Corps-style programs demand substantial time from named team members over a compressed period — customer-discovery interviews, cohort sessions, deliverables. On a one-year, $300,000 Track 1 award, that participation is a meaningful fraction of the project. Name who will do it in the proposal, and budget their time honestly. A team that treats I-Corps as an afterthought will spend Q2 of the award scrambling.

It also tells you what NSF is optimizing for. The through-line from POSE to PESOSE is that NSF does not believe good software becomes an ecosystem on technical merit. It believes ecosystems are built through community discovery, governance, and sustainability planning — and it is willing to make the training compulsory to prove the point.

Missed September 1? The next one is March 2

PESOSE deadlines recur on the first Tuesday in March and September, annually. The next after September 1, 2026 is March 2, 2027.

Given the two-week runway, here is the honest triage:

Go for September 1 if you already have an open-source product with external users, you can name three to five contributors who will write letters this week, and you have a PI whose eligibility is unambiguous. A Track 1 at 7 pages is writable in two weeks by a team that already knows its community.

Wait for March 2 if any of those are missing — especially the letters. A weak collaboration package signals exactly the thing PESOSE screens for: that no ecosystem exists yet. Six months is enough time to build genuine external adoption, recruit contributors, and come back with letters that are evidence rather than favors.

The strategic read for research-software teams: the security track is new, has roughly 10 slots, and competes against a smaller and less-prepared applicant pool than the build track, because most groups pitching open-source work instinctively frame it as growth rather than hardening. If your ecosystem is mature and has known technical debt in its security posture — supply chain, dependency provenance, privacy handling — Track 3 may be a materially better-odds framing of the same project than Track 2.

That is not a trick. It is what NSF said it wanted when it added the word.