Ausschreibungen

Kitodo ist eine quelloffene Softwaresuite für die Digitalisierung von Kulturgut in großen wie kleinen Bibliotheken, Archiven, Museen und Dokumentationszentren.

Kitodo.Presentation ist das Präsentationsmodul der Kitodo-Suite. Es ist als Extension des freien Content Management Systems TYPO3 realisiert.

Kitodo.Presentation verfügt über einige automatisierte funktionale und Unit Tests, muss aufgrund seiner Komplexität jedoch auch manuell getestet werden. Um manuelle Tests durch Entwickelnde wie auch das Release Management zu erleichtern und zu vereinheitlichen, soll eine einfach reproduzierbare Testumgebung geschaffen werden. Diese Umgebung soll eine vordefinierte Konfiguration sowie Beispieldaten enthalten und somit auch als Referenzumgebung für die Abnahme von Pull Requests durch das Release Management dienen.

1. Teilnahmebedingungen

Zum Nachweis von Erfahrungen mit TYPO3 sind drei Referenzen aus den vergangenen drei Jahren einzureichen. Referenzen können z.B. realisierte Webprojekte mit Beschreibung der eigenen Arbeitsanteile oder realisierte TYPO3-Extensions sein, vorzugsweise mit Links ins TER (TYPO3 Extension Repository) oder ein öffentliches Git-Repository. Eine möglichst große Passgenauigkeit der Referenzprojekte zu den Inhalten der Leistungsbeschreibung sind dabei von Vorteil (s. a. 5. Zuschlagskriterien).

Zudem ist der Nachweis von Erfahrungen in der Entwicklung von Open-Source-Systemen bzw. der Durchführung von Open-Source-Projekten in vergleichbarer Weise zu erbringen.

Dem Angebot ist ein detaillierter Zeitplan beizufügen, aus dem ersichtlich ist, wann welche Arbeitsschritte innerhalb der vorgesehenen Projektlaufzeit von sechs Monaten durchgeführt werden. Der Zeitplan soll die geplanten Meilensteine (z.B. Beginn der Entwicklung, Implementierung, Erstellung der Pull-Requests, etc.) sowie den voraussichtlichen Aufwand pro Phase enthalten.

2. Angebotsfrist

Die Frist für die Abgabe eines Angebots ist der 21.04.2026.

3. Leistungsbeschreibung

Ausgangssituation/Hintergrund:

Im Rahmen der Softwareentwicklung und in Vorbereitung neuer Releases müssen immer wieder Tests durchgeführt werden. Obwohl mittlerweile eine Vielzahl automatisierter Unit- und Integrationstests existiert, können viele Funktionen nach wie vor nur manuell getestet werden. Die Installation und Konfiguration von Kitodo.Presentation ist jedoch nicht trivial und/oder standardisiert, so dass die Einrichtung einer Testumgebung mit signifikanten Aufwänden verbunden ist und die Testergebnisse – etwa im Abnahmeprozess mit dem Release Management – zwischen verschiedenen Testinstanzen differieren können.

Die Motivation wurde im Rahmen des Entwicklungsfonds in den GitHub Tickets #1177 sowie #1176 beschrieben.

