Geschäftsentwicklung

Wenn die Entscheidung für einen möglichen Transferweg gefallen ist und eine kommerzielle Softwareverwertung sinnvoll erscheint, stellt sich nun die Frage der konkreten Ausgestaltung der Kommerzialisierung: die Geschäftsentwicklung. Die möglichen Transferwege bilden die Grundlage für die Auswahl und Kombination verschiedener Optionen zur Geschäftsmodellentwicklung. Das Projekt SoftWert hat sich mit zentralen Fragen der Geschäftsentwicklung im Rahmen einer Lizenzierung von Forschungssoftware, dem Aufbau von Services sowie mit dem Thema Ausgründungen beschäftigt.

Im Projekt SoftWert wurde ein Entscheidungsbaum erarbeitet, der Transfermanager:innen dabei unterstützen kann, für eine Forschungssoftware eine geeignete Verwertungsoption auszuwählen, für die eine Geschäftsmodellentwicklung vielversprechend erscheint. Voraussetzung dafür ist, dass es keine rechtlichen Restriktionen gibt, dass entsprechende Ressourcen für das Vorhaben vorhanden sind, dass die Einrichtung die Softwareverwertung unterstützt sowie dass es einen Markt für die Forschungssoftware gibt. Auch die Kombination unterschiedlicher Verwertungsoptionen ist hier mitgedacht. So kann es je nach Zielsetzung und Rahmenbedingungen bspw. sinnvoll sein, Einnahmen über flankierende Dienstleistungen zu generieren, während die Software selbst über eine Open Source Lizenzierung zur Verfügung steht. Ein Beispielablauf zum Umgang mit dem Entscheidungsbaum ist hier zu finden.

Einer weiteren besonderen Thematik der Geschäftsentwicklung widmen sich die zusätzlichen Unterseiten dieses Kapitels Geschäftsentwicklung, nämlich dem Thema Ausgründung auf Basis von innovativer Forschungssoftware.

Entscheidungsbaum

Der Entscheidungsbaum bildet die Grundlage für die Auswahl und Kombination verschiedener Verwertungswege. Während des Ablaufs des Entscheidungsbaums ist es möglich, dass mehrere Verwertungswege als “Geschäftsfeld-Optionen” ausgewählt und „gesammelt“ werden. Je nachdem, welches Set an Optionen ausgewählt wurde, können für die zielgerichtete Geschäftsmodellentwicklung dann bestimmte Fragestellungen beantwortet werden, die in Transfermanager:innen dabei unterstützt, das Geschäftsmodell hinsichtlich individueller Möglichkeiten und Restriktionen auszugestalten.

Es wird empfohlen, zunächst alle Fragen des Entscheidungsbaums zu beantworten und erst im Anschluss die gesammelten Geschäftsfeld-Optionen samt Fragestellungen in einem Gesamtkontext zu konsolidieren.

Entscheidungsbaum zur Ausgestaltung des Verwertungsweges

Die Fragestellungen zur Geschäftsmodellentwicklung für bestimmte Verwertungswege/Optionen befinden sich in einem gesonderten Dokument als Tool:

Geschäftsmodell-Optionen

Geschäftsmodellentwicklung

Ein vereinfachtes softwarebasiertes Geschäftsmodell kann anhand der dargestellten Dimensionen beschrieben werden.

Dimensionen der Geschäftsmodellentwicklung

Die Produktstrategie beschreibt den Schwerpunkt der Produktentwicklung und definiert dabei auch das Vorgehen sowie die Priorisierung bei der Softwareentwicklung. Die Produktstrategie ist eine entscheidende Dimension bei der Entwicklung eines Geschäftsmodells. Konkret sollte sich die Frage gestellt werden, ob eine Software nur für eine bestimmte Gruppe von Benutzern mit eng definierten Anforderungen angeboten werden soll oder ob sie durch einen eher standardisierten und modularen, mitunter weniger komplexen Aufbau von einer größeren Kundengruppe genutzt werden sollte.

