© Bidouze Stéphane, 123RF

Vom ehemaligen Besitzer allein gelassen, vom eigenen Vater adoptiert und mit dem Symbol eines Affen versehen: Mono durchlebt stürmische Zeiten. Wozu das Dotnet für Linux in der Lage ist, beweist eindrucksvoll ein deutscher Datenbankhersteller. In Zukunft wird Mono wohl verstärkt in Jackentaschen verschwinden.

Im Mai 2011 schockte eine Meldung die Entwicklergemeinde: Attachmate kaufte nicht nur Novell, sondern stellte auch die Entwicklung von Mono ein. Das komplette Programmiererteam, einschließlich des Mono-Vaters und Gnome-Gründers Miguel de Icaza, musste gehen. Angeblich war die Nachfrage bei den Kunden zu gering, das Mono-Projekt somit letztendlich nicht profitabel (siehe Kasten “Was ist Mono?”, [1]).

Nicht das Ende

Kurze Zeit sah es sogar danach aus, als wäre dies das Ende der ebenso geliebten wie gehassten Entwicklungsplattform. Der folgende Artikel unternimmt eine Bestandsaufnahme und sortiert die Fakten. Das Linux-Magazin hat dafür mit Mono-Entwicklern und Protagonisten wie Miguel de Icaza (siehe Interview im Kasten “Es bricht mir das Herz”) gesprochen. Zwei weitere Interviews – mit F-Spot-Programmierer Timothy Howard und Daniel Kirstenpfad vom Datenbank-Entwickler Sones – stehen im Online-Plus-Bereich des Linux-Magazins in voller Länge zur Verfügung.

“Es bricht mir das Herz”

Miguel de Icaza hat das Gnome-Projekt gegründet und führt heute die Firma Xamarin und das Mono-Projekt an.

Im Interview am Rande von Microsofts Build-Konferenz 2011 erzählt er, warum er sein iPad liebt und was Xamarin und das Mono-Projekt bewegt.

Linux-Magazin: Warum haben Sie mit Xamarin ein Unternehmen gegründet und keine nicht-kommerzielle Mono-Stiftung?

Icaza: Ich selbst habe nur leider nicht die Zeit für beides. Und ein Not-for-Profit-Unternehmen kann schwerlich die Gehälter für unsere 35 hochqualifizierten Entwickler aufbringen. Aber ich helfe gerne in einer Foundation mit, ich wäre sicher auch ein gutes Mitglied im Board.

Linux-Magazin: Warum hat Xamarin gegenüber Kunden schon öfter Nein sagen müssen? Weil die Manpower nicht reichte?

Icaza: Wir wollen in erster Linie Produkte entwickeln und verkaufen. Bei Novell war das genauso. Bei der Gründung von Xamarin erkannten wir aber den Bedarf. Trotzdem steht der Support nicht im Mittelpunkt unseres Interesses. Ein Start-up ohne viel Kapital kann sich das aber nicht immer aussuchen, und deshalb entstand wohl oft der falsche Eindruck. Aber wir wollen definitiv ein Produkt entwickeln und vermarkten, nicht Support und Consulting.

Klar verraten wir hier den Open-Source-Ansatz, das ist traurig. Aber das Schöne an Mono Touch und Droid bleibt: Es bezahlt unsere Rechnungen.

“Himmlische Verknüpfung”: Mono und iPad

Linux-Magazin: Warum setzt Xamarin auf mobile Plattformen? Ist Dotnet nicht eng mit dem Desktop verbandelt?

