The Developing Heliophysics Standards and Cross-science Collaborations Workshop Report

The Developing Heliophysics Standards and Cross-science Collaborations Workshop Report Authors: Rebecca Ringuette1, 2, Heather Cronk3, Julie Barnum3, Michael Wiltberger4, Daniel Welling5, Jeffrey Carver6, Bryan Harter3, Jon Vandegriff7, Jonathan T. Niehof8, and Brian A. Thomas9. 1Heliophysics Data and Modeling Consortium at the NASA Heliophysics Digital Resource Library, 2ADNET Systems, Inc., 3Laboratory for Atmospheric and Space Physics at the University of Colorado Boulder, 4NSF National Center for Atmospheric Research, 5University of Michigan, 6University of Alabama, 7Applied Physics Laboratory at Johns Hopkins University, 8University of New Hampshire, 9NASA’s Heliophysics Digital Resource Library Contributors: Dan Gengler10, Gabriel Martin10, Jeremy Faden10, Landen Freeman10, Hessler Ramirez Galdamez10, Megan Murphy10, Sydney Tune10, and the staff of the University of Iowa Physics and Astronomy Department. 10University of Iowa Hosted by the University of Iowa Physics and Astronomy Department in Iowa City, IA, USA, August 11-15, 2025. Funding by NASA Topical Workshops, Symposia, and Conferences 2025 Grant# 80NSSC25K7469 Executive Summary The Developing Heliophysics Standards and Cross-science Collaborations Workshop provided a space where the modeling and mission software development communities could discuss potential software standards in Heliophysics and discover new collaborations. Nearly 50 concepts for best practices and standards were discussed and voted on during the workshop, resulting in 20 concepts voted as standards and 25 as best practices. These concepts included software engineering best practices, Open Science practices, and topics specific to modeling and mission software, such as publication of software-produced datasets. The concepts highly prioritized based on expected impact and ease of implementation by each software category give a glimpse into the current state and the challenges faced by each field, such as the modeling software community’s prioritization of open sharing of code and proper data publication, and the mission software community’s focus on code reusability and interoperability. Continued incentives from funding agencies is needed to increase the number of codes converted to open-source software in both mission and modeling software. Echoing recent reports (ISTPNext 2023; Ringuette et al. 2024; NASEM 2025), the discussions in both software categories prioritized the importance of funding stability and career pathways for Research Software Engineers (RSEs) in Heliophysics. Including RSEs in the proposal process and earlier was highly favored to increase software quality and collaboration. The modeling software category also constructed a new type of funding model reminiscent of missions with tiering based on Open Science characteristics and community interactions. These and other ideas were regarded as important pillars to stabilize funding for RSEs in Heliophysics. Both software categories independently and organically discussed software-focused communities of practice. Although the descriptions in each section differ, their similarities suggest that they are different perspectives of the same structure. Such a community would support structured, funded mentoring opportunities; tiered standards and best practices (e.g. Ringuette et al. 2025a; Barnum & Niehof 2025); increased support for contributors, users and newcomers through hackathons and summer schools; advertising for software in higher tiers; and resources of higher quality and depth. Beginning components were noted in the Python in Heliophysics Community, the Center for Space Environment Modeling, and the Heliophysics Software Search Interface, but more development is needed. This workshop also produced the final paper template for a special issue on Science Data Systems, which is planned for 2026 (Smith et al. 2025). Software developers will submit publications based on that template to the special issue, which will conclude with a summary publication pulling together lessons learned from across those publications to inform and improve the development of future systems, including potential modularization of those systems. This workshop report is a call to action for increased focus and support in these areas: ● Increased funding incentives to convert currently closed code to be open-sourced, ● Funded development of the described software-focused communities of practice, and ● Innovative funding structures designed for software, such as a ‘digital mission’ model. 2 Table of Contents 1. Introduction 1.1 Workshop Structure 1.2 Statistics 2. Science Data Systems 3 3. Challenges and Opportunities for Model Software 3.1 Model User Software Community 3.1.1 Community of Practice 3.1.2 User Needs 3.1.3 Citation Culture 3.2 Model Software Developer Community 3.2.1 Funding Model Maintenance and Development 3.2.2 Incorporating Modern Practices and Testing Technologies 3.2.3 Running modeling codes on other HPC systems 4. Software Standards and Best Practices 4.1 Mission Software Priorities 4.2 Implementation Steps for Mission Software 4.3 Model Software Priorities 4.4 Implementing for Model Software 5. Post-Workshop Survey Results 6. Conclusions References Appendix Appendix A: Best Practices and Standards Descriptions for Mission Software Appendix B: Best Practices and Standards Descriptions for Model Software 1. Introduction The Developing Heliophysics Standards and Cross-science Collaborations Workshop provided a space where the modeling and mission software development communities could discuss potential software standards in Heliophysics and discover new collaborations to overcome current technical challenges. This workshop focused on improving Open Science practices for mission-related and model-related software development in Heliophysics, including solar physics, space physics, the ITM (ionosphere, thermosphere, and mesosphere) sciences, and closely related sciences. Attendees were expected to be involved in either mission-related or model-related software in Heliophysics or a closely related field at any career stage from a variety of backgrounds. This workshop gave attendees a unique opportunity to discuss potential collaborations on software with developers throughout the field as well as giving them a place to discuss what best practices and standards would help them collaborate effectively. 3 1.1 Workshop Structure Figure 1 shows the daily breakdown of the workshop's highly interactive format. During the first two days, mission software developers attended the Science Data Systems 3 (SDS3) workshop to collaborate on drafting a template for publications that communicate the lessons they have each learned through developing and operating mission science data systems. At the same time, model software developers participated in dynamic sessions focused on exposure to others’ efforts via presentations and discussions, prioritizing the discovered common challenges and opportunities, and working out potential paths forward for items selected by a common vote. Figure 1: Diagram showing the structure of the workshop. Arrows show information flow forward through the workshop with purple shapes indicating where voting occurred. On the third day (Wednesday), both groups came together to benefit from presentations and discussions on international standards and best practices for software, and connections between the Space and Solar Physics Decadal Survey and software development. Based on these presentations and discussions, attendees drafted a list of standards and best practices for the two Heliophysics software categories of interest. For the remaining two days, both groups focused on discussing the entire list of options and voting on those options, concluding with deeper discussions to work out potential ways to implement those standards and best practices for mission and model software. 1.2 Statistics Roughly two thirds of the 41 registrants attended the workshop either virtually or in-person. Several types of institutions were represented in the registrants and attendees as shown in Figure 2, with roughly half of the affiliations spread across various US-based universities and laboratories, not including industry, demonstrating the widespread applicability of the workshop topics across the Heliophysics software community. 4 Figure 2: Affiliations of the registrants and attendees across several types of institutions. Attendance of the workshop was unfortunately low, possibly due to the sudden change in travel restrictions in the US shortly before the workshop. Attendance in person and online were nearly equal, with 26 people in total. For the portions of the workshop where the attendees were split into different rooms, the attendance in each room was also roughly equal, although the core group of participants in the model sessions was smaller. Several people (11) filled out the post-workshop survey and have the career levels indicated in Figure 3. Nearly half were mid-career with none indicating an earlier career stage. Figure 3: Representation of career stages for the small sample of attendees that filled out the post-workshop survey. 2. Science Data Systems 3 The Science Data Systems 3 workshop is the third in a series of workshops focused on science data systems for missions in Heliophysics and related sciences. Previous workshops in the series focused on presentations, discussions, and the formation of potential collaborations. In the first of those workshops, the attendees decided to contribute publications to a special dedicated issue to present the lessons learned across the community in a structured way. A template for those publications was drafted by attendees of the second workshop. The leads of this third workshop in the series had intended for attendees to use that template to begin writing those publications. However, the group decided to collaborate to improve the template. The resulting product was a vastly improved template that better represented the expected breadth of knowledge, experience, and community of the mission science data systems community 5 (Smith et al. 2025). The editors of the special issue were selected and a long list of potentially interested contributors were generated for later outreach. 3. Challenges and Opportunities for Model Software The modeling portion of the first two days of the workshop week focused on challenges and opportunities in model-related software, including models. The first two sessions featured presentations from leaders, developers, and users of modeling software. Those presentations were: ● Lessons Learned when Open-Sourcing a Large Existing Code Base: The Kaiju Experience. Eric Winter, Software Developer, John Hopkins University Applied Physics Laboratory ● How to develop and maintain 1 million lines of code in the SWMF. Gabor Toth, Scientist, University of Michigan ● A non-modeler experience with models: adventures in OSSEs and experiment planning. Rafael Mesquitea, Model User, John Hopkins University Applied Physics Laboratory ● Moving to Open-Source for PSI's Modeling Software. Ronald Caplan, Scientist, Predictive Science, Inc. ● Physics-based modeling in the age of open science: one modeler’s perspective, concerns, and challenges. Jared Bell, Model User, NASA Headquarters ● Re-Imagining the Center for Space Environment Modeling to Address Challenges in Modeling. Dan Welling, Scientist, University of Michigan ● Lessons learned from CGS experience with moving to OSS. Michael Wiltberger, Scientist, John Hopkins University Applied Physics Laboratory OSS = Open Source Software, PSI = Predictive Science, Inc., OSSE = Observing System Simulation Experiment, CGS = Center for Geospace Storms, SWMF = Space Weather Modeling Framework. Each presenter was given the same five questions to consider in the development of their presentations. Not all questions were answered in each presentation as expected, but each presenter did answer at least 1 or 2, which gave ample material for discussion. Those questions were: 1. What technical and process challenges do you face? 2. What cultural challenges are preventing or slowing down progress? 3. What new technologies are you considering incorporating? 4. How are you incorporating software best practices or data standards into your software? 5. What concerns do you have moving forward? During the presentations and the following two discussion sessions, attendees added and discussed ideas for challenges and opportunities in modeling using a Padlet1. Those ideas were voted on the next day and those voted highest were categorized and discussed in more detail. Additional discussion and voting revealed the most highly rated challenges or needs for the 1 https://padlet.com/rebeccaringuettenasa/heliosoft2025Models 6 model user community and the model software developer community discussed in the following sections. 3.1 Model User Software Community The most highly rated needs for the model user community were: ● A community of practice where knowledge, experience, and mentoring are available; ● User needs, including data storage for large datasets, software provided by model developers to aid in analyzing the produced datasets, understanding how to properly run the models in varying scenarios, and computational resources to perform these tasks with available IT support; and ● A culture of using version-specific identifiers for the software used and the data produced in addition to any existing model reference publication to properly reference what artifacts were used to give proper credit and produce more transparent research. 3.1.1 Community of Practice The attendees considered the current lack of a community of practice to be the most important challenge for the model user software community, which also had a similarly high priority in the 2024 Software for NASA SMD Workshop Report (Ringuette et al. 2024). Considerable time was spent sketching out what components were needed to create a successful community of practice, where success would be measured by the usefulness and participation in that community. These components included: ● A virtual, searchable, and permanent space for people to come together and share experiences on what does or does not work, supported by a thoughtful set of rules, guidelines and policies. ● Structured peer mentoring where experienced users or developers are paired with newer ones, including publication reviewers, supported by routinely held hackathon-style workshops where newcomers learn from more experienced users how to perform various tasks. ● A central body of shared knowledge, including frequently asked questions, links to relevant resources, educational opportunities, and the like. ● Good advertisement, incentives to join, and proper support and incentives for more experienced users and developers to stay involved. The launch and long term success of such a platform depends on thoughtful preparation, collaboration across the modeling community, and funding. Development of one such structure from the University of Michigan’s Center for Space Environment Modeling is underway and could be shifted in useful ways to fit this purpose. Important steps to prepare for success include: ● Exploring existing successful approaches for critically needed components, such as the NASA Biological and Physical Sciences Analysis Working Groups structure, the US Research Software Engineer Association, and the Open Modeling Foundation. ● Create a group charter to set expectations, benefits and the encouraged behaviors. 7 ● Jumpstart the platform by involving a small number of major modeling groups to populate the tiers of expertise, working to include protocommunities of modelers. 3.1.2 User Needs The attendees additionally considered the current lack of support for user needs to be a critical challenge for the model user community. Important components included: ● Data storage and computational infrastructure for proper analysis of the large datasets produced by models. ● Wider understanding of how to run the models in differing realistic scenarios and with observational data used as inputs. ● Software built or certified by model developers to properly analyze and visualize the complex datasets produced by their models. Sharing knowledge of how to use models is incorporated in the community of practice discussed above. Here, the emphasis was instead on developing quality documentation, tutorial videos by the model developers or power users, and increased community engagement. The discussion focused on this and the software needs of the user community. The next steps discussed by the group were: ● Lead sessions at the Python in Heliophysics Community summer schools with two or more model developers groups to teach users how to visualize, analyze, and compare datasets produced from more than one model (e.g., SWMF and Kaiju). ● Increase involvement with the model user community, both in understanding their software needs and in collaborating on improvements to user software. ● Develop, advertise, and lead user sessions based on improved documentation and tutorials, including the proper 3D visualization tools. Additionally, the attendees recognized a need for increased connectivity between major computing platforms where models are run (e.g., NSF NCAR’s Derecho and NASA’s NSSDC) and cloud resources, potentially involving the Hybrid-Cloud Science Data System (HySDS2) software to reduce costs. 3.1.3 Citation Culture The attendees recognized the need to use version-specific DOIs for software and data produced by software in peer-reviewed publications for transparency, reproducibility, and proper attribution. However, significant barriers prevent this simple practice. ● Model and user software developers typically do not create DOIs for their software per release, and often not for the software at all. Typically only a reference publication is the given citation, which is not enough. Where those DOIs exist, they are not easy to find. ● Current infrastructure is tailored towards archiving, preservation, and creation of DOIs for small datasets produced by models and used in peer-reviewed publications (e.g., Zenodo). However, an increasing number of modern numerical models produce datasets 2 https://hysds-core.atlassian.net/wiki/spaces/HYS/overview 8 larger than the typical limitations of generalist repositories, creating a gap in data publication support for these massive datasets. ● Journals are not stringent enough in enforcing existing requirements for version-specific software DOIs. Steps to take to improve these issues are: ● Teach model and user software developers how to create DOIs for each new major release of software, including software that is restricted, through the development of tutorials and related efforts. The tutorials should include adding the correct DOIs to the software readme pages with proper citation instructions. ● Advocate for infrastructure for proper archival and DOI creation for model outputs used in publications. ● Collaborate with DataCite to create a way to automatically include the DOI for the reference publication when the citation for a software is created. ● Collaborate with the Coalition for Publishing Data in the Earth and Space Sciences3 to pressure publishers to require version DOIs for software in publications. 3.2 Model Software Developer Community The most important needs for the model software developer community were: ● Funding model maintenance, including recruiting and keeping Research Software Engineers (RSEs); ● Incorporating modern practices and testing technologies, including testing flexibility, continuous integration for HPC code, and documentation for software (especially non-Python software); and ● Adapting and running modeling codes on other HPC systems. 3.2.1 Funding Model Maintenance and Development The most pressing challenge in the model software developer community was funding, including support for research software engineers as a critical component of a model software team. The attendees spent a considerable amount of time sketching out a reasonable funding model for model software, which was similar to the funding models used for missions. The most important components of a “digital mission” funding model included: ● Funding calls designed for long-term (e.g., 5 years) support with priority placed on the model software capabilities, maintenance, and community support to be accomplished rather than the current focus on the science (e.g., NASA DRIVE Centers). ● Designated support of Research Software Engineers (RSEs) for at least 25% of their time, with their expertise evaluated based on their ability to meet software standards and best practices (e.g., the PyHC standards for python software). ● Tiered funding levels determined by a matrix of characteristics developed by the model developer community (e.g., Ringuette et al. 2025a and Barnum & Niehof 2025 as 3 COPDESS, https://copdess.org/ 9 Step 2: If a software project is choosing not to use an open-source language or a cross-platform technology, provide a justification that will convince the relevant review panels that the choice is needed, including for proposals, Preliminary Design Review, Critical Design Review, and journal articles. 15 (Standard): “Follow relevant domain-specific software development standards…” This item reflects one of the main purposes of the workshop. See Sections 5 and 6. 4.3 Model Software Priorities First, attendees drafted a definition of model software to base their discussions upon: “Modeling software includes source code files, algorithms, scripts, computational workflows, analysis tools, and executables that were created to represent a component or components of the heliophysical environment. Additional software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for the development of modeling software but were not created in the development process should be considered [analysis] software and not model software.” After significant ideation and discussion, the prioritized best practices and standards are presented in Figures 6 and 7 below. Figure 6: Impact and ease of drafted best practices and standards voted as applicable to both numerical models and analysis software. Blue circles indicate items categorized as best practices and orange squares show standards. Labels indicate the item numbers with lead lines where needed for clarity. Items 7 and 23 were shifted by 0.05 to the right to avoid overlap. Items 15 and 29 were rejected and so are not plotted. Quadrant boundary locations indicated with dashed lines were calculated using the centroid of the data shown on this figure and the next. Items in the top left quadrant (quadrant A) are the most impactful and easiest items, and so are prioritized as the next steps (see Table 2). Items in quadrant B are considered second priority, followed by those in quadrant C. See Appendix B for the correlation between item numbers and descriptions. 16 Figure 7: Impact and ease of drafted best practices and standards voted as applicable to numerical models. Same labeling as the previous figure. A total of 30 items were voted on to determine what types of model software the item was relevant for, a 1-5 rating for expected impact and ease of implementation for the item, and whether the item should be considered a best practice to be adopted at will or a standard to be enforced on all in some way. Items voted as relevant for both types of model software (numerical models or analysis software) are found in Figure 6, with those voted as relevant for only numerical models in Figure 7. No items were voted as relevant for only analysis software. Item numbers are included as data labels so the presented information can be connected with the item descriptions (see Appendix B). Item 15 was rejected as unreasonable and item 29 was rejected as repetitive of items 22-28 and 30 during the workshop. See the Mission Software Priorities section for a full description of the plots. Items found in quadrant A in both figures are additionally listed in ranked order in Table 2 with their full descriptions. Items relevant to both model software types are listed first, followed by those voted as only relevant for numerical models. Considering both plots, 14 concepts were voted as standards and 14 as best practices with two concepts rejected (see Appendix B). (Table 2 on next page) 17 Table 2: Model Software Tasks Ranking Order Order Item Number Description 1 5 Concerning software attribution, developers shall regularly mint DOIs corresponding to major releases and list relevant (if any) DOIs for publications about the modeling software; users must use the publication DOI (if one exists) and the software release’s DOI to give proper attribution. 2 18 Model software, except restricted software (as defined in SPD-41a), shall be made available in a publicly accessible repository that is widely recognized by the community. 3 30 When model data is archived (e.g., when used in publications or forecasting), the input files with all input data and settings shall be archived separately. If the input data size is prohibitive, all steps required to obtain the input data set must be given (e.g., data source, version of data and software used, processing steps, etc.). 4 14 Should be developed openly in a publicly accessible, version-controlled platform that allows for contributions and engagement from the community. 5 23 Data produced by models used in publications or official forecasting should be machine-readable (i.e., data should be reasonably structured to allow automated processing). 6 4 Include a code of conduct and guidelines for how to make contributions, even if the contributions simply state none can be accepted. 7 13 Record all of the algorithm versions that produced a given data product, such as versions or commit hashes of the model(s) used, versions of the (pre/post)processing and analysis tools, and any other software used to produce the data product, ideally with DOIs where possible. 8 1 The developer(s) of a model should create & gather an initial core of shared knowledge for the community concerning the model, including documentation, tutorials, examples, and more. 9 24* Data produced by models used in publications or official forecasting should be made available in non-proprietary, modifiable, and open formats. *Voted as most relevant for numerical models. See text. 4.4 Implementing for Model Software Several of the standards and practices below will only be truly effective and, therefore, readily adopted if there is clear harmony with policies and requirements set by funding agencies. An example is data-model and intermodel validation done in the open: this is only possible if funding agencies dedicate resources both to the exercise of validation and for funding models that need improvement. One particularly interesting result is the high rating for item 18 as a standard and 14 as a best practice - both requiring the open sharing of numerical models and the associated analysis 18 software. This signifies a shift in Heliophysics modeling culture from the previous closed code paradigm open results, which motivated the creation of the CCMC in the US, to an open code open results paradigm, where the software is open for everyone to access, study and run themselves. Given the small number of attendees and the institutions represented, we take this as a tentative sign of a turning point in the culture towards open software - one worth celebrating. Several items (13, 21-28, and 30, see Appendix B) concern the publication of model data. It was agreed that publication of model data that fulfills those items should be done when the final result it supports is made public, such as in a peer-reviewed publication or in use as part of a forecast. In short, acceptable publication of model data includes: ● The assignment of a DOI to the dataset with open access to the files (e.g., on Zenodo) and the appropriate authors indicated, ● Metadata to indicate all input data and software versions and settings used to produce the data (DOIs preferred), ● Interoperable file formats, and ● An open license. The DOI for the dataset should then be cited in the forecast or peer-reviewed publication it supports. Attendees noted lacking infrastructure for the publication of model data in the TB to PB file size range. 5 (Standard): “Utilize both software publication and DOI for the specific version for attribution.” Step 1: Creating an example list of services for archiving software and minting DOIs for them (e.g., the GitHub-Zenodo workflow). Step 2: Generate a top 10 FAQ of ‘gotchas’ that have bitten us in the foot for archiving models and analysis software (e.g., on Zenodo), Step 3: If the model or analysis software has one or more reference publications, include the DOI for at least the most recent of those publications on the code repositories main page, preferably in the citation instructions section. Journals typically accepting these types of publications include JGR Technical Reports, Journal of Computational Physics, Journal of Open Source Software (JOSS), and other journals focused on software and computational methods. Traditional scientific journals are often used for these publications as well. Step 4: Contact JOSS to understand how their review process would change for code that is written in multiple languages and/or can only compile/run on HEC. Step 5: Get a DOI for the software and, if possible, a reference publication. Ideally, the software DOIs would become part of an automatic process that is incorporated into the release process for each new major version. 18 (Standard): “Model software …shall be made available in a publicly accessible repository” Step 1: Create a list of publicly accessible repositories that are widely recognized by the Heliophysics modeling community (e.g., GitHub, GitLab, BitBucket). Step 2: Use those repositories to host model and analysis software. 19 Step 3: Ask for streamlined workflows from those repositories to archiving services (e.g., from GitHub to Zenodo) where they don’t exist. 30 (Standard): “When model data is archived…” Step 1: Determine what files are needed to capture all the input data and settings for a model execution, including the total size of those files. When coupled models are used, the inputs to all models should be included. Step 2: Structure these files with a description on what each file is, how it was used, and any other information that would be useful. Step 3: Create a DOI for all input files through an archive, including a citation to the software version the input files are meant for. When the input data is too large for the archive, include a citation to the version of the data. This is to be separate from the data produced by the model. Step 4: Work together to formulate lessons learned and best practices on transparently archiving model data. Note: The discussion included potential edge cases, where input data sets are very large (some cases can be petabyte in size) and sources for the input data may evolve (new versions of solar imaging are produced and older ones discarded). 14 (Best Practice): “Should be developed openly…” This item is self-explanatory. GitHub is a good example of the software repository described, but is not a permanent archiving resource. 23 (Best Practice): “Data produced by models used in publications or official forecasting…” This item is self-explanatory. The example file types discussed included netCDF4, HDF5, FITS, and file formats required for 3D visualization software appropriate for the model. 4 (Standard): “Include a code of conduct and guidelines for how to make contributions…” This item is self-explanatory. Several excellent examples exist in the PyHC community (e.g., PlasmaPy5, SunPy6, and pySPEDAS7). 13 (Standard): “Record all of the algorithm versions that produced a given data product…” This item was not discussed separately, but was part of the discussion of model data publication described above. In order for this to be possible, the versions, commit hashes, or DOIs needed for the softwares used must be available and easily findable. 1 (Best Practice): “The developers should create an initial core of shared knowledge…” There was not enough time to discuss this item, but this is a critical part of the envisioned community of practice for model software described in Section 3.1.1. 7 https://pyspedas.readthedocs.io/en/latest/contributing.html 6 https://sunpy.org/contribute/ 5 https://docs.plasmapy.org/en/latest/contributing/index.html 20 5. Post-Workshop Survey Results Of the 27 people that attended the workshop, 11 filled out the post-workshop survey. Those who attended on-site or virtually were spread roughly evenly from the mission and model portions of the workshop. The majority of those who answered the survey were mission and model software developers or users. One of the main purposes of the workshop was to provide the opportunity for mission and model software developers to form or enhance collaborations for software. Nearly two-thirds of those who completed the survey indicated at least one new or enhanced collaboration, with nearly all of those being with at least one other software group at another institution. This indicates the clear need for workshops to incorporate presentations from the software development community for mission and model software. Without this exposure, software development is expected to continue to be siloed with a high chance of duplication of effort. Another focus of the workshop was to provide a place for the Heliophysics mission and model software communities to discuss best practices and standards for software. Attendees indicated a strong desire to continue these discussions in the post-workshop survey, with over half of the respondents preferring these conversations to continue in sessions at existing conferences, ideally the Data and Analysis Software in Heliophysics (DASH) yearly workshop. There was also some support for a biannual hybrid workshop to be focused on these topics. The desired structure for these discussions indicated in the post-workshop survey tended to include a wider involvement with the model and mission software developer communities prioritizing software developers, coordination and connection with funding agencies and existing initiatives (e.g., DASH), continued cross talk between these and other software developer communities in Heliophysics, and at some future time a central reference place such as a website or GitHub where the software developer community can be the driving force behind these standards and practices. 6. Conclusions The mission software and modeling software communities are in two different stages in adopting Open Science practices. The mission software community’s direct connection to the open data movement for mission data has resulted in increasing Open Science requirements over the last several years, both on the data produced and the software used to produce it. This pressure has prompted increased adoption of Open Science practices, which is reflected in the highly ranked best practices and standards for missions (see Table 1) that generally prioritize reusability and alignment with existing standards. 21 Outside of some early adopters such as SWMF8 and IRI9, the modeling software community has only just begun its movement towards Open Science practices, spurred by requirements recently imposed by funding agencies. However, modeling software faces more challenges in this journey due to the greater software complexity, computational specialization (e.g., HPC and Fortran), and lack of data archival infrastructure. This is seen in Table 2, where the most highly ranked best practices and standards prioritize increased transparency, reusability, open sharing, collaboration, and data publication. Increased funding for these efforts and the removal of funding for closed codes will accelerate this transition to Open Science practices substantially, especially if those funding changes are coordinated across funding agencies. These two software groups also have vastly different funding stabilities. Mission software development continues to be siloed per institution with reasonably stable but decreasing funding dependent on missions. Here, the group called for increased priority on cross-mission and cross-institution collaboration with early involvement of research software engineers (RSEs) to increase funding efficiency and reduce duplication, particularly during the proposal writing stage. RSE input into the design of funding opportunities with a significant software component would benefit their impact and efficiency. The existing funding structure for model software is much more tenuous. The only long-term funding (e.g., more than 1-2 years) available in recent years has been a few opportunities through the NSF and the call for NASA DRIVE Centers. However, those opportunities focus on the science, not the development or maintenance of high quality modeling software used by large portions of the research or forecasting communities or innovative software solutions to existing challenges. To address this critical gap, several components of a ‘digital mission’ funding model were outlined (see section 3.2.1) along with a few high-level ideas on how to determine which modeling software to fund (e.g., Ringuette et al. 2025a and Barnum & Niehof 2025). Both groups saw a more stable funding environment with purposeful support of RSEs as a critical component to improving recruitment and retention of these specialized skillsets. This is particularly important in our science due to the often long ‘ramp-up’ times needed for a software engineer to learn enough of the science to unlock the depth of their skills for the benefit of the project. Another point of agreement between the mission and modeling software development communities was the need for a community of practice focused on software (sections 4.2 and 3.1.1). Although the descriptions in each section differ, their similarities suggest that they are simply different perspectives of the same structure with the following high level characteristics: ● Structured, funded mentoring ● Wider, deeper scope of resources ● Tiered standards and best practices ● More summer schools and hackathons 9 https://irimodel.org/IRI-2016/ 8 https://github.com/SWMFsoftware/SWMF 22 ● Advertising of software in higher tiers Discussions pointed to some combination of the PyHC, the Heliophysics Software Search Interface, and efforts at the Center for Space Environment Modeling, extending to other programming languages. All participants agreed that some small level of long-term funding would be required to build what is needed, likely with some additional start-up cost, but the expected impacts on the software development community was considered well worth the cost and efforts needed. Similar discussions occurred at the Data, Analysis, and Software in Heliophysics Workshop later the same year where a poster on the highlights of this report was presented (Ringuette et al. 2025b). Wider, more sustained involvement is needed in future discussions to ensure more complete representation of the mission and model software development communities. We expect these discussions to take place at future DASH and IHDEA workshops, with summaries of those discussions to be included in the relevant workshop reports. Small side workshops may be required to make focused progress in the highlighted areas, particularly as the software development community in Heliophysics moves towards implementing a community of practice and increasing collaboration. The authors gratefully acknowledge NASA TWSC funding for this workshop. References Barnum, J., & Niehof, J. (2025). PHEPs: intro and current status. International Heliophysics Data Environment Alliance 2025 Workshop, San Antonio, TX, USA. Zenodo. https://doi.org/10.5281/zenodo.17401090. Bell, J. (2025). Physics-based modeling in the age of open science: one modeler's perspective, concerns, and challenges. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353915. Caplan, R., Downs, C., & Linker, J. (2025). Moving to Open Source for Predictive Science Inc.'s Modeling Software. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353865. ISTPNext Committee (2023). Report of the ISTPNext Workshop held May 8-10 at JHU/APL. The International Solar Terrestrial Program (ISTP) Next Workshop, Laurel, MD, USA. https://bit.ly/ISTPNext_report Katz, D. S. (2025). Research Software & Standards. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.16782908 23 Mesquita, R. (2025, August 11). A non-modeler experience with models: adventures in OSSEs and experiment planning. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353787. National Academies of Sciences, Engineering, and Medicine (2025). The Next Decade of Discovery in Solar and Space Physics: Exploring and Safeguarding Humanity's Home in Space. Washington, DC: The National Academies Press. https://doi.org/10.17226/27938. Niehof, J. (2025). Standards as Abstractions. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353940. Ringuette, R., Jin, M., Bell, J., & Schmidt, G. (2025a). Tiered Approaches to Implement Open Science for Complex Computational Software: Implementation Ideas from the NASA SMD Modeling Community. Zenodo. https://doi.org/10.5281/zenodo.15776392. Ringuette, R., Cronk, H., Barnum, J., Wiltberger, M., Welling, D., Carver, J., Thomas, B., Vandegriff, J., & Niehof, J. (2025b). Highlights of the Developing Heliophysics Standards and Cross-science Collaborations Workshop. Data, Analysis, and Software in Heliophysics (DASH), San Antonio, TX, USA. Zenodo. https://doi.org/10.5281/zenodo.17372749. Ringuette, R., Crawford, S., Thomas, B., Muna, D., Ashish, A., Gummo, C., Jenkins, J., Ramirez, P., Saravia-Butler, A., Singer, L., & Steele, J. (2024). 2024 Software for NASA SMD Workshop Report. 2024 Software for the NASA SMD Workshop, NASA HQ, Washington, D.C., USA. https://doi.org/10.5281/zenodo.14047904. Schmidt, G. (2025). Standards in Climate Modeling: What worked, what didn't and why?. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353959. Smith, E. (Brent), Harter, B., Niehof, J., Cronk, H., Barnum, J., Vandegriff, J., Faden, J., Granroth, L., Piker, C., Grimes, E., & Ringuette, R. (2025). Mission Science Data Systems (A Mission-Specific Template). Zenodo. https://doi.org/10.5281/zenodo.17316944 Toth, G. (2025). How to develop and maintain 1 million lines of code in the SWMF. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353811. Welling, D., & The CESM Team. (2025). Re-Imagining the Center for Space Environment Modeling to Address Challenges in Modeling. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353894. 24 Wiltberger, M., & Center for Geospace Storms Team. (2025). Lessons learned from CGS experience with moving to OSS. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353927. Winter, E. (2025). Lessons Learned when Open-Sourcing a Large Existing Code Base: The Kaiju Experience. The Developing Heliophysics Standards and Cross-science Collaborations Workshop, Iowa City, IA, USA. Zenodo. https://doi.org/10.5281/zenodo.17353834. Appendix Appendix A: Best Practices and Standards Descriptions for Mission Software This section of the appendix lists the descriptions of the items voted on for mission software. The definition of mission software drafted during the workshop is “software and related technologies used or developed by the mission to support ground data processing and analysis necessary to turn raw source data (spacecraft or ground measurements) into usable and accessible science data ready for analysis by experts. This software is unique to the domain of supporting mission data after it has been downlinked.” 1. Try to discover and leverage what is already out there (software and standards) 2. Document and publish tool selection reasons; can be simple comparison analysis up to full trade study 3. Make your capability known: make releases citable with DOIs; use existing Citation-centric metadata (like CFF files in Github); publish a paper on your system or software 4. Aggressively promote / advertise any reusable tools you make, especially if you implement an existing standard; network with RSEs and scientists to make your capacity known 5. Use open-source languages that are cross-platform to allow for platform pivots 6. Use good metrics to capture, track and then publish usage statistics as a proxy for community uptake; consider CHAOSS - Community Health Analytics in Open Source Software https://chaoss.community/ 7. Keep reusability and future contributions in mind as you design and develop code (consider modularity, documentation, minimal dependencies, testing, installation support, development and contribution policies) 8. Design data products early in mission design, so they can impact instrument and operations design; involve stakeholders outside of the instrument team in data product design (e.g. incorporate modelers so products are relevant for models and archive representatives so products are designed to standard from the start). Hold data product reviews before they are used. 25