Die Preisgestaltung für eine Software kann sehr verschieden ausfallen und der Kreativität für innovative Umsatzströme sind keine Grenzen gesetzt. Die gängige Preisgestaltung orientiert sich entweder an einer klassischen Einmalzahlung oder einer nutzerorientierten Vergütung, wobei es im Markt noch eine Vielzahl anderer Mechanismen zur Generierung von Einnahmen gibt. Die Höhe der Vergütung sollte sich prinzipiell an einem „value based pricing“ orientieren. Bei der Kalkulation sind unter anderem der bisherige (und ggf. zukünftige) Entwicklungsaufwand sowie die laufenden Kosten für Infrastruktur, aber auch der zu erwartende Nutzen für den Kunden zu berücksichtigen. Darüber hinaus ist die Höhe der Vergütung von der Vertragslaufzeit und die Bereitstellung von Exklusivität abhängig. Zahlungsvereinbarungen können beispielsweise hinsichtlich Einmalzahlung, regelmäßiger Zahlung, umsatz- oder volumenbasierter Zahlung getroffen werden, dabei können die Tranchen regelmäßig, aber auch progressiv vereinbart werden (zum Beispiel ansteigende Zahlungsraten mit günstigen Startbedingungen zur Unterstützung von Start-Ups). Beispiele für vereinbarte Zahlungsmodalitäten befinden sich in der Dealdatenbank.

Um ein geeignetes Vertriebsmodell zu wählen, d.h. zu entscheiden wie Marketing & Vertrieb für ein Softwareprodukt oder einen Service am besten zu organisieren ist, gibt es verschiedene Aspekte, die berücksichtigt werden sollten. Besteht bereits Kontakt zu potentiellen Kund:innen, die klar identifiziert werden können? Ist die Software erklärungsbedürftig? Ist das Image der Einrichtung oder der Entwickler:innnen für die Vermarktung der Software von Vorteil? Dann ist es sinnvoll, sich für ein direktes Vertriebsmodell zu entscheiden, also als Einrichtung direkt mit potentiellen Kunden in Kontakt zu stehen, bzw. diese selbst zu identifizieren und auf das Produkt aufmerksam zu machen. Hierbei ist zu beachten, dass dafür natürlich die internen Ressourcen vorhanden sein müssen. Ist dies nicht zu gewährleisten, bietet es sich an einen Intermediär zwischenzuschalten, d.h. jemanden für den Vertrieb zu beauftragen und mit dieser Person oder Organisation im engen Austausch zu stehen. Wichtig ist dabei zu beachten, dass hier in der Regel eine Provision an den Vermittler gezahlt werden muss. Dennoch kann das Kosten-Nutzen-Verhältnis in diesem Fall trotzdem vorteilhafter sein, als wenn man eigene Ressourcen nutzen würde. Eine weitere Möglichkeit besteht darin, ein Partner-Netzwerk für den Vertrieb zu nutzen. Das ist dann zu empfehlen, wenn bereits ein Netzwerk an Multiplikatoren für eine bestimmte Dienstleistung oder einen Anwendungsfall existiert und einem das Netzwerk ermöglicht, überhaupt erst Kund:innen zu identifizieren und zu kontaktieren bzw. durch das Vertriebsnetzwerk kontaktieren zu lassen. Vorteilhaft sind die Nutzung von Vertriebsnetzwerken mit z. B. sehr etablierten Vertriebswegen, einer großen Expertise und/oder einem positiven Image. Es sollte bedacht werden, dass eine Steuerung von einem direkten Vertrieb hin zu Vertriebsnetzwerken mit einer Änderung in der Preisgestaltung einhergeht. Beim direkten Vertrieb hat die Einrichtung selbst die alleinige Entscheidung über die Preissetzung, bei Vermittlern oder Netzwerken ist, wie bereits erwähnt, eine Provision zu zahlen oder der Rahmen für die Preisgestaltung durch externe Faktoren zusätzlich begrenzt.

Die Implementierung beinhaltet die Erfassung des personellen/finanziellen Aufwands, der noch nötig ist, um ausstehende Informationen oder Weiterentwicklungen in das Software Repository zu integrieren. Diese sind je nach Kundenanforderungen verschieden. In der Regel umfassen diese aber unter anderem:

