Tag Archives: OpenSource

Kalendertool gesucht

Ich vermisse es mal wieder: Mein Wunschkalendertool.

Folgende Eigenschaften soll es haben:

  • Frontend im Stil vom Google-Kalender. Erreichbar über jeden Browser.
  • Verfügbare Software, die ich auf meinem eigenen Server installieren kann und die mir alleinige Kontrolle über meine Daten gibt.
  • Das Backend kann Kalenderdaten in IMAP-Foldern verwalten. Das ist meine derzeitige Speicherform, die den Vorteil hat, dass ich kein zusätzliches LDAP- oder DAV-System installieren muss, sondern einfach mein E-Mail-Postfach verwenden kann.
  • Kostenlos und OpenSource.
  • Optional: Eine schicke API, mit der ich ggf. auch andere Tools wie z.B. einen Reminder anbinden kann. Das muss aber nicht sein, weil die Daten ja auch schon im IMAP-Folder gut lesbar vorliegen.

Sachdienliche Hinweise bitte in die Kommentare oder per Nachricht an mich.

Penguineering

Penguineering ist ein Kunstwort, das aus penguin und engineering zusammengesetzt ist. Die Idee stammt von einer Freundin, die mir dieses Wort freundlicherweise überlassen hat, sodass ich mir gleich mal die Domain penguineering.com reservieren konnte.

Seit gestern Abend ist unter http://tools.penguineering.com eine Sammlung von Tools zu finden, die in einzelner oder gemeinsamer Arbeit der Blog-Autoren entstanden sind und allgemein verfügbar sein sollen.

Die Seite sieht noch etwas mager aus, aber das wird sich im Lauf der Zeit ändern.

LIRC für eisfair – eine Episode voller Rückschläge

Wie man auf Pack-Eis sehen kann, betreue ich das Paket »LIRC« für Eisfair. Wie bei climm und GnuPG bin ich 2005 aus persönlicher Notwendigkeit heraus in diese Rolle gerutscht. Mein Heimserver war damals für das Abspielen meiner Musik verantwortlich und eine Infrarotfernbedienung ist da Gold wert. Wie so oft im OpenSource-Bereich brachte ich das Paket auf einen Stand, der meinen Anforderungen genügte und beließ es bei einer längeren Liste mit Ideen und ToDos, die im Prinzip seit 2005 auf ihre Umsetzung warten – andere Dinge waren halt wichtiger.

Nun wurde kürzlich ein neues Kernel-Paket für eisfair-1 veröffentlicht: ein gepatchter 2.4.35. Wir haben im Testteam lange getestet bis er im März der Öffentlichkeit zum Fraß vorgeworfen wurde. Ein neuer Kernel bedeutet aber auch, dass LIRC neu übersetzt werden muss, da es seine Treiber selbst mitbringt und Kernelmodule nunmal zur Kernelversion passen müssen. Es gab auch schon die eine oder andere Anfrage in der Newsgroup und ich beschäftige mich seit ein paar Tagen mit einer neuen Version des Pakets.

Zunächst steht das Kompilieren an. Ich konnte LIRC 0.8.2 für die eisfair-Kernel 2.4.26-1 und 2.4.35-wt1 jeweils in den Versionen mit und ohne Unterstützung für SMP übersetzen – für 2.4.26 mit der alten Build-Umgebung mit gcc 2.95.3 und für den 2.4.35 mit der zukünftigen Build-Umgebung mit gcc 3.4.6, die zur Zeit vom Testteam getestet wird. Das Übersetzen von LIRC artet schnell in Arbeit aus, weil es mit einem Lauf aus ./configure, make und make install nicht getan ist. Das muss für jede Kernel-Version und jeden gewünschten Treiber einzeln gemacht werden, es sei denn, man kompiliert gleich alle Treiber. Tut man dies nicht, ist noch mindestens ein Lauf mit der Option --with-driver=userspace nötig, damit LIRC auch in der Lage ist mit verschiedenen Treibern gestartet zu werden und nicht nur mit dem, für den es kompiliert wurden, wie z.B. serial.

