[Allegro] Quellensituation und Zukunftsfähigkeit

Mo Jan 12 09:03:17 CET 2015

Neben der Vorbereitung einer V35.1 kuemmern wir uns momentan um eine
weitere und sehr notwendige Verbesserung der Quellensituation, d.h.
der C++-Programme.

Dazu und zur Frage der Zukunftsfähigkeit von allegro ein paar plakative
Anmerkungen. Zeit für eine längere Abhandlung ist gerade nicht, aber
zum Lesen einer solchen vielleicht auch nicht.

Jede Software, die nicht sofort perfekt ist, also jede, wird
irgendwann revisionsbedürftig. Das haben wir 1985 erlebt, als wir
auf eine ganz andere Programmierplattform wechseln mußten (von
Basic + Assembler auf C), und dann haben wir es 1995 erlebt, als
es nötig wurde, nach langer Zeit der Unklarheiten ein Windows-Programm
auf die Beine zu stellen, weil DOS unbeliebt wurde.
1985 mußte notgedrungen alles neu programmiert werden, aber der Umfang
war noch nicht gewaltig groß. Außerdem: 1985 gab es noch nicht viele
Anwender. Wir konnten deren Daten von der obsoleten Plattform auf die
neue überführen und die Weiterarbeit ermöglichen.
1995 fand zwar intern eine erhebliche Umstrukturierung statt
(Objektorientierung, Klassenbibliothek!), aber im Ergebnis mußten
keine Nutzerdaten umstrukturiert werden, d.h. der Umstieg war
in der Hinsicht schmerzlos. Das ist nicht normal, sondern bei einem
größeren Versionswechsel ist oft eine Umwandlung der Nutzdaten in
eine neue Struktur fällig. Es führt dann leicht dazu, daß Anwender
den Wechsel scheuen und lange hinausschieben oder im Extremfall
gar nicht mitvollziehen können, weil es als zu aufwendig empfunden
wird und damit auch zu kostspielig. Wir sehen es z.B. bei MyCore und
bei VuFind, daß eine deutlich bessere Neuversion sehr lange braucht,
bis sie an der Basis "angekommen" ist. Seit 1985 haben wir keinen
solchen Bruch riskiert. Gleichwohl gibt es immer noch Anwender,
die mit 10 Jahre alten Versionen leben, obwohl sie ihre Daten mit
der aktuellsten Version unverändert weiterbenutzen könnten, und nicht
nur die Daten, auch alle Parameter etc. Aber irgendeinen Zwang zum
Wechsel können und wollen wir schließlich auch nicht ausüben.
Auch in diesem Jahr, mit V35, wird es so etwas nicht geben.

Nun kommt aber auf der Welt weniges ohne Nachteile daher, und über
die ist zu reden:

A.
Anwender fragen: Ist eine in der Kernstruktur so alte Software noch
zukunftsfähig?
Da gibt es drei wichtige Aspekte:
1. Entspricht sie noch heutigen und künftigen Nutzererwartungen?
    Zu unterscheiden ist natürlich zwischen den Erwartungen der
    Bibliothekare und der Endnutzer. Letztere sind geprägt von Google-
    Erfahrungen, also von Suchmaschinentechniken. Diesen Erwartungen
    kann man entsprechen durch Auslagerung der OPAC-Funktion in eine
    angekoppelte VuFind-Umgebung. Was aber nicht heißt, daß man die
    alcarta-, PHPAC- oder a35-Oberfläche dann aufgeben müßte, obwohl
    vom Blättern in alphabetisch sortierten Listen ganz allgemein nichts
    mehr gehalten wird.
2. Wie lange bleiben die Programme überhaupt noch funktionsfähig?
    Windows 8 wird von Microsoft bis zum 1.4.2023 garantiert (s.u.).
    Windows 10 wird evtl. etwas länger "leben", aber das weiß noch
    keiner - 2025 ist aber wohl nicht zu hoch gegriffen.
    Für Linux deutet sich kein solcher Meilenstein an; die GNU-Compiler
    jedenfalls werden ganz sicher kompatibel bleiben.
