Work Package

WP1, Project management, specifications, planning, and testing

Authors

Morane Gruenpeter, Renaud Boyer, Sabrina Granger

Reviewer(s)

Clare Dillon, Christopher Erdman, Bastien Guerry, Daniel S. Katz, Violaine Louvet, Micha Moskovic ADD COMMUNITY REVIEWERS

Date

2025-09-30

Version

V1.0 FOR COMMUNITY REVIEW

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

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 development^[1]”

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.

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

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)

Christine

Academic library  director

• Provide reliable indicators to the university’s governance, without reinventing the wheel
• Provide support to develop Data/Software management plans (DMP / SMP)
• Coordinate the metadata curation of the institutional outputs
• Identify the different types of stakeholders within the institution
• Transitioning from Research Data Management to Research Software Support
• Capacity building

• Lack of developer capacity
• The library is not always identified as a key partner when it comes to software. OSPOs come the industry and universities are complex places with unique structures, systems and cultures. Libraries do not exist in corporations.

Leo

Infrastructure technical manager

• Improve the infrastructure code base with the help of his team
• Ensure the consistency of the developments with the infrastructure roadmap
• Plan and allocate resources to tasks and projects

• Complicated adoption of SWHID, which isn't yet recognized in the scholarly ecosystem
• Users of Leo's infrastructure don't ask for SWHIDs
• Software citation seems like high effort with low return

Jitin

Researcher

• Track all his contributions
• Report back for different instances
• Showcase the work done, including, as a software contributor in different types of documents: CV, report, grant request, etc.

• Processes are time consuming - lack of automation
• Lack of support for implementing best practices (archiving, describing, etc.)
• Stakeholders may have conflicting expectations about reported entries
• Contributions made outside of the formal job scope go unrecognized and uncompensated
• Difficult to monitor the impact of the contributions at an individual level

Mostafa

Lead of a research unit

• Identify all the pieces of software produced by the research unit
• Provide a comprehensive list of the software to the local governance as well as to national and international evaluation committees
• Coordinate and validate the lists produced by the researchers
• Promote good practices in terms of software authorship, use of the institutional forges

• Lack of consistency in descriptions (deduplications, inconsistent data quality)
• The high volume of last-minute deposits in the institutional repository prevents us from curating them correctly due to time constraints
• Too much information exchanged in spreadsheets
• Evaluation committees have varying expectations for the required data format and content
• The contribution status for non-authoring roles (e.g., testers or maintainers) is unclear, as there are no clear expectations on what to report. In addition, the roles of a single contributor can be plural, with contributions spanning variable time extents
• Many colleagues don’t consider themselves as developers. So they don’t list their software production in the reports.

Scholarly repositories,

Institutional repositories

Store, manage, and provide access to datasets, enabling their sharing, preservation, and reuse.

Software is not always included as a type of research output within a repository: deposit is not possible^[t]

Coverage issue in terms of archival: “the vast majority of repositories do not feed the universal archive [SWH] yet” (Azzouz-Thuderoz et al., 2023)

Difficult to identify and track the software pieces’ evolution

Descriptions may not provide information that may be relevant for an OSPO, as the extraction of intrinsic metadata, which is found in the source code itself, is not supported.

Intrinsic identifiers are not supported by most of the infrastructures

Aggregators

Integrate, harmonize, and offer access to information originating from different sources, which should otherwise be accessed independently.

Enrich the aggregated content with information that was not available at the sources.

Forges

Facilitate collaborative work on a software project. A forge contains tools like a versioned source code repository, discussion forums, an automated testing environment and so on. (French Ministry of Higher Education and Research.)

Coverage: even if an institutional forge is implemented, end-users may collaborate in external instances.

Archival: forges are collaborative tools, but are not designed for long-term access.

Publishing platforms

Infrastructures associated with journals or publishing companies that are used to deposit scholarly publications

“Only a few publishers have already explicitly integrated this recommendation [the software associated with the publication should be equipped with proper metadata].”

Examples of successful implementations: Dagstuhl, IPOL, eLife, JTCAM, and the journals hosted on the Episcience platform

name

Human-readable title of the software

Institutional inventory of software assets

schema.org name

description

A description of the item.

A research output abstract.

schema.org description

author / contributor

People or organizations responsible for the software

Linking to ORCID and ROR for attribution. Adding author role.

ORCID, ROR

version

