Benutzer:PerfektesChaos/Langfristige Wartung von Werkzeugen im Wiki

aus Wikipedia, der freien Enzyklopädie

Fragen und Herausforderungen zu diesem Thema ergeben sich immer wieder; kürzlich (Frühjahr 2014) anlässlich der Abschaltung des Toolservers.

Dieser Essay beleuchtet einige Aspekte und versucht zu zeigen, warum einige Wunschvorstellungen zur Software-Entwicklung die Probleme nicht lösen würden.

Dokumentation

Der zentrale Punkt ist überhaupt nicht das Schreiben eines Programms, sondern die zugehörigen Texte zur Konzeption und Nutzung (Softwaredokumentation). Diese sind im Wiki-Bereich häufig ungenügend bis überhaupt nicht vorhanden, nur gelegentlich in hinreichendem Umfang und Qualität nachlesbar.

Programmierer-Dokumentation

Voraussetzung, um eine komplexere Software-Einheit (mehr als ein Dutzend Zeilen) über einen längeren Zeitraum betreiben und durch beliebige Personen aktualisieren zu können, sind mehrere Textformen:

  • Makro-Informationen;
    • Genaue Beschreibung des beabsichtigten Zwecks. (Wofür das Werkzeug dann von den Anwendern tatsächlich benutzt wird, ist nochmal eine andere Frage.)
    • Konzeption; meist eine simple Datenbankabfrage, zuweilen aber sehr viel komplexer. Dann ist grafisches und textliches Hintergrundmaterial notwendig.
    • Weiterentwicklung: Welche Probleme hatten sich ergeben; welche Erweiterungswünsche hatten die Anwender geäußert; was geht warum nicht, was wäre gelegentlich aussichtsreich?
    • Kommentare, Wünsche, Anregungen der Anwender (Diskussionsseite).
  • Mikro-Informationen; etwa durch Kommentarzeilen und Parameterbeschreibung der Aufrufe von Unterprogrammen.
    • In der MW-Software vorhanden.
    • In den meisten Tools zwar rudimentär eingestreut, jedoch wohl nur in wenigen konsistent und vollständig.
  • Versionsgeschichte.
    • Bei mwGIT durch commits und Versionsvergleich gut zu verfolgen.
  • Quellcode
    • Beim Toolserver regelmäßig nicht zugreifbar gewesen; somit keine OpenSource, und genaue Funktion nicht nachvollziehbar. Zuweilen wurden irgendwelche Repositorien verlinkt, zu denen es jedoch keine Zugangsberechtigung gab.
    • Für die WikiMedia Cloud solle angeblich der Quellcode nachlesbar sein; das ist aber oft nicht (auch 2020 noch eher selten) der Fall; und dann auf externen GIT-Servern usw.
    • Ohne Offenlegung des Quellcodes für alle ist nicht nachvollziehbar, welche möglicherweise sicherheitsrelevanten und datenschutzmäßig problematischen Aktivitäten heimlich im Hintergrund erfolgen.
      Beispiele:

Anwender-Dokumentation

Für die Anwender müssen die benutzungsrelevanten Informationen in der Muttersprache gegeben und mit Datenbeispielen versehen sein.

Wikitext

Es ist von zentraler Bedeutung, dass ein frei editierbares Wiki mit den vertrauten Mitteln bereitsteht. Jedem Werkzeug muss nach einem einheitlichen Schema eine Startseite für die Dokumentation zugeordnet sein.

  • Übersetzung der Bedienungsanleitung in jede Sprache der Anwender.
  • Verständlichere Darstellung der Bedienungsanleitung aus Perspektive der Anwender.
  • Kommentare, Wünsche, Anregungen der Anwender.

Hieran mangelt es weitgehend.

Kontinuität

Einarbeitung und Wiki-Erfahrung

Um den Anwenderhorizont und einen Überblick über die weltweit auftretenden Fagestellungen zu verinnerlichen, ist eine mehrjährige Erfahrung als Bearbeiter von Wiki-Seiten und ihrer Verwaltung, Kategorisierung usw. erforderlich.

Spezifikation

