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 soll vollständig kompatibel zu TYPO3 14 LTS werden, während zugleich die Kompatibilität zu TYPO3 13 LTS erhalten bleiben soll. In diesem Zug soll auch die aktuell unterstützte Apache Solr Version 9.7 auf mind. 9.10 angehoben werden. Für diese im Folgenden näher ausgeführte Leistung bittet der Verein Kitodo e. V., vertreten durch den Vereinsvorstand, interessierte und qualifizierte Dienstleister um Angebote.

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

3. Leistungsbeschreibung

Ausgangssituation/Hintergrund:

Zurzeit ist Kitodo.Presentation 7.x mit TYPO3 12 LTS sowie TYPO3 13 LTS kompatibel. Der Quellcode nutzt Namespaces, ist sauber strukturiert und ausführlich kommentiert.

Die Motivation und der technische Hintergrund sind im GitHub-Ticket #1886 formuliert.

Leistungen

Es ist die Kompatibilität mit TYPO3 14 LTS herzustellen, während die Kompatibilität mit TYPO3 13 LTS zu erhalten ist. Maßgeblich ist das Changelog der Version 14 LTS. Die Unterstützung für TYPO3 12 LTS soll dagegen nicht aufrechterhalten werden.

Folgende TYPO3-Versionen muss die Extension Kitodo.Presentation demnach nach dieser Entwicklung unterstützen:

• TYPO3 13 LTS
• TYPO3 14 LTS

Die mindestens zu unterstützenden Laufzeitumgebungen ergeben sich aus den gemeinsamen Systemvoraussetzungen der beiden TYPO3-Versionen: PHP 8.2, 8.3, 8.4 und 8.5, MariaDB 10.4.3 sowie MySQL 8.0.17. Apache Solr muss mindestens in Version 9.10 unterstützt werden (bislang wird Version 9.7 unterstützt), besser sogar in Version 10.

In der TYPO3-Version 14 dürfen keine Deprecated-Warnungen mehr erfolgen, es sei denn, dies ist zur Gewährleistung der Abwärtskompatibilität mit Version 13 notwendig. Geprüft wird das im Deprecation-Log sowie über das Backend Modul Admin → Upgrade → Check Extensions.

Alle vorhandenen Unit und Functional Tests sind ebenfalls entsprechend anzupassen, um unter beiden unterstützten TYPO3-Versionen ausgeführt werden zu können.

Dokumentation

Der Quellcode muss gemäß den Kitodo Coding Guidelines dokumentiert werden. Abweichungen werden mit dem Releasemanagement abgesprochen. Die Extension-Dokumentation unter Documentation ist ggf. in geeigneter Form zu ergänzen. Diese Dokumentation wird im reST-Format geschrieben und ist Teil der Extension.

Rahmenbedingungen

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

Die Entwicklung von Kitodo.Presentation erfolgt vollständig auf GitHub im Repository.

Das Releasemanagement für dieses Repository 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 Main-Entwicklungszweig durch das Releasemanagement gilt als Abnahme.

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 ist 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

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

Kitodo.Production ist das Workflowmanagementmodul der Kitodo-Suite. Es unterstützt den Digitalisierungsprozess von verschiedenen Materialarten wie Drucken, Periodika, Handschriften, Noten und Musikalien, Einblattmedien und Dokumentennachlässen. Kitodo.Production ist als Webapplikation in Java programmiert und kann plattform- und ortsunabhängig über einen herkömmlichen Webbrowser bedient werden.

Dieses Arbeitspaket beschreibt die Implementierung einer Suche, die ohne Suchindex funktioniert und nur auf Datenbanken basiert.

1. Teilnahmebedingungen

Zum Nachweis von Erfahrungen mit Java sind drei Referenzen aus den vergangenen drei Jahren einzureichen. Referenzen können z.B. realisierte Projekte mit Beschreibung der eigenen Arbeitsanteile sein. 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 20.07.2026.

3. Leistungsbeschreibung

Ausgangssituation/Hintergrund:

Seit der Veröffentlichung von Kitodo Production in Version 3.9 und der Einführung von Hibernate Search bietet die Anwendung Such- und Filterfunktionen über einen „hybriden“ Ansatz, der die Datenbank und den Suchindex (d. h. OpenSearch oder Elasticsearch) nutzt. Zu diesem Zweck werden die meisten vorgangs- und aufgabenbezogenen Informationen (einschließlich Projekte, Vorlagen usw.) in der Datenbank gespeichert und direkt von dort abgefragt, während der Suchindex hauptsächlich für das Abrufen der in der meta.xml gespeicherten Metadaten verwendet wird.