Software version or release

Tracking evolution of institutional outputs

Semantic Versioning

license

Applicable license(s)

Monitoring license compatibility and compliance

SPDX License IDs

programmingLanguage

Primary implementation languages

Reporting language trends in institutional software

schema.org mapping

relatedPublication

Publications describing or citing the software

Linking code to Scholarly infrastructure (e.g HAL) bibliographic records

DOI, HAL ID

funding

Funding sources that supported development

Tracking grants and sponsor contributions

Grant DOIs, funder ROR IDs

readme / documentation (proposed)

Documentation sources (README, build instructions, manuals)

Ensuring reproducibility and usability in reporting

To be added via CodeMeta PR

#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

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.

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^[u]

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

#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

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.

1. 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
2. Login/forgot password workflows
3. Profil management.
4. Access Control Lists (ACL) depending on user roles (admin, OSPO operator and OSPO collaborator)
5. Create Retrieve Update Delete (CRUD) users.
6. Organization management (name, logo, description, etc.).

Name / Anonymous

Comment

+Upvotes

AAI authentication (EduGain

Feedback summary and response:

#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 Request^[6]” 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^[v] 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 collection, 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^[w]) 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).

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^[x]).

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.

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

#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.

Associated use case

1. Curator opens Search & Add.
2. Enters name or URL and runs the search against SWH.
3. Dashboard lists results with origin URL, SWHID (if any), last snapshot date.
   3a) If a correct match exists → Curator clicks Add to collection → selects target collection/sub-collection → item added (with institutional annotation).
   3b) If no archival record exists → Curator clicks Save Code Now + Add → the system archives the origin, then adds it to the collection.
4. If the item is already in the collection, the UI shows a duplicate notice and prevents double-addition.

Name / Anonymous

Comment

+upvoters

Feedback summary and response:

#W6 General description of the feature’s workflow

Once the collection is populated, users (OSPO Manager / Curator) need a simple list view of software projects associated with their institution, with basic filters (dates, research teams, licenses, programming languages). The goal is clarity and fast retrieval—not advanced analytics—while laying the groundwork for later reporting.

Main actor: OSPO Manager / Contributor (Curator)

Needs or pain-points to be tackled

OSPO-RADAR capabilities

No reliable baseline inventory of software produced vs. used across a wide, multi-unit community; data scattered in many tools; hard to start a landscape analysis.

“Since we are composed of many of the universities in XXX we are an interesting catalyst and example (for the XXX Research Council). Some initial work has been done with XXX and we expect some analysis in July but also via the service we procure in the Fall.”

“While we are just starting out, XXX, and our organisation (XXX), have particular expertise when it comes to research software but we are starting with a landscape analysis of software produced and used in our community which is [country]-wide in the Life Sciences. The challenge is having a baseline to start so that we can build on with guidance and overall monitoring.”

• Internal dashboard list view of all projects in the institution’s collection.

#W7 General description of the feature’s workflow

Institutions need more than a static list of software projects. They need dynamic, up-to-date views that support monitoring, decision-making, and reporting. Filtering allows OSPO managers to quickly identify trends, gaps, or compliance issues without manual data collection.

Main actor: OSPO Manager

Needs or pain-points to be tackled

OSPO-RADAR capabilities

Need to scope the landscape by organizational unit/team.

Licensing posture unclear across the portfolio.

Use filters (e.g., by department, programming language, license type, activity date, contributor) to explore the institutional software portal and generate real-time insights.

• Basic filters: date ranges, research teams/units, licenses, programming languages.
• Unit/Team facet (multi-select), sourced from org metadata.
• License facet with normalization (e.g., SPDX IDs) + “Unknown” bucket.

Metadata fields covered

• affiliation (department / unit)
• license
• programmingLanguage
• dateModified
• funding
• identifier - extrinsic (DOI, HAL-ID, RRID, ROR, ORCID)

User story

As an OSPO manager, I can apply filters in the collection view of the OSPO-RADAR Dashboard to instantly see which departments have the most active projects, which licenses are most commonly used^[y], or which projects have not been updated recently, so that I can provide accurate reports to leadership and funders, and identify areas needing support.

Associated use case

1. OSPO manager logs into Dashboard platform.
2. Opens the institutional collection view.
3. Applies filters such as:

• Department or organizational unit
• License type (e.g., MIT, GPL)
• Programming language
• Date of last modification (dateModified)
• Funding source

