Koha/Entwicklung

Die Entwicklung des Bibliothekssystems Koha als Open Source-Software wurde ursprünglich von einer neuseeländischen Stiftung (dem Horowhenua Library Trust) beauftragt und 1999 innert vier Monaten durch die Firma Katipo Communications, Ltd durchgeführt, sodass die erste Installation bereits am 2. Januar 2000 in Produktion gehen konnte.

Die Weiterentwicklung von Koha geht seither üblicherweise von den einsetzenden Bibliotheken selber aus: Sie wünschen eine neue Funktion oder die Behebung eines Fehlers - es muss also ein sogenannter "fix" entwickelt werden. Entweder tut die Bibliothek das selber, sie bittet die Koha Community darum oder sie beauftragt damit einen Programmierer. Der erstellte "fix" wird dann ans Koha-Projekt geschickt, wo er einen Test und eine Qualitätskontrolle durchläuft. Funktionierende Fehlerbehebungen werden dann üblicherweise in die aktuelle stabile Version aufgenommen, neue Funktionen mit der kommenden Version veröffentlicht. All das geschieht transparent in der Öffentlichkeit - ein vorhandener "fix" kann also bei Bedarf mit den notwendigen Kenntnissen jederzeit auch selber in die eigene Koha-Installation eingefügt werden. Der Programmcode und auch die Datenbankbeschreibung von Koha stehen jedermann zu jeder Zeit zur freien Verfügung.

Die Weiterentwicklung von Koha ist eine der Hauptaktivitäten der Koha-Gemeinschaft, die sich daneben aber auch mit vielen anderen Dingen beschäftzigt, etwa der Anfertigung von Dokumentationen und Übersetzungen, der Durchführung von Test und der Beantwortung von Anwenderfragen. Auch die Koha-Anwender selber können zur Verbesserung des Bibliothekssystems beitragen, indem sie die praktischen Fragen anderer Anwender beantworten, Fehler melden und neue Funktionen anregen, Vorschläge zur Verbesserung von Arbeitsabläufen machen oder ganz allgemein ihre eigenen Informationen mit anderen teilen (z. B. die MARC Frameworks oder Berichte).

Gegenwärtig wird Koha von einem grossen Entwicklerkreis (bisher insgesamt rund dreihundert Programmierer auf der ganzen Welt) aktiv weiterentwickelt und verbessert. Dabei findet unter den sponsernden Bibliotheken eine enge Zusammenarbeit statt. Die Firma Black Duck geht davon aus, dass in Koha rund 201 Mannjahre Entwicklungsarbeit stecken (Stand: Dezember 2016).

Ablauf der Entwicklung

Neuer Programmcode gelangt auf die folgende Weise in Koha hinein. Alle Entwickler halten sich dabei an dieselben Regeln.