Icaza:Nein. Dotnet ist ein Runtime-Environment mit einer großen Anzahl an Bibliotheken. Manche davon sind für Desktops, manche für Server, andere für exotische Sachen, zum Beispiel für Xbox-Spiele. Auf jeden Fall ist es universell für Microsoft. Wir glauben an Dotnet, wir lieben es sogar, aber wir lieben auch unsere Plattform, den Linux-Server, iPhones, iPads und Android. Und Dotnet auf dem iPad, das halten wir eben für eine wahrhaft himmlische Verknüpfung, ebenso Dotnet auf Linux. Das schließt ja Perl oder Python nicht aus, im Gegenteil, da ist Platz für alle Sprachen. Allerdings muss man konstatieren, dass Low-Level-Sprachen eben fehleranfälliger sind als zum Beispiel Dotnet.

Der mobile Markt ist natürlich auch sehr interessant, weil Dotnet eine gute Performance bei hohem Programmierkomfort bieten kann. Deshalb konzentrieren wir bei Xamarin uns auf Dotnet für Nicht-Microsoft-Plattformen. Mit Mono Touch und Mono Droid lässt sich gutes Geld verdienen. Das ist zwar schade, weil der Open-Source-Ansatz verloren geht, aber es hilft, die Rechnungen zu bezahlen. Wir sind knapp 40 Leute und wir konzentrieren uns auf Mobiles. Aber wir arbeiten auch an allgemeinen Sachen, sowohl Server als auch Linux.

Mono immer mehr im Backend

Linux-Magazin: Wenn man sich die Statistiken von Sones anschaut (Abbildung 2), dann scheint Mono ja auch im Backend sehr erfolgreich zu sein. Die Graph DB läuft mit dem neuen Garbage Collector auf Mono schneller als auf Dotnet, wo sie ursprünglich entwickelt wurde.

Icaza: Ehrlich? Das wusste ich gar nicht, das ist ja ein sehr schöner Erfolg. Tja, Mono haben wir ursprünglich für den Desktop entwickelt, für den Linux-Desktop, um genau zu sein. Leider ist aber die Bedeutung des Linux-Desktops stark zurückgegangen. Das ist sehr, sehr traurig, es bricht mir das Herz. Ich bin immer ein Linux-Typ gewesen – ich habe Gnome gestartet! – und schauen Sie sich an, womit ich jetzt herumrenne. [Er zeigt auf sein iPad, Abbildung 3.]

Abbildung 3: Der Gnome-Gründer und Mono-Vordenker Miguel de Icaza glaubt nicht mehr an die Zukunft des Linux-Desktops.

Und genauso ironisch ist doch, dass – bei all dem, was Microsoft so getrieben hat in den letzten Jahrzehnten – am Ende Java vor Gericht gelandet ist. Ausgerechnet Java! Aber ich bin weg davon, jetzt machen wir mobile Applikationen. Und am Wochenende, in meiner freien Zeit, da arbeite ich an Mono für den Mac. Ich mag das, was Steve Jobs macht, das gefällt mir sehr.

Linux-Magazin: Microsoft hat hier auf der Build-Konferenz vor wenigen Stunden mit dem Windows-RT-API und der Metro-Oberfläche für Windows 8 weitreichende Neuheiten vorgestellt. Haben die auch Konsequenzen für Mono?

Icaza: Nein, das glaube ich nicht. Windows RT betrifft eher Anwendungsprogrammierer für Windows, das hat wohl keine Folgen für Mono. Noch vor drei oder vier Jahren hätte ich gesagt: Cool, lasst uns ein RT4Linux-Projekt starten, damit RT-Applikationen auch auf Linux laufen. Windows RT ist eine fantastische Technologie, eine tolle Zwischenschicht für C# und Javascript, aber eben nur für Windows. Sie ist auch nicht so fortschrittlich wie etwa das Cocoa-Framework von Apple. Das macht sie auf dem Mac überflüssig, und deshalb macht ein RT für andere Plattformen wenig Sinn.

Vom Fehler, das perfekte System zu wollen

Heute schaut die Lage für den Linux-Desktop eben schlechter aus: Open Source hat zwar viele Vorteile, aber auch einige Nachteile. Es ist ein Fehler, das perfekte System bauen zu wollen. Es ist ein Fehler, APIs so oft zu ändern, weil man glaubt, durch die Verfügbarkeit des Sourcecode die Anwendungen schnell nachziehen zu können. Aber wenn man wie bei Linux alle sechs Monate APIs ändert, bleiben irgendwann nur sehr wenige Anwendungen übrig.

