Software has become an integral part of the research landscape. According to DOI registrar DataCite, there were 608,539 DOI registrations for software as of February 2025*1. This includes 132,168 software DOIs that have been registered in 2024 alone and the trend continues upwards. The amount and diversity of software developed and used in research projects are so high that it is becoming increasingly challenging for participants in the research process – be they researchers, research software engineers (RSEs, cf. Goth et al. (2025)), research administrators, research funders or students – to make informed decisions when searching and selecting research software (RS) for specific research-related tasks.

Challenge 1 – Search inefficiency: The process of searching for – and ultimately finding – relevant RS is often inefficient (Hucka and Graham 2018): the search is cumbersome, there is no guarantee that the software found is suitable for an intended task or that software suitable for a given task will be found by those looking for it. While software discovery has received less attention than discovering other types of resources – for example, literature (Kang et al. 2023) or data (Contaxis et al. 2022) – some insights from the study of the latter ones are transferable to the former. For instance, the concept of discovery pathways (Thagard 2022) as a series of cognitive steps towards a discovery goal can be applied to software discovery, as can existing typologies in this space (Nishikawa-Pacher 2021) or ideas around workflows that extend beyond papers as the main starting points for discovery (Kang et al. 2023). There is, indeed, a wide range of available discovery pathways, which vary greatly depending on the context (Wittenborg et al. 2025). Searching for software may, for instance, entail exploration of various code or publication repositories, search engines or package managers, each of which having its own search functions and metadata standards. Furthermore, the type of software being searched for, such as data analysis tools, visualisation libraries or simulation frameworks, influences the choice of search strategy and platform. Parameters, such as the scientific domain, familiarity with programming languages, licence considerations and specific use cases, can also influence the search strategy. For example, a bioinformatician might use bio.tools*2 to search for suitable software, while physicists might prefer physics.tools*3, and humanities' scholars the Social Sciences and Humanities Open Marketplace*4. In addition, there are approaches at the institutional (e.g. Helmholtz Research Software Directory - cf. Maassen (2023)) or national level (e.g. NFDI.software - cf. Castro et al. (2025)). This complex network of discovery pathways leads to researchers having difficulties finding relevant software that meets their research needs, which ultimately hinders the progress of their work.

Challenge 2 – Lack of annotations: RS is often insufficiently annotated regarding its functionality or potential scope of usage, making it challenging to understand its capabilities, compatibilities, limitations and actual or potential applications. Many software packages lack comprehensive documentation detailing their algorithms and associated assumptions, input/output formats or usage examples. As a result, researchers and other potential users face difficulties determining whether a particular software, tool or workflow meets their specific needs. This lack of clarity also hinders research reproducibility, since users may not be able to accurately replicate results without a clear understanding of the software’s functionality, parameters, dependencies or interactions with other components of relevant research workflows. Despite promising initiatives for standardised software descriptions (Jones et al. 2017, Druskat et al. 2021, Garijo et al. 2021), their consistent implementation in practice remains lacking, and those descriptions focus on some discovery pathways, while not covering others.

Challenge 3 – Software sustainability: The development of RS, the many initiatives in the area of research software engineering (RSE) and a variety of RSE services that are perceived as infrastructure often rely on a very limited group of people (Hettrick et al. 2022). These individuals are crucial to the development, maintenance and support of the tools and platforms that underpin RS, but compete for attention with their own research or professional obligations. This dependency on a few individuals jeopardises the long-term sustainability of these infrastructures and initiatives. More stable and sustainable models are needed to support the continued development, deployment and maintenance of reliable and effective RS infrastructures, in general and for RS discovery, in particular.