Also wie gesagt, ich konnte LIRC für die Treiber serial und atiusb kompilieren – das sind die beiden, wo ich selbst Hardware zum Testen habe. Dank VMware waren auch die verschiedenen Kernel kein Problem, ich hab einfach für jeden eine neue virtuelle Maschine angelegt. Die anfängliche Euphorie, dass auch ein LIRC 0.7.1 mit den aus 0.8.2 gebauten Kernelmodulen für 2.4.35 läuft, wich dann der ersten Enttäuschung. Ich hatte zunächst die Version, die mit allen Treibern laufen soll, mit --with-driver=none kompiliert. Das funktionierte logischerweise nicht. Der erste herbe Rückschlag: LIRC 0.8.1, 0.8.2 und 0.8.3pre1 lassen sich mit der neuen eisfair-Buildumgebung und der korrekten Option --with-driver=userspace nicht übersetzen, wie man auf der Mailingliste von LIRC nachlesen kann.

Man kann dort ebenfalls nachlesen, dass ich versucht habe, die neueste Version aus dem CVS zu übersetzen, wo dieser Fehler bereits behoben ist. Leider macht mir da die Buildumgebung einen Strich durch die Rechnung. Das Skript ./configure liegt nicht im CVS, sondern wird mit den autotools (autoconf, automake usw.) erst noch selbst erzeugt. In der Theorie funktioniert das gut, in der Praxis tritt bei mir leider der gleiche Fehler auf, den ich vor einiger Zeit schon hatte, als ich climm aus dem SVN bauen wollte. Es wird ein unbrauchbares Skript erzeugt, dass nur eine wenig hilfreiche Meldung ausgibt. Wenn sich jemand gut mit autoconf auskennt und eine Idee hat, wo da das Problem liegt, möge sie sich dringend bei mir melden! Fazit jedenfalls: LIRC aus CVS ist für mich nicht möglich.

Heute erreichte mich dann über die Mailingsliste von LIRC die überraschende Nachricht, dass gerade die 0.8.3pre2 rausgegeben wurde. Der o.g. Fehler tritt nicht mehr auf, dafür ein neuer. LIRC lässt sich nicht mehr mit dem Treiber serial übersetzen, weil in der entsprechenden Quellcode-Datei eine Header-Datei aus den Kernelquellen nicht gefunden wird. Zumindest wird sie bei den 2.4er Kerneln nicht gefunden. Ein flüchtiger Blick in den Quellbaum eines 2.6er Kernels offenbarte, dass es dort zwei Dateien io.h gibt, eine in /usr/src/linux/include/linux und eine in /usr/src/linux/include/asm – beim 2.4er Kernel gibt es bloß letztere.

Auch dies habe ich auf der Mailingliste von LIRC gemeldet und warte erstmal ab. Es gibt nämlich mehrere Möglichkeiten jetzt:

  • ich warte ab, bis die nächste LIRC-Version veröffentlicht wird, mit der ich alles korrekt übersetzen kann
  • ich baue das allgemeine LIRC und die Treiber für atiusb aus der 0.8.3pre2 und die Treiber für serial aus der 0.8.2
  • ich kann durch wundersame Eingebung oder Hilfe von außen den Fehler in der Buildumgebung finden, so es denn tatsächlich einer in dieser ist, und die aktuelle Version aus dem CVS übersetzen
  • ich gehe in den Versionen soweit zurück, bis ich auf eine stoße, die ich komplett übersetzen kann, das wäre dann wahrscheinlich die 0.8.0
  • ich behebe den Fehler in 0.8.3pre2 selbst und übersetze dann meine modifizierte Version

Ehrlich gesagt, gefällt mir die erste Version bisher am besten, allerdings könnte das unter Umständen noch eine Weile dauern, je nachdem wie schnell die Entwickler von LIRC die nächste Version rausbringen. Module aus verschiedenen Versionen wollte ich eigentlich vermeiden, um mir nicht eine zusätzliche Fehlerquelle aufzureißen. Auch eine alte Version finde ich nicht so cool. Ob wir den potentiellen Fehler in der Buildumgebung schnell finden, ist auch ungewiss, bleibt also im Grunde noch die letzte Möglichkeit: ich stöber durch den C-Code und beheb den Fehler selbst – dazu hab ich keine Lust…

Falls sich also jemand fragt, warum die neue Version des LIRC-Pakets für eisfair so lange braucht, ich weise sämtliche Schuld von mir und schiebe es auf höhere Gewalt!

Flexibles Issue Tracking mit roundup

Fuer den Einsatz in der Firma suche ich derzeit ein Bug- und Issue-Tracking-System. Nicht ausschliesslich fuer unsere Engineeringabteilung, sondern auch fuer die Jungs vom Service, die die Hilfeschreie entgegennehmen, wenn der Kunde (fliegendes Personal, und damit extrem ungeduldig) ausnahmsweise mal nicht von der Runway wegkommt.