3. Wird allegro Schritt halten mit dem neuen Umfeld RDA+BIBFRAME?
    (Betrifft nur die normale Anwendung "Katalogisierung", und auch
    diese nur, soweit RDA-Konformität gewünscht ist.)
    RDA ist kein wirkliches Problem! Man kriegt nur hier und da neue
    Uneinheitlichkeiten in den Fremddaten, aber davon gibt's ja immer
    schon eine Menge.
    BIBFRAME? Experten reden jetzt von 10 Jahren, bevor es ernsthaft,
    also auf breiter Basis, MARC ablösen kann.
    Das würde zu A.2. passen! Denn zwar nicht BIBFRAME selbst, aber die
    damit verbundenen Erwartungen und Ansprüche werden ganz andersartige
    Systeme fordern und diese werden entstehen. *Vorher* schon allegro
    abzulösen durch etwas anderes, was *jetzt* schon existiert, das
    ergibt deshalb wenig Sinn - es sei denn, andere Gründe als einfach
    nur Zweifel an allegro sprechen für eine vorzeitige Ablösung, etwa
    ein Verbundbeitritt. Denn man würde sich sonst nur auf eine anders-
    artige Zwischenlösung einlassen, deren Tage gleichfalls schon
    gezählt sind.

B.
Entwickler fragen: Ist eine so alte Software nicht im Kern auch
softwaretechnisch veraltet?
Klar ist sie das. Die wichtige Frage ist: Macht das was aus?
Da gibt es ebenfalls zwei Aspekte:
1. Bleibt das Kompilieren auf neuen Windows- und Linux-Plattformen
    noch möglich?
    Nach allen bisherigen Erfahrungen: ja.
2. Werden unabhängige Entwickler die Programme noch genügend weit
    durchschauen können, um Änderungen ausführen zu können?
    Da liegt das größte Problem, denn die formale Struktur entspricht
    ganz und gar nicht den heute gängigen Standards und Konventionen.

Die Problematik B.2. ergibt sich aus der langen Vorgeschichte:
Der Einstieg 1995 in die objektorientierte Programmierung war ein
Kraftakt, aber es ging dann nicht auf gleichem Niveau weiter: die C++-
Klassen hätten konsequent weiterentwickelt werden müssen und ihre
Anwendung in a99 und acon ebenfalls konsequent klassentechnisch
durchgeführt.
Dazu fehlte definitiv die Zeit. Sowohl a99 wie avanti+acon entstanden
zunächst als hastig zusammengebastelte prozedurale Programme unter
Nutzung der Klassen, auch um deren Funktion gründlicher auszutesten.
Aber dann verselbständigten sie sich, weil ihre Leistungen dringend
gebraucht wurden, und ein fast grotesker Wildwuchs nahm seinen Lauf...
Gleichwohl ist es bis heute ja gelungen, die Programme mehrfach um
substantielle Leistungen (zuletzt HFM) zu erweitern, und zwar auch
die strukturell noch älteren und viel schlimmeren Hilfsprogramme (srch,
index, import, qrix).

Fazit: Zwar bleiben die Programme, so wie sie jetzt sind bzw. Ende 2015
sein werden, noch mindestens 10 Jahre lauffähig, auch wenn gar keine
Änderungen mehr gemacht werden. Wenn aber aus irgendwelchen Gründen
welche gemacht werden müssen, *könnte* es wegen B.2. schwierig werden.
Daher werden wir in diesem Jahr einige Bemühungen auf Punkt B.2.
konzentrieren. Das ist bereits angelaufen und erste Ergebnisse werden
in Kürze vorgestellt. Desgleichen eine weiter verbesserte Dokumentation
zur VuFind.Implementierung incl. Einbindung externer Ressourcen.

Ausführliche Hinweise zu den Microsoft-Plänen:
http://www.focus.de/digital/computer/windows/noch-zwei-wochen-support-ende-fuer-windows-7-das-muessen-sie-jetzt-tun_id_4382819.html

B.Eversberg