Eng verknüpft mit der Wiki-Erfahrung ist das Problem, eine vollständige Aufgabenspezifikation zu schreiben, auf deren Grundlage Außenstehende die Aufgabe wie implizit gewünscht lösen und einen Vertrag definiert erfüllen können.

  • Eine solche Spezifikation zu erstellen ist ein größerer Aufwand und bedarf mehr Kenntnisse von Programmierung und Wiki, als ein Tool selbst zu schreiben. Dann lohnt sich eine Delegation nach außen schon nicht mehr.
  • Die größte Schwierigkeit besteht darin, auch alle implizit in Fleisch und Blut übergegangenen Wiki-Besonderheiten explizit zu definieren, damit sie auch umgesetzt werden können. Es reicht auch nicht, die gewünschte Standardsituation zu durchdenken; auch alle auftretenden Spezialfälle und veränderte Rahmenbedingungen müssen bedacht werden.

Vergisst man bei der Spezifikation etwas, dann hat der Auftragnehmer seine Job gemacht, liefert exakt wie gewünscht ab, und man hat ein Werkzeug mit nicht behebbaren Macken.

  • Entwicklungstechniken für größere Projekte begleiten ein Vorhaben über Jahre und führen in späteren Phasen anhand der von den Anwendern gemachten Erfahrungen die Entwicklung weiter. Das sprengt aber völlig den für ein einzelnes Tool zumutbaren Rahmen.
  • Es gibt einen Satz Testfälle, die für die Übergabe gelöst werden müssen. Vergisst man ein Szenario, stellt es sich erst ein halbes Jahr später heraus, dass bestimmte Konstellationen nicht abgedeckt sind, hat man eben Pech.
  • Das gilt insbesondere, wenn man mal wieder so schlau ist, nur in der englischsprachigen Wikipedia zu erproben und völlig überrascht ist von den Lokalisierungsproblemen bei anderen Sprachen, anderen Schriften, anderen Projektstrukturen, anderen Abläufen.

Projektgruppen der WikiMedia Cloud

  • Das Konzept der WikiMedia Cloud (zunächst „Labs“), die Werkzeuge nicht mehr Einzelpersonen zuzuordnen, sondern mehrere Betreuer für jedes Werkzeugprojekt zuzulassen, ist genau richtig.
  • Grundsätzlich ermöglicht es, die zyklische Übernahme nach dem Ausscheiden vorheriger und das Einarbeiten nachfolgender Betreuer zu unterstützen.
  • Allerdings müssten sich dazu auch mehrere Mitarbeiter finden; teils gibt es Arbeitsgruppen, teils sind weiterhin nur Einzelpersonen zugeordnet.

Können

  • Es bedarf über den durchschnittlichen Standard hinausreichender Programmierkenntnisse, um in wildfremden Codes zielführende und robuste Änderungen vorzunehmen. Neben SQL und HTML müssen PHP, Tcl, Perl und Python beherrscht werden; auch Java-Servlets kommen vor.
  • Weiterhin ist ein tieferes Hintergrundwissen über Software und Wiki-Struktur erforderlich, um zukunftsfähige Weiterentwicklungen vornehmen zu können.
  • Fähigkeit zu konzeptionellem Arbeiten und Gestaltung entwicklungsfähiger Software sind nötig, um die gewünschte langjährige Kontinuität zu erreichen.
  • Wer dies kann, sitzt nicht däumchendrehend herum und wartet auf ein Jobangebot der WM.
  • Die Gehaltsvorstellungen sind rund.

Hauptamtliche Kräfte

Eine verbreitete Illusion ist, es würden sich alle Sorgen von selbst lösen, wenn man statt ehrenamtlicher hauptamtliche Mitarbeiter einsetzen würde.