Ich rede nicht von Inkompatibilitäten, sondern davon, dass Subsysteme wie Sound, Grafik oder Printer überarbeitet und erneuert werden. Das macht es Herstellern sehr schwer, Anwendungen herauszubringen, die funktionieren. Ich habe zu Hause ein Suse-11.2-System laufen, mit dem ich sehr zufrieden bin. Aber versuchen Sie mal, dafür einen aktuellen Chrome zu bekommen – und die 11.2 ist gerade mal anderthalb Jahre alt!

Linux-Magazin: Hat der Linux-Desktop Ihrer Meinung nach keine Zukunft?

Icaza: Linux hat heute keine vertrauenswürdige Plattform. Nein, ich glaube nicht mehr daran, dass Linux auf dem Desktop Perspektiven hat. Nicht weil es das grundsätzlich nicht könnte, sondern weil die Community Standards allzu schnell über den Haufen wirft und neu designt. Wir müssen es erst noch lernen, dass es okay ist, proprietäre Software zu integrieren, und dass es nicht in Ordnung ist, die APIs zu ändern und damit Geschäftsmodelle zu zerstören.

“Für den Linux-Desktop kämpfen lohnt nicht”

Es gibt ja auch solche Anstrengungen: Vor vielen Jahren gab es mal die Linux Standard Base, wo sich alle Distributoren zusammengesetzt haben und Linux standardisiert haben. Damals war Red Hat vorne, hatte deshalb kein Interesse an Standardisierung und hat nicht mitgemacht. Jetzt hat Ubuntu die Nase vorn und sagt das Gleiche: “Wir dürfen uns nicht von Standards gängeln lassen.”

Ich habe viele Jahre für den Linux-Desktop aufgebracht, aber ich glaube, er ist es nicht mehr wert, dafür zu kämpfen. Ich will aber auch niemanden davon abhalten. (Markus Feilner)

Mono: Der Neustart

Miguel De Icaza gründete nach seiner Suse-Karriere zusammen mit Nat Friedman im Mai 2011 das Unternehmen Xamarin ([2], nicht zu verwechseln mit ihrer alten Firma Ximian). Den beiden folgten weitere ehemalige Mono-Entwickler. Dummerweise verblieben die Rechte an den Mono-Produkten bei Attachmate beziehungsweise Suse. Das betraf insbesondere die profitablen Mono-Portierungen auf Android und iPhone.

Also begann Xamarin zunächst mit der Entwicklung eigener mobiler Mono-Varianten. Mitte Juli überließ Suse jedoch überraschend dem kleinen Start-up eine unbegrenzte und umfassende Lizenz an Mono, Mono Touch, Mono for Android (Mono Droid) und den Mono-Tools für Visual Studio [3].

Gleichzeitig übernahm Xamarin alle Supportverträge der ehemaligen Novell-Mono-Kunden sowie die Federführung beim Mono-Community-Projekt. Dieses Projekt entwickelt die quelloffene Desktop-Variante von Mono nebst C#-Compiler weiter. Auf der Mono-Homepage [1] war zum Redaktionsschluss aber noch Novell als Projektsponsor, Ansprechpartner und Anbieter von kommerziellem Support genannt, auch die entsprechenden Seiten bei Suse existierten weiterhin.

ECMA-Standards

Die Mono-Entwickler orientieren sich an den ECMA-Standards für die C#-Programmiersprache [4] und der so genannten Common Language Infrastructure, also der Laufzeitumgebung mit einigen Basisbibliotheken [5]. Dort sind allerdings nicht alle Teile von Microsofts Dotnet normiert. Damit dennoch möglichst viele Dotnet-Programme unter Mono laufen, versuchen die Mono-Entwickler zumindest die wichtigsten Microsoft-Bibliotheken nachzubauen.