Lizenzierung der Software, bzw. Überprüfung der Lizenzgültigkeit
Bereitstellung einer hinreichenden Dokumentation, (Installation/Nutzung/Konfiguration/ggf. Beispiele/Lizenz/Credit Projekt/ggf. Autoren)
hinreichende Code-Kommentierung
strukturierter, nachvollziehbarer Code
Implementierung des Codes in einem DevOps Repository (z.B. GitLab/GitHub)
nachvollziehbare Strukturierung des Repositories
Überprüfung des Deployments: ist der Code installierbar
Gewährleistung der Funktionalität
Validierung der Software, ist sie auf andere Anwendungsfälle übertragbar
Integration einer Pipeline zur Automatisierung von Software Tests
ausstehende Featureentwicklungen vor des ersten/nächsten Releases
etc.

Dienstleistungen beziehen sich in diesem Kontext auf Serviceangebote, die rund um die Software angeboten werden können, also alles außerhalb von Software-as-a-Service und der klassichen Softwarelizenzierung. Dienstleistungen sind beispielsweise Maintenance, Patches, Schulungen, Support, Consulting, usw. Der Umfang der Leistungserbringung für kostenpflichtige Dienstleistungen sollte in gesonderten Verträgen geregelt und vor allem auch genaue Angaben über den Leistungszeitraum enthalten sein. Neben der Laufzeit, in der eine Dienstleistung erbracht wird, können auch maximale Anzahl von Stunden (Support, Coaching) oder die Regelmäßigkeit von Updates (Maintenance, Patches) geregelt werden. Für wissenschaftliche Einrichtungen ist es außerdem wichtig zu überdenken, welches Personal für die Dienstleistung zur Verfügung steht und welche Backupmöglichkeiten bei einem Ausfall gegeben sind. Entsprechend sind ggf. Ausstiegsklauseln aus Verträgen zu formulieren (zum Beispiel: Updates werden 1x im Jahr geliefert, sollte dies nicht realisiert werden, gilt der Vertrag als beendet).¹

Geschäftsentwicklungs-Glossar

Da in den vorgestellten Tools und Hilfestellungen verschiedene Begrifflichkeiten zum Thema Geschäftsentwicklung verwendet werden, die ggf. unterschiedlich definiert sein können, findet sich im Folgenden ein Glossar zu den speziellen Begrifflichkeiten dieses Bausteins vom SoftWert-Methodenkoffer, so wie diese in diesem Projekt definiert wurden (einige Begriffe finden sich auch im globalen Glossar des Wikis):

Duale Lizenzierung:

Bezieht sich in diesem Kontext im Speziellen auf die Verwertungsstrategie, ein Softwareprodukt Open Source zu veröffentlichen und es dabei unter zwei verschiedenen Lizenzen zur Nutzung anzubieten:

1. kostenfrei unter einer Copyleft Lizenz,
2. unter einer proprietären Lizenz, die es erlaubt das Produkt ohne Copylefteffekt in eine andere Software zu integrieren.

Weitere Details zu diesem Konzept sind unter Dual Lizenzierung zu finden.

Dual-Use/Exportkontrolle:

Die Exportkontrolle betrifft die Ausfuhr von Gütern. Der Güterbegriff ist jedoch kein physischer und umfasst auch Software und Technologie. Ausfuhr meint eine Übertragung von Software mittels elektronischer Medien außerhalb der Europäischen Gemeinschaft. Dies beinhaltet auch das Bereitstellen von Software oder Technologie in elektronischer Form für Personen außerhalb der EU. Software unterliegt der Exportkontrolle, wenn diese aufgrund der möglichen kritischen Verwendung gemäß Gattung D (Softwareverarbeitungsprogramme) der Kategorien 1 bis 9 der Ausfuhrliste Teil I Abschnitt B erfasst ist. Zu beachten ist jedoch die Allgemeine Software-Anmerkung (ASA). Danach erfassen Gattungen D der Kategorien 1 bis 9 keine Software, auf die besondere Kriterien zutreffen wie z.B., dass die Software frei erhältlich ist und so konzipiert wurde, dass der Benutzer sie ohne umfangreiche Unterstützung durch den Anbieter installieren kann.

