D1.1 OSPO-RADAR Stakeholder Requirements and Specifications

D1.1 OSPO-RADAR Stakeholder Requirements and Specifications Project Title Open Source Program Office Research Assets Dashboard and Archival Resource Project Acronym OSPO-RADAR Grant Agreement No. 2025-25188 Start Date of Project 2025-06-01 Duration of Project 24 months Project Website https://www.softwareheritage.org/2025/04/02/ospo-radar/ Work Package WP1, Project management, specifications, planning, and testing Authors Morane Gruenpeter, Renaud Boyer, Sabrina Granger Reviewer(s) Bastien Guerry, ADD COMMUNITY REVIEWERS Date 2025-09-30 Version V1.0 FOR COMMUNITY REVIEW Document log Issue Date Comment Author/Editor/ Reviewer v.0.1 06-08-2025 Inception and first structure draft M. Gruenpeter & R. Boyer v.0.2 21-08-2025 Writing sprint and gaps identification M. Gruenpeter, R. Boyer & S.Granger v.0.3 04-09-2025 Draft of main sections M. Gruenpeter, R. Boyer & S.Granger v 0.4 22-09-2025 Added workflows, use cases & personas M. Gruenpeter, R. Boyer & S.Granger 1.0 26-09-2025 Version 1.0 shared for community review M. Gruenpeter, R. Boyer & S.Granger Abstract The OSPO-RADAR project will develop the technical tooling to enable Academic Open-Source Programme Offices (OSPOs) to efficiently archive, manage, and showcase their institutions' software productions. This will elevate research software to a first-class research output and enable an evidence-based approach to software development. Built on the integration with Software Heritage, the portal will offer enhanced metadata management, streamlined workflows, and institutional visibility, fostering a sustainable ecosystem for open-source software management. OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Terminology Terminology/Acronym Definition ARDC Archive, Reference, Describe & Cite Referencing a software refers to: making software artifacts identifiable by attributing SoftWare Hash Identifiers (SWHIDs). CFF Citation File Format CRUD Create, Read, Update, and Delete DMP Data Management Plan: “...is a living summary document that provides assistance with organising and planning all the phases in the lifecycle of data. It explains, for each dataset, how project data will be managed, from creation or collection to sharing and archiving.” (Université Paris Saclay, 2019) Software can be tracked in a software management plan (SMP). FAIR Principles based on community expectations in respect of research outputs - findable, accessible, interoperable, and reusable. JATS Journal Article Tag Suite: XML format used to describe scientific literature published online MVP “A Minimum Viable Product is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development1” PID Persistent identifier: generally expected to be unique, resolvable, and persistent. RSMD Research Software MetaData (guidelines) SIRS Scholarly infrastructures for research software (report) SPDX System Package Data Exchange is an open standard capable of representing systems with digital components as bills of materials. SWHID SoftWare Hash Identifiers are designed to identify permanently and intrinsically all the levels of granularity that correspond to concrete software artifacts: snapshots, releases, commits, directories, files and code fragments. SWHID became ISO/IEC international standard 18670 on April 23, 2025. SWORD Simple Web-service Offering Repository Deposit is an interoperability standard developed by JISC extending ATOM. 1 https://en.wikipedia.org/wiki/Minimum_viable_product 2 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Table of contents 1/ Introduction 1.1/ Objectives 1.2/ Scope and Methodology 2/ Stakeholder groups and personas 2.1/ What is the Open Source Programme Office Scope in Academia? 2.2/ Scholarly Ecosystem stakeholders 2.3/ Personas, as a collective image of a segment of the target audience 3/ Current landscape and associated challenges 3.1/ The existing infrastructures in the ecosystem 3.2/ Building on existing infrastructures and components 3.3/ The Role of CodeMeta in OSPO-RADAR 4/ About the specifications 4.1/ Overview 4.2/ Out of Scope 4.3/ Objectives (aligned with the SIRS pillars) 4.4/ Existing features OSPOs can use 5/ Minimum Viable Product: features and workflows overviews 5.1/ Account creation, login and management 5.2/ Populate the software source code dashboard 5.3/ View dashboard, curate and filter 5.4/ Public view and search capabilities 6/ Non-functional requirements to address 6.1/ Accessibility 6.2/ Performance / compatibility 6.3/ Legal requirements 6.4/ Sustainability & maintainability 7/ What’s next? Interoperability & reusability of the Dashboard. 7.1 / integration with existing tools 7.2/ Functionalities and capabilities to keep in mind after MVP 8/ The road ahead: a sustainable service model References Appendices Appendix A: Premortem Appendix B: Persona Academic OSPO Manager Appendix C: A collection of use cases from the RSMD workshop (2023) Appendix D: Review grid of the RSAC components specifications 3 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. 1/ Introduction 1.1/ Objectives The OSPO-RADAR project (Open Source Program Office Research Assets Dashboard and Archival Resource) addresses a growing need in the research ecosystem: the effective management, preservation, and recognition of software as a first-class research output. At the highest policy level, such as the UNESCO recommendations on Open Science, the DORA declaration, and the French National Plan for Open Science, software is increasingly acknowledged as a key scholarly product. Yet, unlike articles or datasets, the infrastructures supporting the archival, curation, and metadata management of software remain underdeveloped. The inherent complexity of software, with its dynamic nature, dependency layers, and varied documentation, poses unique challenges for discoverability, preservation, and attribution. For Open Source Program Offices (OSPOs) within academic and research institutions, these gaps translate into operational difficulties. OSPOs play a critical role in managing and promoting open source practices, yet they face recurring obstacles in: ● Archiving and tracking software outputs; ● Ensuring alignment with institutional processes; ● Managing metadata in ways that foster visibility, compliance, and strategic decision-making. (C. Dillon, 2025) Effective metadata management is central to overcoming these challenges. Metadata links software to related publications, datasets, and contributors, thus strengthening its academic recognition and impact. Standards such as CodeMeta, widely adopted by the community and endorsed by EOSC, RDA, and Force11, provide a strong foundation. However, they require further refinement to address OSPO-specific workflows, such as capturing license compatibility or documenting diverse forms of software documentation. To meet these needs, OSPO-RADAR proposes the development of a Dashboard. Built on the Software Heritage archive and grounded in metadata standards, the dashboard will offer OSPOs a unified, interoperable, and scalable platform to: 4 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ● Manage institutional software assets; Enrich and curate metadata; ● Support proper software citation and attribution; ● Track contributions, funding, and reuse; ● Interconnect with existing infrastructures such as InvenioRDM. This dashboard aims to simplify workflows, enhance discoverability, and increase the visibility of research software, thereby empowering OSPOs to better support their institutions and contribute to the sustainability of open science. The SIRS (Scholarly Infrastructures for Research Software, EOSC 2020) distills four essentials for a healthy software scholarship ecosystem—archive, reference, describe, cite—and couples them with a cross-cutting call for interoperability and researcher education (notably via publishers). Together, these set the north star for OSPO-RADAR: move beyond principles into day-to-day operations that institutions can actually run. Why SIRS matters now Despite broad consensus, practice lags: hand-offs between repositories remain brittle, identifiers aren’t used consistently, metadata is shallow or siloed, and citation guidance is fragmented. Infrastructures have the leverage to normalize practice, provided the tooling makes compliance the path of least resistance. OSPO-RADAR operationalizes SIRS recommendations via ready-to-run flows, opinionated defaults, and actionable signals that the OSPO offices can adopt quickly. Archive ● Ensure durable, verifiable, provenance-rich preservation of source code and its context. ● Define institutional deposit flows to Software Heritage (human and API), provenance capture (origin URLs, timestamps, authorship), and retention policies visible in the dashboard. Reference ● Make software findable and unambiguously referable over time. ● Treat PIDs (notably SWHIDs) as first-class data: stored, displayed, exported, and resolvable across UI and API. Describe ● Provide rich, reusable metadata to enable discovery, assessment, and reuse. ● Implications for D1.1. Adopt CodeMeta profiles, require a minimal metadata core, support mappings to local schemas, and reduce curator burden with assisted extraction (“FAIRifiers”). Cite ● Normalize correct software citation across venues. ● Provide rich, reusable metadata to enable discovery, assessment, and reuse. ● Adopt CodeMeta profiles, require a minimal metadata core, support mappings to local schemas, and reduce curator burden with assisted extraction (“FAIRifiers”). 1.2/ Scope and Methodology The scope of D1.1 is to capture the requirements, expectations, and challenges of Open Source Program Offices (OSPOs) in academic and research institutions, in order to shape the functional design of OSPO-RADAR. The methodology combined two complementary approaches: (1) 5 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. gathering structured feedback through a survey distributed across the OSPO and research software community, and (2) validating and enriching these findings through a community review process, during September and October 2025. 1.2.1/ Survey Results The OSPO-RADAR survey collected responses from 16 organizations, with a majority representing universities (68.8%), followed by research institutes (25%). The maturity of OSPOs varied: most respondents indicated that their initiatives are just getting started (53.8%), while others reported defined roles and goals (23.1%) or defined policies with limited tooling (15.4%). Only one organization reported advanced workflows with automation. Key findings included: ● Curation workflows: Respondents were evenly split between preferring researcher-initiated (50%) and institution-initiated (50%) curation. ● Functional priorities: The most valuable features identified were tracking reuse, citations, and funding links (27.9%), integration with platforms (23.2%), and public-facing software showcases and citation tools (16.2% each). Automatic archival (SWHIDs) and centralized metadata management also received significant support. ● Solution preferences: A majority favored integration into existing systems (58.3%), while 41.7% expressed interest in a SaaS solution provided by Software Heritage. ● Challenges: Common issues included lack of systematic tracking and archiving, difficulty convincing researchers to deposit software, fragmented schemas across groups, and concerns around interoperability, metadata curation, and quality control. ● Engagement: More than half of the respondents were willing to contribute to OSPO-RADAR specifications, with a preference for online workshops (54.6%) and contributions through shared documents or code repositories. These results provide a clear picture of the diverse contexts and priorities of OSPOs in academia, confirming both the demand for dedicated tooling and the importance of interoperability with existing platforms. 1.2.2/ Community Review Process In addition to the survey, a community review process was implemented to validate and refine the preliminary findings. This process combined synchronous and asynchronous exchanges to maximize participation and depth of feedback: ● Targeted workshop: A small workshop was held with five designated OSPOs, allowing for focused discussions on the survey outcomes and the initial scope of OSPO-RADAR. ● Asynchronous review: Drafts of this deliverable were circulated for comments over a one-month period, enabling broader community members to provide input at their own pace. ● Iterative refinement: Feedback from both the workshop and the asynchronous review was consolidated and used to adjust the interpretation of survey results and sharpen the identified priorities. 6 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. This combined approach confirmed the survey’s main conclusions, while emphasizing the importance of flexibility to accommodate institutions at different maturity levels. It also reinforced the value of transparency and continued engagement, ensuring that OSPO-RADAR remains shaped by its community. 2/ Stakeholder groups and personas “One of the most promising and differentiating characteristics of university OSPOs is their ability to support novel forms of impact through new partnerships and engagement.” (Young et al., 2024) 2.1/ What is the Open Source Programme Office Scope in Academia? Within the academic landscape, Open Source Programme Offices (OSPOs) play a strategic role in bridging institutional research practices with the broader open-source ecosystem. While corporate OSPOs primarily address compliance, risk management, and efficiency, academic OSPOs are distinguished by their focus on advancing Open Science and supporting research software as a first-class scholarly output. The scope of an academic OSPO typically includes: ● Governance and Policy Establishing clear institutional policies for open-source software development, licensing, intellectual property, and compliance, while aligning with national and international Open Science strategies. ● Research Software Management Supporting the long-term archiving, citation, and discoverability of software outputs; promoting the use of persistent identifiers and metadata standards (e.g., SWHIDs, CodeMeta); and ensuring research reproducibility. ● Community and Capacity Building Serving as a hub that connects researchers, research software engineers (RSEs), librarians, and IT professionals. Academic OSPOs provide training, workshops, and guidance on open-source best practices, while fostering recognition of software contributions in research assessment. ● Infrastructure and Tools Facilitating the integration of institutional systems with external infrastructures such as Software Heritage, Zenodo, or GitHub/GitLab; developing dashboards and monitoring tools to track reuse, impact, and sustainability of research software. ● Strategic Partnerships Acting as the institutional interface with external open-source communities, funders, and international initiatives (e.g., EOSC, RDA, ReSA, SciCodes). Academic OSPOs help position their institutions as active contributors to the global open knowledge ecosystem. In this way, OSPOs in academia contribute not only to the efficient management of research software assets but also to the cultural shift required for software to be fully recognized as a critical component of scholarly communication. 7 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. 2.2/ Scholarly Ecosystem stakeholders The Software Source Code Identification Working Group (SCID WG), a joint effort under the Research Data Alliance (RDA) and FORCE11, produced a landmark output on use cases and identifier schemes for persistent software source code identification. Published in 2020, the report identifies a broad range of stakeholders that are listed below. Infrastructures and tooling: ● Archive: Preserves human knowledge, particularly software source code. Examples: Software Heritage (SWH), Zenodo ● Citation Manager: Provides services or tools for managing citations. Examples: Zotero, Mendeley, EndNote ● Collaborative Development Platform / Forge: Host collaborative software development in public or private repositories. Examples: GitHub, GitLab, Bitbucket ● Indexer: Aggregate, classify, and provide access to research outputs, improving findability of software items. Examples: ADS, Scopus, Web of Science, Google Scholar ● Institutional, National or Domain Repository: Preserve intellectual outputs of a specific institution or domain. Examples: HAL ● Journal / Publication Venue / Publication platform: Disseminate research outputs (articles, data, software) through peer review, journals, or conferences. Examples: JOSS, POPL, Episciences ● Package Manager: Facilitate installation, configuration, and management of software tools. Examples: PyPI, NPM ● Registry: Provide online catalogs describing software projects with metadata. Examples: ASCL, swMATH, SciCrunch, Wikidata Organization types and actors: ● Funder: Provide financial support for research projects, including those producing software, and evaluate outcomes. Examples: NSF, NIH, Wellcome Trust ● Institution / Research Center / University: Employ researchers, may hold copyright of outputs, and evaluate contributions. Examples: MIT, ENS, Inria, Grenoble Alpes University, Delft University of Technology ● Technology transfer offices: have a different scope than OSPOs, but can maximize the impact of open source software outside the academic environment. ● Library / University Library Collect and curate resources, may provide emulation services for legacy software. Research libraries help researchers develop data/software management plans as these are increasingly mandatory by research funding organisations. Examples: Stanford Library; The Department of Libraries, Information and Open Science (DiBISO) at Paris Saclay University ● Curator / Librarian / Digital Archivist: Moderate and curate research/software artifacts descriptions in archives, repositories, or libraries. Support scholarly communications (i.e. open access, emerging trends in publishing). Provide training and create learning materials on open science best practices. Contribute to the open science institutional policy. 8 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ● Policy Maker: Define institutional, national, or international policies related to research outputs. Examples: European Commission, national research committees ● Researcher as Software User (RSU): Use software in research without contributing to its creation. Examples: Any researcher using existing tools in their work ● Researcher as Software Author (RSA) / Research Software Engineer Create research software, possibly fulfilling roles such as design, architecture, coding, debugging, maintenance, documentation, testing, or management. ● Software Engineer Develop and maintain software without necessarily being a researcher, often contributing to creation, maintenance, or dependencies. 2.3/ Personas, as a collective image of a segment of the target audience A persona is an archetype representing a group of people whose behaviors, motivations, and goals are similar. The purpose of personas is not to represent all audiences or address all needs of the website or a product, but instead to focus on the major needs of the most important user groups. Creating personas helps identify the barriers to accessing the product, which leads to asking why users would choose the future product over another. Persona ’s name Job title Main needs Pain points Sofia Academic OSPO Manager ● Build open source awareness across the institution ● Define and implement OSPO policies and best practices ● Support researchers in licensing, compliance, and community contributions ● Connect the institution to European and global OSPO networks (CURIOSS, CHAOSS, etc.) ● Deploy tools for the ecosystem (legal compliance, metrics, etc.) ● Keep up to date with available tools for OSPOs ● Lack of developer capacity ● Unclear internal policies ● Balancing compliance with innovation ● Within the institution, some groups might view an OSPO as a “competitor” rather than a complementary resource (Young et al., 2024) 9 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Research Data Alliance/FORCE11 Software Source Code Identification WGet al. (2020). Software Source Code Identification Use cases and identifier schemes for persistent software source code identification (1.1). Zenodo. https://doi.org/10.15497/RDA00053 ● CLI for automated deposits and scripting. ● Provenance & version updates in deposits (track new releases/versions). Bulk Archival at Scale ● Bulk Save API (/save/bulk/) to submit large lists of origins (CSV/JSON).4 ● Status tracking endpoint (/save/bulk/<request_id>/) to monitor progress.5 Metadata & Citation (no dashboard needed) ● Metadata query by SWHID or origin URL (intrinsic/extrinsic; raw/indexed). ● Citation API endpoints: ○ /api/1/raw-intrinsic-metadata/citation/origin/ ○ /api/1/raw-intrinsic-metadata/citation/swhid/{SWHID}/ ● Automatic BibTeX generation from codemeta.json or CITATION.cff (with smart entry types based on SWHID: snapshot/release/revision/directory/content). ● CodeMeta-aware ingestion and mapping (CFF → CodeMeta → BibTeX). Discoverability & Referencing ● Stable SWHIDs (permalinks) at multiple granularity levels (origin/snapshot/release/revision/directory/content) for long-term reference. ● Public web “Citation” tab under permalinks for quick copy-paste (optional UI use). Integration Support ● Comprehensive tech docs & user guides for all of the above. ● Partner deposit admin view (optional web UI for partners; not required to use APIs/CLI). 5 https://archive.softwareheritage.org/api/1/origin/save/bulk/request/doc/ 4 https://archive.softwareheritage.org/api/1/origin/save/bulk/doc/ 16 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. 5/ Minimum Viable Product: features and workflows overviews The section captures the basic operations that the OSPO-RADAR Dashboard needs to support. They describe how a user interacts with the system, how the Dashboard connects with the Software Heritage archive, and what minimal features are required for a Minimum Viable Product (MVP). The idea is to keep things lightweight and usable, while ensuring that provenance and integration are handled correctly from the start. The MVP delivers the minimal end-to-end path, including: - Secure account/role management; - Collection population (batch import, signal sw repo, search/add); - Internal view/filter/curate; - A read-only public front-shop that can be injected in institutional website through an API. Following the community review of the proposed MVP, a clear boundary will be set for the OSPO-RADAR project (2025-2027) and all other use cases, features and tools will be deferred to the backlog as issues. 5.1/ Account creation, login and management 5.1.1/ Account creation #W1 Account creation: General description of the feature’s workflow How new users request access, with validation by an administrator and retrieval of an API token from Software Heritage. This sets up the user profile and organization link. Main actor: OSPO manager / dashboard admin Needs or pain-points to be tackled OSPO-RADAR capabilities Adding a new OSPO to the dashboard is a process that requires manual validation to confirm the participants' identity and train them on the tool. ● Create a user (admin) account associated with a collection - manually validated by SWH team The OSPO must then be autonomous in managing user accounts linked to its organization. ● Create accounts for other institutional users (contributors) - validated by user (admin) We should be able to differentiate between two different user levels in an OSPO: a contributor level to manage only the collection & metadata, and a manager level who can also make changes to the organization's settings (description, users, etc.). ● Organization management (name, logo, description) restricted to Admin/Manager It is important to minimize the amount of personal data collected during account creation. ● Data minimization; retention policy for denied/expired requests; visibility into stored personal data 17 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Whenever possible, existing organization/user accounts from Software Heritage's centralized authentication should be reused. ● If possible, use same account that is used in the archive.softwareheritage.org User story As a prospective OSPO collaborator, I want to request an account on the OSPO-RADAR Dashboard, so that I can access my institution’s collection and contribute entries. Associated use case A prospective user opens the OSPO-RADAR Dashboard and submits an account request. The Dashboard records the request and immediately notifies the designated Admin for that organization. A validation phase follows: ● If the Admin rejects the request: the Admin records the decision in the Dashboard. The Dashboard closes the request and sends a notification to the user informing them that access was not granted. ● If the Admin accepts the request: the Dashboard creates the user record in the OSPO-RADAR database (and, if needed, creates or links the organization record). The Dashboard then contacts Software Heritage (SWH) to obtain an organization-scoped API token. Once the token is returned, it is stored in the OSPO-RADAR database. Finally, the Dashboard notifies the user that their account has been approved and provides next-step instructions for signing in. End state: Either the request is closed as rejected (user informed), or the user is active, linked to the correct organization, and the SWH API token is stored for later authenticated operations. Access roles Role Description (+Personas) Create collection & Bulk addition Update & Validate entries in collection View collection Admin - manager Full control: can create sub-collections, bulk add, update/validate entries, and view. Yes Yes Yes Curator - contributor Can enrich and maintain collections: update/validate entries and view. No Yes Yes Researcher Read-only access to consult collections. No No Yes Large public General audience with view-only access. No No Yes 18 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Workflow overview: #W1 Account creation for user (contributor) 5.1.2/ Login to Dashboard #W2 General description of the feature’s workflow Standard authentication with error handling and password reset. Nothing fancy, but secure and consistent with institutional practices. Ensure that different institution profiles can be accessed by role based levels of access. Main actor: User (contributor) / User (admin) Needs or pain-points to be tackled OSPO-RADAR capabilities The authentication mechanism must be secure: requiring complex passwords and recommending two-factor authentication. ● Enforce password policy; optional TOTP/WebAuthn 2FA via Keycloak It should be easy to change a password without needing to contact a manager or Software Heritage. ● Self-service password change & forgot-password flow handled by Keycloak 19 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. User story ● As the OSPO-RADAR operator, I need to login in as an administrator of my collection. Associated use case 1. authenticate myself on the site to securely manage my data and my organization's data. I also need to be able to manage other users linked to my organization. a. Initial account creation mechanism for the OSPO, this account must be linked to a global organization account on the other SWH website to be able to use our APIs b. Login/forgot password workflows c. Profil management. d. Access Control Lists (ACL) depending on user roles (admin, OSPO operator and OSPO collaborator) e. Create Retrieve Update Delete (CRUD) users. f. Organization management (name, logo, description, etc.). Community review for workflows: #W1 & #W2 Account management (creation, login and management) Name / Anonymous Comment +Upvotes Feedback summary and response: 20 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Workflow overview: #W2 Account login 21 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. 5.2/ Populate the software source code dashboard 5.2.1/ Batch import #W3 General description of the feature’s workflow Allows an OSPO manager to submit a list of software projects/urls to populate the collection. The workflow calls “Bulk Save Request6” and annotates the origin with the institution information. OSPOs are already using other tools to track projects / software, they want to reuse available data instead of having to refill forms Main actor: Admin / OSPO Manager Needs or pain-points to be tackled OSPO-RADAR capabilities The initial import process needs to be simple and not rely on a specific tool. A simple list of software URLs (link to the project on a forge, a package manager, etc.) should work. ● Import inputs: paste a newline-separated list of URLs; optional CSV upload (single column or header url); API endpoint for programmatic imports. URL validation supports known forges and package registries. ● Bonus: Add metadata of sub-collections and other tags for filtering. A detailed report should be available after the import to know what has been added to the collecion, archived, etc. ● Immediately: Import report shown in-app - per-row status (Added to collection, Already in collection) ● After Bulk save request ingested: Import report with: ○ URL, ○ Save request status (if Failed + reason), ○ Archived (SWHID) - heuristic of DIR swhid of root directory in master branch. User story As an OSPO, I want to import a list of software to my collection and view a status report of this import, so that I can quickly populate the collection from existing sources, ensure each origin is archived and assigned an SWHID, and act on a clear per-item outcome without manual re-entry. Associated use case 1. The Logged-in User submits a list of software origins to the OR Dashboard. 2. The OR Dashboard validates the payload (basic URL checks, duplicates) and enqueues a batch “Save Code Now” job with the Task Scheduler. 3. The Task Scheduler processes the job origin by origin: 3.1) Calls SWH to archive the origin (or retrieve existing archival state). 3.2) Receives metadata/SWHIDs from SWH. 3.3) Sends progress updates back to the OR Dashboard, which updates the job status and adds/updates items in the User’s organization collection (including institutional annotations). 4. When all origins are processed, the OR Dashboard finalizes the job and prepares a status report (successes, already archived, failures with reasons, SWHIDs where applicable). 5. The OR Dashboard notifies the User that the import has completed and provides access to the report (view/download). 6 https://archive.softwareheritage.org/api/1/origin/save/bulk/doc/ 22 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Workflow overview: #W3 Batch import 5.2.2/ Signal software #W4 General description of the feature’s workflow For one-off additions. A researcher provides a URL, a curator is notified and validates it. If the project isn’t there yet, a Save Code Now request is triggered before adding it to the collection. Have software contributions automatically included in institutionally validated exports that can be reused in CVs, annual activity reports, and grant applications. Main actor: Researcher / Scientist / Research manager Needs or pain-points to be tackled OSPO-RADAR capabilities Avoid friction due to account creation, login / password etc. and at the same time the form to signal software must not be easily discoverable outside the institution. ● Provide a simple form for the researcher to submit a URL and indicate whether the institution: ○ created or contributed to the software ○ used or depends on the software ● Without login: Ensure institutional affiliation of the submitter without forcing account creation (lightweight email check). OSPO staff need simple curation tools/workflows to triage submissions before anything appears on the public “front-shop” view. ● Provide simple tools/workflows to manage the list of signaled software. A curation has to be done before adding the software to the front-shop view. 23 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. If a project isn’t archived, a simple mechanism in the workflow should make it easy to do. ● Trigger a save code now if needed. Researchers add mentions of software in articles that are deposited in scholarly repositories (e.g HAL) and to ease the additions of these inputs in an institutional collection, a notification meachnism to the OSPO, could facilitate the input. Optional: COAR Notify from other infrastructures to include software origins to a collection (relates to the workflow of identifying software in articles) User story As a researcher, I want my software contributions to appear in the collection. Reason: Researchers want their software outputs to be visible and recognized alongside publications and datasets, without having to manually compile scattered records. Institutionally curated exports ensure accuracy, persistence, and proper citation. Associated use case 1. (optional) Researcher includes a codemeta.json file in their repository. 2. Researcher provides the url and institutional email in to simple “signal software” form. 3. An email is sent to the Researcher email account for validation 4. If validated, email is sent to OSPO to accept the additional request 5. OSPO validates the request to integrate into the institutional dashboard 6. Origin is archived in Software Heritage → generates an SWHID. 7. The Dashboard ingests metadata and associates the project with the researcher’s ORCID and institutional affiliation. 8. OSPO manager validates the metadata and adds the record to the institutional collection. Metadata fields covered: ● identifier (SWHID, DOI) ● author (with ORCID) ● affiliation (institution) ● name (software title) ● version ● dateCreated, dateModified, datePublished ● relatedPublication ● funding, funder ● license 24 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Workflow overview: #W4 Signal software source code asset 5.2.3/ Search and add software #W5 General description of the feature’s workflow For one-off additions. A curator searches a software by its name or url in Software Heritage’s database. If the project isn’t archived, the Curator triggers Save Code Now and then adds it to the collection. Main actor: Curator Needs or pain-points to be tackled OSPO-RADAR capabilities Provide access to Software Heritage’s search engine. ● Built-in SWH search integration (name or URL query) with results returned in-app. ● One-click “Save Code Now + Add to collection” action when no archival record is found. Provide a simple interface to query the search engine and identify matching projects, to enable on-off additions. ● “Add to collection” action on any matched result (with collection/sub-collection picker). ● Duplicate check with inline warning if the item already exists in the org’s collection. User story As a Curator, I want the piece of software I’ve identified to appear in the collection after searching by name or URL, so that I can quickly curate the catalog without manual re-entry and ensure an SWHID exists. 25 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Associated use case 1. The user selects a set of projects (all institutional projects or a filtered subset). 2. For each project, Dashboard checks if the origin is archived in Software Heritage. ○ If yes, retrieve the Directory SWHID. ○ If not, trigger “Save Code Now” automatically, then retrieve the new SWHID. 3. Compile results into a structured CSV with: ○ Component/Project name ○ Repository URL ○ Directory SWHID 4. Provide the CSV as a downloadable artifact or via API. Workflow overview: #W9 Export a list of assets with most recent dir SWHID 32 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Community review for workflows: #W6, #W7, #W8 & W9: internal view and dashboard functionalities Name / Anonymous Comment +upvoters Feedback summary and response: 5.4/ Public view and search capabilities 5.4.1/ Front-shop view #W10 General description of the feature’s workflow Beyond the internal dashboard, institutions often need a public-facing view of their software outputs. The idea is to expose a “front-shop” that displays selected projects from the dashboard, with metadata from intrinsic sources or from institutional annotations. This is a read-only public portal that surfaces a curated subset of records. It includes: ● Portal homepage (entry point for all users). ● Institution-specific OSPO pages. ● Software-specific modals. The public site is fed directly from the dashboard (source of truth). Institutions control visibility through publish/unpublish, feature/unfeature toggles. The list of published entries can be displayed on any institutional website, using the dashboard API endpoint. Main actor: All (public visitors, researchers, funders, OSPO staff) Needs or pain-points to be tackled OSPO-RADAR capabilities Institutions want to showcase software outputs publicly without duplicating data. The front-shop portal is automatically fed from the curated internal collection; OSPO staff select which records are public. No re-entry required. Need to control publication while keeping workflows lightweight. Publish/unpublish and feature/unfeature toggles in the dashboard, with instant sync to the public site. Make it easier for machines to navigate the pages by implementing Signposting patterns Public pages include Signposting HTTP link headers and structured links (to SWHID, DOI, 33 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. related publications), enabling automated harvesting and interoperability. Institutions need to know impact and reach of their portfolio. Built-in basic analytics: counts of page views, downloads, and outbound clicks, aggregated per project and per institution. User story ● As an OSPO staff member, I can mark projects as public/featured and provide short descriptions so that visitors can discover our key software. ● As a public visitor, I can browse/search the portal and open a software page to view core metadata and links. ● As a researcher, I can find the project’s repository, archival identifier, license, and citation information from a single page. Associated use case 1. Browse/search the portal (Public visitor) a. Public visitor accesses the portal homepage. b. Uses search box or filters (name, tags, domain, license) to browse. c. Featured projects appear highlighted on the homepage/OSPO page. 2. View a software entry a. Visitor selects an entry→ public software entry opens. b. Page displays: ■ Title / description (from dashboard annotation). ■ Repository URL (link to forge). ■ SWHID (stable archival link) + iframe? ■ License/s (SPDX) - if available (warning if missing) ■ Citation info (e.g., BibTeX/CSL). ■ Related outputs (papers, datasets). Workflow overview: #W10 Showcase OSPO’s collection and subcollections 34 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Community review for workflows: #W10 Front-shop view and API usage of collection list Name / Anonymous Comment +upvoters Feedback summary and response: 6/ Non-functional requirements to address 6.1/ Accessibility To allow the greatest number of people to access the site's content, we aim for an AA conformity level with The Web Content Accessibility Guidelines. 6.2/ Performance / compatibility We will depend on external APIs (search, deposit, etc.) so we’ll need to find ways of displaying loading states. The public website must: ● work with javascript disabled ● work on multiple screen sizes (responsive design) ● work on the latest three versions of major browsers The dashboard itself will require javascript and at least a tablet-sized screen to work properly. 6.3/ Legal requirements The OSPO-RADAR Dashboard will comply with EU and French law and transparent policies for cookies, privacy, and terms: ● GDPR (EU): collect only necessary data, minimal cookies (consent only if non-essential). ● Provide Privacy Notice, Terms of Use, Content Policy, and DPO contact. ● Host in France/EU; document data flows and log retention. 6.4/ Sustainability & maintainability The OSPO-RADAR Dashboard will be developed as open source project, under a permissive license and, and can be self-hosted, forked, and extended without lock-in. We will: 35 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ● License & governance: permissive license (e.g., MIT/Apache-2.0), CONTRIBUTING.md, CODE_OF_CONDUCT.md, lightweight maintainer model, issue templates, release notes. ● Architecture: modular services with clear boundaries; stable, versioned public APIs (SemVer); dependency minimization; replaceable adapters for SWH/ID providers. ● Data portability: full export/import (JSON/CSV), documented schemas, no hidden state; migration scripts between versions. ● Quality & tests: CI/CD with unit/integration/e2e tests; code coverage targets; static analysis and linting. ● Docs & training: docs available, quick-start recipes, upgrade guides, and periodic refresh of examples. ● Community: public tickets of features for MVP and next versions, discussions, and periodic community calls; encourage upstreaming of institutional extensions. 7/ What’s next? Interoperability & reusability of the Dashboard. OSPO-RADAR’s users and partners emphasize different starting points and levels of ambition. Taken together, these inputs point to a modular product that is easy to plug in, easy to ignore if out-of-scope, and easy to reuse elsewhere. Key signals from partners ● Some are procuring dashboards/mining systems and want the SWHAD to expose a clean API their tools can call—without forcing a platform switch. ● Others already track software in the Research Software Directory (RSD) and need lightweight connectors rather than overlapping features. ● Several use Dataverse and prefer bi-directional sync (metadata + links, ideally files where appropriate). ● Many want to move beyond static checklists toward interactive, guided workflows (while acknowledging that SWH isn’t yet embedded in current practices). ● A subset note that managing researchers’ software isn’t their mandate; for them, the SWHAD should stay low-touch, primarily signposting to external services and repositories. Design implication: Favor simple UX and a minimal, well-chosen feature set over breadth. Make integration the default path to value. 7.1 / integration with existing tools “Finally, OSPO-RADAR must be modular, interoperable, and reusable, with components that are openly documented and capable of integrating seamlessly with repositories, registries, forges, and publishing platforms. In this way, OSPO-RADAR can become the connective tissue of the scholarly ecosystem, turning lessons learned into durable infrastructure for research software management.” (see §3.2) Evaluate integrations ● Software Heritage (SWH) ○ Evaluate usage of Deposit API or creating archival records and obtaining SWHIDs and the existing deposit partners needs. 36 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ○ Docs: https://docs.softwareheritage.org/user/deposit/index.html ● Scholarly Infrastructures as a source of input and a OSPO-RADAR Dashboard consumer (HAL, Zenodo, Research Software Directory (RSD), and others ○ One-way (read) to surface existing software and metadata. ○ Optional write-back: push enriched links (e.g., SWHIDs, citations) when enabled. ○ Bi-directional metadata sync (datasets ↔ software records, related identifiers). ○ Map persistent IDs (DOI, SWHID, ORCID, ROR) and provenance fields. Interaction pattern ● API-first: every feature available via REST/GraphQL endpoints. ● Connectors over code forks: adapters that translate between schemas (CodeMeta, RSD JSON, Dataverse metadata blocks). ● Progressive enhancement: start with read-only discovery. From checklists to guided flows ● Replace static “to-do”s with step-by-step wizards (e.g., “Archive → Reference → Describe → Cite”). ● Offer contextual tips and auto-fill from existing records (RSD/Dataverse) to reduce user effort. ● Keep a no-ops path for orgs that only want pointers to external services. Outcomes ● Orgs with existing stacks gain value via APIs and connectors. ● Orgs without stacks can still use a simple, focused OSPO-RADAR Dashboard without feature bloat. ● Researchers benefit from fewer steps, better links, and durable identifiers across the ecosystem. 7.2/ Functionalities and capabilities to keep in mind after MVP ● Provenance & traceability ○ Capture event logs (who/when: archive, curate, edit, approve). ○ Store verbatim codemeta.json + normalized model; show diffs across versions/snapshots. ● Identifier ecosystem ○ Intrinsic: SWHIDs (dir/rev/snp/origin). ○ Extrinsic: DOIs (Zenodo), ORCID (people), ROR (orgs), HAL-ids, RRIDs. ○ Deduplication rules across identifiers; merge/split records. ● Interoperability & connectors ○ Harvesters for GitHub/GitLab/self-hosted forges, HAL, Zenodo, Dataverse, InvenioRDM, CRIS. ○ Webhooks & scheduled jobs; “Save Code Now” integration at import time. ○ Import profiles: CodeMeta v3, CITATION.cff; export profiles: CodeMeta v3, BibLaTeX, CSV, JSON. ● Metadata quality & policy ○ Validations (SPDX license, dates, ORCID format, ROR match). ○ Required vs optional fields 37 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ○ Quality signals: README present, license present, CI badge, test coverage link, container/Env spec. ● Software quality & reusability ○ Software hygiene ○ Dependency management ○ Containerization ● Curation workflows ○ Queue with statuses: proposed → needs fix → under review → approved → published. ○ Field-level locks after approval; change requests; audit trail. Bulk actions (approve/assign curator/retire). ● Search, filters, and analytics ○ Filters: department (ROR), language, license, last activity, funding, project, topic. ○ Saved views; scheduled exports. ○ Indicators: active/inactive, missing metadata, risky licenses, “no release” flag. ○ Institutional KPIs: growth, reuse (downstream deps), citation coverage. ● Public “Front-Shop” ○ Theming (logo/colors), featured projects, SEO (sitemaps, schema.org). ○ Soft publication rules (auto-publish if policy met; otherwise hold for OSPO). ● Reporting & exports ○ One-click institutional report (PDF/CSV) + API. ○ Researcher/Group exports for CV/annual review (CSV, PDF, BibLaTeX). ○ Benchmark pack (aggregate, anonymized) — optional, opt-in. ● Roles & permissions ○ Roles: Viewer, Contributor, Curator, OSPO Manager, Admin. ○ Scopes by org unit (department/lab); SSO (Keycloak/OIDC). ○ Consent flags for public display; PII minimization. ● Ops & deployment ○ SaaS & on-prem profiles; staging/production; backups & retention policies. ○ Observability (metrics, logs, traces); rate limiting; job retries. ○ Accessibility (WCAG 2.1), i18n for UI + multilingual metadata. 8/ The road ahead: a sustainable service model The project delivers the OSPO-RADAR Dashboard as its primary outcome: a standards-based platform that enables OSPOs to manage, archive, and showcase research software. The dashboard can serve as the foundation for a broader suite of institutional products, designed to amplify the visibility and strategic use of research software in academia. A dedicated Open Science helpdesk will support the product adoption and effective use of the dashboard. Once the dashboard is in place, another potential emerges with the combination of regular institutional reporting. These report, drawing on the dashboard’s data, the Software Heritage archive and the a massive data analysis of the archive, could transform raw information into actionable insights. They enable institutions to: 38 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. ● Track software outputs across departments and research groups; ● Assess compliance with Open Science policies and Open Source guidelines; ● Identify flagship projects, emerging practices, and sustainability gaps; ● Demonstrate institutional contributions to funders and policymakers. As Roberto Di Cosmo has often emphasized, university OSPOs are the local execution engines of open-source and open-science policy: they sit at the interface between researchers and institutional functions (tech transfer, legal, research office, libraries/open science), track national and local policy evolution, and build a coherent, institution-wide view of software production. In practical terms, they coach and equip research teams across the full lifecycle: Archive & Reference (deposit in Software Heritage and, where relevant, HAL; assign stable SWHIDs), Describe & Cite (maintain codemeta.json; generate publisher-ready software citations linked to research outputs and evaluation), Compliance & License (default-open decision flow, compatibility checks, and legal support), and Development & Dissemination (good forge hygiene, CI/testing, packaging, onboarding, and community practices) (Di Cosmo at UGA). OSPO-RADAR is designed as the operational gateway for these tasks, giving OSPOs the workflows, metadata, and dashboards needed to make policy actionable at scale. The pilot report on French academic institutions preserved in Software Heritage (Di Cosmo, July 2025) demonstrates the feasibility of such a product. Using the institutional analysis pipeline, Software Heritage was able to provide: ● Key numbers (projects, contributions, active developers, activity timespan); ● Distributions and trends (last activity, first contributions, project lifetimes); ● Top repositories by contributions, stars, and longevity; ● Programming languages and domains; ● Citation practices (CodeMeta and CITATION.cff adoption). The OSPO-RADAR dashboard, complemented by institutional reports, establishes a product ecosystem that extends beyond the project’s two-year timeline. Reports can be offered as: ● Membership benefits for OSPO-RADAR institutional partners; ● Services integrated into national infrastructures (e.g., HAL, EOSC); ● Benchmarks for international collaborations (SciCodes, ReSA, RDA). For OSPOs, institutional-level reports represent far more than static analyses: they function as strategic tools that allow institutions to monitor software production across departments and labs, identify flagship projects and emerging communities, benchmark practices such as metadata adoption and project sustainability, demonstrate impact to funders and policy bodies, and support compliance with Open Science mandates, including archiving and citation readiness. By packaging the dashboard’s data into exportable reports, OSPO-RADAR extends its role beyond day-to-day management, providing OSPOs with a means to communicate effectively with leadership, funders, and external stakeholders. In this way, OSPO-RADAR moves from a one-off project deliverable to a sustainable service model, positioning Software Heritage as both an archival resource and a provider of institutional intelligence for research software and beyond. 39 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. References Description/Link https://www.zotero.org/groups/5682994/faircoreeosc_d./library Alliez, P., Cosmo, R. D., Guedj, B., Girault, A., Hacid, M.-S., Legrand, A., & Rougier, N. (2020). Attributing and Referencing (Research) Software: Best Practices and Outlook From Inria. Computing in Science & Engineering, 22(1), 39–52. https://doi.org/10.1109/MCSE.2019.2949413 Azzouz-Thuderoz, M., Del Cano, L., Castro, L. J., Dumiszewski, Ł., Garijo, D., Gonzalez Lopez, J. B., Gruenpeter, M., Schubotz, M., & Wolski, M. (2023). SIRS Gap Analysis Report. https://zenodo.org/records/10376006 Bilder, G., Lin, J., & Neylon, C. (2020). The Principles of Open Scholarly Infrastructure. https://doi.org/10.24343/C34W2H Carlin, D., Rainer, A., & Wilson, D. (2023). Where is all the research software? An analysis of software in UK academic repositories. PeerJ Computer Science, 9, e1546. https://doi.org/10.7717/peerj-cs.1546 Declaration on Research Assessment. (2013). San Francisco Declaration on Research Assessment. DORA. https://sfdora.org/read/ Di Cosmo, R. (2025, September 8). Academic Software Landscape overview through the Software Heritage looking glass. Access to research software: Opportunities and challenges, OECD. Zenodo. https://zenodo.org/doi/10.5281/zenodo.17075792 Di Cosmo, R., Gruenpeter, M., & Zacchiroli, S. (2018). Identifiers for Digital Objects: The Case of Software Source Code Preservation. 1–9. https://doi.org/10.17605/OSF.IO/KDE56 Di Cosmo, R. (2023, March). SWHID specification kickoff meeting. SWHID kick-off meeting, Online Conference. https://hal.science/hal-04121507 Dillon, C. (2025). Academic OSPOs, What are they & Why we need them! 5ème séminaire de l’écosystème Recherche Data Gouv, Lille. https://rdg-seminaire5.sciencesconf.org/program/details Directorate-General for Research and Innovation (European Commission) & EOSC Executive Board. (2022). Strategic Research and Innovation Agenda (SRIA) of the European Open Science Cloud (EOSC). Publications Office of the European Union. https://data.europa.eu/doi/10.2777/935288 Eglen, S., & Nüst, D. (2019). CODECHECK: An open-science initiative to facilitate sharing of computer programs and results presented in scientific publications. Septentrio Conference Series, 1. https://doi.org/10.7557/5.4910 EOSC Executive Board & EOSC Secretariat. (2020). Scholarly infrastructures for research software. Report from the EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS. European Commission. Directorate General for Research and Innovation. https://data.europa.eu/doi/10.2777/28598 Garijo, D., Arroyo, M., Gonzalez, E., Treude, C., & Tarocco, N. (2024). Bidirectional Paper-Repository Tracing in Software Engineering. Proceedings of the 21st International Conference on Mining Software Repositories, 642–646. https://doi.org/10.1145/3643991.3644876 Granger, S., Gruenpeter, M., Monteil, A., Nivault, E., & Sadowska, J. (2022, October 26). Modérer un dépôt logiciel dans HAL: Dépôt source et dépôt SWHID. Inria ; CCSD ; Software Heritage. https://inria.hal.science/hal-01876705 Gruenpeter, M., Sadowska, J., Nivault, E., & Monteil, A. (2022). Create software deposit in HAL. Inria ; CCSD ; Software Heritage. https://inria.hal.science/hal-01872189 Gruenpeter, M., Granger, S., Monteil, A., Chue Hong, N., Breitmoser, E., Antonioletti, M., Garijo, D., González Guardia, E., Gonzalez Beltran, A., Goble, C., Soiland-Reyes, S., Juty, N., & Mejias, G. (2023). D4.4—Guidelines for recommended metadata standard for research software within EOSC. https://doi.org/10.5281/ZENODO.8199104 40 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Guerry, B. (2025, September 24). Renforcer la visibilité et l’interconnexion entre les OSPOs du secteur public. Inauguration de l’Open Source Program Office de l’Université Grenoble Alpes, Saint Martin d’Hères. https://ospo-uga.sciencesconf.org/data/pages/bg_dinum_uga_2025_v1.0.pdf Katz, D. S., & Barker, M. (2023). The Research Software Alliance (ReSA). Upstream. https://doi.org/10.54900/zwm7q-vet94 Le Berre, D., Jeannas, J.-Y., Cosmo, R. D., & Pellegrini, F. (2023). Higher Education and Research Forges in France—Definition, uses, limitations encountered and needs analysis [Report]. Comité pour la science ouverte. https://doi.org/10.52949/37 Lopez, M. (2021, February 7). Open Source Program Offices (OSPO) and their role in OSS ecosystems. How having an OSPO might help to open source software ecosystem sustainability. Fosdem 2021, Online Conference. https://fosdem.org/2021/schedule/event/community_devroom_ospo_oss_ecosystems/some of them already have tooling, some not: different strategies Malone, J., Brown, A., Lister, A. L., Ison, J., Hull, D., Parkinson, H., & Stevens, R. (2014). The Software Ontology (SWO): A resource for reproducibility in biomedical data analysis, curation and digital preservation. Journal of Biomedical Semantics, 5(1), 25. https://doi.org/10.1186/2041-1480-5-25 Mayernik, M. S. (2016). Research data and metadata curation as institutional issues. Journal of the Association for Information Science and Technology, 67(4), 973–993. https://doi.org/10.1002/asi.23425 Rios, F. (2018). Incorporating Software Curation into Research Data Management Services: Lessons Learned. International Journal of Digital Curation, 13(1), Article 1. https://doi.org/10.2218/ijdc.v13i1.608 Task Force on Best Practices for Software Registries, Monteil, A., Gonzalez-Beltran, A., Ioannidis, A., Allen, A., Lee, A., Bandrowski, A., Wilson, B. E., Mecum, B., Du, C. F., Robinson, C., Garijo, D., Katz, D. S., Long, D., Milliken, G., Ménager, H., Hausman, J., Spaaks, J. H., Fenlon, K., … Morrell, T. (2020). Nine Best Practices for Research Software Registries and Repositories: A Concise Guide (arXiv:2012.13117). arXiv. http://arxiv.org/abs/2012.13117 Treloar, A., & Wilkinson, R. (2008). Rethinking Metadata Creation and Management in a Data-Driven Research World. 2008 IEEE Fourth International Conference on EScience, 782–789. https://doi.org/10.1109/eScience.2008.41 Université Paris Saclay. (2019, November 29). Introduction to data management plans. Université Paris-Saclay. http://www.universite-paris-saclay.fr/en/recherche/science-ouverte/les-donnees-de-la-recher che/introduction-data-management-plans van de Sandt, S., Nielsen, L. H., Ioannidis, A., Muench, A., Henneken, E., Accomazzi, A., Bigarella, C., Lopez, J. B. G., & Dallmeier-Tiessen, S. (2019). Practice meets Principle: Tracking Software and Data Citations to Zenodo DOIs (Version 1). arXiv. https://doi.org/10.48550/ARXIV.1911.00295 Young, J., Barba, L. A., Choudhury, S., Flanagan, C., Lippert, D., & Littauer, R. (2024). A Definition of an Academic OSPO. https://doi.org/10.5281/ZENODO.13910683 41 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Actor - Who? Action - What? Reason - Why? Scenario metadata Stakeholder that does the action Action needed The goal of the action, why do this actor needs this action As a [actor] I can [action] so that [reason] developmentStatu s Developers Description of development status, e.g. Active, inactive, suspended. See repostatus.org Inform the public if a software is live or outdated. Important information to decide, if I - as a researcher - want to use or build on this software for my research As a user, I want to know, if I can use this software for my research. As a developer, I want to know, if anyone is actively maintaining this software embargoDate Authors when publishing software via any sort of repository? Date when the embargo is over Some software might be restricted for a period of time. The users need to know when this period of restriction has ended. OperatingSystem User/service Reinstall / reuse The operating system should be described so the user or service can install or run the tool An IT user wanting to compare performances of given OS’s used in the implementation of some kind of software SoftwareRequirem ents user/other software/depende ncies Install before reuse, Or combine with other tools To ensure all the pre-requisites for the software are available before re-use To inform about dependencies of the Resource A user wanting to be sure that the software is not using a dependency which ha can not use in his own environment (incompatibilities) 48 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Appendix D: Review grid of the RSAC components specifications Table 5: Reviewing grid explanation Section Subsection Suggested usage The question to answer Overview Text from proposal Objectives Archive Archive Reference Reference Describe Describe Cite Cite Out of Scope Identify elements in the proposal that are out of scope for this particular subcomponent And identify other limitations due to resources or feasibility What are the limitations of the subcomponent in achieving the 4 pillar objectivesarchive, reference, describe and cite? Requirements User stories As a __ I can ___ so that ___ What is the user’s story? Why does this user want to achieve a particular goal? User requirements Identifying the needs, goals, and tasks directly from the SIRS report What is the user’s need to achieve the goal and have a happy ending? Functional requirements Identification of application requirements, server, database, etc.. What does the system / infrastructure can provide as new or improved functionalities to obtain the happy ending? Non-functional requirements What does the system / infrastructure can provide as non technical additions to obtain the happy ending? Specifications Architectural design Sequence diagram What components are related and what is the workflow to obtain the objectives? Functional specifications A breakdown of the implementation function: capabilities, appearance, and interactions with users in detail for software developers (equivalent to a issue / ticket / task that can be resolved with one PR / diff) What will the subcomponent team implement as part of the infrastructure features/functionalities to answer the identified requirements? 49 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188. Service specifications How do I test that the service is working properly? Operational specifications Integration with EOSC Core components List the FC4E CC with links to each specs and identify the points of integration / interoperability How does this subcomponent interact with each one of the FC4E Core Components? External references implementation infrastructure Relevant documentation on infrastructure website Where can I get more information about the implementation’s current state? Software Heritage Relevant documentation on SWH Where can I get more information about the SWH archive's current state? 50 | OSPO-RADAR has received funding from the Sloan Foundation under Grant Agreement no. 2025-25188.