Mangels helfender Hände hecheln sie dabei jedoch Microsoft ständig hinterher. So implementiert die aktuelle Version 2.10 von Mono gerade mal die Basisbibliotheken der Dotnet-2.0-Spezifikation vollständig. Von den Nachfolgern 3.0, 3.5 und 4.0 sind nur Teile umgesetzt. Der Kasten “Bestandsaufnahme” verrät, welche Klassen Mono derzeit kennt und welche nicht.

Um die Lücken zu kompensieren, bringt Mono eigene Klassenbibliotheken mit. Diese binden die Gecko-Engine des Mozilla-Browsers ein, rüsten Posix-Unterstützung für Unix-Betriebssysteme nach und liefern Zugriff auf Datenbanken, wie Db4o, Firebird, MySQL, PostgreSQL oder SQLite. Damit stehen aber wieder nicht alle Klassenbibliotheken aus Mono unter Dotnet bereit. Wer also ein Dotnet-Programm für mehrere Plattformen schreiben möchte, muss sich auf den kleinsten gemeinsamen Nenner beschränken.

Android, I-OS und der Problemfall Grafik

Ähnliches gilt, wenn man die Welt von Android und I-OS betritt: Die Mono-Fassungen für die mobilen Geräte umfassen lediglich die Kern-Libraries sowie Klassenbibliotheken, über die man die nativen APIs der Geräte anspricht. Wer sich auf Android beschränkt, muss immerhin die Anwendung nur einmal entwickeln, damit sie auf allen Android-Geräten läuft.

Mono Touch für das iPhone übersetzt übrigens den Quellcode in nativen iPhone-Programmcode, da Apple dazwischengeschaltete (JIT-)Interpreter und virtuelle Maschinen verbietet.

Ein weiteres Problem bilden grafische Benutzeroberflächen. Hier ist besonders spürbar, dass unter Mono die Windows Presentation Foundations (WPF) fehlen. Zwar sollen diese – neuesten Meldungen von Microsoft zufolge – ab Windows 8 wegfallen, doch mit den in WPF enthaltenen Klassen entstehen heutzutage die Benutzeroberflächen von Dotnet-Programmen. Unter Mono muss der Entwickler auf die alten, eigentlich durch die WPF abgelösten Windows Forms oder eben GTK# zurückgreifen.

Wie der Name andeutet, bindet GTK# die guten alten GTK+-Bibliotheken ein. Der F-Spot-Programmierer Timothy Howard bestätigt, dass die Bibliotheken zwar mittlerweile stabil unter Windows laufen, sie sehen aber nach Meinung vieler Nutzer hässlich und veraltet aus.

Eine gewöhnungsbedürftige Optik zeigt allerdings auch der Windows-Forms-Ersatz auf Nicht-Windows-Rechnern. Neben den Forms und GTK# gibt es weitere GUI-Toolkits, die die Mono-Entwickler auf ihren Projektseiten detailliert gegenübergestellt haben [9].

F-Spot: Plattformabhängige Bildbearbeitung mit Mono

Mehr Probleme bekam Timothy Howard, als er die Bildbearbeitung F-Spot [10] auf Windows portieren wollte. F-Spot selbst ist komplett in C# und Mono geschrieben. Für die Benutzeroberfläche setzt es auf GTK# – primär, um sich besser in den Gnome-Desktop zu integrieren.

F-Spot war jedoch nie auf Plattformunabhängigkeit ausgelegt. Seine Entwickler hatten deshalb nicht nur einfach hemmungslos drauflosprogrammiert, sondern auch so genannten “unmanaged Code” verwendet, also externe Linux-Bibliotheken und Programme eingebunden. Davon betroffen waren unter anderem das Farbmanagement und der Import von Fotos aus der Kamera, dies geschah beispielsweise mit Gphoto.