Exklusivität:

Bei der Lizenzierung bzw. dem Verkauf von Software kann einem Kunden die Option zur exklusiven Nutzung angeboten werden, damit dieser sich das alleinige Recht zur Nutzung sichern kann. Im Gegensatz dazu wird ein erhöhter Preis aufgerufen. Die lizenzgebende Einrichtung sollte in diesem Fall die Exklusivität sinnvoll einschränken, zum Beispiel hinsichtlich der Dauer, Applikation, Nutzungsort, etc. Insbesondere die Dauer der Exklusivität sollte nach einem gewissen Zeitraum neu verhandelt werden können, da es mit einer Änderung der Marktlage für die Einrichtung lukrativer sein kann, die Software mehreren Lizenznehmern anzubieten. Des Weiteren sollte darauf geachtet werden, dass mit dem Recht der Nutzung auch eine Pflicht zur Nutzung einhergeht, um zu verhindern, dass Marktteilnehmer durch einen exklusiven Vertrag lediglich den Zugang verwehren.

Free-Core:

Bei der Bereitstellung einer Software innerhalb eines Free-Core Modells wird der Kern (core), bzw. die Basisversion der Software den Nutzer:innen kostenfrei zur Verfügung gestellt. Darüber hinaus stehen besondere Funktionalitäten/Features oder bestimmte Module des Codes nur gegen eine Nutzungsgebühr zur Verfügung. Software im Free-Core Modell kann sowohl als Service zur Verfügung gestellt werden, als auch für einen definierten Zeitraum direkt an eine Kund:in lizenziert werden. Eine Open Source Veröffentlichung des Kerns ist nicht zwingend notwendig, erlaubt aber den Kund:innen eine Einsicht in die Codequalität und kann, bei hoher Qualitätssicherung, ggf. ein Nutzungsargument sein.

Kostenpflichtige Features, die über die Kernfunktionalität angeboten werden können, können unter anderem sein:
mehr Funktionalitäten (z.B. zusätzliche Module)
erhöhte Speicherkapazität
schnellere Prozessierung (erhöhte zur Verfügungstellung von Kernels/RAM)
erhöhte Anzahl der Nutzer (bei Nutzeranzahlbegrenzung in der Basisversion)
Anspruch auf Support (garantierten Supportzeitraum klären)
Anspruch auf Gewährleistung

Bei der Bereitstellung von zusätzlichen Funktionalitäten, sollten diese genau beschrieben werden, um der Kund:in maximale Transparenz zu ermöglichen. Darüber hinaus sollte sich im Vorfeld Gedanken gemacht werden, ob man bei der Open Source Stellung des Basiscodes auch den Code der zusätzlichen Funktionalitäten bereitstellt (bei Vertragsabschluss), oder ob dieser immer closed-source bleibt. Darüber hinaus sollte man eine Vereinbarung hinsichtlich neuer Features finden: sie diese für die zahlende Kund:in automatisch kostenfrei verfügbar, oder erfordert dies einen gesonderten Vertragsabschluss?

Lizenzauswahl:

Um Software legal nutzen zu können, müssen Rechte und Pflichten für Dritte transparent ersichtlich in einer beigefügten Softwarelizenz geregelt sein. Die Wahl der richtigen Lizenz erfolgt durch die Berücksichtigung von Randbedingungen, welche im Abschnitt Lizenzen näher beschrieben werden.

Lizenzvertrag:

Der Aufwand zur Erstellung von individualisierten Lizenzverträgen kann sehr hoch sein, insbesondere wenn diese Verträge mit den Lizenznehmern direkt ausverhandelt werden. Für Software, die einer Vielzahl von Lizenznehmern angeboten werden soll, ist es daher sinnvoll einen Standardvertrag zu entwickeln, dessen Inhalt nicht verhandelbar ist. Für die Formulierung von Rechten und Pflichten können ggf. auf die Ausformulierungen aus den Lizenzen zurückgegriffen werden. Sinnvoll ist es auch, für die Einrichtung gängige Formulierungen und Templates zur Wiedernutzung vorzuhalten.