4. Dashboard dynamically updates and displays:

• Counts and distributions (charts, tables)
• Lists of matching software projects
• Key indicators (e.g., projects with missing metadata, inactive projects).

5. OSPO manager exports filtered results for further analysis or inclusion in reports.

#W8 General description of the feature’s workflow

Curators open a software record in the internal dashboard, edit/enrich key metadata, validate fields (licenses, teams, ORCID links, funding), and save. Admin/Managers may review and publish changes to the public “front-shop” view. The goal is to improve data quality with minimal friction while keeping provenance clear (what came from the source vs what the institution added).

Main actor: Curator / Contributor

Secondary actor: Admin / Manager (review & publish)

Needs or pain-points to be tackled

OSPO-RADAR capabilities

Missing or inconsistent metadata across records.

Difficulty normalizing licenses, languages, teams, and identifiers.

• Controlled vocabularies: SPDX license picker, programmingLanguage picker, org unit/team selector; identifier inputs (SWHID/DOI) with format checks.

Capturing funding and related outputs (papers, datasets) minimally.

• Simple fields: funding/funder, relatedPublication (ID/URL), minimal free-text notes.

Linking people and affiliations reliably.

• ORCID lookup/link for authors; affiliation selector (institution → unit/team).

Distinguishing what comes from the code repo vs institutional curation.

Provenance badges (Intrinsic from repo / Extrinsic curated); field-level source indicators.

Hard to tell how the institution relates to a piece of software (created vs contributed vs used vs dependent).

Add four explicit checkboxes on submit/curate forms:

• Own/Authored: Primary development is by our institution (project we own/lead).
• Contributed to: We made identifiable contributions to an external project (PRs, commits, packages, docs).
• Used: We use the software in research/ops (a dependency/tool in our work).
• Referenced: We cite/mention the software in outputs (papers, reports, curricula), but do not necessarily use or contribute.

Quickly spotting incomplete records.

Bonus: Data-quality hints (e.g., “Missing license”, “No ORCID”, “Unknown language”).

User Story

As a curator, I want to flag external projects our teams Contributed to so we can credit staff contributions and surface them in evaluations.

Associated use case

1. Find the project

1. Search by name or URL in SWH.
2. If not found, run Save Code Now.
3. Add it to the collection.

2. View intrinsic metadata

1. Dashboard shows what SWH already has in intrinsic metadata or other annotated metadata (name, URL, SWHID, license, language).
2. These fields are read-only.
3. Optional: Dashboard highlights data-quality issues (e.g., missing ORCID).

3. Annotate

1. Tick Contributed to (and optionally Own/Authored, Used, Referenced).
2. Add contributors (Name, ORCID if available), team/unit, and evidence links (PRs, commits, citations).
3. Annotate missing fields (license, funder, keywords) without overwriting intrinsic data.

4. Save & review

1. Save annotations (as draft).
2. Admin/Manager can review.
3. After review, annotation is validated and captured locally. Annotations can also be sent to the main archive for storage.

#W9 General description of the feature’s workflow

Generate a CSV file containing an institutional inventory of software components, their source repository URLs, and their corresponding Software Hash identifiers (SWHIDs).

Reason:
Institutions need a reliable record of their software assets that can be reused for reporting, compliance checks, and integration with other systems (e.g., CRIS, data catalogs, grant reports). By standardizing on SWHIDs, the exported file guarantees long-term traceability and avoids duplication.

Main actor: OSPO Manager / Research Support Staff

Needs or pain-points to be tackled

OSPO-RADAR capabilities

Institutions need certainty that every software component in their inventory is safely archived and has a clear, reproducible SWHID. Without this, exported lists may include unarchived or untraceable code, undermining trust in reporting and compliance.

Metadata fields covered:

• name (component)
• identifier (SWHID)
• codeRepository (URL)

User story

As an OSPO manager, I can export a CSV with three columns: Component/Project Name, URL (origin), SWHID; so that my institution has an authoritative list of its archived software assets, which can be used for internal tracking or shared with funders.

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.

Name / Anonymous

Comment

+upvoters

Feedback summary and response:

#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^[z].
• 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, related publications), enabling automated harvesting and interoperability.

Institutions need to know impact and reach of their portfolio.^[aa][ab][ac]

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)