Timothy Howard kommentierte deshalb erst einmal die meisten dieser Funktionen aus und konzentrierte sich zunächst ganz auf die Benutzeroberfläche [11]. Die ließ sich mit GTK# nach einigen Anfangsschwierigkeiten mit Signal-Handlern und GTK Builder ziemlich reibungslos portieren. Auch die unterschiedlich aufgebauten Verzeichnisnamen und Trennzeichen (»\« statt des Schrägstrichs) waren recht schnell korrigiert. “Nachdem ich das GTK-Builder-Problem gelöst hatte, fand ich es erstaunlich einfach, F-Spot zum Laufen zu bekommen, die SQLite-Datenbank zu lesen und Fotos anzuzeigen”, so Timothy Howard.

Sehr viel weiter kam er jedoch noch nicht – vor allem weil F-Spot seinen Angaben zufolge selbst auf Eis liegt. Die Gründe dafür sind jedoch weniger bei Mono zu suchen als bei fehlenden Entwicklern. Ob es noch einmal weitergeht, ist ungewiss. Distributionen wie Fedora und Ubuntu haben die Bildbearbeitung schon vor einigen Ausgaben aus der Standardinstallation verbannt.

Auch hier gaben wieder die Funktionen den Ausschlag, nicht Mono selbst. Im Gegenteil: Die meisten Linux-Distributionen mit Gnome-Desktop installieren Mono nach wie vor standardmäßig.

Spot aus?

Gegenüber dem Linux-Magazin resümiert Timothy Howard: “So wie ich das anhand des Windows-Ports beurteilen kann, ist F-Spots größtes Problem, dass es von den aktuellen Mono-Standards überholt wurde. Die Entwicklung begann 2005 nahezu gleichzeitig mit der Entstehung von Mono (auch wenn Mono 1.0 im Juni 2004 erschien).” Sein Blick zurück? “Viele Dinge wurden damals getan, die ich heute sicher anders machen würde, insbesondere dann, wenn man die Entwicklung einer Crossplattform-Fotoverwaltung im Auge behält.”

Wie einfach sich mit Mono portable Programme schreiben lassen, beweist die in Leipzig ansässige Sones GmbH mit ihrer Graphdatenbank Graph DB [12].

Mono im Datenbank-Backend: Sones Graph DB

Im Gegensatz zu MySQL & Co. speichert Graph DB keine Tabellen, sondern komplexe Graphen (Abbildung 1). Die bestehen wiederum aus Knoten (den Informationsträgern) und Kanten (den Beziehungen zwischen den Informationen). Ein Graph repräsentiert so je nach Anwendungsgebiet eine Straßenkarte, eine Netzwerktopologie oder die Beziehungen zwischen Mitarbeitern in einer Firma.

Abbildung 1: Ein kleines Beispiel für einen Graphen: Hier zeigt er die Beziehungen zwischen verschiedenen Personen.

Bei solchen Daten liefert die spezialisierte Graph DB zusammen mit der eigenen Abfragesprache GQL wesentlich schneller ein Abfrage-Ergebnis als herkömmliche relationale Datenbanken. Es entfallen insbesondere die zeitfressenden Joins und Lookups.

Graph DB ist vollständig in C# geschrieben und ließ sich 2010 mit Mono auf Linux und Mac OS X portieren. “Das lief erstaunlich gut: Schon nach wenigen Stunden kompilierte alles, nach einigen Tagen lief die Datenbank unter Mono”, erläutert Daniel Kirstenpfad, CTO von Sones. Probleme konnten die Entwickler schnell zusammen mit den Mono-Machern klären: “Wir konnten bei Fragen und Anregungen schnell den eigentlichen Autor kontaktieren und haben immer zügig Feedback erhalten. Mit der Gründung von Xamarin haben sich aus unserer Sicht Austausch und Unterstützung noch einmal verbessert.”