Challenge 4 – Research silos: RS infrastructures, such as the European Open Science Cloud*5 or Germany’s National Research Data Infrastructure (NFDI)*6, are often built within national or institutional boundaries, making them less accessible to researchers outside those boundaries. These infrastructures are designed to provide researchers with essential resources and tools for managing, sharing and analysing data. However, the geographic and organisational restrictions create barriers to international collaboration, as researchers from different countries or institutions may not be able to access these infrastructures, resulting in fragmented data and tools making it difficult to share data and knowledge across borders. This highlights the need for more inclusive and globally accessible RS infrastructures to support a truly open and collaborative scientific community. Initiatives like swMATH – which annotates mathematical publications indexed in zbMATH Open with the underlying software (Azzouz-Thuderoz et al. 2022) – can help overcome such administration-related silos. We will work closely with swMATH as well as with MaRDI – the mathematical NFDI consortium (Schubotz et al. 2023) – and the NFDI Basic service nfdi.software*7 to extend the functionality of swMATH and to use it as a starting point to enable interlinking between software and other research resources also for other disciplines

As RS discovery has not received much attention so far (see above) and the associated needs are not well circumscribed. We thus decided to conduct an initial analysis of user groups for RS discovery in the form of personas, as well as to identify a total of 12 scenarios for a search for RS (Gey et al. 2025). Based on these findings, we conducted a workshop with representatives of the RSE community (Wittenborg et al. 2025), which led to the following conclusions:

One of the greatest challenges is the lack of a coherent mechanism for researchers to find relevant software. Such a mechanism serves as the basis for a single, unified platform and would be particularly beneficial for users who are less experienced in dealing with software and do not have the necessary knowledge of the different discovery pathways.

The results of the workshop are confirmed by a position paper of the German association for research software, deRSE e.V. (Anzt et al. 2021). In the paper, the authors outlined challenges for sustainable research software in Germany and consider RS discovery as a prerequisite for enabling the reuse of existing software and avoiding redundant development. However, insufficient information retrieval strategies and a lack of knowledge about relevant repositories are crucial factors hindering a sustainable RS discovery (Anzt et al. 2021).

The discovery of RS is facilitated by various platforms, tools and workflows that can be grouped into different categories, of which we will briefly outline some of the most commonly used ones (a detailed environmental analysis was recently conducted by the authors - cf. Gey et al. (2025)).

Code repositories such as GitHub, GitLab and Codeberg provide management and collaboration features, while mixed content publication platforms, such as Zenodo, allow researchers to publish their research outcomes more generally, including software. Software repositories or package repositories are centralised locations for software packages and may be specific to programming languages or operating systems. Examples include PyPi for Python, CRAN for R or the App Store for iOS. Software archives, such as Software Heritage, preserve code for future generations, while catalogues, including domain-specific, institutional and national/supranational catalogues, collect metadata and point to persistent RS repositories. Curated lists, such as the Awesome Lists on GitHub, are collections of high-quality content on specific topics and are often used to search for topic-specific software. Search engines, including general-purpose search engines like Google and science-orientated competitors like BASE, provide comprehensive strategies for aggregating content and search functions. Specialised search engines, such as Betty’s ReSearch Engine, specialise in research software. Software journals, such as JORS and JOSS, publish text articles on software publications, making software searchable. Social networks can be a valuable resource for RS discovery, too, as researchers often rely on their academic network for information (Hucka and Graham 2018, Murphy-Hill et al. 2015). Furthermore, large language models can be used for RS discovery to identify relevant tools and provide information about their functions and capabilities. Last, but not least, knowledge graphs provide a structured approach to organising and linking diverse pieces of information (including from all the other categories mentioned before), facilitating semantic search capabilities and discovery of RS tailored to specific research purposes. They can also support recommendation systems, provide contextual information and lead to engaging visualisations. A key feature of knowledge graphs in the context of research software discovery is that many discovery pathways can be supported, with every node potentially serving as an entry point or as a seed for more specific subgraphs and every edge as a bridge to other parts of the graph or even to other graphs, databases or further resources. The Knowledge Graph Infrastructure KGI4NFDI*8 is an initiative to review the usage of scholarly knowledge graphs within NFDI and to support disciplinary communities in choosing and using suitable knowledge graph approaches. We are involved and we will closely monitor KGI4NFDI activities from the perspective of RS discovery, consulting with related initiatives like NFDI.software as appropriate. There have been prior efforts regarding knowledge graphs for software. They can be classified in several ways, one of which would be whether they are based on stand-alone (Schubotz et al. 2023, Kelley and Garijo 2021, Samuel and Mietchen 2024a) or community-driven infrastructures, particularly Wikidata (Thornton et al. 2018, Rasberry et al. 2022).

