Dropbox: Platz im Netz

Gestern bin ich auf Dropbox gestoßen, ein Dienst, der Dateien im Netz ablegt, versioniert und synchronisiert. Die Kosten für Dropbox sind moderat (angefangen bei einer kostenlosen Variante mit 2GB Platz), die Software ist intuitiv: Neben der auch bei anderen Diensten bestehenden Möglichkeit, Dateien zwischen zwei Maschinen zu synchronisieren, gibt Dropbox dem Nutzer die Fähigkeit an die Hand, auf alte Versionen einer Datei zuzugreifen. Damit lassen sich schnell einfach Backup-Szenarien umsetzen.

Für bestehende Dropbox-Benutzer gibt's die Möglichkeit, andere Benutzer zu werben: Wer z.B. dem Link in diesem Blog folgt, um sich bei Dropbox anzumelden, beschehrt mir ein paar MB zusätzlichen Speicherplatz. Eine interessante Wendung ist aber, daß ein neuer Benutzer, der einer Einladung folgt, selbst ebenfalls zusätzlichen Gratis-Speicherplatz erhält, was es auch für den Eingeladenen interessanter macht, einer Einladung zu folgen.

Wie es mit der Sicherheit der im Netz abgelegten Daten aussieht, ist mir bisher nicht bekannt. Es bietet sich also zunächst einmal an, nur Daten seiner Dropbox anzuvertrauen, die man guten Gewissens auch anderen zugänglich machen kann.

Insgesamt ein interessanter Start eines praktischen Dienstes, insbesondere im Vergleich mit JUnit MAX. Ein gewisses Vertrauen zu den Anbietern muß man allerdings schon aufbringen.

Max ist tot

Kent Beck hat gerade JUnit MAX beerdigt: Das TDD-Tool für Eclipse wird vorerst nicht weiterentwickelt, sondern aktiv "abgemanaged".

Was für Becks Three Rivers Institute ärgerlich ist, ist für Eclipse-Benutzer traurig, weil ein nützliches Tool aus dem Arsenal von Java-Entwicklern verschwindet. Allerdings versorgt uns MAX auch auf dem Totenbett noch mit wertvollen Lektionen zum Lernen:

1. Auch gute Ideen brauchen Werbung.
2. Nutzerbasis ist wichtiger als Marge.
3. Paid Beta ist ein sicherer Weg in den Untergang.

JUnit MAX hat praktisch jede Gelegenheit vermieden, in Entwicklerkreisen bekannt zu werden. Einzig Kent Becks Blog- und Twitter-Leser sind gelegentlich auf MAX gestoßen (wie in den Kommentaren zum Blog zu lesen ist). Die initiale Nutzerbasis war also begrenzt. Ganz offensichtlich hat Kent Becks guter Name und die spärlichen Informationen über sein Produkt allein nicht gereicht, im Info-Meer sichtbar zu werden. Aktives Marketing wäre also unbedingt notwendig gewesen.

Der Versuch, MAX frühzeitig über ein Subscription-Modell zu finanzieren, hat das Wachstumspotential von vornherein beschränkt. Als folglich die Anzahl der neuen Subscriptions zurückging, wurde versucht, das finanzielle Loch über höhere Preise pro Subscription zu stopfen, was vorhersehbar neue Subscriptions weiter reduzierte. Die Schlußfolgerung ist eigentlich zu trivial, um sie wiederzukauen, aber trotzdem: Die Breite der Nutzerbasis ist umgekehrt proportional zu den Kosten für den Nutzer.

Letztlich ist aber die Idee der Paid Beta der verdiente Todesstoß für jeden neuen Dienst im Netz. Unabhängig von der "Innovationshöhe" eines Dienstes dient der Beta-Test in erster Linie dem Anbieter des Dienstes, Nutzer des Dienstes müssen i.d.R. mit willkürlichen Einschränkungen des Dienstes leben. Für das Testen eines Produktes werden Tester daher traditionell bezahlt. Die Umkehrung dieser Situation ist wohl glücklicherweise genügend potentiellen Kunden aufgefallen, bevor aus MAX ein Verbraucher-Präzendenzfall werden konnte.

Zum Schluß wünsche ich Kent Beck natürlich, doch noch irgendwie einen Erfolg aus MAX zu machen. Möglichst auch einen finanzellen Erfolg.

Googles nächster Wurf: Chrome OS

Google hat es wieder mal geschafft: Alle reden über Chrome OS, und das, obwohl es gerade mal angekündigt wurde (und das Licht der Welt nicht vor Mitte 2010, also in einem Jahr, erblicken wird): Was beschehrt uns Google da jetzt wieder grandios Neues?