Die derzeit rund um Graph DB entstehenden Hilfswerkzeuge sind allerdings im Moment nur unter Windows verfügbar. Das noch nicht freigegebene Graph-DB-Visualization-Tool, das die gespeicherten Graphen übersichtlich auf den Bildschirm zeichnet, nutzt bislang die WPF [13].

Entwickelt in Dotnet, aber schneller dank Mono

Der bereits erhältliche Sones Assembly Merger verwendet hingegen die Windows Forms, wäre somit prinzipiell auch auf Mono portierbar [14]. Offiziell gibt es aber nur eine Windows-Version, der Quellcode liegt jedoch offen [15]. In Zukunft will Sones Benutzeroberflächen mit plattformunabhängigen Webtechniken programmieren, namentlich mit HTML 5 und Javascript.

Mit Version 2.8 erhielt Mono einen neuen Garbage Collector, also die integrierte automatische Speicherverwaltung. Die sorgt in vielen Fällen für einen solchen Geschwindigkeitsschub, dass Graph DB unter Mono heute schneller läuft als unter Microsofts Dotnet (Abbildung 2). Genaue Zahlen liefert das Sones-Entwickler-Blog auf der Webseite der Firma.

Abbildung 2: Wie Sones Messungen belegen, liefert die Graph DB Anfragen unter aktuellen Mono-Versionen wesentlich schneller aus als unter Dotnet.

Community Edition, Dotnet 4.0 und mobile Plattformen

Die Community Edition von Graph DB steht übrigens unter der AGPL 3 (Affero General Public License), die zugehörigen Client-Bibliotheken zum Anbinden eigener Programme unter der LGPL. Zusätzlich gibt es eine kommerzielle Enterprise-Variante mit erweiterten Funktionen. So merkt sich die freie Version beispielsweise Graphen nur im RAM.

Die Mono-Entwickler werkeln derzeit fleißig an einer Unterstützung für Dotnet 4.0. Außen vor bleibt dabei auch künftig die Windows Presentation Foundation. Als Grund nennt Miguel de Icaza in seinem Blog den schlichtweg zu hohen Arbeitsaufwand. Immerhin soll es demnächst eine Unterstützung für die Beschreibungssprache XAML geben, und die wird laut Microsoft auch weiterhin ein wichtiges Standbein für Windows-Entwickler sein.

Xamarin legt den Fokus auf die mobilen Plattformen und macht damit wohl rege Gewinne [16]. Nach Icazas Angaben schlummern in den App-Stores mittlerweile über 2000 mit Mono geschriebene Anwendungen. Deren Entwickler mussten brav eine Mono-Lizenz erwerben, die zudem nicht ganz billig ist: Fast 400 Euro pro Jahr muss ein Android-Developer in der einfachsten Variante hinblättern. Darüber hinaus wächst der Markt mit Smartphones und Tablets, der traditionelle Desktop ist rückläufig. Laut Icaza hat Mono auf dem iPhone und Android mehr Entwickler, als jemals zuvor auf dem Desktop.

Richard Doll, der CEO von Sones, betrachtet dies auch für den Desktop als vorteilhaft: “Durch die Verschiedenheit und die Beschränkungen der Anbieter hat sich hier ein glasklarer Anwendungsfall für die Portierbarkeit von Mono-Code-Development ergeben. Das kann nur gut sein für die Bekanntheit und das Wachsen von Mono. Für viele Entwickler einer populären Plattform heißt das, dass sich für das Mono-Projekt die kommerziellen Chancen erhöhen. Das sichert die Zukunft.”

Die Referenzliste auf den Seiten des Mono-Projekts [17] scheint dies auf den ersten Blick zu unterstreichen: Erstaunlich viele Firmen setzen auf Mono, darunter auch Größen wie Electronic Arts, die Wikipedia oder die 3-D-Spiele-Engine Unity. Doch bei genauer Betrachtung kommt Mono oft nur in kleineren Teilaufgaben zum Einsatz. Für Dotnet gibt es dagegen Unmengen an Anwendungen.