For this initial phase of the implementation of find.software, we have chosen to concentrate on Wikidata, for several reasons. First, Wikidata is open, transdisciplinary and multilingual, which forms a good foundation for a potentially large user base. Second, Wikidata runs on Wikibase – a tried and tested backend for collaborative curation of structured data – that can also be used in a stand-alone fashion, as is the case with MaRDI (Schubotz et al. 2023). Third, a worldwide community has already formed around Wikidata and Wikibase, from whose experiences and organisational structures we want to benefit and to which we want to contribute with find.software for the research software domain. Fourth, the barriers for the participation of individuals are as low as possible, which facilitates broad participation in the design of find.software. Fifth, thanks to diverse community efforts, the Wikidata database already contains many software-related items (e.g. 13000 direct instances of software*9, over 5000 subclasses of software*10 and millions of instances of software or any of its subclasses*11), along with over 100 Wikidata properties related to software*12, of which over 60 have the term software in their English label, description or aliases*13. This forms a good basis for supporting a range of discovery pathways for software in general and – in light of the strong presence of research-related concepts in Wikidata (Nielsen et al. 2017, Waagmeester et al. 2020) and efforts to establish links between them and software (Rasberry and Mietchen 2022) – for research software in particular. In addition, MaRDI – the mathematical consortium within Germany’s National Research Data Infrastructure (NFDI) – uses a stand-alone Wikibase instance as a productive backend for its own portal for research data management in mathematics (Schubotz et al. 2023), which is integrated with swMATH to facilitate software discovery in the field. This software stack can be reused by find.software and serve as a starting point, especially since our project team already has considerable experience in working with Wikidata and Wikibase.

Taking into account the identified needs of the target audience and the identified existing alternatives for software discovery (both previous section), we would like to propose find.software as a solution to enable cross-domain and community-maintained software discovery. With find.software, we are setting up a functional prototype (cf. Fig. 1) and thus assign ourselves to Phase 1 (Set-up and testing) of the DFG funding programme Research Software Infrastructures.

The project will be conducted over 36 months. Funding is requested for the entire duration.

find.software serves as the primary entry point for researchers to search for suitable RS, regardless of application scenarios, such as research domain, target architecture or programming language:

Objective 1: Scientists find and evaluate RS indexed on find.software that may be relevant to their own research. For an open, free and egalitarian research and knowledge landscape, it is essential that an infrastructure for RS discovery is in the hands of a diverse global community that is committed to the values of open science;

Objective 2: Scientists, citizen scientists and Wikidata enthusiasts jointly administer and expand the find.software instance and the RS metadata it contains.

In Table 1, Objectives 1 and 2 are broken down into sub-objectives and supplemented by the challenges assumed, the approach chosen, the results targeted and the expected impact.

The four work packages (WPs) can be briefly characterised by way of a table of deliverables (cf. Table 2), a Gantt chart (cf. Fig. 2) and short narrative summaries (below):

WP1 (month 1 - 18): Conceptualisation

WP 1.1 Identify and prioritise discovery pathways for RS. We will document a range of discovery pathways for RS, based on a set of use cases and personas. In doing so, we will pay special attention to pain points that potential RS users experience on the way or that are associated with not finding what they need. We will also consider the perspective of software developers that want their software to be found by potential users. On that basis, we will explore what changes to software discovery pathways would have the potential to ease these pains and take them into account – together with technical and legal aspects – when prioritising our subsequent work on supporting specific discovery pathways. The results of the exploration will be compiled into a brief report (D1.1) that portrays different RS discovery pathways and compares them using a rubric that can assist with the development of the data model.

WP 1.2 Identify relevant metadata schemas/vocabularies for RS. This sub-package will examine existing metadata standards and determine which are best suited for capturing the various characteristics of RS. The metadata should take into account the needs of both researchers and software developers.The team will produce a detailed report documenting the selected metadata standards (D1.2).

