JKCEMU - Hinweise zum Modifizieren von JKCEMU

JKCEMU ist OpenSource. Sie können also die Quelltexte nehmen und verändern. Wenn Sie das beabsichtigen und modifizierte JKCEMU-Versionen veröffentlichen möchten, müssen die Lizenzbestimmungen (bitte lesen!) strikt eingehalten werden. Des Weiteren bitte ich zur Vermeidung von Konflikten, Missverständnissen, Streitereien oder anderen Problemen folgende Hinweise zu beachten:

JKCEMU ist ein Hobbyprojekt, welches ich in meiner Freizeit realisiere. Es geht mir bei dem Projekt nicht primär darum, den besten Emulator für DDR-Kleincomputer zu entwickeln, sondern ich möchte mich am Beispiel eines Emulators softwaretechnologisch ausprobieren. JKCEMU ist für mich eine Art Java-Spielwiese. Deshalb sind auch Dinge wie Audiorecorder, Assembler, BASIC-Compiler oder Bildbearbeitung enthalten, was nicht unbedingt zu einem Emulator gehört. Des Weiteren habe ich einige Funktionalitäten, die heutige Betriebssysteme nicht bzw. in der von mir gewünschten Form/Bedienung nicht (mehr) enthalten, für meinen eigenen Nutzungskomfort ebenfalls eingebaut (z.B. Dateisuche, HEX-Editor, Prüfsummen-/Hashwertberechnung, Rechner). Das erklärt den Funktionsumfang von JKCEMU, über den sich manche bisher vielleicht etwas gewundert haben.
Ich bekomme häufig Anregungen und Wünsche zur Verbesserung und Erweiterung von JKCEMU. Dafür möchte ich mich herzlich bedanken. Allerdings werde ich solche Wünsche nur dann erfüllen, wenn sie in mein Konzept passen, d.h. wenn ich von deren Sinnhaftigkeit und Machbarkeit überzeugt bin, und wenn ich dafür Zeit, Lust und Laune finde. Letzteres ist aufgrund meiner beruflichen Entwicklung immer weniger bzw. immer seltener der Fall geworden. Viele Wünsche, auch eigene Ideen, werde ich wohl nicht mehr groß umsetzen können.
Wenn ich einen Änderungswunsch ablehne, führt das häufig zu Diskussionen. Hier möchte ich deutlich sagen, dass mir meine spärliche Freitzeit für solche Diskussionen zu schade ist. Ich muss mich nicht erklären, warum ich in meinem Hobbyprojekt etwas so, so oder so oder auch gar nicht mache. Ich bitte darum, das einfach zu aktzeptieren!
Wenn ich gewisse Änderungswünsche nicht erfüllen kann oder will, kommen manche Anwender auf die Idee, selbst Hand anzulegen. Ich bin schon mehrfach gefragt worden, ob ich die Quellen in ein öffentliches Repository legen kann, damit Interessierte an dem Projekt mitarbeiten können. Nach langen Überlegungen bin ich zu dem Schluss gekommen, das nicht zu tun. Wenn mehrere Leute an einem Projekt arbeiten, müssen diese koordiniert werden und es kommen zwangsweise Diskussionen (und vielleicht auch Streitereien) über Strategien, Entwicklungsrichtungen usw. auf. Mit soetwas muss ich mich bereits auf Arbeit beschäftigen und brauche es in meiner Freizeit nicht. JKCEMU ist für mich ein Hobbyprojekt und eine Java-Spielwiese, und das soll es auch bleiben.
Da ich die Quellen nicht in ein öffentliches Repository gelegt habe, gibt es inzwischen mehrere JKCEMU-Forks im Internet. Mir persönlich ist es wichtig, dass ein Anwender ganz klar unterscheiden kann, ob er eine originale JKCEMU-Version vor sich hat (die also von mir stammt) oder ob es eine Version von einem abgeleiteten Projekt (Fork) ist. Ich möchte nämlich nicht, dass mein Qualitätsanspruch an JKCEMU verwässert wird. Außerdem möchte ich nicht von Anwendern kontaktiert werden, die mit einer modifizierten JKCEMU-Version ein Problem haben. Deshalb bitte ich darum, wenn im Fork eine größere Weiterentwicklung geplant ist, am besten gleich den Projektnamen zu ändern. Wenn nur kleine Änderungen geplant sind und deshalb der Name JKCEMU beibehalten werden soll, dann bitte wenigstens das Versionsnummernschema entspreched erweitern! Wenn z.B. jemand mit dem Nicknamen oder den Initialen XY auf Basis von JKCEMU Version 0.9.7 einen Fork aufmacht, dann soll er bitte als erstes in der Datei Main.java die Versionsnummer auf z.B. "0.9.7-XY-0.1" oder so ähnlich ändern! Wenn man im Emulator den Menüpunkt Über JKCEMU... aufruft, muss aus dem Namen oder des Versionsnummernschemas ersichtlich sein, dass die vorliegende Version aus einem Fork stammt! Saubere Versionierung ist eine zwingende Grundlage für Softwarequalität. Und da kann man nicht einer modifizierten Version die exakt gleiche Versionsnummer geben wie der originalen Version!
Ich selbst werde mir für zukünftige originale JKCEMU-Versionen kein anderes Versionsnummerschema als das bisher verwendete aufzwingen lassen. Wenn also die aktuelle offizielle Version 0.9.7 heißt, kann eine von dritten modifizierte Version nicht einfach 0.9.8 oder 1.0 genannt werden, denn so werden zukünftige offizielle JKCEMU-Versionen heißen. Deshalb die Vorgabe mit der Erweiterung des Versionsnummernschemas für modifizierte JKCEMU-Versionen (oder eben dem neuen Projekt einen anderen Namen geben).
Ich habe mir JKCEMU ausgedacht, sowohl das Projekt als auch den Namen. Deshalb sind nur die auf meiner Homepage zum Download angebotenen JKCEMU-Versionen offiziell! Ich möchte nicht sehen, dass jemand modifizierte JKCEMU-Versionen als offizielle JKCEMU-Versionen anbietet. Wenn der Projektname geändert wurde, dann kann man unter dem neuen Namen natürlich offizielle Versionen herausbringen und anbieten, aber eben nicht unter dem Namen JKCEMU.
Da JKCEMU für mich eine Java-Spielwiese ist, auf der ich mich ohne äußere Beschränkungen austoben möchte, soll bitte niemand die Erwartung haben, dass ich Programmcode aus einem JKCEMU-Fork in die offizielle JKCEMU-Linie übernehmen werde. Es kann sein, dass ich das im Einzelfall tun werde (ich darf es ja, da der Fork zwangsweise und ausschließlich der GNU-GPL Version 3 unterliegt), aber versprechen tue ich nichts. Es kann aber auch sein, dass ich eine in einem Fork neu implementierte Funktionalität in meiner offiziellen JKCEMU-Linie mit eigenem Programmcode und somit unter eigener Urheberschaft selbst nachimplementiere.

