{"id":873,"date":"2026-07-30T12:23:26","date_gmt":"2026-07-30T12:23:26","guid":{"rendered":"https:\/\/matforge.org\/?p=873","raw":"https:\/\/matforge.org\/?p=873"},"modified":"2026-07-30T12:23:26","modified_gmt":"2026-07-30T12:23:26","slug":"building-sustainable-research-software-communities","status":"publish","type":"post","link":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/","title":{"rendered":"Aufbau nachhaltiger Forschungssoftware-Communities","raw":"Aufbau nachhaltiger Forschungssoftware-Communities"},"content":{"rendered":"<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 7<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span><article>\n<p>Forschungssoftware beginnt oft als L\u00f6sung f\u00fcr ein bestimmtes wissenschaftliches Problem. Ein Forscher schreibt Code, um Daten zu verarbeiten, ein System zu simulieren, ein Experiment zu automatisieren oder eine Analyse zu reproduzieren. Wenn sich das Werkzeug als n\u00fctzlich erweist, h\u00e4ngen andere Forscher davon ab. Was als kleines Skript begann, kann f\u00fcr ein ganzes Feld zu einer wesentlichen Infrastruktur werden.<\/p>\n<p>Der technische Erfolg garantiert nicht das langfristige \u00dcberleben. Viele wertvolle Werkzeuge werden schwierig zu warten, nachdem ein Stipendium beendet ist, ein studentischer Absolvent oder der urspr\u00fcngliche Entwickler den Job wechselt. Nachhaltige Forschungssoftware erfordert daher mehr als zuverl\u00e4ssigen Code. Es braucht eine Community, die Wissen austauschen, Benutzer unterst\u00fctzen, Entscheidungen treffen, Mitwirkende ausbilden und Ressourcen im Laufe der Zeit sichern kann.<\/p>\n<h2>Was ist eine Forschungssoftware-Community?<\/h2>\n<p>Eine Forschungssoftware-Community umfasst jeden, der zur Erstellung, Verwendung, Unterst\u00fctzung und Leitung eines Projekts beitr\u00e4gt. Kernentwickler sind nur ein Teil dieser Gruppe. Benutzer, Forschungssoftwareingenieure, Dokumentationsschreiber, Tester, Trainer, institutionelle Partner, Geldgeber und Domain-Experten k\u00f6nnen alle wichtige Rollen spielen.<\/p>\n<p>Einige Mitglieder bringen Code bei. Andere melden Fehler, bereiten Beispiele vor, \u00fcberpr\u00fcfen wissenschaftliche Methoden, verbessern Tutorials, beantworten Fragen oder testen die Software auf verschiedenen Systemen. Eine gesunde Gemeinschaft erkennt alle diese Aktivit\u00e4ten als sinnvolle Beitr\u00e4ge an.<\/p>\n<h2>Nachhaltigkeit ist mehr als Wartung<\/h2>\n<p>Software-Wartung bedeutet normalerweise das Beheben von Fehlern, das Aktualisieren von Abh\u00e4ngigkeiten und die Kompatibilit\u00e4t eines Programms mit aktuellen Systemen. Nachhaltigkeit ist breiter. Es umfasst technische, soziale, finanzielle und institutionelle Kontinuit\u00e4t.<\/p>\n<p>Eine starke Codebasis kann immer noch fehlschlagen, wenn eine Person wesentliche Kenntnisse kontrolliert oder Betreuer keine Zeit f\u00fcr Unterst\u00fctzung erhalten. Nachhaltige Software bleibt verst\u00e4ndlich, nutzbar und wissenschaftlich vertrauensw\u00fcrdig, wenn sich Menschen, Technologien und Finanzierungsbedingungen \u00e4ndern.<\/p>\n<h2>Beginnen Sie mit einer klaren Mission<\/h2>\n<p>Eine Community muss verstehen, wof\u00fcr die Software ausgelegt ist und welche Probleme au\u00dferhalb ihres Geltungsbereichs liegen. Eine klare Mission hilft den Benutzern bei der Entscheidung, ob das Tool angemessen ist, und hilft den Betreuern bei der Bewertung von Funktionsanforderungen.<\/p>\n<p>Die Mission sollte das wissenschaftliche Hauptproblem, die Zielgruppe und die zentralen Anwendungsf\u00e4lle identifizieren. Es sollte auch wichtige Ausschl\u00fcsse enthalten. Ohne Grenzen kann ein Projekt unabh\u00e4ngige Funktionen sammeln, bis die Wartung un\u00fcberschaubar wird. Eine fokussierte Mission gibt dem Wachstum eine klare Richtung.<\/p>\n<h2>transparente Governance schaffen<\/h2>\n<p>Kleine Projekte st\u00fctzen sich oft auf informelle Entscheidungen. Dies kann funktionieren, w\u00e4hrend das Team nur wenige Personen enth\u00e4lt. Wenn die Gemeinschaft w\u00e4chst, kann unklare Autorit\u00e4t zu Verz\u00f6gerungen und Konflikten f\u00fchren.<\/p>\n<p>Governance erkl\u00e4rt, wie Entscheidungen getroffen werden, wer Releases genehmigen kann, wie die Betreuer ausgew\u00e4hlt werden und wie Unstimmigkeiten gehandhabt werden. Ein Projekt kann einen Lead-Betreuer, einen Betreuer-Rat oder einen Lenkungsausschuss verwenden. Die Mitwirkenden sollten wissen, wo Vorschl\u00e4ge besprochen werden, wer die endg\u00fcltige Verantwortung tr\u00e4gt und wie sie in die Projektleitung einsteigen k\u00f6nnen.<\/p>\n<h2>Rollen definieren und Verantwortung verteilen<\/h2>\n<p>Projekte werden fragil, wenn jede wichtige Aufgabe an den Gr\u00fcnder zur\u00fcckkehrt. Die Verantwortlichkeiten sollten auf Rollen wie Betreuer, Pr\u00fcfer, Release-Manager, Dokumentationsleitung, Sicherheitskontakt und Community-Koordinator verteilt werden.<\/p>\n<p>Eine Person kann mehrere Rollen in einem kleinen Projekt innehaben, aber die Aufgaben sollten immer noch dokumentiert werden. Dies macht unsichtbare Arbeit sichtbar und hilft dem Team, L\u00fccken zu erkennen. Rollenbeschreibungen unterst\u00fctzen auch die Nachfolge, indem sie zeigen, was erforderlich ist, um ein Gutachter oder Betreuer zu werden.<\/p>\n<h2>Abh\u00e4ngigkeit von Schl\u00fcsselpersonen verringern<\/h2>\n<p>Der Verlust einer Person sollte die Ver\u00f6ffentlichungen nicht stoppen, den Zugriff auf wesentliche Dienste entfernen oder die Architektur nicht verst\u00e4ndlich machen. Projekte k\u00f6nnen dieses Risiko verringern, indem sie den administrativen Zugriff teilen, Freigabeverfahren dokumentieren, wichtige \u00c4nderungen gemeinsam \u00fcberpr\u00fcfen und wichtige technische Entscheidungen aufzeichnen.<\/p>\n<p>Mindestens zwei vertrauensw\u00fcrdige Personen sollten wichtige Vorg\u00e4nge wie das Ver\u00f6ffentlichen von Paketen, das Verwalten von Dom\u00e4nen, das Erneuern von Zertifikaten und das Wiederherstellen von Sicherungen verstehen. Der Wissenstransfer sollte kontinuierlich und nicht nur dann erfolgen, wenn ein Betreuer eine Abreise ank\u00fcndigt.<\/p>\n<h2>den ersten Beitrag erzielbar machen<\/h2>\n<p>Ein einladender Beitragsweg ist eines der st\u00e4rksten Zeichen einer gesunden Gemeinschaft. Neue Teilnehmer sollten in der Lage sein, Installationsanweisungen, Entwicklungsschritte, Testbefehle, Codierungsstandards und Pull-Anforderungserwartungen zu finden, ohne sich auf private Hilfe zu verlassen.<\/p>\n<p>Eine klare <code>CONTRIBUTING<\/code>-Datei kann den Prozess erkl\u00e4ren. Gut vorbereitete Anf\u00e4ngerprobleme sollten Kontext, erwartetes Verhalten, relevante Dateien und eine Kontaktperson umfassen. Ziel ist es, vermeidbare Verwirrung zu beseitigen, damit sich die Mitwirkenden auf das wissenschaftliche oder technische Problem konzentrieren k\u00f6nnen.<\/p>\n<h2>Beitr\u00e4ge \u00fcber den Code hinaus unterst\u00fctzen<\/h2>\n<p>Die Forschungssoftware h\u00e4ngt von Aktivit\u00e4ten ab, die keinen Quellcode erzeugen. Benutzer k\u00f6nnen Beispiele verbessern, Installationsanweisungen testen, Dokumentationen \u00fcbersetzen, Lehrmaterialien erstellen, Ergebnisse validieren, Workshops organisieren oder Supportfragen beantworten.<\/p>\n<p>Projekte sollten diese M\u00f6glichkeiten klar beschreiben. Die Anerkennung sollte die geleistete Arbeit widerspiegeln. Mitwirkende Listen, Versionshinweise, Projektwebsites und Zitationsleitf\u00e4den k\u00f6nnen technische, wissenschaftliche, p\u00e4dagogische und Community-Beitr\u00e4ge anerkennen.<\/p>\n<h2>Dokumentation als Kernprodukt behandeln<\/h2>\n<p>Die Dokumentation ist Teil der Software, keine optionale Erg\u00e4nzung. Benutzer ben\u00f6tigen ein Installationshandbuch, ein kurzes erstes Beispiel, konzeptionelle Erkl\u00e4rungen, API-Referenzen, Informationen zur Fehlerbehebung und vollst\u00e4ndige Workflows.<\/p>\n<p>Unterschiedliche Leser brauchen unterschiedliche Wege. Ein Anf\u00e4nger ben\u00f6tigt m\u00f6glicherweise ein zehnmin\u00fctiges Tutorial. Ein erfahrener Forscher ben\u00f6tigt m\u00f6glicherweise genaue Parameterdefinitionen. Ein Mitwirkender ben\u00f6tigt m\u00f6glicherweise Architekturnotizen und Testanweisungen. Die Dokumentation sollte mit Code\u00e4nderungen \u00fcberpr\u00fcft werden, und Beispiele sollten nach M\u00f6glichkeit automatisch getestet werden.<\/p>\n<h2>Reproduzierbarkeit in das Projekt einbauen<\/h2>\n<p>Die Forschungssoftware soll den Benutzern helfen, genau zu identifizieren, welche Version ein Ergebnis hervorgerufen hat. Stabile Releases, versionierte Dokumentation, archivierte Pakete und Umgebungsdateien machen dies m\u00f6glich.<\/p>\n<p>Beispiele sollten erforderliche Daten, Abh\u00e4ngigkeiten, Konfigurationseinstellungen und zuf\u00e4llige Starts sein, falls relevant. Publikationen sollten sich auf eine bestimmte Softwareversion beziehen, anstatt nur auf ein sich \u00e4nderndes Repository zu verlinken. Langzeitarchive und persistente Kennungen verbinden wissenschaftliche Behauptungen mit der exakten Software.<\/p>\n<h2>faire Prinzipien anwenden<\/h2>\n<p>Forschungssoftware sollte auffindbar, zug\u00e4nglich, interoperabel und wiederverwendbar sein. Die Suchbarkeit erfordert n\u00fctzliche Metadaten, durchsuchbare Register, klare Projektnamen und persistente Bezeichner. Die Barrierefreiheit erfordert dokumentierte M\u00f6glichkeiten, um die Software und ihre Metadaten zu erhalten.<\/p>\n<p>Die Interoperabilit\u00e4t verbessert sich, wenn Projekte Standardformate, stabile Schnittstellen und klar beschriebene Ein- und Ausg\u00e4nge verwenden. Die Wiederverwendbarkeit h\u00e4ngt von der Lizenzierung, Dokumentation, Herkunft, Tests und dem ausreichenden Kontext ab, um die Software korrekt anzuwenden. Das Ver\u00f6ffentlichen eines Repositorys reicht nicht aus, wenn Benutzer es nicht verstehen, installieren oder legal wiederverwenden k\u00f6nnen.<\/p>\n<h2>W\u00e4hlen Sie eine klare Lizenz- und Zitationsrichtlinie<\/h2>\n<p>Ohne eine Lizenz haben potenzielle Benutzer m\u00f6glicherweise keine gesetzliche Erlaubnis, die Software wiederzuverwenden, zu \u00e4ndern oder weiterzuverteilen. Projekte sollten eine Lizenz ausw\u00e4hlen, die ihren Zielen entspricht und mit den eingeschlossenen Abh\u00e4ngigkeiten kompatibel ist.<\/p>\n<p>Code, Dokumentation und Beispieldaten erfordern m\u00f6glicherweise separate Lizenzen. Projekte sollten auch erkl\u00e4ren, wie die Software zitiert werden sollte. Eine <code>CITATION.cff<\/code>-Datei und ein DOI f\u00fcr stabile Releases erleichtern das Zitieren.<\/p>\n<h2>Erstellen Sie respektvolle und integrative Praktiken<\/h2>\n<p>Menschen tragen eher dazu bei, wenn Fragen respektvolle Antworten erhalten und Fehler als Teil des Lernens behandelt werden. Ein Verhaltenskodex sollte das erwartete Verhalten beschreiben und einen praktischen Berichterstattungsprozess bereitstellen.<\/p>\n<p>Die Kommunikation sollte verschiedene Zeitzonen, Sprachen, F\u00e4higkeiten und Erfahrungsstufen unterst\u00fctzen. Meetings k\u00f6nnen f\u00fcr Personen dokumentiert werden, die nicht teilnehmen k\u00f6nnen. Wichtige technische Diskussionen sollten in \u00f6ffentlichen Themen, Vorschl\u00e4gen oder Entscheidungsaufzeichnungen verf\u00fcgbar bleiben, wann immer Datenschutz und Sicherheit dies zulassen.<\/p>\n<h2>Nutzen Sie Kommunikationskan\u00e4le bewusst<\/h2>\n<p>Issue Tracker sind n\u00fctzlich f\u00fcr reproduzierbare M\u00e4ngel und geplante Aufgaben. Diskussionsforen unterst\u00fctzen Fragen und Vorschl\u00e4ge. Chat-Tools helfen bei der kurzen Koordination. Mailinglisten und Release-Notizen kommunizieren offizielle Updates.<\/p>\n<p>Wichtige Entscheidungen sollten nicht in privaten Nachrichten oder tempor\u00e4ren Chats verschwinden. Eine \u00f6ffentliche Zusammenfassung bewahrt die Argumentation und verhindert wiederholte Debatten. Projekte sollten auch realistische Reaktionszeiten angeben.<\/p>\n<h2>Anfragen mit Projektkapazit\u00e4t ausgleichen<\/h2>\n<p>Erfolgreiche Projekte erhalten oft mehr Feature-Anfragen, als das Team umsetzen kann. Jede neue Funktion schafft zuk\u00fcnftige Arbeit in den Bereichen Test, Dokumentation, Support und Kompatibilit\u00e4t.<\/p>\n<p>Anfragen sollten anhand der Projektmission, des wissenschaftlichen Werts, der wahrscheinlichen Anzahl der Benutzer, der Implementierungskosten und der Wartungsbelastung bewertet werden. Einige Ideen k\u00f6nnen besser als Plugins oder externe Pakete entwickelt werden. Nein zu sagen kann die Zuverl\u00e4ssigkeit sch\u00fctzen und die \u00dcberlastung der Wartungskr\u00e4fte verhindern.<\/p>\n<h2>Etablieren Sie vorhersehbare Qualit\u00e4ts- und Freigabepraktiken<\/h2>\n<p>Automatisiertes Testen, kontinuierliche Integration, Code-\u00dcberpr\u00fcfung, Formatierungspr\u00fcfungen und Freigabe-Checklisten verringern die Abh\u00e4ngigkeit vom individuellen Speicher. Sie helfen den Mitwirkenden auch zu verstehen, ob eine \u00c4nderung bereit ist.<\/p>\n<p>Releases sollten einer dokumentierten Versionierungsrichtlinie folgen und ein Changelog enthalten. Um \u00c4nderungen zu unterbrechen, sind Abschreibungsbenachrichtigungen und Migrationsrichtlinien erforderlich. Die Qualit\u00e4tsanforderungen sollten praktisch bleiben, damit kleine Verbesserungen nicht unn\u00f6tig schwierig werden.<\/p>\n<h2>Planung f\u00fcr Sicherheit<\/h2>\n<p>Forschungssoftware kann sensible Daten verarbeiten, auf gemeinsam genutzten Systemen laufen oder Teil kritischer Workflows werden. Communities ben\u00f6tigen eine private M\u00f6glichkeit, Schwachstellen zu melden, und einen Prozess zum Freigeben von Korrekturen.<\/p>\n<p>Repository-Zugriff, Paketregistrierungen, Dom\u00e4nen und Automatisierungsanmeldeinformationen sollten starke Authentifizierungs- und Sicherungsadministratoren verwenden. Abh\u00e4ngigkeiten sollten auf bekannte Probleme \u00fcberwacht werden. Wissenschaftliche Korrektheit und Sicherheit sind getrennte Verantwortlichkeiten, und beide erfordern Aufmerksamkeit.<\/p>\n<h2>Entwickeln Sie ein realistisches Finanzierungsmodell<\/h2>\n<p>Erste Zusch\u00fcsse unterst\u00fctzen h\u00e4ufig neue Funktionen, bieten jedoch nur eine begrenzte Finanzierung f\u00fcr die Wartung. Nachhaltige Projekte m\u00fcssen f\u00fcr Abh\u00e4ngigkeitsaktualisierungen, Dokumentation, Unterst\u00fctzung, \u00dcberpr\u00fcfung, Infrastruktur, Sicherheit und Koordinierung der Gemeinde einplanen.<\/p>\n<p>Die Finanzierung kann durch Forschungsstipendien, institutionelle Unterst\u00fctzung, Wartungsprogramme, Konsortialmitgliedschaft, Schulungen, Beratung oder Partnerschaften erfolgen. Die meisten Projekte profitieren von der Kombination mehrerer Quellen. Die Finanzierungspl\u00e4ne sollten den \u00f6ffentlichen Versprechen entsprechen, da ein kleines Freiwilligenteam nicht unbegrenzte Unterst\u00fctzung und schnelle Ver\u00f6ffentlichungen auf unbestimmte Zeit bieten kann.<\/p>\n<h2>institutionelle Unterst\u00fctzung aufbauen<\/h2>\n<p>Universit\u00e4ten und Forschungsorganisationen k\u00f6nnen die Nachhaltigkeit verbessern, indem sie Software als Forschungsausgaben erkennen und professionelle Forschungssoftware-Engineeringrollen unterst\u00fctzen.<\/p>\n<p>Zentrale Teams k\u00f6nnen Fachwissen in den Bereichen Testing, Architektur, Lizenzierung, Sicherheit und Bereitstellung bereitstellen. Institutionen k\u00f6nnen auch Repositories, Schulungsprogramme, rechtliche Unterst\u00fctzung und permanente technische Positionen unterhalten.<\/p>\n<h2>Trainieren Sie zuk\u00fcnftige Betreuer<\/h2>\n<p>Communities sollten einen Pfad vom Benutzer zum Mitwirkenden, zum Pr\u00fcfer und zum Betreuer erstellen. Mentoring, gepaarte Bewertungen, Architekturexemplare und gemeinsame Release-Arbeit helfen den Menschen, Vertrauen zu gewinnen.<\/p>\n<p>Die Verantwortung kann schrittweise eingef\u00fchrt werden. Ein Mitwirkender kann zun\u00e4chst ein Modul unterhalten, Dokumentations\u00e4nderungen \u00fcberpr\u00fcfen oder eine kleine Version koordinieren. Ein Nachfolgeplan sollte erkl\u00e4ren, wie Pfleger hinzugef\u00fcgt werden, wie der Zugriff \u00fcbertragen wird und was passiert, wenn ein Lead nach unten tritt.<\/p>\n<h2>Messen Sie die Gesundheit der Gemeinschaft sorgf\u00e4ltig<\/h2>\n<p>Downloads, Stars und Zitate zeigen Sichtbarkeit, beschreiben jedoch nicht vollst\u00e4ndig die Nachhaltigkeit. Weitere n\u00fctzliche Signale sind die Anzahl der aktiven Betreuer, die Verteilung der Beitr\u00e4ge, die \u00dcberpr\u00fcfungszeit, die Beibehaltung der Mitwirkenden, die Dokumentationsaktivit\u00e4t und die Regelm\u00e4\u00dfigkeit der Freisetzung.<\/p>\n<p>Metriken sollten eher Reflexion als Wettbewerb unterst\u00fctzen. Das Z\u00e4hlen von Commits oder Codezeilen kann Mentoring, \u00dcberpr\u00fcfung, Unterst\u00fctzung und Projektmanagement unterbewerten. Die zentrale Frage ist, ob die Gemeinschaft die wesentliche Arbeit fortsetzen kann, ohne eine kleine Gruppe zu ersch\u00f6pfen.<\/p>\n<h2>Wissen, wann der Umfang oder das Archiv reduziert werden m\u00fcssen<\/h2>\n<p>Nicht jedes Projekt sollte f\u00fcr immer wachsen. Eine Community kann in den Wartungsmodus wechseln, wenn die Software stabil ist, die Nutzung begrenzt ist oder der Ressourcenabfall sinkt. Es kann auch eine besser unterst\u00fctzte Alternative empfehlen.<\/p>\n<p>Wenn eine sichere Wartung nicht mehr m\u00f6glich ist, ist eine verantwortungsvolle Archivierung besser als die stille Aufgabe. Das Team sollte eine endg\u00fcltige Version ver\u00f6ffentlichen, die Dokumentation und den Quellcode beibehalten, das Projekt als archiviert markieren und den Support-Status erl\u00e4utern. Ein archiviertes Projekt kann f\u00fcr die historische Reproduzierbarkeit noch wertvoll bleiben.<\/p>\n<h2>Eine praktische Nachhaltigkeits-Checkliste<\/h2>\n<table class=\"custom-table\">\n<tbody>\n<tr>\n<th>Bereich<\/th>\n<th>Schl\u00fcsselfrage<\/th>\n<\/tr>\n<tr>\n<td>Mission<\/td>\n<td>Ist der wissenschaftliche Zweck und der Projektumfang klar?<\/td>\n<\/tr>\n<tr>\n<td>Regierungsf\u00fchrung<\/td>\n<td>Verstehen die Mitwirkenden, wie Entscheidungen getroffen werden?<\/td>\n<\/tr>\n<tr>\n<td>Mitwirkende<\/td>\n<td>Kann ein neuer Teilnehmer einen ersten Beitrag abschlie\u00dfen?<\/td>\n<\/tr>\n<tr>\n<td>Dokumentation<\/td>\n<td>K\u00f6nnen Benutzer ohne direkte Hilfe der Autoren beginnen?<\/td>\n<\/tr>\n<tr>\n<td>Kredit<\/td>\n<td>Werden codierende und nicht codierende Beitr\u00e4ge anerkannt?<\/td>\n<\/tr>\n<tr>\n<td>Finanzierung<\/td>\n<td>Sind Wartungs- und Gemeinschaftsaufgaben in den Budgets enthalten?<\/td>\n<\/tr>\n<tr>\n<td>Kontinuit\u00e4t<\/td>\n<td>Kann das Projekt ohne seinen Gr\u00fcnder fortgesetzt werden?<\/td>\n<\/tr>\n<tr>\n<td>Sicherheit<\/td>\n<td>Gibt es einen Prozess zur Berichterstellung und Behebung von Schwachstellen?<\/td>\n<\/tr>\n<tr>\n<td>Ausstiegsplan<\/td>\n<td>Kann die Software verantwortungsbewusst in den Wartungs- oder Archivmodus verlagern?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Schlussfolgerung<\/h2>\n<p>Nachhaltige Forschungssoftware-Communities werden durch eine Kombination aus zuverl\u00e4ssiger Technologie und starken sozialen Strukturen aufgebaut. Guter Kodex ist wichtig, aber auch Governance, Dokumentation, Unterst\u00fctzung bei der Unterst\u00fctzung, Anerkennung, Finanzierung, Sicherheit und Nachfolge.<\/p>\n<p>Die st\u00e4rksten Projekte machen die Teilnahme verst\u00e4ndlich und verteilen Verantwortung \u00fcber den urspr\u00fcnglichen Autor hinaus. Sie verbinden Softwareversionen mit Rechercheergebnissen, erkennen viele Formen des Beitrags und kommunizieren ehrlich \u00fcber Kapazit\u00e4t.<\/p>\n<p>Eine nachhaltige Gemeinschaft muss nicht auf unbestimmte Zeit expandieren. Es braucht die F\u00e4higkeit, die Software zu warten, anzupassen, zu \u00fcbertragen oder verantwortungsbewusst zu archivieren, wenn sich wissenschaftliche Bed\u00fcrfnisse \u00e4ndern. Wenn diese Praktiken fr\u00fchzeitig eingerichtet werden, kann die Forschungssoftware lange nach dem ersten Zuschuss-, Ver\u00f6ffentlichungs- oder Entwicklungsteam n\u00fctzlich bleiben.<\/p>\n<\/article>\n","protected":false,"raw":"<article>\n<p>Forschungssoftware beginnt oft als L\u00f6sung f\u00fcr ein bestimmtes wissenschaftliches Problem. Ein Forscher schreibt Code, um Daten zu verarbeiten, ein System zu simulieren, ein Experiment zu automatisieren oder eine Analyse zu reproduzieren. Wenn sich das Werkzeug als n\u00fctzlich erweist, h\u00e4ngen andere Forscher davon ab. Was als kleines Skript begann, kann f\u00fcr ein ganzes Feld zu einer wesentlichen Infrastruktur werden.<\/p>\n<p>Der technische Erfolg garantiert nicht das langfristige \u00dcberleben. Viele wertvolle Werkzeuge werden schwierig zu warten, nachdem ein Stipendium beendet ist, ein studentischer Absolvent oder der urspr\u00fcngliche Entwickler den Job wechselt. Nachhaltige Forschungssoftware erfordert daher mehr als zuverl\u00e4ssigen Code. Es braucht eine Community, die Wissen austauschen, Benutzer unterst\u00fctzen, Entscheidungen treffen, Mitwirkende ausbilden und Ressourcen im Laufe der Zeit sichern kann.<\/p>\n<h2>Was ist eine Forschungssoftware-Community?<\/h2>\n<p>Eine Forschungssoftware-Community umfasst jeden, der zur Erstellung, Verwendung, Unterst\u00fctzung und Leitung eines Projekts beitr\u00e4gt. Kernentwickler sind nur ein Teil dieser Gruppe. Benutzer, Forschungssoftwareingenieure, Dokumentationsschreiber, Tester, Trainer, institutionelle Partner, Geldgeber und Domain-Experten k\u00f6nnen alle wichtige Rollen spielen.<\/p>\n<p>Einige Mitglieder bringen Code bei. Andere melden Fehler, bereiten Beispiele vor, \u00fcberpr\u00fcfen wissenschaftliche Methoden, verbessern Tutorials, beantworten Fragen oder testen die Software auf verschiedenen Systemen. Eine gesunde Gemeinschaft erkennt alle diese Aktivit\u00e4ten als sinnvolle Beitr\u00e4ge an.<\/p>\n<h2>Nachhaltigkeit ist mehr als Wartung<\/h2>\n<p>Software-Wartung bedeutet normalerweise das Beheben von Fehlern, das Aktualisieren von Abh\u00e4ngigkeiten und die Kompatibilit\u00e4t eines Programms mit aktuellen Systemen. Nachhaltigkeit ist breiter. Es umfasst technische, soziale, finanzielle und institutionelle Kontinuit\u00e4t.<\/p>\n<p>Eine starke Codebasis kann immer noch fehlschlagen, wenn eine Person wesentliche Kenntnisse kontrolliert oder Betreuer keine Zeit f\u00fcr Unterst\u00fctzung erhalten. Nachhaltige Software bleibt verst\u00e4ndlich, nutzbar und wissenschaftlich vertrauensw\u00fcrdig, wenn sich Menschen, Technologien und Finanzierungsbedingungen \u00e4ndern.<\/p>\n<h2>Beginnen Sie mit einer klaren Mission<\/h2>\n<p>Eine Community muss verstehen, wof\u00fcr die Software ausgelegt ist und welche Probleme au\u00dferhalb ihres Geltungsbereichs liegen. Eine klare Mission hilft den Benutzern bei der Entscheidung, ob das Tool angemessen ist, und hilft den Betreuern bei der Bewertung von Funktionsanforderungen.<\/p>\n<p>Die Mission sollte das wissenschaftliche Hauptproblem, die Zielgruppe und die zentralen Anwendungsf\u00e4lle identifizieren. Es sollte auch wichtige Ausschl\u00fcsse enthalten. Ohne Grenzen kann ein Projekt unabh\u00e4ngige Funktionen sammeln, bis die Wartung un\u00fcberschaubar wird. Eine fokussierte Mission gibt dem Wachstum eine klare Richtung.<\/p>\n<h2>transparente Governance schaffen<\/h2>\n<p>Kleine Projekte st\u00fctzen sich oft auf informelle Entscheidungen. Dies kann funktionieren, w\u00e4hrend das Team nur wenige Personen enth\u00e4lt. Wenn die Gemeinschaft w\u00e4chst, kann unklare Autorit\u00e4t zu Verz\u00f6gerungen und Konflikten f\u00fchren.<\/p>\n<p>Governance erkl\u00e4rt, wie Entscheidungen getroffen werden, wer Releases genehmigen kann, wie die Betreuer ausgew\u00e4hlt werden und wie Unstimmigkeiten gehandhabt werden. Ein Projekt kann einen Lead-Betreuer, einen Betreuer-Rat oder einen Lenkungsausschuss verwenden. Die Mitwirkenden sollten wissen, wo Vorschl\u00e4ge besprochen werden, wer die endg\u00fcltige Verantwortung tr\u00e4gt und wie sie in die Projektleitung einsteigen k\u00f6nnen.<\/p>\n<h2>Rollen definieren und Verantwortung verteilen<\/h2>\n<p>Projekte werden fragil, wenn jede wichtige Aufgabe an den Gr\u00fcnder zur\u00fcckkehrt. Die Verantwortlichkeiten sollten auf Rollen wie Betreuer, Pr\u00fcfer, Release-Manager, Dokumentationsleitung, Sicherheitskontakt und Community-Koordinator verteilt werden.<\/p>\n<p>Eine Person kann mehrere Rollen in einem kleinen Projekt innehaben, aber die Aufgaben sollten immer noch dokumentiert werden. Dies macht unsichtbare Arbeit sichtbar und hilft dem Team, L\u00fccken zu erkennen. Rollenbeschreibungen unterst\u00fctzen auch die Nachfolge, indem sie zeigen, was erforderlich ist, um ein Gutachter oder Betreuer zu werden.<\/p>\n<h2>Abh\u00e4ngigkeit von Schl\u00fcsselpersonen verringern<\/h2>\n<p>Der Verlust einer Person sollte die Ver\u00f6ffentlichungen nicht stoppen, den Zugriff auf wesentliche Dienste entfernen oder die Architektur nicht verst\u00e4ndlich machen. Projekte k\u00f6nnen dieses Risiko verringern, indem sie den administrativen Zugriff teilen, Freigabeverfahren dokumentieren, wichtige \u00c4nderungen gemeinsam \u00fcberpr\u00fcfen und wichtige technische Entscheidungen aufzeichnen.<\/p>\n<p>Mindestens zwei vertrauensw\u00fcrdige Personen sollten wichtige Vorg\u00e4nge wie das Ver\u00f6ffentlichen von Paketen, das Verwalten von Dom\u00e4nen, das Erneuern von Zertifikaten und das Wiederherstellen von Sicherungen verstehen. Der Wissenstransfer sollte kontinuierlich und nicht nur dann erfolgen, wenn ein Betreuer eine Abreise ank\u00fcndigt.<\/p>\n<h2>den ersten Beitrag erzielbar machen<\/h2>\n<p>Ein einladender Beitragsweg ist eines der st\u00e4rksten Zeichen einer gesunden Gemeinschaft. Neue Teilnehmer sollten in der Lage sein, Installationsanweisungen, Entwicklungsschritte, Testbefehle, Codierungsstandards und Pull-Anforderungserwartungen zu finden, ohne sich auf private Hilfe zu verlassen.<\/p>\n<p>Eine klare <code>CONTRIBUTING<\/code>-Datei kann den Prozess erkl\u00e4ren. Gut vorbereitete Anf\u00e4ngerprobleme sollten Kontext, erwartetes Verhalten, relevante Dateien und eine Kontaktperson umfassen. Ziel ist es, vermeidbare Verwirrung zu beseitigen, damit sich die Mitwirkenden auf das wissenschaftliche oder technische Problem konzentrieren k\u00f6nnen.<\/p>\n<h2>Beitr\u00e4ge \u00fcber den Code hinaus unterst\u00fctzen<\/h2>\n<p>Die Forschungssoftware h\u00e4ngt von Aktivit\u00e4ten ab, die keinen Quellcode erzeugen. Benutzer k\u00f6nnen Beispiele verbessern, Installationsanweisungen testen, Dokumentationen \u00fcbersetzen, Lehrmaterialien erstellen, Ergebnisse validieren, Workshops organisieren oder Supportfragen beantworten.<\/p>\n<p>Projekte sollten diese M\u00f6glichkeiten klar beschreiben. Die Anerkennung sollte die geleistete Arbeit widerspiegeln. Mitwirkende Listen, Versionshinweise, Projektwebsites und Zitationsleitf\u00e4den k\u00f6nnen technische, wissenschaftliche, p\u00e4dagogische und Community-Beitr\u00e4ge anerkennen.<\/p>\n<h2>Dokumentation als Kernprodukt behandeln<\/h2>\n<p>Die Dokumentation ist Teil der Software, keine optionale Erg\u00e4nzung. Benutzer ben\u00f6tigen ein Installationshandbuch, ein kurzes erstes Beispiel, konzeptionelle Erkl\u00e4rungen, API-Referenzen, Informationen zur Fehlerbehebung und vollst\u00e4ndige Workflows.<\/p>\n<p>Unterschiedliche Leser brauchen unterschiedliche Wege. Ein Anf\u00e4nger ben\u00f6tigt m\u00f6glicherweise ein zehnmin\u00fctiges Tutorial. Ein erfahrener Forscher ben\u00f6tigt m\u00f6glicherweise genaue Parameterdefinitionen. Ein Mitwirkender ben\u00f6tigt m\u00f6glicherweise Architekturnotizen und Testanweisungen. Die Dokumentation sollte mit Code\u00e4nderungen \u00fcberpr\u00fcft werden, und Beispiele sollten nach M\u00f6glichkeit automatisch getestet werden.<\/p>\n<h2>Reproduzierbarkeit in das Projekt einbauen<\/h2>\n<p>Die Forschungssoftware soll den Benutzern helfen, genau zu identifizieren, welche Version ein Ergebnis hervorgerufen hat. Stabile Releases, versionierte Dokumentation, archivierte Pakete und Umgebungsdateien machen dies m\u00f6glich.<\/p>\n<p>Beispiele sollten erforderliche Daten, Abh\u00e4ngigkeiten, Konfigurationseinstellungen und zuf\u00e4llige Starts sein, falls relevant. Publikationen sollten sich auf eine bestimmte Softwareversion beziehen, anstatt nur auf ein sich \u00e4nderndes Repository zu verlinken. Langzeitarchive und persistente Kennungen verbinden wissenschaftliche Behauptungen mit der exakten Software.<\/p>\n<h2>faire Prinzipien anwenden<\/h2>\n<p>Forschungssoftware sollte auffindbar, zug\u00e4nglich, interoperabel und wiederverwendbar sein. Die Suchbarkeit erfordert n\u00fctzliche Metadaten, durchsuchbare Register, klare Projektnamen und persistente Bezeichner. Die Barrierefreiheit erfordert dokumentierte M\u00f6glichkeiten, um die Software und ihre Metadaten zu erhalten.<\/p>\n<p>Die Interoperabilit\u00e4t verbessert sich, wenn Projekte Standardformate, stabile Schnittstellen und klar beschriebene Ein- und Ausg\u00e4nge verwenden. Die Wiederverwendbarkeit h\u00e4ngt von der Lizenzierung, Dokumentation, Herkunft, Tests und dem ausreichenden Kontext ab, um die Software korrekt anzuwenden. Das Ver\u00f6ffentlichen eines Repositorys reicht nicht aus, wenn Benutzer es nicht verstehen, installieren oder legal wiederverwenden k\u00f6nnen.<\/p>\n<h2>W\u00e4hlen Sie eine klare Lizenz- und Zitationsrichtlinie<\/h2>\n<p>Ohne eine Lizenz haben potenzielle Benutzer m\u00f6glicherweise keine gesetzliche Erlaubnis, die Software wiederzuverwenden, zu \u00e4ndern oder weiterzuverteilen. Projekte sollten eine Lizenz ausw\u00e4hlen, die ihren Zielen entspricht und mit den eingeschlossenen Abh\u00e4ngigkeiten kompatibel ist.<\/p>\n<p>Code, Dokumentation und Beispieldaten erfordern m\u00f6glicherweise separate Lizenzen. Projekte sollten auch erkl\u00e4ren, wie die Software zitiert werden sollte. Eine <code>CITATION.cff<\/code>-Datei und ein DOI f\u00fcr stabile Releases erleichtern das Zitieren.<\/p>\n<h2>Erstellen Sie respektvolle und integrative Praktiken<\/h2>\n<p>Menschen tragen eher dazu bei, wenn Fragen respektvolle Antworten erhalten und Fehler als Teil des Lernens behandelt werden. Ein Verhaltenskodex sollte das erwartete Verhalten beschreiben und einen praktischen Berichterstattungsprozess bereitstellen.<\/p>\n<p>Die Kommunikation sollte verschiedene Zeitzonen, Sprachen, F\u00e4higkeiten und Erfahrungsstufen unterst\u00fctzen. Meetings k\u00f6nnen f\u00fcr Personen dokumentiert werden, die nicht teilnehmen k\u00f6nnen. Wichtige technische Diskussionen sollten in \u00f6ffentlichen Themen, Vorschl\u00e4gen oder Entscheidungsaufzeichnungen verf\u00fcgbar bleiben, wann immer Datenschutz und Sicherheit dies zulassen.<\/p>\n<h2>Nutzen Sie Kommunikationskan\u00e4le bewusst<\/h2>\n<p>Issue Tracker sind n\u00fctzlich f\u00fcr reproduzierbare M\u00e4ngel und geplante Aufgaben. Diskussionsforen unterst\u00fctzen Fragen und Vorschl\u00e4ge. Chat-Tools helfen bei der kurzen Koordination. Mailinglisten und Release-Notizen kommunizieren offizielle Updates.<\/p>\n<p>Wichtige Entscheidungen sollten nicht in privaten Nachrichten oder tempor\u00e4ren Chats verschwinden. Eine \u00f6ffentliche Zusammenfassung bewahrt die Argumentation und verhindert wiederholte Debatten. Projekte sollten auch realistische Reaktionszeiten angeben.<\/p>\n<h2>Anfragen mit Projektkapazit\u00e4t ausgleichen<\/h2>\n<p>Erfolgreiche Projekte erhalten oft mehr Feature-Anfragen, als das Team umsetzen kann. Jede neue Funktion schafft zuk\u00fcnftige Arbeit in den Bereichen Test, Dokumentation, Support und Kompatibilit\u00e4t.<\/p>\n<p>Anfragen sollten anhand der Projektmission, des wissenschaftlichen Werts, der wahrscheinlichen Anzahl der Benutzer, der Implementierungskosten und der Wartungsbelastung bewertet werden. Einige Ideen k\u00f6nnen besser als Plugins oder externe Pakete entwickelt werden. Nein zu sagen kann die Zuverl\u00e4ssigkeit sch\u00fctzen und die \u00dcberlastung der Wartungskr\u00e4fte verhindern.<\/p>\n<h2>Etablieren Sie vorhersehbare Qualit\u00e4ts- und Freigabepraktiken<\/h2>\n<p>Automatisiertes Testen, kontinuierliche Integration, Code-\u00dcberpr\u00fcfung, Formatierungspr\u00fcfungen und Freigabe-Checklisten verringern die Abh\u00e4ngigkeit vom individuellen Speicher. Sie helfen den Mitwirkenden auch zu verstehen, ob eine \u00c4nderung bereit ist.<\/p>\n<p>Releases sollten einer dokumentierten Versionierungsrichtlinie folgen und ein Changelog enthalten. Um \u00c4nderungen zu unterbrechen, sind Abschreibungsbenachrichtigungen und Migrationsrichtlinien erforderlich. Die Qualit\u00e4tsanforderungen sollten praktisch bleiben, damit kleine Verbesserungen nicht unn\u00f6tig schwierig werden.<\/p>\n<h2>Planung f\u00fcr Sicherheit<\/h2>\n<p>Forschungssoftware kann sensible Daten verarbeiten, auf gemeinsam genutzten Systemen laufen oder Teil kritischer Workflows werden. Communities ben\u00f6tigen eine private M\u00f6glichkeit, Schwachstellen zu melden, und einen Prozess zum Freigeben von Korrekturen.<\/p>\n<p>Repository-Zugriff, Paketregistrierungen, Dom\u00e4nen und Automatisierungsanmeldeinformationen sollten starke Authentifizierungs- und Sicherungsadministratoren verwenden. Abh\u00e4ngigkeiten sollten auf bekannte Probleme \u00fcberwacht werden. Wissenschaftliche Korrektheit und Sicherheit sind getrennte Verantwortlichkeiten, und beide erfordern Aufmerksamkeit.<\/p>\n<h2>Entwickeln Sie ein realistisches Finanzierungsmodell<\/h2>\n<p>Erste Zusch\u00fcsse unterst\u00fctzen h\u00e4ufig neue Funktionen, bieten jedoch nur eine begrenzte Finanzierung f\u00fcr die Wartung. Nachhaltige Projekte m\u00fcssen f\u00fcr Abh\u00e4ngigkeitsaktualisierungen, Dokumentation, Unterst\u00fctzung, \u00dcberpr\u00fcfung, Infrastruktur, Sicherheit und Koordinierung der Gemeinde einplanen.<\/p>\n<p>Die Finanzierung kann durch Forschungsstipendien, institutionelle Unterst\u00fctzung, Wartungsprogramme, Konsortialmitgliedschaft, Schulungen, Beratung oder Partnerschaften erfolgen. Die meisten Projekte profitieren von der Kombination mehrerer Quellen. Die Finanzierungspl\u00e4ne sollten den \u00f6ffentlichen Versprechen entsprechen, da ein kleines Freiwilligenteam nicht unbegrenzte Unterst\u00fctzung und schnelle Ver\u00f6ffentlichungen auf unbestimmte Zeit bieten kann.<\/p>\n<h2>institutionelle Unterst\u00fctzung aufbauen<\/h2>\n<p>Universit\u00e4ten und Forschungsorganisationen k\u00f6nnen die Nachhaltigkeit verbessern, indem sie Software als Forschungsausgaben erkennen und professionelle Forschungssoftware-Engineeringrollen unterst\u00fctzen.<\/p>\n<p>Zentrale Teams k\u00f6nnen Fachwissen in den Bereichen Testing, Architektur, Lizenzierung, Sicherheit und Bereitstellung bereitstellen. Institutionen k\u00f6nnen auch Repositories, Schulungsprogramme, rechtliche Unterst\u00fctzung und permanente technische Positionen unterhalten.<\/p>\n<h2>Trainieren Sie zuk\u00fcnftige Betreuer<\/h2>\n<p>Communities sollten einen Pfad vom Benutzer zum Mitwirkenden, zum Pr\u00fcfer und zum Betreuer erstellen. Mentoring, gepaarte Bewertungen, Architekturexemplare und gemeinsame Release-Arbeit helfen den Menschen, Vertrauen zu gewinnen.<\/p>\n<p>Die Verantwortung kann schrittweise eingef\u00fchrt werden. Ein Mitwirkender kann zun\u00e4chst ein Modul unterhalten, Dokumentations\u00e4nderungen \u00fcberpr\u00fcfen oder eine kleine Version koordinieren. Ein Nachfolgeplan sollte erkl\u00e4ren, wie Pfleger hinzugef\u00fcgt werden, wie der Zugriff \u00fcbertragen wird und was passiert, wenn ein Lead nach unten tritt.<\/p>\n<h2>Messen Sie die Gesundheit der Gemeinschaft sorgf\u00e4ltig<\/h2>\n<p>Downloads, Stars und Zitate zeigen Sichtbarkeit, beschreiben jedoch nicht vollst\u00e4ndig die Nachhaltigkeit. Weitere n\u00fctzliche Signale sind die Anzahl der aktiven Betreuer, die Verteilung der Beitr\u00e4ge, die \u00dcberpr\u00fcfungszeit, die Beibehaltung der Mitwirkenden, die Dokumentationsaktivit\u00e4t und die Regelm\u00e4\u00dfigkeit der Freisetzung.<\/p>\n<p>Metriken sollten eher Reflexion als Wettbewerb unterst\u00fctzen. Das Z\u00e4hlen von Commits oder Codezeilen kann Mentoring, \u00dcberpr\u00fcfung, Unterst\u00fctzung und Projektmanagement unterbewerten. Die zentrale Frage ist, ob die Gemeinschaft die wesentliche Arbeit fortsetzen kann, ohne eine kleine Gruppe zu ersch\u00f6pfen.<\/p>\n<h2>Wissen, wann der Umfang oder das Archiv reduziert werden m\u00fcssen<\/h2>\n<p>Nicht jedes Projekt sollte f\u00fcr immer wachsen. Eine Community kann in den Wartungsmodus wechseln, wenn die Software stabil ist, die Nutzung begrenzt ist oder der Ressourcenabfall sinkt. Es kann auch eine besser unterst\u00fctzte Alternative empfehlen.<\/p>\n<p>Wenn eine sichere Wartung nicht mehr m\u00f6glich ist, ist eine verantwortungsvolle Archivierung besser als die stille Aufgabe. Das Team sollte eine endg\u00fcltige Version ver\u00f6ffentlichen, die Dokumentation und den Quellcode beibehalten, das Projekt als archiviert markieren und den Support-Status erl\u00e4utern. Ein archiviertes Projekt kann f\u00fcr die historische Reproduzierbarkeit noch wertvoll bleiben.<\/p>\n<h2>Eine praktische Nachhaltigkeits-Checkliste<\/h2>\n<table class=\"custom-table\">\n<tbody><tr>\n<th>Bereich<\/th>\n<th>Schl\u00fcsselfrage<\/th>\n<\/tr>\n<tr>\n<td>Mission<\/td>\n<td>Ist der wissenschaftliche Zweck und der Projektumfang klar?<\/td>\n<\/tr>\n<tr>\n<td>Regierungsf\u00fchrung<\/td>\n<td>Verstehen die Mitwirkenden, wie Entscheidungen getroffen werden?<\/td>\n<\/tr>\n<tr>\n<td>Mitwirkende<\/td>\n<td>Kann ein neuer Teilnehmer einen ersten Beitrag abschlie\u00dfen?<\/td>\n<\/tr>\n<tr>\n<td>Dokumentation<\/td>\n<td>K\u00f6nnen Benutzer ohne direkte Hilfe der Autoren beginnen?<\/td>\n<\/tr>\n<tr>\n<td>Kredit<\/td>\n<td>Werden codierende und nicht codierende Beitr\u00e4ge anerkannt?<\/td>\n<\/tr>\n<tr>\n<td>Finanzierung<\/td>\n<td>Sind Wartungs- und Gemeinschaftsaufgaben in den Budgets enthalten?<\/td>\n<\/tr>\n<tr>\n<td>Kontinuit\u00e4t<\/td>\n<td>Kann das Projekt ohne seinen Gr\u00fcnder fortgesetzt werden?<\/td>\n<\/tr>\n<tr>\n<td>Sicherheit<\/td>\n<td>Gibt es einen Prozess zur Berichterstellung und Behebung von Schwachstellen?<\/td>\n<\/tr>\n<tr>\n<td>Ausstiegsplan<\/td>\n<td>Kann die Software verantwortungsbewusst in den Wartungs- oder Archivmodus verlagern?<\/td>\n<\/tr>\n<\/tbody><\/table>\n<h2>Schlussfolgerung<\/h2>\n<p>Nachhaltige Forschungssoftware-Communities werden durch eine Kombination aus zuverl\u00e4ssiger Technologie und starken sozialen Strukturen aufgebaut. Guter Kodex ist wichtig, aber auch Governance, Dokumentation, Unterst\u00fctzung bei der Unterst\u00fctzung, Anerkennung, Finanzierung, Sicherheit und Nachfolge.<\/p>\n<p>Die st\u00e4rksten Projekte machen die Teilnahme verst\u00e4ndlich und verteilen Verantwortung \u00fcber den urspr\u00fcnglichen Autor hinaus. Sie verbinden Softwareversionen mit Rechercheergebnissen, erkennen viele Formen des Beitrags und kommunizieren ehrlich \u00fcber Kapazit\u00e4t.<\/p>\n<p>Eine nachhaltige Gemeinschaft muss nicht auf unbestimmte Zeit expandieren. Es braucht die F\u00e4higkeit, die Software zu warten, anzupassen, zu \u00fcbertragen oder verantwortungsbewusst zu archivieren, wenn sich wissenschaftliche Bed\u00fcrfnisse \u00e4ndern. Wenn diese Praktiken fr\u00fchzeitig eingerichtet werden, kann die Forschungssoftware lange nach dem ersten Zuschuss-, Ver\u00f6ffentlichungs- oder Entwicklungsteam n\u00fctzlich bleiben.<\/p>\n<\/article>\n"},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 7<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span>Forschungssoftware beginnt oft als L\u00f6sung f\u00fcr ein bestimmtes wissenschaftliches Problem. Ein Forscher schreibt Code, um Daten zu verarbeiten, ein System zu simulieren, ein Experiment zu automatisieren oder eine Analyse zu reproduzieren. Wenn sich das Werkzeug als n\u00fctzlich erweist, h\u00e4ngen andere Forscher davon ab. Was als kleines Skript begann, kann f\u00fcr ein ganzes Feld zu einer [&hellip;]<\/p>\n","protected":false,"raw":""},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"de_DE","_original_post":"https:\/\/matforge.org\/?p=473","iawp_total_views":0,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-873","post","type-post","status-publish","format-standard","hentry","category-issue-tracking-tickets-technical-requests","de-DE"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.1 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Aufbau nachhaltiger Forschungssoftware-Communities<\/title>\n<meta name=\"description\" content=\"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Aufbau nachhaltiger Forschungssoftware-Communities\" \/>\n<meta property=\"og:description\" content=\"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-30T12:23:26+00:00\" \/>\n<meta name=\"author\" content=\"Priya Nair\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Priya Nair\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"11\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/\"},\"author\":{\"name\":\"Priya Nair\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"headline\":\"Aufbau nachhaltiger Forschungssoftware-Communities\",\"datePublished\":\"2026-07-30T12:23:26+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/\"},\"wordCount\":2148,\"commentCount\":0,\"articleSection\":[\"Issue Tracking, Tickets & amp; Technische Anfragen\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/\",\"name\":\"Aufbau nachhaltiger Forschungssoftware-Communities\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-07-30T12:23:26+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"description\":\"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/building-sustainable-research-software-communities\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Aufbau nachhaltiger Forschungssoftware-Communities\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\",\"name\":\"Priya Nair\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"caption\":\"Priya Nair\"},\"sameAs\":[\"http:\\\/\\\/matforge.org\"],\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/priya-nair\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Aufbau nachhaltiger Forschungssoftware-Communities","description":"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/","og_locale":"de_DE","og_type":"article","og_title":"Aufbau nachhaltiger Forschungssoftware-Communities","og_description":"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.","og_url":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/","og_site_name":"matforge.org","article_published_time":"2026-07-30T12:23:26+00:00","author":"Priya Nair","twitter_card":"summary_large_image","twitter_misc":{"Verfasst von":"Priya Nair","Gesch\u00e4tzte Lesezeit":"11\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/"},"author":{"name":"Priya Nair","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"headline":"Aufbau nachhaltiger Forschungssoftware-Communities","datePublished":"2026-07-30T12:23:26+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/"},"wordCount":2148,"commentCount":0,"articleSection":["Issue Tracking, Tickets & amp; Technische Anfragen"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/","url":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/","name":"Aufbau nachhaltiger Forschungssoftware-Communities","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-07-30T12:23:26+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"description":"Erfahren Sie, wie Governance, Dokumentation, Finanzierung, Unterst\u00fctzung bei der Unterst\u00fctzung und offene Zusammenarbeit dazu beitragen, dass Forschungssoftware-Communitys wachsen und nachhaltig bleiben.","breadcrumb":{"@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/de\/building-sustainable-research-software-communities\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/de\/"},{"@type":"ListItem","position":2,"name":"Aufbau nachhaltiger Forschungssoftware-Communities"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795","name":"Priya Nair","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","caption":"Priya Nair"},"sameAs":["http:\/\/matforge.org"],"url":"https:\/\/matforge.org\/author\/priya-nair\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/873","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=873"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/873\/revisions"}],"predecessor-version":[{"id":1035,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/873\/revisions\/1035"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=873"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=873"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=873"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}