Marketing und Vertrieb:

Marketing und die Art des Vertriebs zur Erhöhung der Nutzungszahlen einer Software ist ein umfangreiches Thema, welches hier nur angeschnitten werden soll. Innerhalb einer Kosten-/Nutzenanalyse könnten beispielsweise folgende Punkte evaluiert werden:

Erfolgsaussichten von passiver oder aktiver Bewerbung der Software
Ressourcen- bzw. finanzieller Aufwand für das Marketing
Integration auf Distributionsplattformen:
Plattformen der Community (z.B. Webseiten/Spotlight Pags/Flagship Stores der eigenen Einrichtung)
allgemeinen Softwareplattformen (z.B. Zenodo)
Packagedistributionsplatformen (z.B. PyPi)
Vertrieb auf Drittanbieterplattformen (z.B. Cloud-Anbieter)
Social Media Platformen (z.B. LinkedIn)
Softwareveröffentlichungen in Software Journals
Einrichtung geeigneter Google Metatags
Aktive Kundengewinnung via:
Kaltakquise - Direktansprache der Kund:innen - ggf. sehr aufwendig
direkte Kontaktaufnahme auf relevanten Messen, Konferenzen
Multiplikatoren (z.B. durch sehr gute Betreuung von Erstkunden, dadurch Weiterverbreitung über Empfehlungen)
Marktanalyse durchführen und Kundenverständnis gewinnen:
Hervorheben des Unique Selling Points
Vertriebsmodell kritisch betrachten:
Direktlizenzierung vs. Servicebereitstellung
werden mit dem Modell Kund:innen abgeholt
passt die Preisgestaltung zu den Vorstellungen der Kund:innen (Orientierung an Marktpreisen)
Hinweise zu gewählten Vertriebsmodellen anderer Forschungssoftware finden sich beispielsweise in der Dealdatenbank.

Zu beachten ist, dass Vertrieb und Marketing sehr zeitaufwendig sein kann und deswegen geklärt werden muss, ob dafür entsprechend Personal und Kompetenzen zur Verfügung stehen.

Moderation einer Open Source Community:

Um die Entwicklung einer Open Source Software zu forcieren ist es erstrebenswert eine Community rund um die Software mit aufzubauen, die sich ebenfalls aktiv an der Weiterentwicklung des Codes beteiligt. Vorbereitend dazu sollte der Software Code gut strukturiert und dokumentiert in einem Repository abgelegt werden, welches von der Community auch geforkt werden kann. Um die Hemmschwelle einer Beteiligung möglichst niedrig zu halten, sollten die Lizenzbedingungen, sowie der Prozess und die Regeln zur Weiterentwicklung so transparent wie möglich zu kommuniziert werden, letzteres zum Beispiel innerhalb eines Dokuments “Beteiligung” bzw. “contributing”. Darin sollte dargestellt sein, inwiefern eine Beteiligung durch Dritte erwünscht ist, z.B. sind Hinweise zu Bugs/Features erwünscht (z.B. über Issues), sind Pushs aus anderen Forks erwünscht oder kann direkt innerhalb des Repositories mitentwickelt werden, gibt es Vorschriften hinsichtlich der Code-Dokumentation bzw. hinsichtlich des Programmierstils und gibt es entsprechend automatische Checks dazu (z.B. über linting)? Auch sollte transparent dargestellt werden, wenn die Abgabe eines Contributing License Agreements (CLA) eine Vorbedingung ist, um überhaupt innerhalb des Codes mitzuwirken. Dieses Dokument sollte auch fertig definiert sein und innerhalb des Repositories zum Download bereitstehen. Um die Beteiligung der Community aufrechtzuerhalten sollte außerdem geklärt werden, wer als zuverlässiger Ansprechpartner fungiert, damit alle Anfragen auch zeitnah beantwortet werden, bzw. Vorschläge für Codeänderungen zeitnah gereviewt werden. Der Aufbau und die Aufrechterhaltung einer Community erfordern somit eine regelmäßige Aktivität der Verantwortlichen!