Perspektiven, Gegner und Zukunft

Xamarin und Mono arbeiten immer gegen die riesigen Teams von Microsoft und die starke Verzahnung von Dotnet mit Windows an. Dass die Redmonder jüngst einige Dotnet-Komponenten geöffnet haben, hat auch die Weiterentwicklung von Mono beschleunigt.

Allerdings sind nach wie vor einige Teile der auch von Mono angebotenen Klassenbibliotheken möglicherweise mit Patenten von Microsoft belastet, was Verfechter freier Software unermüdlich kritisieren, auch wenn Microsoft immerhin angekündigt hat, bei Dotnet auf Patentklagen zu verzichten. Die Teile des ECMA-Standards unterstehen zudem dem Microsoft Community Promise, einer Art Nichtangriffspakt [18].

Im Frühling überraschte Sones mit der Meldung, gemeinsam mit Xamarin eine Stiftung für Mono gründen zu wollen, allerdings noch bevor Suse ihre Mono-Lizenzen an Xamarin übertrug und Icazas Firma die Führung im Mono-Projekt übernahm [19].

Die Zukunft von Mono sehen die Entwicklern bei den mobilen Plattformen. Xamarin entwickelt zwar Mono weiter, konzentriert sich dabei aber auf den ECMA-Standard und wird nicht bedingungslos Microsofts Dotnet hinterherhecheln. Sones Graph DB zeigt, wozu Mono heute in der Lage ist – und F-Spot, wo mögliche Probleme warten. Die entstehen vor allem dann, wenn man grafische Oberflächen benötigt, auf native Bibliotheken zurückgreift und nicht auf portierbaren Programmcode achtet.

Empfehlenswerter Einstieg: Ein Build- und Testsystem

Wer plattformübergreifende Anwendungen mit Mono schreiben möchte, dem rät Daniel Kirstenpfad von Sones “ein entsprechendes Build- und Testsystem schon zu Beginn der Entwicklung aufzusetzen. Dieses kann dann automatisiert unter Mono und Dotnet auf verschiedenen Plattformen den aktuellen Stand der Entwicklung durchtesten”. Einsteiger in Mono und Dotnet sollten zudem “kleine Schritte gehen. So gewinnt man Vertrauen und Sicherheit zur Technologie. Die Community zu fragen und selbst zu helfen ist immer eine gute Idee”.

Timothy Howard empfiehlt, sich erfolgreiche und portable Anwendungen anzusehen. “Eine Crossplattform-Anwendung mit Mono zu erstellen ist mittlerweile eine triviale Aufgabe, verglichen mit der Situation vor ein paar Jahren”, so der ehemalige F-Spot-Programmierer.

Icaza: Trennt die Logik von der Darstellungsebene!

Miguel de Icaza ist erst einmal wichtig, dass “die Leute die Sprache aussuchen, die ihnen am meisten liegt. Mir ist Java ein wenig zu statisch. Viele moderne Ansätze anderer Sprachen gibt es dort einfach nicht, aber wenn einem Programmierer Java, Perl, PHP oder C# besser gefällt als Mono, soll er das verwenden. Da habe ich volles Verständnis dafür.” Was immer die Probleme löse, sei ideal, so Icaza. Aber das Core-Set von Mono-APIs sei universell und robust, was sich eben vor allem bei der Datenbankanbindung zeige.

Für die Darstellung entstünden immer mehr APIs, vom Web über iPhone, Mac, Android bis zum neuen Windows RT. Wichtig ist auf jeden Fall: “Ich rate jedem Entwickler, Business Engine und Applikationslogik von Darstellungsschicht zu trennen. Im Frontend bedarf es verschiedener Apps für unterschiedliche Geräte und Eingabeformen. Also ist es besser, den Code so zu strukturieren, dass Programmierer nur noch die jeweilige App erstellen und polieren müssen.”