Software-Haus

  • Eine beauftragte Firma löst eine konkret spezifizierte Aufgabe zu einem Ablieferungstermin. Wenn das dann läuft, bekommt sie das vertraglich vereinbarte Geld und Ende Banane.
  • Mehrjährige Wartungsverträge sind möglich – aber für die vergleichsweise winzigen Tools schlicht unbezahlbar; zu den vertretbaren Geldern ist es für keine Firma lukrativ, sich vertraglich auf Jahre hinaus zu ungewissen zukünftigen Leistungen zu verpflichten und die Folgen einer Nichterfüllung ausbaden zu müssen.
  • Die Zeiten, wo Software-Leute eine Lebensanstellung bei der Firma und zum 50-jährigen Jubiläum eine goldene Uhr bekamen, sind auch schon etwas länger vorbei. Aufgaben der fraglichen Art werden aus einem Pool freier Mitarbeiter abgearbeitet. Wenn zwei Jahre später wieder etwas am selben Tool zu machen ist, gibt es die Mitarbeiter längst nicht mehr. Falls noch Kontakt zu ihnen besteht, sind sie zu 110 % unter Termindruck auf Monate hinaus in ein anderes Projekt eingebunden. Deshalb wird kein Auftragnehmer eine Garantie abgeben, dieselben eingearbeiteten Leute zwei Jahre später wieder einzusetzen; muss mit erneuter monatelanger Einarbeitung und hohem Aufwand für eine vergleichsweise geringfügige Aktion rechnen. Rechnet sich das? Für den Auftragnehmer, den Auftraggeber?

Festanstellung

Falls man Menschen mit dem erforderlichen Können gefunden hat und diese die Wiki-Erfahrung mitbrachten oder sie sich nunmehr erarbeitet hatten, kann man sie natürlich auf viele Jahre hinweg fest anstellen.

Man muss dann aber auch einen kontinuierlichen Aufgabenfluss und interessante, abwechslungsreiche Tätigkeitsfelder sicherstellen. Das Salär ist so hoch zu bemessen, dass nicht mit Abwanderung und Abwerbung zu rechnen ist.

Die WMF hat einige wenige langjährige Experten unter Vertrag. Sie sind unersetzlich.

Fremdprodukt

Ein Fremdprodukt kauft man schlüsselfertg ein, lässt es vielleicht ein wenig modifizieren, und dann ist es da.

An der Konzeption und Entwicklung hat niemand mitgearbeitet. Niemand kennt sich mit den inneren Abläufen aus. Man kann kostenpflichtig die Hersteller fragen, ob sie dies weiterentwickeln würde, wie es einem genehm ist, nachdem sich im Lauf der Zeit durch tausendfache Benutzung herausgestellt hat, welche weiteren Funktionalitäten man braucht oder wie sie abzuwandeln wären. Ob dann so fortgeführt wird, wie man es gerne hätte, hat man nicht in der Hand.

Ist der Hersteller nicht mehr am Markt, sind alle Wartungsverträge obsolet und das Werkzeug kann noch einige Jahre weiter schnurgerade im letztverfügbaren Zustand weiterlaufen.

Ergebnis

Die Fluktuationsprobleme bei ehrenamtlichen und hauptamtlichen Kräften sind völlig identisch.

  • Motivierte Wiki-Leute sind über Jahre hinweg dabei. Sie haben ihr Baby und zumindest einige Jahre Interesse daran, dass ihr Ding läuft und die Anwender damit glücklich sind. Durch sich wandelnde Lebensumstände und Interessenlagen kann sich das ändern.
  • Angestellte bekommen ihren Arbeitsauftrag, machen zwei Monate rum, liefern ihn wie spezifiziert ab und vergessen dann die Sache und sind weg.
  • Ausschlaggebend ist vielmehr, dass an jedem Software-Produkt mehrere Leute mit prinzipiell langer oder nicht von vornherein begrenzter Verweildauer mitarbeiten und sich untereinander über Konzepte und Strategien austauschen. Scheidet jemand aus, so bleiben eingearbeitete Leute im Team und können Newcomer einarbeiten. Bei der MediaWiki-Kernsoftware ist das gegeben, bei den WikiMedia Cloud-Tools wird versucht, es so zu organisieren. Tools und Gadgets werden aber in der Regel von Einzelpersonen auf die Beine gestellt, nur selten von mehreren langfristig tätigen Entwicklern gemeinschaftlich umgesetzt und gewartet.

Software-Qualität

