NASA ROSES Research Grants and Ongoing Programs: How to Get Funded to Study Earth and Space With NASA Data
If you’ve ever looked at a NASA dataset and thought, I could do something real with this—you’re exactly the kind of person NASA’s Research Opportunities in Space and Earth Science (ROSES) ecosystem is built for.
If you’ve ever looked at a NASA dataset and thought, I could do something real with this—you’re exactly the kind of person NASA’s Research Opportunities in Space and Earth Science (ROSES) ecosystem is built for.
ROSES isn’t one tidy grant with one tidy deadline. It’s more like a sprawling research bazaar that NASA’s Science Mission Directorate (SMD) runs every year: dozens of topic-specific calls, each with its own rules, its own due date, and its own personality. Some are classic annual deadlines. Others are “no due date” programs where you can submit any time (yes, really). The result is a year-round pipeline of opportunities for scientists, engineers, educators, and data wizards who can turn NASA’s missions and archives into new knowledge.
And the timing couldn’t be better. NASA’s science archives are already enormous—over 100 petabytes of observational and model data stored today—and NASA expects the pace to accelerate dramatically in the next few years, with projections that the divisions could generate 100+ petabytes per year as new missions come online. That’s not a “nice-to-have” problem. That’s a “we need more brains” problem. ROSES is one of the main ways NASA pays people to bring those brains.
One more thing before we get practical: this is a tough arena. NASA peer review is serious, competitive, and often humbling. But it’s also wonderfully legible—if you respect the instructions, talk to the right program officer early, and write like a scientist who understands reviewers are busy humans, you can absolutely put yourself in the winning column.
Below is your field guide: what ROSES is, who it fits, what reviewers look for, and how to plan a sane application process even when the program has “ongoing” or shifting dates.
At a Glance: NASA ROSES and NASA Science Researcher Funding
| Key Fact | Details |
|---|---|
| Funding type | Grants / cooperative agreements through NASA SMD research solicitations (ROSES and related programs) |
| Primary focus | Space and Earth science research, analysis, and technology development using NASA missions/data |
| Opportunity structure | Omnibus solicitation made up of many program elements (topic calls), each with its own due date |
| Deadline | Ongoing overall; specific ROSES program elements have specific deadlines, and some are No Due Date |
| Who can apply | Typically U.S.-based institutions and organizations (universities, nonprofits, companies, NASA centers, government labs); specific eligibility varies by program element |
| Review style | Peer review; includes Dual-Anonymous Peer Review in some areas/program elements |
| Where proposals go | Usually through NASA’s proposal systems (e.g., NSPIRES via linked program elements) |
| Help contacts | Program officers (topic-specific) and SMD research contacts; general continuity email listed as [email protected] |
| Best starting point | NASA “For Researchers” hub and the current ROSES table of program elements |
| Official opportunity page | https://science.nasa.gov/researchers/ |
What This Opportunity Offers (Beyond Just a Check)
ROSES and the broader NASA “For Researchers” ecosystem offer something rarer than money: a structured way to plug into the world’s most recognizable science brand while doing work that can be intensely fundamental (dark matter! exoplanets!) or deeply applied (Earth observations! microgravity biology!).
First, there’s the obvious: research funding for projects that use NASA science data, support mission science, improve models, develop methods, or tackle unanswered questions across NASA’s science divisions (think Earth Science, Planetary Science, Heliophysics, Astrophysics, and Biological & Physical Sciences depending on the year and call). ROSES is the umbrella; under it sit the actual program elements you propose to.
Second, there’s the infrastructure. NASA’s science archives aren’t just big—they’re operationally serious. When you work in this ecosystem, you’re often working with standardized archives, established provenance expectations (basically: “show your work” for data lineage), and communities that care about reproducibility. If your research life involves wrangling messy data in lonely corners of the internet, NASA’s model can feel like switching from backroads to highways.
Third, you get process transparency and community resources. NASA publishes FAQs, statistics, policies, proposal-writing resources, and updates through amendments. That sounds dull until you realize it’s a competitive advantage: people who read the updates and follow instructions tend to do better.
Finally, ROSES is not only for the stereotypical “professor with a lab.” NASA SMD research spans universities, nonprofits, companies, government labs, and NASA centers. If you’re at a smaller institution, early-career, or crossing disciplines, you’re not automatically out. But you do need to choose the right program element and build a credible plan.
Who Should Apply (With Real-World Examples)
You should apply if your work can answer a meaningful science question using NASA-relevant data, models, missions, or measurement needs—and you can explain that clearly to reviewers who may like your topic but won’t read your mind.
A classic ROSES applicant is a university researcher proposing a focused investigation: for example, using archived telescope observations to test a hypothesis about galaxy evolution, or combining multiple Earth-observing datasets to improve drought monitoring. But ROSES has room for more variety than people assume.
If you’re a data scientist who normally lives in machine learning conferences, you might be a fit if you can do three things: (1) anchor your method in an actual NASA science question, (2) show you understand the data’s quirks (calibration, biases, missingness, resolution limits), and (3) promise outputs the science community can actually use. A proposal that reads like “we will apply Model X to Dataset Y” tends to get smacked down unless it’s tied to real scientific stakes.
If you’re at a nonprofit or institute doing applied work, you may find program elements that care about decision support, data usability, or analysis tools—especially if your team can demonstrate that the outputs won’t vanish into a PDF at the end of the grant.
If you’re in industry, you might be eligible for some elements as a for-profit corporation, but you must pay close attention to the specific call rules. The NASA world is friendly to innovation, but it’s allergic to fuzzy scopes and salesy language. Write like a scientist with a deliverables plan, not like a product page.
Early-career researchers should not self-reject. NASA even encourages early-career folks to get involved as peer reviewers in some contexts, which is one of the fastest ways to learn what “good” looks like. The trick is positioning: pick a question narrow enough to finish, build a realistic team, and show you know the literature and the data.
Understanding ROSES Without Getting Lost in the Acronym Soup
ROSES is the omnibus solicitation. Under ROSES live many “program elements” (topic calls). Each element has its own due date(s), rules, page limits, and expected deliverables.
Two details matter more than almost anything:
- You are not applying to ROSES in general. You are applying to a specific program element under ROSES. Treat that element like its own grant competition with its own culture.
- Amendments happen. Due dates can shift, requirements can change, and clarifications appear. NASA is good about posting updates—but you have to keep an eye on them.
NASA also runs resources that support proposers: FAQs, “how to” guides, new PI resources, program officer lists, and information about peer review approaches like Dual-Anonymous Peer Review (where applicable). Think of these as the guardrails that keep you from driving into a ditch.
Insider Tips for a Winning NASA ROSES Application (The Stuff Reviewers Secretly Beg For)
A NASA proposal doesn’t win because it’s exciting. It wins because it’s exciting and believable, with every major risk acknowledged and handled.
Here are seven tactics that consistently move proposals from “interesting” to “fundable”:
1) Talk to the program officer early—and bring a one-page concept
Program officers aren’t gatekeepers in the villain sense. They’re translators between your idea and the call’s intent. Send a short summary: your question, dataset(s), method, and why the program element is the right home. Ask, plainly, “Is this responsive?” That one email can save you two months of writing the wrong proposal.
2) Make the science question the headline, not the dataset
NASA has mountains of data. Reviewers are not impressed that you found a dataset. They want to know what you’ll prove, measure, test, or constrain. A strong proposal reads like: “We will quantify X to distinguish between Y and Z hypotheses,” not “We will analyze JWST/Hubble/whatever data.”
3) Build a scope that fits the budget and the calendar
Over-scoping is the #1 self-own. If your workplan includes five major analyses, three software packages, and a new model assimilation system—on a two-year budget—you’ve written science fiction. Pick the highest-value deliverable, then add only what supports it.
4) Treat “risk” like an adult topic, not a superstition
Reviewers don’t punish risk; they punish pretending risk doesn’t exist. If your method depends on a particular data release, instrument calibration, or algorithm performance, say so and provide a backup plan. The backup plan is not “we will try harder.” It’s a concrete alternative dataset, approach, or smaller but still publishable objective.
5) Show your data management and computing plan is real
NASA cares about data stewardship for good reason: petabytes don’t manage themselves. Even if the program element doesn’t demand a full novel of a plan, demonstrate that you know where the data lives, how you’ll access it, what compute you need, and how you’ll document provenance (the chain of custody for data and processing steps). A short, competent paragraph here can calm reviewer nerves.
6) Write for the reviewer who is smart, tired, and reading at night
Use signposting. Put mini-summaries at the ends of sections. Define acronyms once. Use figures if allowed and meaningful. Make it easy to find: objectives, methods, milestones, and expected outcomes. Reviewers shouldn’t have to hunt for what you’re actually doing.
7) If dual-anonymous review applies, follow it like it’s a law of physics
Where Dual-Anonymous Peer Review is in play, sloppiness can cost you. Don’t self-identify. Don’t “as we showed in our 2023 paper…” in a way that screams your name. There are acceptable ways to cite and describe prior work while staying compliant, but you must learn the rules early and build your draft around them—not patch it the night before.
Application Timeline (Working Backward From a Moving Target)
Because ROSES includes many calls—some with fixed deadlines, some with ongoing submission—your timeline should be built around the specific program element you choose. Still, most competitive proposals follow a similar rhythm.
If your program element has a known due date, start 10–12 weeks out. That’s not perfectionism; that’s reality when you factor in institutional approvals, budgets, letters, and compliance.
- 12 weeks before deadline: Confirm the right program element, email the program officer, and sketch a one-page concept. Decide whether your proposal needs partners, subawards, or specialized resources (compute, lab work, field validation).
- 10 weeks before: Lock your science objectives and success metrics. Start your outline, then write the workplan like a project manager: tasks, owners, milestones, and outputs.
- 8 weeks before: Draft the technical narrative. Start budget planning in parallel—waiting until the end is how you end up with a gorgeous idea and an impossible budget.
- 6 weeks before: Internal review by someone outside your project. If they can’t summarize your goals in two sentences after reading, your proposal is still foggy.
- 4 weeks before: Revise for clarity and compliance. Gather required documents. Confirm your submission system account and institutional routing process.
- 2 weeks before: Final budget justification, biosketches, current & pending support (if required), and document formatting. Run a compliance checklist against the program element instructions.
- Final week: Submit early if you can. NASA systems do not care that your PDF failed to compile at 4:58 p.m.
If you’re targeting a No Due Date program element, treat it like you’re creating your own deadline. Pick one, announce it to your team, and follow the same backward planning. “Ongoing” is wonderful—until it becomes “someday,” which is where proposals go to die.
Required Materials (And How to Prepare Without Panic)
The exact package varies by program element, but most NASA research proposals require a familiar set of components. Prepare them like you’re building a kit you’ll reuse.
Expect to assemble items such as:
- A project narrative/technical proposal that clearly states objectives, background, approach, and expected results.
- A workplan with tasks, timeline, and milestones (even when not explicitly required, it strengthens credibility).
- A budget and budget justification that match the workplan line by line (people notice when they don’t).
- Key personnel documents (often biosketches/CVs) and role descriptions that prove the team can do the work.
- Any required current and pending support disclosures or related forms, depending on the call.
- If relevant, a data management approach describing how you’ll access, document, and share outputs consistent with NASA expectations.
Preparation advice that saves grief: write your workplan first, then build the budget from it, then revise the narrative to match. When those three pieces agree, reviewers relax. When they conflict, reviewers assume you don’t actually know what you’re doing yet.
What Makes an Application Stand Out (How NASA Peer Review Thinks)
NASA peer review is not a vibe check. It’s a structured assessment against criteria that typically revolve around scientific merit, feasibility, and relevance to the call.
A standout proposal usually has:
Crystal-clear responsiveness. Reviewers should be able to point to the program element text and say, “Yes, this fits.” If they have to argue with themselves about fit, you’ve already lost points.
A hypothesis-driven or question-driven core. Even applied proposals benefit from a strong framing: what will be learned, improved, or validated, and what will the community be able to do afterward?
Methodological credibility. You don’t need to promise miracles; you need to show that your approach is appropriate and that the team has done related work before. If you’re crossing into a new area, partner with someone who has scars from that battlefield.
A realistic management plan. NASA reviewers have seen ambitious plans implode. A proposal that admits constraints and still delivers high-value outputs often beats the overly grand one.
Thoughtful outputs. Publications matter, but so do well-documented code, curated derived datasets, validation reports, or tools the community can actually run. When you describe outputs, describe who will use them and how.
Common Mistakes to Avoid (And How to Fix Them)
1) Applying to the wrong program element
Fix: Before you write page two, confirm fit with the program officer and compare your objectives to the call text. If your idea is adjacent but not aligned, find a better home.
2) Writing a methods showcase instead of a science proposal
Fix: Lead with the question and why it matters. Methods support the question; they are not the star of the show.
3) A budget that looks like it was guessed in a hurry
Fix: Tie dollars to tasks. If you need a graduate student for 12 months, show what they’ll do. If you need compute or travel, justify it with project needs.
4) Ignoring data provenance and reproducibility
Fix: Briefly describe your processing pipeline, documentation approach, and where outputs will live. You don’t need to write a manifesto—just demonstrate competence and intent.
5) Waiting too long to learn the submission system
Fix: Create accounts, test logins, and confirm institutional routing early. The last week is for polishing, not for discovering you can’t access the portal.
6) Treating amendments like optional reading
Fix: Subscribe to updates where possible and check the relevant ROSES blog/updates during your writing period. A small change can affect formatting, due dates, or requirements.
Frequently Asked Questions (Because Everyone Wonders the Same Things)
1) Is ROSES one grant or many?
Many. ROSES is the umbrella solicitation. You apply to a specific program element inside it, and each element can feel like a different competition.
2) The listing says ongoing. Does that mean I can submit anytime?
Not always. “Ongoing” here reflects the broader NASA researcher funding hub and the existence of no-due-date programs. Most ROSES elements still have due dates. Confirm the deadline for your specific element.
3) Do I need to work at NASA to apply?
No. NASA funds research across universities, nonprofits, other government labs, NASA centers, and sometimes for-profit companies—depending on the program element’s eligibility rules.
4) What is Dual-Anonymous Peer Review, and should I worry about it?
It’s a review approach where identifying information is minimized so reviewers focus on the work, not the names. If your program element uses it, you must follow the rules carefully in how you reference prior work and present the team.
5) How competitive is it?
Competitive enough that you should assume serious peer scrutiny. The best defense is a proposal that is responsive, clear, feasible, and tightly aligned with the call.
6) Should I volunteer to be a peer reviewer if I am early-career?
If you’re eligible, it can be incredibly educational. Seeing how reviewers discuss proposals teaches you more than a dozen generic webinars. Just be mindful of time and conflicts of interest.
7) Who do I contact when I have questions?
Start with the program officer for the program element you’re targeting. For general page questions or corrections, the NASA SMD research contact email listed is [email protected].
8) Where do I find the current list of ROSES opportunities?
NASA maintains a current ROSES table of program elements (often linking out to proposal pages). Start from the main researchers hub and follow links to the current ROSES year and program element listings.
How to Apply (Next Steps You Can Do This Week)
First, choose your target like a strategist. Go to the NASA researchers hub, find the current ROSES year’s program elements, and shortlist two or three that match your science question. Don’t settle for “close enough.” The best match is usually obvious once you read the element descriptions carefully.
Second, write a one-page concept summary and email the relevant program officer. Keep it crisp: your question, your approach, which NASA datasets/missions you’ll use, what you’ll deliver, and why it fits the element. Ask whether your idea is responsive and whether there are common pitfalls applicants hit in that element.
Third, build your timeline and start drafting in the order that prevents chaos: objectives → workplan → budget → narrative polish. Aim to finish a full draft with at least two weeks to spare so you can get an outside read and fix clarity issues before submission.
Finally, stay alert for amendments and updates while you write. ROSES changes happen; strong proposers adapt quickly and keep moving.
Get Started (Official Link)
Ready to apply? Visit the official NASA opportunity hub for researchers here: https://science.nasa.gov/researchers/
If you need to contact NASA about the page or general guidance channels referenced there, the listed email is: [email protected]