Zunächst mal ist Chrome OS im Kern ein Linux. Das ist nicht überraschend, schließlich gibt es im Moment gerade mal drei Hauptstränge bei der OS-Entwicklung: BSD-Unix inklusve der Abkömmlinge Solaris und (Mac) OS X, Windows NT und dessen Nachfolger, und eben Linux -- und in der Vergangenheit hat Google eine gewisse Affinität zu Linux bewiesen. Ernsthafte Neuigkeiten waren da ja schon aufgrund des Entwicklungsaufwands für ein komplettes OS nicht zu erwarten.

Was Chrome OS uns also voraussichtlich bringen wird, ist eine Art Linux-Distribution mit einer neuen Oberfläche. Auch die Oberfläche wird voraussichtlich auf etablierten Systemen aufsetzen.

Technologisch wird es also möglicherweise hinreichend unterschiedlich von bekannten Linux-Distributionen sein, um das bloße Übertragen von Paketen zu verhindern, aber andererseits auch nicht wirklich neu. Vielmehr halte ich es für einen ähnlichen Ansatz wie Apples iPhone: Auf der Basis von etablierter Technologie wird ein neuer Ansatz der Nutzung forciert, bei dem die Nutzer die lokale Gewalt über ihre Daten zugunsten eines ausgelagerten Managements aufgeben.

Und das könnte durchaus interessant werden: Die Debatte um Datenschutz und Unabhängigkeit vs. Nutzerbequemlichkeit ist wiedermal eröffnet. Dabei ist der Ausgang absehbar: Ich behaupte, die Mehrzahl der IT-Nutzer ist nicht an IT selbst interessiert, und würde den täglichen Kampf gegen Spams und die Jagd nach Updates und Patches lieber heute als morgen ad acta legen.

Vielleicht ist Chrome OS ja die Möglichkeit für die Entwickler der etablierten Systeme, sich von der oftmals selbstherrlich mißverstandenen Losung "educate your user" loszusagen, die Komplexität für den Anwender zu reduzieren und IT endlich wieder als Werkzeug und nicht als Selbstzweck zu begreifen. Alternativ werden sie über kurz oder lang alle Nutzer verlieren, die einfach nur tägliche Aufgaben erledigen wollen -- und das sollte die Mehrheit der Nutzer sein.

Und das wäre wirklich mal etwas Neues.

Refactoring für Sterbliche

Yahuda Katz, einer der Rails Großmeister (wenn es diesen Titel denn gibt), hat vor ein paar Tagen einen guten Blog-Artikel zum Thema Refactoring verfaßt: 6 Steps To Refactoring Rails (For Mere Mortals) beleuchtet ein paar grundsätzliche Vorgehensweisen zum Refactoring (und zwar nicht nur für Rails). Ich denke, nachdem es schon ganze Bücher zum Thema Refactoring gibt, ist das tatsächlich die Essenz des Refactoring, trotzdem halte ich zwei Punkte für besonders wichtig:

Erstmal bedeuted Refactoring, daß neuer Code die gleiche Funktion erfüllt (und keine neuen Features einführt), zweitens funktioniert Refactoring nur mit Tests. Vielen, vielen Tests, die alle funktionalen Bereiche des Codes abdecken.

Meine bescheidene Erfahrung sagt, daß vor dem und während des Refactoring ein ganzer Haufen neuer Tests entsteht. Grundsätzlich muß sowohl der alte als auch der neue Code die Tests bestehen; wenn der alte Code das nicht tut, gibt es nur zwei Szenarien: Der alte Code war fehlerhaft (was ja immer sein kann), oder die Tests stellen auf die neue Codestruktur ab (was möglicherweise etwas fragwürdig ist).

Zuletzt noch eine Anmerkung, die für Nicht-Rails- und Nicht-Ruby-Entwickler vielleicht etwas untergeht: Refactoring passiert nicht auf dem Master-Branch, sondern etwas abseits, da zwischendurch mit Sicherheit ein ganzer Haufen Fehler auftritt (ein SCM ist ohnehin Pflicht). Alle Nutzer von klassischen SCMs haben hier natürlich schlechte Karten, da ihr Code in Dateien organisiert ist, die vom SCM als separate Einheiten gesehen werden. Aber es gibt Hoffnung: Ein Refactoring ist ein guter Grund, sich mal git anzusehen. (Soviel zum Thema Propaganda.)