Sowohl für die notwendigen Designarbeiten als auch die reproduzierbare Testumgebung liegen bereits umfangreiche Vorarbeiten vor, die vollständig nachgenutzt werden können. Basis des generischen Standard-Designs können die Templates, Stylesheets und Grafiken der ehemaligen Kitodo.Presentation Demo-Instanz sein, die frei verändert werden dürfen. Das Repository besitzt auch noch nicht integrierte Pull Requests, die zusätzliche Aktualisierungen und Ergänzungen bereitstellen. Grundlage der reproduzierbaren Testumgebung können wiederum Vorarbeiten der SLUB Dresden sein, die ebenfalls auf GitHub (https://github.com/kitodo/ddev-kitodo-presentation und https://github.com/slub/slub_digitalcollections) zu finden sind sowie auf Anfrage bereitgestellt werden. Die Verwendung dieser Vorarbeiten ist optional.

Leistungen

Es soll eine reproduzierbare, vorkonfigurierte und einfach zu installierende Appliance erstellt werden. Diese Testumgebung soll alle derzeit im Hauptentwicklungszweig (main) verfügbaren Funktionalitäten in einer Standardkonfiguration mit generischem Design bereitstellen und dazu einen noch zu definierenden Satz einiger Dutzend möglichst vielfältiger Beispieldokumente^[1] enthalten, um umfassende Testszenarien zu ermöglichen.

Die Appliance darf jedoch nicht nur einmalig statisch (z. B. als Docker-Container) erstellt werden, sondern muss dynamisch mithilfe parametrisierbarer Softwareversionen erzeugbar sein. Beispielsweise muss konfigurierbar sein, welche der von Kitodo.Presentation aktuell unterstützten PHP- und TYPO3-Versionen beim Einrichten der Umgebung verwendet werden soll (derzeit PHP 8.2 – 8.4 sowie TYPO3 v12 und v13) sowie welcher auf GitHub veröffentlichte Code-Branch getestet werden soll.

Gefordert wird eine auf der freien PHP-Entwicklungsumgebung DDEV basierende Lösung, die sowohl lokal^[2] als auch im Rahmen von GitHub Codespaces ausgeführt werden kann. Die möglichen Systemumgebungen (PHP-/TYPO3-Version) könnten etwa über entsprechende DDEV Environmental Overrides bereitgestellt werden. Die Umgebung ist so zu konfigurieren, dass alle notwendigen Konfigurationen, Templates, Beispieldaten, Seitenstrukturen, etc. bereitgestellt und automatisch importiert werden, so dass eine vollständig nutzbare Instanz von Kitodo.Presentation entsteht.

Im Einzelnen umfasst der Leistungskatalog demnach folgende Arbeiten:

1. Bereitstellung sämtlicher Konfigurationen, Skripte und Dateien, die für das Erzeugen einer DDEV-Umgebung mit konfigurierbarer PHP- und TYPO3-Version sowie frei wählbarem Kitodo-Branch mittels weniger Kommandos notwendig sind.
2. Die DDEV-Umgebung muss in einer Weise vorkonfiguriert und geskriptet sein, dass mit Ausführen der Kommandos eine im Browser vollständig nutzbare Umgebung aus folgenden Komponenten entsteht:
   1. TYPO3-Webseite mit installierter Kitodo.Presentation-Extension inkl. aller notwendigen Abhängigkeiten (unter Verwendung von Composer)
   2. MariaDB-Datenbank mit importierten Beispieldaten, Konfigurationen, Seitenstrukturen, etc.
   3. Apache Solr-Suchindex mit indexierten Beispieldokumenten
3. Das System ist so zu konfigurieren, dass alle Funktionen von Kitodo.Presentation ohne weitere Konfiguration getestet werden können (beispielsweise erfordern einige Funktionen einen FE User Account und entsprechende Login-Masken, diese müssen also ebenfalls vorkonfiguriert bzw. Testzugänge vorhanden sein).
4. Im System ist ein Layout und Design zu implementieren, das alle Kitodo-Funktionen sowie notwendige Basiskomponenten (wie etwa Login-Masken) umfasst. Da es sich um ein nicht-öffentliches Referenz- und Testsystem handelt, kann das Design generisch-reduziert sein und mehr funktionalen als ästhetischen Gesichtspunkten genügen. Das Design muss auf den bestehenden Templates und Partials der Extension basieren, die nur soweit unbedingt notwendig verändert werden sollten.

Mindestens die folgenden Funktionen von Kitodo.Presentation müssen in der Testumgebung verwendbar sein:

• 3D-Digitalisate (mit Standard „model-viewer“)
• A/V-Medien-Player
• Inhaltsverzeichnisse/Strukturnavigation
• Kollektionen (inkl. mindestens einer dynamischen Sammlung)
• Metadatenanzeige (inkl. mehrstufiger Metadaten)
• MultiView-Ansicht
• OAI-PMH-Schnittstelle (inkl. mindestens zwei inhaltlich verschiedener Sets)
• RSS-Feeds
• Seitenanzeige und Thumbnail-Vorschau/-Navigation
• Suchfunktionen (Metadaten- und Volltextrecherche, Listenansicht und Facetten)
• Toolbox-Funktionen (div. Download-Optionen, Bildmanipulation, In-Dokument-Suche, etc.)
• Volltexte (Anzeige von ALTO-, TEI- und MEI-Volltexten, Volltextsuche, Zeilen- und Taktsynchronisation zwischen Faksimile und Volltext)
• Warenkorb-Funktionen
• Zeitungen und Periodika (inkl. Kalenderansicht)

Alle notwendigen Inhalte (Beispieldokumente, Sammlungsbeschreibungen, etc.) werden über das Release Management bereitgestellt.

Dokumentation

Der Quellcode muss gemäß den Kitodo Coding Guidelines dokumentiert werden. Abweichungen werden mit dem Releasemanagement abgesprochen. Die Extension-Dokumentation unter Documentation ist in geeigneter Form zu ergänzen, um die Verwendung der Testumgebung und insbesondere deren Parametrisierung zu erläutern. Diese Dokumentation wird im reST-Format geschrieben und ist Teil der Extension.

Rahmenbedingungen

Die Entwicklung von Kitodo.Presentation erfolgt vollständig auf GitHub. Das Releasemanagement ist aktuell bei Open Culture Consulting angesiedelt.

Zu Beginn der Entwicklung muss mit dem Releasemanagement die Vorgehensweise abgesprochen werden (z.B. Feature-Branch). Grundsätzlich arbeitet der Dienstleister in seinem eigenen Fork und bietet seine Entwicklungen als Pull-Request an. Es ist anzustreben, möglichst kleinteilige Pull-Requests zu erstellen, die leicht und schnell reviewed werden können.

Abnahme

Das Mergen in den Hauptentwicklungszweig (main) durch das Releasemanagement gilt als Abnahme. Das Release Management behält sich vor, auch nach dem Merge ggf. noch Fehlerbehebungen nachzufordern, sofern die Fehler nachweislich durch einen Pull Request des Dienstleisters entstanden sind.

4. Zeitplanung

Der Beginn der Arbeiten soll in der Regel unmittelbar nach Auftragsvergabe erfolgen. Wegen möglicher Abhängigkeiten von anderen Entwicklungen ist der tatsächliche Beginn mit dem Releasemanagement abzusprechen

Der Abschluss der Entwicklung muss innerhalb von 6 Monaten, nach Beginn der Arbeiten erfolgen. Für diese Zeit wird angestrebt, dass sich der Quellcode nicht grundlegend ändert.

Die Geschäftsstelle muss monatlich über den aktuellen Stand der Entwicklungen informiert werden.

Änderungen am Zeitplan müssen frühzeitig kommuniziert und vom Auftraggeber abgestimmt werden.

5. Zuschlagskriterien

Den Zuschlag erhält das wirtschaftlichste Angebot unter Berücksichtigung der angebotenen Leistungen, der nachgewiesenen Referenzen (s. a. 1. Teilnahmebedingungen) und des Preises.

6. Vertragsbedingungen

Lizenzierung als Open Source Software

Der vollständige Quellcode und alle damit in Verbindung stehenden elektronischen Ressourcen (Images, Stylesheets, etc.) sind unter GNU General Public License in der Version 3 (GPL3) oder neuer an den Kitodo e. V. zu lizensieren. Werden Frameworks, Bibliotheken, Fonts oder andere Software Dritter verwendet, so müssen diese Bestandteile ebenfalls unter einer mit der GPL3 kompatiblen Lizenz vorliegen und die Lizenz explizit ausweisen.

Die freie Lizenzierung schließt die Dokumentation ein.

7. Einzureichende Unterlagen, Erklärungen und Nachweise

Zur Abgabe eines Angebots ist das angehängte Formblatt zu nutzen.

Darüber hinaus müssen folgende Erklärungen und Nachweise beigelegt werden:

• Handelsregisterauszug
• Referenzen (s. 1. Teilnahmebedingungen)
• Zeitplan (s. 1. Teilnahmenbedingungen)

Alle Unterlagen sind in elektronischer oder gedruckter Form in der Geschäftsstelle des Vereins Kitodo e. V. einzureichen.

8. Ansprechpersonen

Kitodo e. V.

Magdalena Eberle
Kitodo. Key to digital objects e. V. | Geschäftsstelle
c/o Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky
Von-Melle-Park 3
20146 Hamburg
contact@kitodo.org
040-42838-2368

Release Management für Kitodo.Presentation

Sebastian Meyer
Open Culture Consulting
sebastian.meyer@opencultureconsulting.com

[1] Die Auswahl und Bereitstellung der Beispieldokumente erfolgt durch das Release Management. Diese werden in einem GitHub Code Repository öffentlich bereitgestellt und sind in die Testumgebung zu integrieren.

[2] Das Vorhandensein einer lokalen DDEV-Installation kann vorausgesetzt werden.