Dieses Setup bietet erhebliche Vorteile hinsichtlich verkürzter Indexierungszeiten und einer stärker standardisierten Indexierung durch Hibernate Search. Allerdings hat die „hybride“ Strategie auch Einschränkungen, insbesondere bei größeren Instanzen. Da die verwendeten Suchindizes in der Regel nicht mehr als 10.000 Ergebnisse zurückgeben, ist die metadatenbasierte Abfrage häufig unvollständig (siehe insbesondere GitHub-Issue #6772).

Dies hat auch nachgelagerte Auswirkungen:

• Generierte Statistiken enthalten nur einen Bruchteil der relevanten Ergebnisse
• Es werden fehlerhafte Ergebnislisten zurückgegeben, da nicht alle vom Suchindex gelieferten Datensätze bei der weiteren Filterung in der Datenbank berücksichtigt werden können

Diese Einschränkungen beeinträchtigen die tägliche Nutzung von Kitodo bei großen Installationen erheblich. Ziel ist es daher, den Nutzern auch bei sehr großen Instanzen korrekte und vollständige Suchergebnisse sowie Statistiken bereitzustellen und gleichzeitig die Zuverlässigkeit von Kitodo.Production im täglichen Betrieb zu verbessern.

Während der aktuelle Suchansatz bei der Metadatensuche in größeren Instanzen erhebliche Einschränkungen aufweist, funktioniert das Abrufen von Nicht-Metadaten in Kitodo auf Basis relationaler Datenbanken auch bei großen Instanzen gut. Relationale Datenbanken haben zudem in den letzten Jahren ihre Leistungsfähigkeit im Bereich der Volltextsuche deutlich verbessert. Diese Weiterentwicklungen der Datenbanken ermöglichen es, ursprüngliche technische Entscheidungen neu zu bewerten.

Leistungen

Im Rahmen dieses Arbeitspaketes sollen die folgenden funktionalen Anforderungen erfüllt werden:

• Die Implementierung sollte alle relevanten Such- und Filteroperationen in der relationalen Datenbank abdecken. Dies umfasst sowohl alle klassischen Filterkriterien („alle abgeschlossenen Prozesse“) als auch die Volltextsuche in den Metadaten („alle Prozesse, bei denen das Wort ‚Rhein‘ im Titelfeld enthalten ist“).
• Die Entwicklung sollte eine datenbankbasierte Volltextsuche in allen definierten Metadatenfeldern des Regelsatzes sowie in allen Kommentaren und Prozesstiteln ermöglichen. Alle Felder sollten entweder mit vollständigen Tokens („Rhein“) oder rechts abgeschnittenen Tokens („Rhein*“) durchsuchbar sein, sowohl mit Feldspezifikator („title:Rhein“) als auch ohne („[search]:Rhein“).
• Die Entfernung von Elasticsearch/OpenSearch und damit sämtlichem suchmaschinenbezogenen Code aus dem Technologie-Stack von Kitodo Production.
• Die Implementierung einer robusten Strategie zur erstmaligen (einmaligen) Indexierung aller Metadateneinträge beim ersten Start der Anwendung sowie die Umsetzung eines automatischen (oder manuell ausgelösten) Reindexierungsmechanismus bei Änderungen der Metadaten.

Die Implementierung sollte die folgenden nicht-funktionalen Anforderungen berücksichtigen:

• Das System (insbesondere Prozess- und Aufgabenlisten) sollte performant sein und auch bei großen Instanzen (mehr als eine Million Prozesse) ausreichend schnelle Abfragen ermöglichen (weniger als 1,5–2 Sekunden bei regulären Abfragen).
• Die Implementierung sollte, soweit möglich, auf dem Hibernate-ORM-Framework basieren und Strategien zur Abfrageerstellung verwenden, die zwischen verschiedenen Datenbankanbietern portierbar sind, um Kitodo Production datenbankagnostisch zu halten.
• Für alle entwickelten Such- und Filterfunktionen müssen geeignete Unit-, Integrations- und Selenium-Tests bereitgestellt werden. Dies sollte insbesondere robuste Mechanismen zur Prüfung datenbankspezifischer Anpassungen sowie Tests des Codes gegen die H2-Datenbank umfassen.

GitHub-Issue #6952

Dokumentation

Der Quellcode muss gemäß den Kitodo Coding Guidelines dokumentiert werden. Abweichungen werden mit dem Release Management abgesprochen.

Rahmenbedingungen

Die Entwicklung von Kitodo.Production erfolgt vollständig auf GitHub im Repository.

Das Releasemanagement für dieses Repository ist bei der Firma effective WEBWORK GmbH angesiedelt. Zu Beginn der Entwicklung muss mit dem Release Management 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. Jeder entwickelte Code muss mit Unit- und Integration-Tests getestet sein. Änderungen am Frontend müssen mit Selenium-Tests abgedeckt werden. Es ist anzustreben, möglichst kleinteilige Pull-Requests zu erstellen, die leicht und schnell gereviewt werden können.

Abnahme

Das Mergen in den Main-Entwicklungszweig durch das Releasemanagement gilt als Abnahme.

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 ist 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.Production

Arved Solth
effective WEBWORK GmbH
Neuer Wall 18
20354 Hamburg
solth@effective-webwork.de
040-609408577

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

Kitodo.Production ist das Workflowmanagementmodul der Kitodo-Suite. Es unterstützt den Digitalisierungsprozess von verschiedenen Materialarten wie Drucken, Periodika, Handschriften, Noten und Musikalien, Einblattmedien und Dokumentennachlässen. Kitodo.Production ist als Webapplikation in Java programmiert und kann plattform- und ortsunabhängig über einen herkömmlichen Webbrowser bedient werden.

Dieses Arbeitspaket beschreibt die Implementierung einer Export-Funktion in Kitodo.Production, die es erlaubt IIIF-Manifeste für Digitalisierungsvorgänge zu generieren.

1. Teilnahmebedingungen

Zum Nachweis von Erfahrungen mit Java sind drei Referenzen aus den vergangenen drei Jahren einzureichen. Referenzen können z.B. realisierte Projekte mit Beschreibung der eigenen Arbeitsanteile sein. 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 20.07.2026.

3. Leistungsbeschreibung

Ausgangssituation/Hintergrund:

Aktuell bietet Kitodo.Production die Möglichkeit, Digitalisierungsvorgänge im Format METS/MODS zu exportieren, welches kompatibel mit nachnutzenden Systemen wie Kitodo.Presentation und dem DFG-Viewer ist. Zusätzlich dazu wächst jedoch der Bedarf nach IIIF-Manifesten in der wissenschaftlichen Gemeinschaft. Um diesen Bedarf zu decken, soll Kitodo.Production in die Lage gebracht werden, IIIF-Manifeste zu generieren.

Leistungen

Im Rahmen dieses Arbeitspaketes soll eine neue Funktionalität implementiert werden, die Kitodo-Digitalisierungsvorgänge als IIIF-Manifeste exportiert. Diese Manifeste werden im JSON-Format ausgeliefert und sollen sich so weit wie möglich an der aktuellen IIIF-API-Spezifikation in der Version 3.0 orientieren, das beinhaltet in jedem Fall eine fehlerfreie Validierung durch einen IIIF-Online-Validator (https://presentation-validator.iiif.io/).

Folgende Bestandteile der bestehenden METS-Exporte sollen nach Möglichkeit mindestens in den erzeugten IIIF-Manifesten abgebildet werden:

• Logische Struktur (entspricht <structMap type=“logical“> in METS)
• Physische Struktur (entspricht <structMap type=“physical“> in METS)
• Volltexte (entspricht <fileGrp use="fulltext“> in METS)
• Metadaten der obersten Strukturebene (entspricht <dmdSec> des Root-Knotens der logischen Struktur in METS)

In der IIIF-API-Spezifikation werden verschiedene Konzepte beschrieben, die zur Abbildung der oben genannten METS-Bestandteile genutzt werden können (e.g. IIIF canvas, structure, range, annotation etc.)

Da IIIF jedoch keine strukturierten Metadaten in seiner Spezifikation vorsieht, können nicht alle Metadaten von strukturierten METS-Dokumenten abgebildet werden. Als Minimalziel sollen jedoch zumindest die Metadaten des Wurzelknotens eines Vorgangs als Key-Value-Paare in dem erzeugten JSON-Objekt enthalten sein.

Die genauen Details der Implementierung sind vor der Umsetzung mit dem Release Management abzustimmen.

GitHub-Issue #5578

Dokumentation

Der Quellcode muss gemäß den Kitodo Coding Guidelines dokumentiert werden. Abweichungen werden mit dem Release Management abgesprochen.

Rahmenbedingungen

Die Entwicklung von Kitodo.Production erfolgt vollständig auf GitHub im Repository.

Das Releasemanagement für dieses Repository ist bei der Firma effective WEBWORK GmbH angesiedelt. Zu Beginn der Entwicklung muss mit dem Release Management 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. Jeder entwickelte Code muss mit Unit- und Integration-Tests getestet sein. Änderungen am Frontend müssen mit Selenium-Tests abgedeckt werden. Es ist anzustreben, möglichst kleinteilige Pull-Requests zu erstellen, die leicht und schnell gereviewt werden können.

Abnahme

Das Mergen in den Main-Entwicklungszweig durch das Releasemanagement gilt als Abnahme.

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 ist 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.Production

Arved Solth
effective WEBWORK GmbH
Neuer Wall 18
20354 Hamburg
solth@effective-webwork.de
040-609408577