Seit 12 Jahren bin ich nun MSDN-Abonnent, im Laufe der Zeit in den verschiedensten Stufen. Von MSDN-Universal bis MSDN-Library hatte ich alles dabei, die jeweilige Stufe hing immer davon ab, welche Neuerungen von Microsoft im nächsten Jahr zu erwarten waren. Da die Lizenzen auch nach Ende des Abos nicht ablaufen, war es für mich letztlich unsinnig, die MSDN-Universal zu verlängern, wenn in absehbarer Zeit keine neuen Hauptversionen von Entwicklungstools geplant waren.

Vor zwei Jahren hat mich Ramirez auf das Empower-Programm für ISVs verwiesen. Die Programmgebühr beträgt 320 Euro (zzgl. USt), darin enthalten sind u.a. bis zu fünf Lizenzen Windows XP Professional und eine 5er-Lizenz von MSDN Universal (heute MSDN Premium). Das Programm läuft ein Jahr, kann aber um weitere 12 Monate verlängert werden. Der einzige Nachteil besteht darin, dass die Lizenzen im Gegensatz zu einem normalen MSDN-Abo nach den zwei Jahren auch verfallen, das heißt, sie gelten nur während des Programms.

Bei mir ist es nun Ende Mai soweit, daher war ich in letzter Zeit quasi auf der Suche nach einer Anschlussfinanzierung. Leider gibt es beim Abschluss eines MSDN-Abos neuerdings keine Upgrademöglichkeiten mehr von früheren Entwicklungstools, es bleibt nur der Erwerb eines neuen regulären MSDN-Abos übrig. Über die aufgelisteten Bezugsquellen kam ich dann zum Softwarevertrieb Heine. In einem sehr angenehmen Telefongespräch empfahl mir eine Mitarbeiterin, das MSDN-Abo als OPEN-Lizenz zu bestellen. Ein großer Vorteil dabei wäre, dass die Laufzeit einer OPEN-Lizenz zwei Jahre beträgt, die eines normalen MSDN-Abos dagegen (bekannterweise) nur ein Jahr. Preislich gesehen kommt man mit der OPEN-Lizenz sogar noch günstiger weg, so dass ich das Angebot gerne annahm.

Heute kamen nun die Autorisierungs- und Lizenznummer, mit denen sich auf dem Webportal eOPEN die Lizenzen verwalten lassen. Nach der Aktivierung der Lizenz konnte ich mit Hilfe des Verwaltungstools für MSDN-Abonnements auch gleich das MSDN-Abo freischalten. Nervige Produktaktivierungen werden in nächster Zeit wohl nicht mehr nötig sein, da es bei OPEN License Volumen-Lizenzschlüssel gibt.

Ich hatte mir Anfang des Jahres zwar vorgenommen, das Jahr relativ stressfrei zu verbringen, aber in den Wochen vor und nach Veröffentlichung einer neuen Version lässt sich eine gewisse Anspannung nicht vermeiden.

In der letzten Phase des Betatests vor dem Erscheinen eines Updates werden nur noch Fehler korrigiert. Neue Funktionen werden nicht mehr eingebaut, da diese nicht mehr ausreichend getestet werden können. Zwischen Betatest und Veröffentlichung des Updates liegen dann meist noch ca. 14 Tage, in denen nur noch schwerwiegende Probleme (sogenannte Showstopper) behoben werden. Nach der Freigabe beginnt dann das bange Warten, ob meine fleißigen Betatester nicht doch den einen oder anderen Fehler übersehen haben. Aufgrund des hohen Funktionsumfangs ist das auch nicht vermeidbar. In der 11.1 hatte sich z.B. ein Fehler bei der Erkennung von mit dem SC8 verschlüsselten SCB-Archiven eingeschlichen. Dies wurde erst nach der Veröffentlichung von einem Anwender entdeckt, der solche Archive noch entpacken möchte. In dieser ganzen Zeitspanne steht die Entwicklung neuer Funktionen praktisch still. Um diese Zeit über das Jahr gesehen möglichst gering zu halten, versuche ich, Updates für SpeedCommander und Squeez kurz hintereinander zu legen.

Die Anspannung hängt auch davon ab, wieviel Code seit der letzten Version überarbeitet wurde. Anfang des Jahres habe ich mich z.B. in einen großen Teil des von Rainer übernommenen Codes eingearbeitet und diesen auch aufgeklart. Dabei bleibt es leider nicht aus, dass sich auch Fehler einschleichen. Der eine oder andere wird sich jetzt sicher fragen: Warum lässt Du es dann nicht einfach so, wie es ist? Nun, fremder Code ist fast wie eine Blackbox. Man hat keinen Überblick über das Ganze und hangelt sich bei der Fehlersuche von einer Zeile zur anderen. Erweiterungen sind auch nur schwer möglich, da man aufgrund des fehlenden Überblicks nicht abschätzen kann, wo man ansetzen muss und welche Seiteneffekte auftreten könnten. Daher habe ich mir angewöhnt, fremden Code Stück für Stück durchzugehen und in meinen Schreibstil zu übertragen. Das hilft enorm, vorhandene Zusammenhänge aufzudecken und die Funktionsweise des Moduls schrittweise zu erfassen.

Wie es ausschaut, kann es nun mit dem Programmieren weitergehen. Irgendwie kribbelt es auch schon wieder in den Fingern…