WP 1.3 Define data models. The models will define the structure for representing metadata aboutRS within Wikidata. The data model will be based on existing RS-related data structures in Wikidata and will consider integration and compatibility with different metadata vocabularies, paying special attention to swMATH and MaRDI. The result will be a comprehensive design (D1.3) that will guide the implementation of the data service in later phases.

WP 1.4 Legal aspects. This subpackage documents and addresses the legal and ethical considerations associated with the collection, storage and dissemination of metadata about RS, focusing on the discovery pathways identified and prioritised in WP 1.1. Key tasks include analysing licensing terms of potential data sources and relevant metadata, ensuring compliance with data protection regulations like GDPR and planning for future phases of find.software development that are expected to support a broader range of RS discovery pathways.

WP 1.5 Define harvesting setup. Here, we design a mechanism for the collection of metadata from a variety of sources, including software repositories, publication databases and metadata catalogues. The setup will define protocols for both automated and manual data ingestion, with the objective of ensuring consistency and accuracy. The evaluation and selection of tools and APIs for harvesting will be based on their compatibility with the data model and project requirements. The process will include data validation and deduplication to maintain data quality.

WP2 (month 7 - 33): Service implementation

WP 2.1 Set-up data service and frontend. In this sub-package, we will adapt Wikidata workflows forRS metadata and related information. We will configure and customise Scholia, a specialised frontend tool designed for academic use cases, to serve as the user interface for the underlying data in Wikidata.The customisation work will focus on optimising Scholia’s search function and creating software-specific filters. Adjustments will also be made to ensure that the user interface effectively highlights important metadata attributes such as software authorship, dependencies and licences.

WP 2.2 Implement data model. We define a data model for RS in Wikidata and propose the changes needed for its implementation to ensure that all metadata types, relationships and attributes are correctly represented in the system. The implementation includes the creation of relevant items, properties and templates in Wikidata. Data migration strategies and data validation rules are also defined to ensure consistency and accuracy.

WP 2.3 Harvesting and integration. In this step, metadata is imported from external sources and made available for use in Wikidata. Automated scripts and tools are used to collect data from repositories, software catalogues and other relevant platforms. Data integration processes ensure that the collected metadata is in line with the data model and free of duplicates. Sub-package 2.3 results in deliverable D2.1, a minimum viable product (MVP).

WP 2.4 Prototype evaluation. We will evaluate the first prototype of the Scholia frontend both internally and with community representatives. This will involve user testing and feedback sessions with a range of stakeholders. The evaluation will focus on functionality, usability and the quality of search results. Identified issues or challenges will be documented and addressed in the next iteration (WP2.5).

WP 2.5 Scaling and update. In this sub-package, we enable a more comprehensive dataset by integrating additional data sources. While the initial prototype integrated a limited number of data sources, the aim now is to include as many relevant and representative sources of RS metadata as possible, thus ensuring the compatibility of the sources with the existing data model and the development of robust integration mechanisms. The system and the connection of the data source are designed and documented in such a way that evolving metadata standards and changes in the data sources can be adequately taken into account. Sub-package 2.5 results in deliverable D2.2, an implemented service.

WP 2.6 Maintenance concept. We develop a long-term strategy for maintaining and further developing find.software. This includes defining roles and responsibilities for ongoing system administration, creating protocols for regular updates and backups and planning user support. A governance model is proposed to ensure accountability and transparency. This step ensures the longevity of the system and its continued relevance to the RSE community.

WP3 (month 3 - 36): Community and networking

WP 3.1 Workshops and roadshows. Workshops will be organised that are aimed at educating and engaging the broader RS community. These workshops will include practical training on how to use find.software, how to provide metadata and how to integrate it into the researchers’ own workflows. In the workshops, we will also collect feedback from users to incorporate their insights into the project. Both researchers and software developers are invited to attend. The sessions will be tailored to beginners or advanced users, depending on the context. The roadshow includes visits to scientific community events (e.g. NFDI consortia like NFDI4Earth) and aims to raise awareness of the project, promote collaboration and attract scientific communities to the project. These events will showcase the functionalities of find.software, highlight the benefits of metadata capture for RS and promote adoption in various scientific fields. Both, workshops and roadshows will be held in person and online.