Eins ist klar: Es muss Open-Source sein. Zum einen will ich nicht erst eine ellenlange Begruendung fuer die Finanzbuchhaltung schreiben, warum sie bitte schoen n+1 Euro fuer eine Software ausgeben sollen, deren Nutzen fuer die Firma sie ohnehin (wieder mal) nicht korrekt quantifizieren koennen. Zum anderen will ich nicht erst mit m+1 Vertrieblern von irgendwelchen Softwarebuden quatschen, die mir ihre “Marktfuehrer”-Loesung aufschwatzen wollen. Aber noch viel wichtiger: Ich will schnell mal eben was aendern koennen, wenn das Tagesgeschaeft es notwendig macht!

Also dann, Wikipedia ist mein Freund, und auf in die taktische Aufklaerung auf dem Softwarefeld: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems listet einen ganzen Wald von Optionen auf. Neben dem eierlegenden Wollmilchborstenviehmoloch “Bugzilla” existieren viele nette kleinere Systeme, die zwar nicht so dick auftragen, die dafuer aber umso schneller und wartbarer sind und fuer deren man Evaluierung man nicht erst im RDBMS herumfuhrwerken muss (bravo!). Web- und Email-Frontends sind anscheinend per stiller Konvention ohnehin ueberall dabei (wobei ich das Email-Frontend derzeit ueberhaupt nicht brauch’).

Besonderen Gefallen habe ich an Roundup gefunden, der ist nicht nur sehr flink, sondern vor allem sehr vielseitig. Eine der Uebersetzungen von Roundup aus dem Englischen ist “Razzia”, und dem Namen macht das kleine Softwarepaket alle Ehre: Neben PostgreSQL und MySQL kann Roundup auch mit sqlite umgehen, das macht das Testen sehr bequem; es bringt seinen eigenen Webserver mit, fuehlt sich aber im mod_python-erweiterten Apache2 genauso daheim; es laesst sich als Bugtracker, Trouble-Ticket-System, ToDo-Liste, persoenliche Zeiterfassung und sogar als Kaffeemaschine konfigurieren. Okay, die Kaffeemaschine ist jetzt gelogen, aber ich wette, lange dauert’s nicht mehr, dann gibt’s auch das! Nettes Feature: Pro Eintrag in die Issue Liste wird eine kleine Mailingliste angelegt, so dass alle Beteiligten/Interessenten ohne viel Aufwand verfolgen koennen, wie sich ein Problem seiner Loesung naehert.

Am besten gefaellt mir bei der Arbeit mit Roundup die Dokumentation, die mit Beispielen nicht geizt, wie man unkompliziert Erweiterungen am Datenbankschema und an den Eingabemasken und Ansichten vornehmen kann: http://roundup.sourceforge.net/doc-1.0/customizing.html. Die Beispiele wirken allesamt wie direkt aus der Praxis entnommen und geben selbst einem Python-Laien wie mir in kuerzester Zeit das Gefuehl, die Dinge wirklich in der Hand zu haben. Innerhalb eines Tages ist es mir gelungen, einen Protoypen zu basteln, in den wir exemplarisch mal ein paar der Bugs der letzten Wochen eingetragen haben. Der Tag Arbeit schliesst eine Customization der CSS-Stylesheets auf unsere Firmen-CI genauso mit ein, wie das Erstellen von automatisierten Reports ueber den Lebenszyklus von Kundenanfragen und Fehlermeldungen fuer die Geschaeftsleitung. Und demnaechst wird auch die Serviceabteilung angebunden, kann ja nicht laenger als einen Tag dauern. ;-)

Fazit: Ich frage mich, warum ich mir ueberhaupt andere Systeme angeschaut und nicht stattdessen gleich Roundup genommen habe. Hier finde ich alles, was ich brauche, um meinen Job zu erledigen, ohne viel Zeit von den Hauptaufgaben abzuzwacken. Ich wuenschte, es waer immer so einfach! Und ich komme von meinem Vorurteilen ueber Python weg, der Produktivitaetsgewinn macht die infantile Syntax locker wieder wett. ;-)

Probleme in OpenSource-Gemeinschaften