Mein Qualitätsanspruch

Das oben geschriebene mag streng, hochtrabend und pingelig klingen. Deshalb möchte ich kurz erläutern, was ich mit Qualitätsanspruch meine. Ich persönlich freue mich z.B. sehr, wenn es mir gelingt, eine gewünschte Funktionalität besonders intuitiv, logisch und einfach benutzbar (zusammenfassend also "perfekt") zu implementieren. Deshalb kann man in JKCEMU Dateien fast überall auch mit Drag&Drop öffnen, der Dateiauswahldialog öffnet im zuletzt benutzen Verzeichnis, Fehlermeldungen sind aussagekräftig, bei einigen Konfliktsituationen in den Einstellungen warnt der Emulator usw... Dass ich diesen Qualitätsanspruch nicht überall erreiche, weiß ich auch und ist aufgrund meiner begrenzten technischen und zeitlichen Möglichkeiten auch nicht machbar. Trotzdem strebe ich danach.

An einfachen kleinen Beispielen möchte ich mal zeigen, wo ich einen niedrigeren Qualitätsanspruch als meinen eigenen sehe. Es gibt auch andere Beispiele, auf die ich hier aber nicht eingehen werde.

Produktqualität

JKCEMU hat eine konsequent deutsche Benutzeroberfläche, da sich der Emulator ausschließlich an deutschsprachige Anwender richtet (die in der DDR hergestellten und von JKCEMU emulierten Computer wurden gewöhnlich nicht ins Ausland verkauft). Wenn nun in einem Fork eine neue Funktion eingebaut wird und diese in der Oberfläche mit englischen Wörtern sichtbar ist, ist die Sprache nicht mehr konsequent Deutsch (Sprachwirrwarr).
Wird in einem Fork eine neue Funktion eingebaut, aber in der Hilfe nicht beschrieben, gibt es eine Diskrepanz und der Emulator fühlt sich nicht mehr konsistent an.

Die hier aufgeführten Beispiele sind nicht wirklich gravierend und ich möchte auch niemanden vergraulen, selbst Hand anzulegen. Auch möchte ich niemanden meinen Qualitätsanspruch aufzwingen (deshalb kommentiere und bewerte ich die Forks auch nicht), aber ich möchte, dass jeder sich mit seinen eigenen Federn schmückt. Dazu ist auch eine gewisse Qualität im Projektmanagement notwendig.

Projektmanagementqualität

Wird ein neuer Fork eröffnet, Quelltextdateien geändert aber die Versionsnummer nicht geändert, dann passiert irgendwann folgendes: Jemand nimmt den aktuellen Softwarestand im Fork, erzeugt einen Build und verteilt diesen (das muss nicht mal der Projektmanager selbst sein bzw. dieser weiß davon evtentuell noch nicht einmal etwas). Und schon kursieren modifizierte JKCEMU-Versionen mit einer originalen Versionsnummer! Und genau deshalb ist das Nichtanpassen des Versionsnummernschemas für mich ein mangelhaftes Qualitätsverständnis des Fork-/Projektmanagers!

Die Krönung ist dann, wenn ich eine Fehlermeldung von so einer modifizierten JKCEMU-Version erhalte (gemeint ist die Protokolldatei, die JKCEMU bei einem internen Programmabsturz erzeugt), ich von der Modifizierung nichts weiß und mir einen Wolf suche, weil der gemeldete Fehler in der (von mir als original geglaubten Version) an der betreffenden Stelle irgendwie so gar nicht auftreten kann. Da bin ich dann wirklich sauer, wenn ich meine spärliche Freizeit wegen so etwas vergeute!