Wer	Beschreibung	Bugzilla-Status
"bug reporter"	Meldung eines Falles in Bugzilla (unter https://bugs.koha-community.org/bugzilla3/). Dabei muss es sich nicht zwingend um einen Programmfehler (engl. bug) handeln, sondern der Fall kann auch einen Verbesserungsvorschlag oder einen Wunsch nach Erweiterung (engl. enhancement) des Programms betreffen. siehe dazu die Bug reporting guidelines
"patch writer"	Ein Flick (engl. patch) wird in den Koha-Programmcode eingefügt. siehe dazu Submitting a patch	Needs sign-off
Release Manager	Unter Umständen wird der Flick auf einen eigenen QA-Zweig (engl. branch) verschoben
"patch signer"	Der Flick wird getestet und im Erfolgsfall absigniert (engl. sign off). siehe dazu Sign off on patches Der Test kann beispielsweise in einer "Sandbox" erfolgen. siehe dazu Sandboxes	Signed off
QA Manager	Der Flick wird von einem Mitgglied des QA-Teams getestet.	Passed QA
Release Manager	Der Flick wird vom Release Manager getestet und im Erfolgsfall absigniert. Anschliessend wird er in den Entwicklungszweig "master" verschoben. siehe dazu How the RM push	Patch Pushed
Release Maintainer	Unter Umständen entscheidet der Release Maintainer, dass der Flick auch in die stabile Version verschoben werden muss	Pushed to stable.
"bug closer"	Der Fall wird als gelöst gekennzeichnet.	Resolved/Fixed
	Der Fall wird erst dann tatsächlich geschlossen, wenn diejenige Koha-Version bzw. Koha-Revision offiziell veröffentlicht wird, welche den entsprechenden Flick enthält.

Organisation

Der gesamte Programmcode wird öffentlich durch eine Vielzahl von Personen auf der ganzen Welt entwickelt. Der Code wird dabei nach Funktionserweiterungen sowie der Behebung von Fehlern unterschieden. Erweiterungen werden alle sechs Monate jeweils im Mai und im November veröffentlicht - dabei handelt es sich um die x.x.0-Bezeichnungen (3.8.0, 3.10.0, 3.12.0 usw.). Jeden Monat werden zusätzlich Fehlerbehebungen (bugfixes) veröffentlicht, dabei handelt es sich um die Bezeichnungen 3.12.1, 3.12.2 usw.

Da die Entwicklung von Programmierern auf der ganzen Welt geleistet wird, muss ihre gemeinsame Arbeit gut organisiert sein. Dies wird durch eine klare Zuweisung von Rollen und der damit verbundenen Kompetenzen gewährleistet. Die Rollen werden in einem öffentlichen Wahlverfahren besetzt - dabei gibt es unter anderem die folgenden Rollen.

Rolle	Person (Koha 3.12)	Aufgabe
Release Manager	Jared Camins-Esakov	Koordination der jeweils kommenden Freigabe. Die Freigaben sind zeitgesteuert (time based) - es wird regelmässig alle sechs Monate eine Freigabe veröffentlicht, welche die verfügbaren und getesteten Erweiterungen enthält. Der Release Manager ist im Fall von Differenzen auch für die Klärung und Entscheidung verantwortlich.
Release Maintainer	Chris Cormack (3.8, 3.10) Liz Rea (3.6)	Pflege der letzten stabilen Version. Dazu werden ausgewählte Erweiterungen übernommen und Korrekturen in dieser Version eingepflegt.
Quality Assurance Manager	Katrin Fischer	Qualitätskontrolle des Programmcodes, der ins System aufgenommen wird - diese muss immer durch mindestens zwei Personen von zwei verschiedenen Firmen erfolgen. Unterstützung durch mehrere "QA Assistants".
Documentation Manager	Nicole C. Engard	Erstellung der englischsprachigen Originaldokumentation.
Translation Manager	D. Ruth Bavousett	Bereitstellung der Infrastruktur für Übersetzungen in andere Sprachen.
Packaging Manager	Robin Sheat	Erstellung der DEB-Softwarepakete, welche unter der Linux-Distribution Debian installiert werden können.

Die an der jeweils eingesetzten Version beteiligten Bibliotheken und Entwickler können über die Dienstoberfläche im Menü "Über Koha > Koha-Team" angezeigt werden.

Die Kommunikation der Entwickler untereinander erfolgt hauptsächlich über Mailinglisten, Chat, Wikis und Blogs. Jährlich findet ausserdem an weltweit wechselnden Orten der Koha-Kongress KohaCon statt. Dort und an den damit verbundenen "Hackfests" können sich die Entwickler auch persönlich kennenlernen. Die Teilnahme am Kongress war bisher jeweils kostenlos.

Als Fehlermeldesystem wird die Software Bugzilla verwendet. Dort können Fehler und Erweiterungswünsche gemeldet werden, ebenso ist eine Suche nach Sponsoren und Entwicklern möglich.

Als Versionskontrollsystem dient GIT, bei der Verwaltung der Übersetzungen kommt Pootle zum Einsatz. Für die Entwicklungsstatistik wird Ohloh verwendet.

Weblinks

Herausgeber	Sprache	Webseitentitel	Anmerkungen
Koha Community	eng	Gitwbm	Software-Versionsverwaltung des Koha-Projekts
Koha Community	eng	SchemaSpy Analysis of testsql_commentswbm	Datenbankbeschreibung mit Hilfe der Open Source-Software SchemaSpy
Koha Community	eng	Bugzillawbm	Fehlermeldesystem
Koha Community	eng	Koha Dashboardwbm	Übersicht der aktuellen Entwicklung
Youtube	eng	Koha Library Software History Visualizationwbm	Eine mit Gource visualisierte Geschichte der Koha-Entwicklung von 1999-2010
Koha Community	eng	Development workflowwbm	Offizielles Wiki - Arbeitsablauf bei der Entwicklung
Koha Community	eng	Release Schedulewbm	Offizielle Webseite - Veröffentlichungsweise
Koha Community	eng	Supportwbm Paid support	Offizielle Webseite
Koha Community	eng	Ohlohwbm	Koha-Entwicklungsstatistik
Black Duck Open Hub	eng	Koha library automation package : estimated costwbm