Ich lese zur Zeit das Buch »Producing Open Source Software« von Karl Fogel. Er beschreibt aus Insidersicht was für Probleme in OpenSource-Projekten so auftreten und wie man diese von vornherein vermeiden oder später lösen könnte. Ich finde dieses Buch sehr interessant in Bezug auf die Projekte, wo ich persönlich beteiligt bin oder die ich intensiv verfolge (eisfair, IMPULS, climm). Viele Probleme sind da weniger technischer denn sozialer Natur und es gibt interessante Parallelen zwischen all diesen Projekten und den im Buch als Beispiel herangezogenen. Vom Glanz so erfolgreicher Projekte wie Subversion lässt man sich da nur allzu leicht blenden. Es ist vielmehr so, dass die allermeisten Projekte besser laufen könnten. Das ist mir am Wochenende beim Release von Eisfair 1.5.0 aufgefallen und gerade heute noch an anderer Stelle deutlich geworden, als Oliver von F!XMBR über seinen persönlichen Frust mit FreeBSD berichtet hat.

Ich will in Bezug auf Eisfair an dieser Stelle nicht ins Detail gehen, aber ich werde das für die Vorschläge, die ich diese Woche im Eisfair-Team machen will, berücksichtigen…

Was bringt mir das? Vorteile der Offenlegung von Software

Anfang 2007 habe ich bei Google ein Video eines sogenannten TechTalks gesehen: How Open Source Projects Survive Poisonous People (And You Can Too). Ben Collins-Sussman und Brian Fitzpatrick, beide aktiv an der Entwicklung von Subversion beteiligt, haben einen Vortrag gehalten über die Communitys, die hinter Open Source Projekten stehen und wie man dort am besten mit Leuten umgeht, die die Atmosphäre unter den Entwicklern vergiften. Das Video ist 55 Minuten lang und ich habe es das Jahr über an der einen oder anderen Stelle empfohlen, unter anderem auch beim Eisfair-Entwicklertreffen, von dem ich vor zwei Wochen berichtete.

Heute nun bin ich über die verschlungenen Pfade der Blogosphäre auf das Blog von Ben Collins-Sussman gestoßen. Dort finden sich allerlei interessante Beiträge unter anderem auch der Hinweis auf einen weiteren TechTalk aus dem Oktober 2007. Das Video ist fast 50 Minuten lang, aber nicht minder empfehlenswert, wenn auch nicht ganz so amüsant.

Letzte Woche habe ich mich im Büro mit einem Kollegen über genau das Thema unterhalten. Inwiefern können Unternehmen von der Freigabe ihres Quellcodes profitieren? Der Grund dafür, dass es eine längere Unterhaltung war, findet sich auch in dem oben zitierten Video: es gibt keine einfache Antwort. Im Vortrag erläutern Ben und Brian, was sie für den besten Weg halten, den Unternehmen gehen sollten, wenn sie tatsächlich ein Open Source Projekt in die Wege leiten wollen (egal ob auf Basis von vorhandem Code oder von Grund auf). Auf die konkrete Frage, wie sich das mit kommerziellen Interessen verträgt, haben sie auch keine Antwort, die sich in einem Satz zusammenfassen ließe. Viele Vorteile lassen sich nicht direkt in Verkaufszahlen messen, sondern sind nur sehr langfristig sichtbar und betreffen eher den Ruf einer Firma oder die Veränderung eines Software-Marktes. Die Software selbst wird auch besser, aber konkret höhere Profitaussichten durch das offengelegte Projekt, sind wohl kaum der Grund.

Ganz nebenbei wird nochmal der Kernpunkt für eine erfolgreiche Open Source Software erwähnt: eine gesunde Community. In diesem Punkt muss ich den Herren auch aus persönlicher Erfahrung voll und ganz recht geben. Man braucht ein Kernteam von einer Hand voll engagierten und fähigen Entwicklern, die sich gegenseitig respektieren, freundlich und gelassen untereinander sowie zu allen sind, die Fragen zum Projekt haben oder etwas beitragen wollen. Ein Entwickler reicht nicht und Teamwork ist unbedingt notwendig, sonst wird nichts aus dem Projekt.

Das soll als kurze Zusammenfassung zu den beiden Videos erstmal reichen. Ich sehe noch Raum für einen längeren Beitrag über die persönliche Motivation selbst etwas zu Open Source Software beizutragen oder über die Vorteile von Open Source Software im Allgemeinen. Zu den Möglichkeiten für Unternehmen sollte sich jedoch jemand äußern, der besser weiß, womit Firmen wie Trolltech oder MySQL AB ihr Geld verdienen.