WP 3.2 Sustainable community engagement. The involvement of the general public in the project will be achieved through crowdsourcing of metadata contributions, the involvement of volunteers in the validation of RS data and the involvement of community members in the development process. Participants are supported through the design of teaching materials and online tools (forms and Wikidata GWAPs (Games with a Purpose)).

WP 3.3 User and developer documentation. We are creating comprehensive user and developer documentation for find.software. The documentation will cover both technical and non-technical aspects and provide clear instructions for using the system, contributing metadata and interacting with the platform. The developer manuals will include technical specifications, APIs and integration instructions, while the user documentation will explain how to search, retrieve and analyse metadata.

WP 3.4 Science communication. Science communication activities are being developed to raise awareness of the project and its goals. Short videos and blog posts will explain the project’s purpose, its benefits for the RS community and how users can become involved. The material will be disseminated via online platforms, such as social media, project websites and academic networks to ensure broad visibility. The videos are intended to appeal to a wide audience, from researchers to the general public.

WP4 (month 1 - 36): Project management

WP 4.1 Initialisation. This sub-package focuses on laying the foundations for the research project. Activities include defining the scope of the project, setting key objectives and assembling the core project team. Project tools and communication channels are also defined. The preliminary technical requirements for the Wikibase instance are also evaluated.

WP 4.2 Coordination. This sub-package includes the ongoing management and synchronisation of project activities across all work packages. Regular project meetings are organised and documented. A comprehensive communication strategy is implemented. Coordination efforts also include risk management, monitoring the schedule (work packages, deliverables, reports) and ensuring that tasks and deliverables are completed on time.

WP 4.3 Research data management. We ensure that metadata is curated, stored and shared according to best practice. In this sub-package, the storage, versioning and backup of data and the underlying workflows are realised. Ethical considerations and compliance with relevant data protection regulations are addressed. The project ensures that RS metadata is freely accessible to the global research community in line with the principles of open science. All project relevant data will be published at the end of the project (Deliverable D4.1) under a common open access licence.

WP 4.4 Reporting. This sub-package focuses on the systematic documentation and reporting of project progress and outcomes. We track achievements, challenges and adjustments to the project plan. The preparation of deliverables and research findings will be managed within this sub-package. The main focus of the package, however, is to write the DFG Final Report under Infrastructure Funding (DFG form 12.02 - 10/24), (Deliverable D4.2).

We do not anticipate that our research will result in any risks and/or harm to individuals or groups and/or the potential for other negative impacts. Some potential discovery pathways for research software involve information about people, such as authorship or co-authorship of papers or software, yet we will only process such information if it is already public and such ethical dimensions will be taken into account when we prioritise which discovery pathways to support and how (cf. WP 1.1 and WP 1.4).

We will avoid air travel as part of the project implementation*16. When organising workshops, care will always be taken to enable hybrid participation and, thus, minimise the cost of travel to and from the event. When collecting, processing and presenting software metadata in find.software, we will try to take ecological aspects (carbon footprint, ecological benchmarks) of the assessed research software into account (Lannelongue et al. 2021) and offer specially tailored services (filter options, ecological assessments).

We commit ourselves to making all project results (text, data and software publications, documentation and software code) openly available to the general public via permissive licences*17. Data suitable for Wikidata will be shared there. The project results will conform to the FAIR and FAIR4RS principles. The applicants are supported in research data management and compliance with the FAIR and FAIR4RS criteria by the responsible structural units at their institutions*18.

The applicant institutions each guarantee the 10% of their own contributions required for Phase 1 of the Research Software Infrastructures programme. All results will be Open Access and comply with FAIR and FAIR4RS principles. Software developed will be open source. Developer documentation and user documentation will be created and made publicly available alongside the respective software and data model. In general, software will be modularised and constructed in a generally applicable manner to allow for easy reuse and transfer in/to other projects. For long-term archiving, all research artefacts will be published and made available free of charge. Source code and documentation will be made available under free open source licences. Scientific publications and tech reports will be made available in (green or gold) open access. In terms of sustainability, all partners commit to using the software developed in this project internally also outside of the scope of the project.