Nutzungsbedingungen für Services:

Die Vereinbarungen der Nutzungsbedingungen für Services beinhalten unter anderem Punkte zu Leistungsumfang, Laufzeit, Gewährleistung, Haftung, Datenschutz, Nutzermanagement, etc. Um den Überblick über die Vereinbarungen zu halten, werden idealerweise allen Kund:innen der Service zu einheitlichen Bedingungen angeboten (geregelt innerhalb von Allgemeinen Geschäftsbedingungen (AGBs)). Sind Individualverträge notwendig, spricht man eher von einem Service Level Agreement (SLA). Aus Sicht der Einrichtung sollte vor Vertragsabschluss über mögliche Backupvarianten zu bestimmten Leistungen nachgedacht werden, vor allem hinsichtlich personeller Verfügbarkeit: wer kann die entsprechenden Leistungen erbringen bei einem Ausfall der hauptverantwortlichen Person? Ggf. sollten innerhalb des Vertrags entsprechende Ausstiegsklauseln formuliert werden.

Open Source Veröffentlichung:

Der Verwertungsweg Open Source Veröffentlichung bezieht sich auf die Veröffentlichung von Software im Internet, um sie der Allgemeinheit zugänglich zu machen (beispielsweise realisiert durch die Einstellung “public” innerhalb eines Repositories auf GitLab/GitHub). Dies ist nicht zu verwechseln mit einer Sichtbarmachung des Codes gegenüber einem einzelnen Dritten (beispielsweise eines Lizenznehmers), dem zum Zwecke der Transparenz Einblick in den Code gestattet wird.

Rückanbietung/Rücklizenzierung:

Ist Software zum Verkauf vorgesehen, und kommt es damit zu einer IP Übertragung, so sollte innerhalb des Vertrags eine Klausel zur Rückanbietung/Rücklizenzierung ergänzt werden. Darin wird geregelt, dass der Einrichtung nach der Übertragung weiterhin Lizenzrechte gewährt werden, die zumindest die Nutzung und Weiterentwicklung der Software für wissenschaftliche/nicht-kommerzielle Zwecke, ggf. aber sogar zur weiteren kommerziellen Verwertung erlaubt. Bis zum Status des Verkaufs getätigte weitere Lizenzierungen der Einrichtung an Dritte müssten außerdem auch vom Käufer als Unterlizenz der Einrichtung akzeptiert werden, ggf. müssen dafür Vereinbarungen zu Vergütungsbeteiligungen getroffen werden (zum Beispiel 80%/20% Modell).

SaaS:

SaaS steht für “Software-as-a-Service” und umfasst alle Services, die im Zusammenhang mit Cloud Computing und Remote-Zugriff stehen, d.h. dem Zugriff auf eine Software über einen Webservice. Solche Webservices können über flexible Geschäftsmodelle angeboten werden und zielen nicht auf eine Softwareweitergabe bzw. Überlassung durch einen Verkauf oder eine Lizenzierung². Für die Verwertung von Forschungssoftware spielt SaaS eine bedeutende Rolle, da beispielsweise eine bereits Open Source veröffentliche Forschungssoftware dafür genutzt werden kann (je nach Lizenz).

Verwaltung der Software:

Softwareverwaltung umfasst die regelmäßige Wartung (Maintenance, Bug-Fixing) und Weiterentwicklung (Updates, Featureentwicklung) von Software. Ggf. muss auch eine regelmäßige Wartung und Aktualisierung der dazugehörigen Infrastruktur mit eingeplant werden. Bei lizenzierter Software kann das Updateintervall der Software individuell festgelegt werden, als kritisch sind hier nur sicherheitsrelevante oder funktionale Bugfixes zu sehen, welche als Patch außerhalb des vereinbarten Updateintervalls zur Verfügung gestellt werden. Bei SaaS Lösungen ist das Aktualisierungsintervall ggf. zeitkritischer, da jederzeit die Lauffähigkeit des Services sicherzustellen ist. Sinnvoll ist in diesem Zusammenhang eine klare Benennung von Verantwortlichkeiten und Zuständigkeiten innerhalb des Entwicklerteams.