Sie ist bei den erstellten Tools sehr unterschiedlich. In wenigen Fällen ist der Quellcode einsehbar; anhand von Dokumentationsqualität und Verhalten sind jedoch Rückschlüsse möglich.

  • Teilweise professionell und sauber.
  • Teilweise laienhaft solange rumgefrickelt, bis im Moment meistens das rauskommt, was rauskommen sollte. Manchmal unerklärliches Verhalten. Bei der ersten notwendig werdenden Anpassung bricht alles zusammen.
  • Sehr unterschiedlicher Kenntnis- und Erfahrungshintergrund der Entwickler. Dementsprechend alles zu finden; von Profi-Arbeit bis Schulkind-Bastelei.
  • Oft entstanden aus einer privaten Lösung zur individuellen Arbeitserleichterung. Dann anderen Benutzern zur Verfügung gestellt; nur für die eigene Muttersprache vorgesehen. Keine Vorkehrungen getroffen für die Anpassung an sich ändernde Rahmenbedingungen, fremde Sprachen usw. und nicht auf jahrelange Weiterentwicklung ausgelegt.

Die einzige Lösung für eine langjährige Kontinuität ist eine saubere Dokumentation.

  • Die Vorstellung einer personellen mehrjährigen Kontinuität, egal ob hauptberuflich oder freiwillig, ist Illusion.
  • Es ist unausweichlich, dass Personen im Lauf der Zeit wechseln.
  • Günstig sind dabei Teams.
    • Möglichst aus zwei oder drei Leuten, von denen mal einer geht, einer neu hinzukommt und sich einarbeiten muss und einer handlungsfähig ist, Fragen beantworten und den informellen Geist weitertragen kann.
    • Das Konzept der WikiMedia Cloud-Projektgruppen ist genau auf solche Arbeitsgruppen ausgelegt. Leider sind viele Tools erneut als Ein-Benutzer-Account konzipiert, wie das bereits auf dem Toolserver zwangsläufig war und dort das gleiche Kontinuitätsproblem auslöste; und zwar automatisch ein halbes Jahr nach letzter Anmeldung der Account verfiel. Hier war die Übernahme des Accounts schwieriger und das Einarbeitungsproblem für die Nachfolger sehr viel größer.
  • Umstellungen im Lauf der Jahre durch sich ändernde Rahmenbedingungen und gestiegene Anforderungen sind im Softwarebereich unausweichlich.
    • Es ist eine laienhafte Vorstellung, man könne eine komplexere Aufgabe über Jahrzehnte mit unverändertem Code ausführen lassen.
    • Wartung, Pflege, Anpassung, Weiterentwicklung muss von vornherein in jedes haltbare Softwareprodukt eingeplant werden.
  • Nur eine gute Dokumentation minimiert den Umstellungsaufwand und ermöglicht nach jahrelanger Nichtbefassung den Wiedereinstieg.

Schlussfolgerungen

  • Die langjährige Wartung und Pflege von Software ist immer schwierg, egal ob freiwillig oder bezahlt.
  • Niemand kann dreimal täglich auf ein funktionierendes Werkzeug gucken, während nur alle Jahre oder nach ein paar Jahren etwas anzupassen und zu programmieren ist.
    • Dann ist aber für jeden Beteiligten eine erneute Einarbeitung in die Details erforderlich; am einfachsten für denjenigen, der es ursprünglich konzipiert hatte oder eine wesentliche Neufassung schrieb.
    • Es hilft auch nichts, das Werkzeug zu Trainingszwecken einmal in der Woche umzuschreiben und die Funktion zu erweitern. Damit würden zwangsläufig ständig Fehler in der produktiven Anwendung verursacht werden, und die von Anwendern erwartete Funktionalität schlägt Purzelbäume. Vielmehr wird man ein ordnungsgemäß arbeitendes Werkzeug in Ruhe lassen, über viele Monate, bis es etwas zu tun gibt. Dann muss man sich aber erst wieder einlesen.
    • Man hat aber nicht nur ein einzelnes Werkzeug zu betreuen, sondern mehrere Dutzend von zwanzig verschiedenen Ursprungsautoren.
Abgerufen von „https://de.wikiup.org/index.php?title=Benutzer:PerfektesChaos/Langfristige_Wartung_von_Werkzeugen_im_Wiki&oldid=208999534“