1. Public visitor accesses the portal homepage.
2. Uses search box or filters (name, tags, domain, license) to browse.
3. Featured projects appear highlighted on the homepage/OSPO page.

2. View a software entry

1. Visitor selects an entry→ public software entry opens.
2. 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).

Name / Anonymous

Comment

+upvoters

Feedback summary and response:

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

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

35. 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-recherche/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

Identified Risk / Cause of Failure

Proposed Mitigation Measure

The product doesn’t match functional needs.

Define key functionalities and a clear MVP.

No active users or engagement.

Use an agile, iterative approach with frequent user testing and feedback.

Users themselves don’t know or can’t articulate what they need.

Early engagement, lightweight prototypes, and validation sessions.

Too many divergent use cases → scattered development and feature overload.

Define scope via governance and Product Owner oversight.

Service architecture or delivery model (SaaS, archive integration) is unclear or unmanageable.

Clarify delivery model early; validate feasibility with the technical team.

Operating costs are too high.

Design for efficiency; plan, budget and sustainability model from start.

Users can’t operate the tool autonomously → overload on the helpdesk.

Ensure usability; provide training and clear documentation.

Governance is unclear → difficulty prioritizing features, risk of scope creep.

Establish a governance structure and validation mechanism.

Some partners perceive the product as a competitor → threatens collaboration.

Communicate clearly why Software Heritage is the right actor to deliver this solution.

Not all potential user groups were identified.

Map stakeholders early; revisit and update regularly.

Another team or competitor develops a similar service in parallel.

Monitor the ecosystem and position OSPO-RADAR as complementary.

Insufficient resources for development, deployment, and maintenance.

Secure adequate funding; adjust scope if needed.

Academia and industry have fundamentally different needs.

Keep modular design; allow context-specific configurations.

Negative reputation risk (e.g., concerns over tracking or privacy).

Include privacy protections (e.g., hide personal data when needed).

CodeRepository

Software developer

open an issue

contribute to an existing tool to improve it

identifier

Sw author or responsible asks for PID

PID provider mints/calculates a PID

Ask

Assign/Calculate

To make the resource easily identifiable to the world

As an Author/responsible of the software, I ask for a PID (extrinsic) or enable automatic calculation (intrinsic, e.g., by having the software in SWH) so my sw has a unique PID

author

Curator or from code repository/README

Entered by a curator or harvested from another site or within the software

attribution/contact

As a collaborator, I can identify a creator of the code so that they get attribution in a citation

dateModified

Developer / researcher

As a developer / researcher, I can check the modified date so that I know if the software is “up to date” (has not been worked on a long time ago).

BuildInstructions

A user

needs to install or run the software

To use the software locally or in its own hardware (such as a HPC, or cloud)

DateCreated

Developer of the software

As a developer I can have credit and attribution for a software I worked on.

Readme

A user

Wants to understand if the software is useful for their purpose

To select the software they are going to use

Readme

A user

Wants to understand the requirements of using a given software (see also software requirements)

To decide whether or not the requirements can be met before running the software

Readme

A user

Wants to know who to acknowledge

To add a reference to the software tool in a publication, or a poster or any other scholarly output

datePublished

Developer / Aggregator

Citation

So that people know when it was released.

version

User

refer a specific version of software

To be able to cite it for reproduction of older results from colleagues

As a user I can refer to a specific version of a software so that I can cite it when reproducing older research.

Keyword

Search engine

Help in findability of the resource, but also in the classification of it.

aries/Ontologies

Resources need to be classified in order to be easily findable

A postdoctorant looking for some software helping in analysing his data

ProgrammingLanguage

User / search engine

search for language specific tools

To enable interoperability with other tools written in the same language

To allow reuse by users who can use that language

A teacher wanting to illustrate a way to solve a problem using a specific language

runtimePlatform

User / Contributor

Use (or develop) the software

To have compatible environment where the software should work as intended

As a user (or contributor) I can use (or develop) the software so that I have a compatible environment where the software works as it should.

license

Authors of the software

Make a decision about a proper license and add (a) LICENSE file(s)

To make a clear statement, what are the conditions and terms that apply to use the product/software

As a developer I want to be able to clearly state, who should be allowed to do what with my software

As a user, I want to know, what I am allowed to do with this software (use it, build on it)

developmentStatus

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

SoftwareRequirements

user/other software/dependencies

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)

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 objectives- archive, 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?

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?