Unterlizenzierung:

Unterlizenzierung behandelt die Fragestellung, ob ein Lizenznehmer eine (modifizierte) Software seinerseits auch an Dritte weiterlizenzieren darf. Dies sollte innerhalb von Lizenzverträgen individuell geregelt sein. Unterlizenzierung kann ausgeschlossen werden, wenn im Geschäftsmodell vorgesehen ist, dass Einnahmen vor allem durch eigene, direkte Lizenzierungen erreicht werden sollten. Unterlizenzierung kann aber auch bewusst zugelassen werden, beispielsweise mit einer Klausel, dass der ursprüngliche Lizenzgeber dann auch direkt davon mit profitiert.

Software, die unter einer FOSS Lizenz zur Verfügung gestellt wird, erlaubt immer die Weitergabe von (modifizierter) Software, ohne dass der ursprüngliche Lizenzgeber daran automatisch direkt mit beteiligt wird.

Zählbarkeit der Veröffentlichung:

Software erfährt zunehmend eine höhere Bedeutung als Teil der wissenschaftlichen Infrastruktur, weshalb aktuell unterschiedliche Metriken erstellt werden, um der Entwicklung einer Software einen gleichartigen Stellenwert einzuräumen, wie einer Publikation. Neben verschiedenen Kriterien, die evaluiert werden können, um den Wert einer Software einzuschätzen (unter anderem FAIR4RS Richtlinien³, direkte Nutzerverfolgung), ist für Wissenschaftler:innen vor allem eine direkte Zählbarkeit einer Softwareentwicklung relevant. Dies kann im einfachsten Fall durch die Zuweisung eines Digital Object Identifiers (DOI) realisiert werden. Dafür spezialisierte Plattformen, wie beispielsweise Zenodo⁴, erlauben sogar eine versionsabhängige DOI Zuweisung.

Eine zunehmende Sichtbarkeit, und damit auch eine erhöhte Chance durch Dritte in Nutzung zu gelangen, erfährt Software durch die Vorstellung in expliziten Software Artikeln in entsprechenden Fachjournalen (z.B. Journal of Open Source Software⁶, Journal of Open Research Software⁷), bzw. durch die Zitierung in anwendungsfokussierten, wissenschaftlichen Artikeln. Darüber hinaus kann Software in geeigneten Repositories (GitLab, GitHub), beziehungsweise durch Verlinkung zu wissenschaftlichen Softwaredatenbanken, wie beispielsweise das Helmholtz Research Software Directory⁵ oder über die Integration in gängige Softwarepackagerepositories (z.B. PyPI⁸ für Python Packages, CRAN für R Packages) in die Verbreitung gelangen.

Referenzen

---

1. Rajala, Risto & Rossi, Matti & Tuunainen, Virpi. (2003). A framework for analyzing software business models. pages 1614-1627. URL: https://www.researchgate.net/publication/221409264_A_framework_for_analyzing_software_business_models ↩

2. https://www.netapp.com/de/cloud-services/what-is-anything-as-a-service-xaas/ ↩

3. Chue Hong, Neil P., Katz, Daniel S., Barker, Michelle, Lamprecht, Anna-Lena, Martinez, Carlos, Psomopoulos, Fotis E., Harrow, Jen, Castro, Leyla Jael, Gruenpeter, Morane, Martinez, Paula Andrea, Honeyman, Tom, Struck, Alexander, Lee, Allen, Loewe, Axel, van Werkhoven, Ben, Jones, Catherine, Garijo, Daniel, Plomp, Esther, Genova, Francoise, … RDA FAIR4RS WG. (2022). FAIR Principles for Research Software (FAIR4RS Principles) (1.0). https://doi.org/10.15497/RDA00068 ↩

4. https://zenodo.org/ ↩

5. https://helmholtz.software/ ↩

6. https://joss.theoj.org/ ↩

7. https://openresearchsoftware.metajnl.com/ ↩

8. https://pypi.org/ ↩

9. https://cran.r-project.org/ ↩