VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
Oktober 2003
[Inhaltsverzeichnis]
|
| Von Christian Langanke © Oktober 2003 |
Wenn es wahr ist, daß interessante Technologien und Konzepte sehr wichtig für Programmierer sind, die neue Methoden kennenlernen möchten, wie beeinflussen die Geschehnisse des letzten Jahrzehnts vielleicht die Shareware- und Freeware-Entwickler für OS/2 und eComStation? Schließlich hat IBM als Erfinder von OS/2 zunächst Schlüsseltechnologien entwickelt und in OS/2 integriert und dann dramatisch die Richtung gewechselt. Schauen wir aus der Blickrichtung eines Programmierers auf Teile dieser Geschichte zurück, ohne allzu technisch zu werden. Und selbst wenn wir den traurigen Teil des aufgegebenen Ports von OS/2 auf Power PCs sowie weitere Details auslassen, bleibt auf vieles zurückzuschauen.
Für jede Firma ist es wichtig, neue Technologien oder Methoden zu finden. Also hat auch IBM wie jede andere Firma von Zeit zu Zeit versucht, eine neue Technologie zu finden. Dies ergab jeweils einen neuen Begriff, mit dessen Hilfe man Aufmerksamkeit im Markt und damit hoffentlich mehr Marktanteil erlangen konnte. Wenn IBM nun eine solche Idee für eine neue Technologie hatte, passierte üblicherweise eins von zwei Dingen: entweder wurden vorhandene Technologien für die neue benötigt, was so gesehen besser für existierende Lösungen gewesen ist. Oder es wurde angekündigt, alte Technologien würden noch eine Weile weiter neben der neuen Technologie unterstützt, aber IBM versuchte dann, ihre Kunden langsam in Richtung ihres gegenwärtigen, neuen Paradigmas zu bewegen, weil neue Methoden teilweise, oder schlimmer, gänzlich inkompatibel zu existierenden Lösungen war. Um ehrlich zu sein, ist an diesem Vorgang nichts besonderes, tatsächlich passiert dies mit allen möglichen Produkten immer wieder. Und so passierte es auch mit OS/2 und den Schlüsseltechnologien, die einmal darin integriert wurden.
Aber beginnen wir von vorne. In den ersten vier Jahren seit OS/2 V2.0 wurden alte Technologien nicht aufgegeben, sondern immer sozusagen zu einer neuen Technologiestufe weiterentwickelt. Ich denke, in diesen Tagen mußten Programmierer den Eindruck haben (und ich hatte ihn definitiv), daß es einen klaren und direkten Weg in der Art gibt, in der immer neue Schlüsseltechnologien in OS/2 integriert wurden.
Zunächst war (und ist immer noch) die Workplace Shell, die auf dem System Object Model (SOM) basiert. Das bedeutet, daß jedes Objekt der Workplace Shell von der SOM-Laufzeitbibliothek gesteuert wird. Dann wurde OS/2 um DSOM erweitert, die verteilte Version von SOM (Distributed SOM), das den Zugriff auf (D)SOM-Objekte auf andere Maschinen im Netzwerk ermöglichte. Dies kann man zur verteilten Haltung von Daten über Maschinengrenzen hinaus benutzen, aber es bedeutet dennoch mehr als nur etwa das Verschieben von Dateien von einer lokalen Festplatte auf ein Netzlaufwerk, denn ein (D)SOM-Objekt beinhaltet Daten und Funktionalität.
Aber DSOM kann nicht nur benutzt werden, um mit Objekten auf anderen OS/2-Mschinen zu interagieren, denn (D)SOM ist ganz nebenbei die OS/2-Implementation eines Common Object Request Broker (CORBA). Das bedeutet, daß SOM/DSOM-Objekte mit Objekten auf anderen Systemen kommunizieren können, gleichgültig, welches Betriebssystem darauf läuft, solange dort nur eine CORBA-Implementation läuft (das wird weiter unten interessant). Auf Basis von SOM/DSOM implementierte IBM dann das OpenDoc-Konzept, das ein Framework von Anwendungsteilen (Application Parts, hier ein anderer Name für Objekte) darstellt, mit welchem der Endanwender Dokumente beliebigen Typs zusammenstellen kann (sogenannte Compound Documents). Dies funktioniert ähnlich wie OLE, aber das Konzept ist viel besser.
Aber was passierte mit all diesen Technologien? Sie wurden alle aufgegeben, als das schlimmste für OS/2 passierte, was passieren kann: IBM fand eine neue Schlüsseltechnologie, für die die alten Technologien nicht mehr benötigt wurden, sondern alle inkompatibel dazu waren - Java. Von diesem Zeitpunkt an beschloß IBM aus mehreren Gründen, sich langsam von OS/2 bzw. der Pflege eines eigenen PC-Betriebssystems wegzubewegen, zum einen, weil sie mit OS/2 nicht genug Marktanteil gegenüber den Mitbewerbern im Betriebssystemmarkt gewonnen hatten, und sie setzen zum anderen auf die Cross-Plattform-Java-Strategie und den sogenannten Thin Networked Client. Es ist eine pure Ironie für OS/2-Anwender, daß IBM nicht etwa völlig konsequent diesem neuen eigenen Paradigma folgte, sondern gleichzeitig erfolgreich einen anderen fetten PC-Client als Solution Provider unterstützte (nämlich Windows NT und Nachfolger, mega-fett im Vergleich zu OS/2). Soviel zu IBMs Vision eines Thin Networked Client... Aber was ist nun mit OS/2 und den wertvollen Technologien, die darin implementiert wurden?
Ja, die Workplace Shell ist eine Technologie, die aufgegeben wurde. Der letze Entwicklungsschub (wenn wir es denn so nennen möchten) fand statt, als OS/2 Warp 4 erstellt wurde und die OS/2-Arbeitsoberfläche dafür etwas überarbeitet wurde. Danach fand noch etwas an Fehlerbereinigung statt, mehr nicht. Es gab noch etwas an SOM und Workplace Shell-Entwicklung innerhalb der IBM, aber es darf wohl angenommen werden, daß diese nie die Festplatten der IBM-Entwickler verlassen haben, und daß das unglücklicherweise wohl auch nicht mehr passieren wird.
Ja, Distributed SOM ist eine Technologie, die aufgegeben wurde. Es ist etwa zehn Jahre her, daß ich IBMler auf einer Technical Interchange Conference ihre verteilte SOM-Anwendung präsentieren sah, die ihre Daten und Funktionen zwischen OS/2-Workstations, einem AS/400-Server und sogar einem Win-3.1-Client austauschen ließ. All diese Systeme ließen einen CORBA laufen, die Objekte zwischen ihren Systemen interagieren ließen. Dies war eine beeindruckende Demonstration für eine verteilte Anwendung in einem heterogenen Netzwerk! Und während es vielleicht heutzutage eine CORBA-Implementation gibt, so daß Java und DSOM-Onjekte ebenso interagieren könnten, versuchte IBM später noch nicht einmal, Java so an die DSOM-Schnittstelle anzupassen. Dies wäre die Möglichkeit für OS/2-Kunden gewesen, (D)SOM und der Workplace Shell als Benutzerschnittstelle weiternutzen zu können, wenn sie es denn wollten. Aber IBMs Entscheidung über OS/2 erlaubte dies offensichtlich nicht...
Ja, OpenDoc ist eine Technologie, die aufgegeben wurde. Die großartige Vision von Anwendungsteilen (Application Parts), mit denen Endanwender ihre eigene Office Suite zusammenstellen, indem sie diese Anwendungsteile, oder besser, OpenDoc-Objekte in ihre sogenannten Compound Documents ziehen, ist niemals auch nur ansatzweise wahr geworden. Anstatt, daß der Anwendern nur die Programmteile kauft und verwendet, die er wirklich braucht, kosten total überfrachtete Office-Pakete weiterhin viel zu viel Geld. Und die größte Firma, die nach diesem Schema Geld verdient (raten Sie mal, welche?), denkt sich ein Lizenzmodell nach dem nächsten aus, um noch mehr Geld aus den Kunden zu ziehen, obwohl der durchschnittliche Anwender allenfalls 40 bis 50 Prozent der ganzen Suite benötigt.
Alle diese Technologien wurden zugunsten von Java aufgegeben, aber OpenDoc ist vielleicht die größte verpaßte Gelegenheit, zum einem für den Endanwender, aber sicher auch für IBM als Softwarehersteller. Wenn dies zu einer ernsthaften Alternative zu fetten Office-Paketen hätte heranwachsen können, hätte dies weitreichende Einflüsse auf den Betriebssystem- und Office-Software-Markt haben können. Aber statt dieser Vision zu folgen, und das gegebenenfalls mit wenig nur Aufwand über Jahre verteilt, gab IBM einfach eine weitere großartige Technologie zugunsten von Java auf.
Auf anderen Plattformen wurden im Gegensatz dazu diese Technologien übernommen, so wie das GNOME-Projekt für Linux einen CORBA implementiert hat, und das etwa drei Jahre, nachdem IBM OpenDoc und mit ihm SOM/DSOM aufgab (Zur Erinnerung: die Workplace Shell basiert auf (D)SOM, was eine OS/2-Implementation eines CORBA ist). So haben also Linux-Freizeitprogrammierer erfolgreich eine Technologie aufgegriffen, die IBM drei Jahre zuvor zugunsten von Java aufgegeben hatte. Und obwohl GNOME wegen anderer Gründe (noch?) keine ernsthafte Alternative zur Workplace Shell ist, ließ mich das dennoch aufhorchen!
Der Punkt, auf den ich letztendlich hinaus will, ist folgender: CORBA und seine OS/2-Implementation werden zwar nicht länger weiterentwickelt, aber eine Technologie ist nicht nur einfach tot, nur weil IBM sie aufgegeben hat. Könnte es sein, daß IBM die falsche Entscheidung traf? Ist es möglich, daß in der engstirnig angelegten Jagd auf eine allumfassende Lösung versäumt wurde, gut laufende Technologien einfach weiterlaufen zu lassen? Haben sie nicht etwa überstürzt die Entscheidung getroffen, OS/2-Schlüsseltechnologien auslaufen zu lassen?
Das führt mich zurück zu der Frage über Technologien und was sie für OS/2-Programmierer bedeuten. Während Warpstock Europa 2000 hörte ich einige Leute sagen: "Hört einfach nicht immer darauf, was IBM sagt und tut.". Das sollte heißen, daß man von IBM auf lange Sicht nicht mehr viel erwarten konnte, und dies stimmt ganz besonders für Entwickler, die native Programme für OS/2 und eComStation erstellen wollen. Für diese Entwicklergemeinde geht es jetzt viel mehr um die Suche nach Alternativen in der Form, daß sie sich selbst Schlüsseltechnologien suchen und nicht länger darauf warten, was sie von IBM präsentiert bekommt. Da man von IBM mitterweile bezüglich Entwicklung nicht viel mehr als Java und Linux erwarten kann, sollten wir Java an den paar Stellen benutzen, wo es vielleicht für uns Sinn macht, und sonst Gebrauch von Linux-Konzepten und Programm-Ports machen, da wo dies Sinn macht. Aber der Fokus liegt nicht länger auf IBM, oder darauf zu warten, daß sie OS/2 wieder im großen Stil unterstüzen oder neue Technologien darin implementieren. Das werden sie nicht tun, aber das macht eigentlich nichts mehr aus.
Nachdem all dies gesagt ist, komme ich zurück auf den Punkt, daß ich sage: Benutzt, was verfügbar ist. Nun füge ich hinzu: sucht außerdem nach anderen Optionen. Warum sollte man nicht einen CORBA auf Linux-Basis reimplementieren? Oder sogar etwas dazu vergleichbares Cross-Plattform für OS/2 und Linux zugleich entwickeln? Es sind noch soviele Möglichkeiten offen und neue kommen von anderen Seiten immer wieder dazu. Mein Programmierspaß mit OS/2 ist noch lange nicht vorbei. Er beginnt (von neuem) mit jeder neuen Bibliothek oder jedem neuen Programm, daß wir z.B. von Linux her übernehmen können. Und er endet noch lange nicht damit, über Dutzende neue Ideen nachzudenken, die ich noch für neue Workplace Shell-Erweiterungen habe.
Habe ich gerade eben gesagt, dass IBM keine Rolle spielt? Sie dachten sicher, ich will Sie auf den Arm nehmen, oder? Nun, zumindest, was die Implementation neuer Technologie angeht, meine ich immer noch, daß ich damit richtig liege, aber es gibt immer noch eine Stelle, an der IBM sprichwörtlich den Stecker ziehen kann. Wie lange wird IBM OS/2 unterstützen, und damit die OEM-Version eComStation, zumindest mit Einheitentreibern? Wie lange wird IBM es Serenity System erlauben, der einzige Großkunde zu sein, der Fehlerkorrekturen einfordern kann? Wenn Sie neugierig darauf sind, gehen Sie los und kaufen Sie eComStation-Lizenzen, sonst könnte es mit OS/2 und Co. schneller zu Ende sein, als wir uns vorstellen können.
Eine andere Frage beschäftigt ebenfalls die Gemüter, und, ja, ich weiß, es gibt regelrechte Flame-Schlachten darüber, was denn die beste Möglichkeit für Endanwender ist, die Sache am Laufen zu halten: entweder Convenience Packs direkt von IBM zu kaufen oder durch den Kauf von eComStation diese zu unterstützen. Witzigerweise denken einige Leute, daß IBM länger bei OS/2 dabei bleiben wird, wenn SOHO-Anwender (Small Office/Home-Anwender) weiterhin Convenience Packs kaufen würden, anstatt eComStation-Lizenzen. Hey Leute, wacht auf und hört auf, zu träumen. Die eher geringe Menge an Geld, die SOHO-Anwender ausgeben könnten, um entweder direkt von IBM zu kaufen oder OEM-Lizenzen, lohnt das Nachdenken überhaupt nicht, verglichen mit dem Geld, das IBM noch immer mit großen Installationen in großen Firmen verdient hat (und irgendwo offensichtlich immer noch verdient ;-) ). So traurig es klingt, irgendwelches Geld aus dem SOHO-Markt wird IBM nicht dazu bringen, auch nur etwas länger bei OS/2 zu bleiben, als sie durch bestehende Verträge mit ihren Großkunden gezwungen werden. Punktum. Lassen Sie uns also hoffen, daß zumindest ein Großkundenvertrag niemals auslaufen wird, nämlich der des Herstellers von eComStation.
Bis dahin mag es für den Endanwender auch eine Frage des Geschmacks sein, ob es Convenience Pack oder eComStation sein soll. Und ich muß sagen, daß ich den eComStation-Ansatz sehr viel mehr mag. Ich kann mich nämlich nicht errinnern, daß IBM zu irgendeiner Zeit Software aus der Freeware-/Shareware-Szene in OS/2 integriert hätte, stattdessen schlugen sie eine große Anzahl von hervorragenden Vorschlägen zur Erweiterungen an OS/2 aus, sei es aus Desinteresse oder aus übergroßer Angst vor Instabilitäten. Nun aber werden in eComStation eine Menge an Ideen und Software von außen integriert. Dabei ergeben sich selbstverständlich Risiken wie etwa Integrationsprobleme, wie uns die erste Version der eComStation gezeigt hat. Aber meiner Meinung nach werden diese durch die Chancen mehr als aufgewogen, wie uns eComStation V1.1 nun hoffentlich zeigen wird.
Wir haben noch nicht über eine wichtige, wenn nicht gar die wichtigste Motivationsquelle für Entwickler gesprochen, nämlich Rückmeldung. Irgendwelche Rückmeldungen vom Anwender, und wenn es nur ein schlichtes Dankeschön ist, ist sehr wichtig. Gleichzeitig scheint dies aber eine Art von Tabu für die meisten Endanwender zu sein, denn zumeist verhalten sich OS/2- und eComSation-Anwender so, als wenn es eine überwältigende Menge von Freeware- oder Shareware-Programmierern gäbe, die nur darauf wartet, einfach zu bedienende, billige, wenn nicht gar kostenfreie und stabile Lösungen anbieten zu dürfen. Und gleichzeitig beklagen sich Anwender darüber, daß die Anzahl der verfügbaren Anwendungen und Utilities abnehmen würde...
Ich kenne mehr als einen Programmierer, der wirklich gute Software für OS/2 und nun eComStation erstellt hat, und total frustriert ist, weil einfach keine Rückmeldungen kommen. Viele Leute benutzen Software jahrelang und sagen noch nicht einmal Danke, obwohl dies nicht viel mehr kosten würde als eine E-Mail. Können Sie sich vorstellen, daß ein Entwickler ein Programm einfach aufgibt, weil einfach nichts zurückkommt? Wenn Sie das herausfinden wollen, benutzen Sie einfach weiter Programme und teilen Sie das den Autoren oder Programmpflegern einfach nicht mit. Es ist die einfachste Weise, auf Dauer mehr gut funktionierende und gepflegte Programme verschwinden oder veralten zu lassen, als Sie sich vorstellen können.
Aus meiner persönlichen Erfahrung kann ich sagen, daß die wenige Rückmeldung, die überhaupt kommt, Fehlermeldungen und zusätzliche persönliche Anforderungen und Wünsche bzw. Vorschläge für ein Programm sind. Und manchmal versuche ich mir einzureden, daß dies doch immer noch besser sei als gar nichts. Aber selbst dieses wenige kommt oft überhaupt nicht, ganz zu schweigen von glücklicherweise seltenen Fällen, in denen Anwender sich in einer unglaublich übertrieben Art und Weise über vermeintlich fehlende Funktionen oder fehlende Qualität aufregen, als hätten sie viel Geld für ein Programm ausgegeben, auch wenn sie das nicht getan haben. Wie dumm sich manche Leute benehmen können...
Ein anderes, weithin erlebbares Phänomen ist, daß Anwender einfach darauf warten, daß Software, für die sie nichts bezahlen (wollen), einfach des Weges kommt, sozusagen betriebsbereit und fehlerfrei. Während dies aus verschiedenen Gründen für Anwender auf anderen Plattformen mehr oder weniger eine übliche Haltung ist und sein kann, ist dies definitiv keine passende Haltung für die OS/2- und eComStation-Anwender. Lassen Sie mich hier zwei Beispiele anführen.
Nehmen wir zum einen den Internet-Assistenten, der eine komplexe, aber dennoch modulare Anwendung darstellt. Sie benötigt wie viele andere Programme eine Menge von Tests, um sicherstellen zu können, daß sie auf unterschiedlichen Systemen funktioniert. Während dieses Programm nicht sehr hardwareabhängig ist, wie z.B. Einheitentreiber, konfiguriert es aber auch nicht weniger als sechs verschiedene Einwahlprogramme, die der Anwender auf einem System installiert haben kann. Um nun sichergehen zu können, daß alles stabil funktioniert, ist es eigentlich erforderlich, daß der Internet-Assistent in Verbindung mit allen Einwahlprogrammen getestet würde, und das auf sovielen Systemen wie möglich. Außerdem ermöglichen die meisten Einwahlprogramme mehr als eine Kommunikationsart, sodaß derselbe Anwendungsfall jeweils für serielle, ISDN und DSL-Verbindungen zu testen ist, wenn diese von einem Einwahlprogramm unterstützt wird. Für den Internet-Assistenten existiert ebenfalls eine ausführliche Web-Site, die dies alles im Detail erklärt und zur Unterstützung, vor allem beim Testen aufruft. Aber ob Sie es glauben oder nicht - während einer monatelangen Betaphase (die mittlerweile abgeschlossen ist), habe ich brauchbare Rückmeldungen eigentlich nur von Leuten bekommen, die ich persönlich angesprochen und darum gebeten habe. Außerdem ist gerade mal eine (!) einzelne Fehlermeldung im Bugtracker von eComStation eingegangen (der BugTracker ist öffentlich zugänglich für registrierte Anwender der eComStation). Ansonsten meldet sich nur ab und an jemand bei der Mailingliste an, natürlich in den meisten Fällen, ohne auch nur eine einzige Zeile zu schreiben.
Hey, alle zusammen, wacht mal auf. Dieses Projekt könnte schon bald tot sein, nicht etwa, weil keiner programmieren möchte, sondern weil einfach kaum jemand Notiz davon nimmt und etwa hilft mitzutesten. Mir ist schon klar, daß es sich komisch anhören muß, daß eComStation-Anwender noch etwas Arbeit erledigen sollen, obwohl sie doch ein eComStation-Paket gekauft haben oder noch kaufen wollen, und dieses Paket beinhaltet ja genau dieses Programm, das sie jetzt obendrein noch testen sollen. Aber so läuft das Spiel einfach, oder es wird keinen stabilen Internet-Assistenten geben. Nachdem ich jetzt über 16 Monate programmiert habe, kann ich das Programm nicht auch noch komplett durchtesten, aber nicht nur wegen der fehlenden Zeit, sondern auch, weil ein Test nur dann Sinn macht, wenn er auf möglichst vielen Systemen erfolgt. Im schlimmsten Fall müssen Anwender die ASCII-Konfigurationsdateien von ISDNPM oder eCSCoNet wieder von Hand editieren, mit Dutzenden von Schlüsselwörtern - nun, viel Spaß damit! Ich kann Ihnen versichern, daß es wesentlich weniger mühevoll ist, mal beim Testen mitzuhelfen...
Ein anderes Beispiel ist Odin. In den letzten 18 Monaten hat es dort eine gute Enwicklung im Projekt gegeben, alles wird stabiler, mehr Programme arbeiten nun gut genug, um sie täglich verwenden zu können. Nun hat mir ein befreundeter Programmierer von einem OS/2-Anwender erzählt, der über eine Anwendung berichtete, die zu diesem Zeitpunkt nicht mit Odin unter OS/2 lief, aber er würde hoffen, daß dies wohl bald, eben nur einige Zeit später tun würde. Das Merkwürdige an der Sache waren nun die Gründe, warum er dachte, daß es so kommen müßte und wie er sich gegenüber dem Odin-Projekt verhielt. Er meinte, schließlich hätte Odin im letzen Jahr ja ziemlich Forstschritte gemacht. Dennoch ist er niemals mit dem Odin-Team in Kontakt getreten, noch hat er in der Mailingliste nach bestimmter Funktionalität gefragt. Ich weiß auch nicht, ob diese Person jemals einen Eintrag in die Applikationsdatenbank auf netlabs.org gemacht hat, um mitzuteilen, ob und wie gut sich eine Windows 32-Bit-Anwendung installieren lässt bzw. wie gut sie läuft. Aber aus naheliegenden Gründen nehme ich an, daß es nicht so ist.
Sie werden sich fragen, warum ich dieses Verhalten merkwürdig finde? Nun,
lassen Sie mich Ihnen einige grundlegende Wahrheiten aus der Welt der Shareware-
und Freeware-Entwickler offenbaren, die sich vielleicht noch nicht herumgesprochen
haben:
Zu allererst werden die Dinge nicht notwendigerweise besser in der Zukunft, nur
weil sie sich in der Vergangenheit verbessert haben. Das bedeutet, daß es
absolut keine Garantie dafür gibt, daß zum Beispiel ein bestimmtes Projekt
nicht plötzlich in einen Tiefschlaf fällt, und wenn, würden Sie das
über Monate hinweg noch nicht eimal mitbekommen.
Zweitens wußte dieser Anwender nicht, warum Odin eigentlich einen so großen Fortschritt in den letzten achtzehn Monaten gemacht hat. Es wurde, zumindest einen bestimmten Teil betreffend, für die Verwendung in einem kommerziellen Projekt angepaßt, und dies geschah aus kommerziellen Gründen, und nicht etwa, weil die Odin-Entwickler plötzlich viel mehr Freizeit hatten. Wenn also, aus welchen Gründen auch immer, in naher Zukunft keine weiteren kommerziellen Projekte einen Entwicklungsschub für Odin auslösen, wird es um so länger dauern, daß beliebige Anwendungen plötzlich doch unter Odin laufen. Sie können sich eines sicher sein: es gibt absolut keinen Automatismus dafür, daß dies für eine bestimmte Anwendung überhaupt jemals wahr werden wird.
Drittens gibt es natürlich keine Garantie, daß alle Odin-Entwickler für immer beim Projekt bleiben, schließlich haben einige von ihnen über Jahre mitgemacht, und mittlerweile gibt es vielleicht auch mal andere interessante Dinge zum Programmieren. Außerdem sollte man sich nicht durch die recht lange Liste derjenigen beeindrucken lassen, die etwas zum Projekt beigesteuert haben: viele davon haben eher einen sehr kleinen Teil geliefert, wohingegen nur sehr wenige sehr viel programmiert haben. Und nun denken Sie mal darüber nach, was passiert, wenn nur einer der wenigen, die viel an Odin mitgearbeitet haben, die Mitarbeit an Odin einstellt. Und raten Sie mal, was mittlerweile passiert ist. Und warum...
Einfach wegen des vierten und wichtigsten Punktes, und hier schließt sich der Kreis wieder. Es geht um fehlende Rückmeldung, und hier nicht nur darum, Danke zu sagen, sondern auch vernünftige Fehlerbeschreibungen abzugeben. Einer derjenigen Entwickler, der Odin mit am meisten vorangebracht hat, ist schier frustriert über die mangelhafte Beteiligung von Endanwendern und hat schlicht aufgegeben.
Dies sind nur zwei Beispiele, und es gibt sicherlich noch mehr davon. Als Schlußfolgerung aus diesem Punkt bleibt zu sagen, daß die Endanwender von OS/2 und eComStation auf dem besten Wege sind, durch ihr Verhalten selbst die Anzahl der motivierten Programmierer für ihre Plattform auszudünnen. Es macht den Eindruck, daß sie zu viele Dinge für selbstverständlich oder zu unwichtig nehmen, was im Gegenzug wiederum zu weniger verfügbaren Programmen und Lösungen für sie selbst führt.
Es gibt noch so viel mit meinen Projekten für mich zu tun, daß ich noch nicht einmal die Zeit habe, darüber nachzudenken, was für Probleme ich in einigen Jahren mit meiner bevorzugten Plattform haben könnte. Sicherlich, auch ich ärgere mich von Zeit zu Zeit darüber, zuwenig Rückmeldungen zu bekommen, was es schwierig macht, die Motivation auch für Langzeitprojekte aufrecht zu erhalten.
Ich kann Ihnen nicht sagen, wo ich in fünf Jahren stehe und für welche Plattform ich dann in meiner Freizeit programmiere. Wenn es kein OS/2 oder eComStation mehr geben sollte, bin ich vielleicht einer der ersten, die bei etwas ähnlichem wie die Workplace Shell für Linux mitprogrammiert, wenn ich nur irgendwie mit all den Dingen klarkomme, die ich an Linux nicht mag... Bis dahin werde ich weiterhin mehr von meinen Programmen und Utilities für OS/2 und eComStation veröffentlichen, netlabs.org durch das Aufsetzen weiterer OS/2- und eComStation-bezogenen Projekte unterstützen und mit dem Projekt Internet-Assistent fortfahren, und hoffentlich, mit der Hilfe von vielen Endanwendern, daraus ein genügend stabiles Programm machen können.
Abgesehen davon ist mein Spaß am Programmieren mit OS/2 ~Co. nicht vorbei, ganz im Gegenteil. Ich habe erst in letzter Zeit das Workplace Shell Toolkit veröffentlicht, das dabei helfen soll, auf viel einfachere Art Erweiterungen für die Workplace Shell zu erstellen. Hoffentlich wird es von anderen Projekten verwendet, um z.B. Konfigurationsobjekte anzubieten, die perfekt in die Workplace Shell passen und nebenbei die elegante Konfiguration per Einstellungsbefehle (settings strings) ermöglichen, und das ohne zusätzlichen Programmieraufwand.
Darüber hinaus ist dieses Toolkit sehr ausführlich dokumentiert, so als wäre es Teil des Developers Toolkit for OS/2 - eine detaillierte Online-Hilfe zusammen mit Beispielprogrammen, die fast jedes API des Toolkits abdecken, sind wichtiger Bestandteil davon. Ich hoffe sehr, daß der ein oder andere OS/2- bzw. eComStation-Anwender und Möchtegern-Programmierer oder fertige Programmierer mal darüber nachdenkt, ob er mit dieser Hilfe nicht für eine der besten Programmierschnittstellen programmieren möchte, die für eine Benutzeroberfläche zu haben ist - ich bin dabei, sie alle zu unterstützen.
Was also bleibt von meinem früheren Enthusiasmus für die Programmierschnittstellen von OS/2? Die Konzepte zum Programmieren unter OS/2 sind immer noch da, auch wenn einige davon eher Geschichte sind. Programmierer für OS/2 und eComStation können weiterhin Erweiterungen für die Workplace Shell erstellen, und wie bereits gesagt, sehe ich immer noch kein Ende dafür ab, im Gegenteil sind noch viele Anwendungen möglich, genauso wie die echte Workplace-Shell-Integration von konventionellen GUI-Programmen.
Wenn es Programmierern dennoch zu langweilig wird, laßt uns Ideen von der Linux-Seite aufgreifen. Da gibt es unzählige verwendbare Dinge, die sinnvollerweise nach OS/2 portiert werden könnten, und das os2tounix-Projekt unterstützt dieses Ziel sehr gut. Für die Programmierer, die ein größeres Publikum bevorzugen, sind mittlerweile recht brauchbare Cross-Plattform-GUI-Bibliotheken wie "Dynamic Windows" oder "wxWindows" vielleicht eine Lösung, um den Anwenderkreis für ihre Programme zu verbreitern. Überhaupt sind Cross-Plattform-Projekte eine technisch sehr interessante Herausforderung und dazu geeignet, den Horizont des Programmierens sehr zu erweitern.
Ich bin wirklich besorgt über das Problem der verfügbaren Kompiler unter OS/2 und eComStation. Die zwei verbliebenen Kompiler, die noch weiter entwickelt werden, müssen brauchbar bleiben, und hoffentlich werden sie auch weiterhin mit allen Anforderungen fertig werden, die auch große OS/2-Projekte heutzutage an sie stellen können. Eine positive Nachricht zu diesem Punkt ist, daß derzeit zumindest der GNU-Kompiler weiterentwickelt wird, Entwickler von Innotek arbeiten an einer GCC-Distribution, der die neuesten C++-Standards unterstützt.
Ich bin außerdem besorgt über die Entwicklergemeinde, die bekannte Programmierer an andere Plattformen verliert (damit meine ich übrigens nicht mich). Diese haben die Nase voll davon, zu programmieren und keine Rückmeldung zu erhalten, und nicht zu wissen, ob irgendjemand ihre Programme überhaupt benutzt. Um mit den Worten eines berühmten Mannes zu sprechen: "Fragt nicht (nur) euer Betriebssystem, was es für Euch tun kann...". Auch wenn wir für unser bevorzugtes Betriebssystem insgesamt mehr ausgeben müssen als für andere, kann es dennoch sein, daß es nicht ausreicht, nur das Betriebssystem und weitere Software zu kaufen, denn es ist gut möglich, daß wir dann von denjenigen welche verlieren, die mit der Programmierung für OS/2 und eComStation kein Geld verdienen. Und wie ich das sehe, können wir nicht auf sie verzichten.
Daten und Quellen:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org