Während der PostgreSQL Elephant seinen Weg
in Richtung einer weiteren Version fortsetzt, habe ich ziemlich viel darüber nachgedacht
, welche Rolle Benutzer von Software spielen sollten sein User Interface
Design. Heute habe ich etwas vorgeschlagen, das einen Datenbankparameter macht,
um den sich die Leute früher Sorgen machen mussten, und der überhaupt nicht offensichtlich war,
wie man ihn einstellt, und dessen Wert weitgehend automatisch wird. Das ist eine ziemlich
eindeutige Vorwärtsänderung; Benutzer waren verärgert, gutes Standardverhalten
eingestellt und dieses Standardverhalten als Patch vorgeschlagen. Wenn es angewendet wird, wäre ich schockiert, jemanden zu finden, der das für eine schlechte
Entscheidung hält.
Es gab eine ähnliche Diskussion darüber,
wie man die Benutzeroberfläche um Datenbankprüfpunkte herum überarbeitet. Im Moment
wird die Geschwindigkeit, mit der Daten von einem Checkpoint auf die Platte geschrieben werden,
von drei Werten beeinflusst, die der Benutzer angeben kann. Die Interaktion
zwischen diesen ist gut genug dokumentiert, wenn auch auf eine Weise, die
die Komplexität widerspiegelt, und einige Benutzer finden, dass das dadurch gegebene Verhalten
gut funktioniert. Es ist durchaus möglich, dass es, um die Dinge
für den typischen Benutzer zu verbessern, in einigen Fällen zu einer Leistungsregression
relativ zum aktuellen Code kommt. Die Verwendung einer
anderen Implementierung, die die effektive Skala der
Parameter ändert, führt zu subtilen Timing-Änderungen, die
nicht notwendigerweise alle positiv sind. In dieser Situation ist das Beste, was wir als Entwickler-Community
tun können, genügend Benchmark-Daten zu sammeln,
um diese Entscheidung zu treffen. Es kann sein, dass die Verbesserung der Worst-Case-Szenarien
im Vergleich zur früheren Implementierung etwas verstimmt. Wenn sich
das Endergebnis als einfacher anzupassen herausstellt – das Ersetzen mehrerer
komplizierter Einstellungen durch eine einzige, wie ich vorgeschlagen habe, könnte hier die
richtige Richtung sein – im Durchschnitt sollte das besser sein. Manchmal ist es notwendig, den alten Ansatz loszulassen, um
einen besseren zu finden.
Aber so sehr sind wir besorgt
über das Verhalten, auf das sich Benutzer verlassen. Es gibt einen großen Fokus auf
Abwärtskompatibilität und das Hinzufügen von Dingen nur auf eine Weise, die
den alten Ansatz in der PostgreSQL-Entwicklung nicht aufhebt. Manchmal gibt es aber
keine Wahl:Man muss auf einen neuen Ansatz drängen. In Fällen
in denen sowohl altes als auch neues Verhalten völlig legitim ist, ist es schwierig,
auch nur eine klare Mehrheitsmeinung zu erreichen. Das ist im User Interface Design oft der Fall. Sie können das zwar mit den
richtigen Tools und Fachleuten messen, aber in der
Open-Source-Community wird das selten gemacht. Aus dieser Mischung
sehr persönlicher Meinungen einen Community-Konsens zu ziehen, ist schwierig.
Ich wurde erneut daran erinnert, wie man
als Entwickler nicht mit Benutzer-Feedback umgehen sollte, indem ich heute einige Updates erhielt
über eine lange ärgerliche Regression in der Art und Weise, wie Gnome- terminal, mein nominell
bevorzugtes Befehlszeilenterminal, verarbeitet Tastatureingaben. Das Problem
hatte sich vor fast genau zwei Jahren zum ersten Mal in einem Fehlerbericht auf einem
Ubuntu-Tracker nieder, nur um zur zugrunde liegenden
Quelle der Regression zu migrieren:eine absichtliche Änderung durch einen der GNOME
Entwicklern, um unangemessenes Verhalten zu beseitigen. Es wurde ein Ticket eröffnet, in dem um eine Lösung gebeten wurde, aber es war nie mehr als beleidigend für alle Beteiligten.
Ich war in der Geschichte des letzteren
Tickets so aktiv, dass ich meine Argumentation hier nicht wiederholen muss.
Im Grunde war alles, was ich wollte eine Kontrollkästchen-Konfigurationsoption, um
das Zurückkehren zum alten Verhalten zu ermöglichen. Ich fing sogar an,
daran zu arbeiten, indem ich mich in den Code vertiefte, um Problemumgehungen vorzuschlagen,
nur um festzustellen, dass dies auf keinen Fall jemals zusammengeführt werden würde. Meine
Vorschläge konzentrierten sich darauf, eine gemeinsame Basis zu finden, die
allen gefallen würde. Es ist jedoch ganz klar, dass sich die Entwickler
darüber einfach nicht scheren. Sie machen das, was sie wollen, und
alle anderen sind egal. Dass mir gesagt wurde, dass es „
ein paar hundert“ Beschwerden braucht, bevor dies als wichtig angesehen wird,
verwundert mich, wenn man bedenkt, dass die Verwendung von Kontrollschlüsseln im Terminal
nicht gerade die beliebteste Sache ist . Es gab Dutzende von Berichten,
jede einzelne eingegangene Beschwerde wurde in der bevorzugten
Lösung zusammengefasst, und die einzige Person, die anderer Meinung war, war einer ihrer
Entwickler.
Wir bekommen einige Beschwerden von Leuten, dass
die PostgreSQL-Community voller Entwickler ist, die
technisch reine Lösungen bevorzugen, anstatt den Benutzern einfach das zu geben, was sie wollen.
Das stimmt bis zu einem gewissen Grad, wie zum Beispiel der anhaltende Widerstand gegen
das Hinzufügen von Anzeigetabellen als alternative Möglichkeit, die
Datenbank in Ihrer Datenbank zu finden. Aber all diese Diskussionen betrafen
Themen, bei denen die Diskussion sehr gemischte Meinungen hervorbringt; Viele Leute
haben eine starke Meinung auf beiden Seiten. Wenn jeder Benutzer einem
Design zustimmt, was bei diesem Gnome-Terminal-Problem der Fall ist,
diese Meinungen abzulehnen, da sie immer noch nicht richtig sind, ist der Gipfel der Entwicklerarroganz
.
Eines der interessanteren Beispiele für
diese Art von Dingen betrifft die Entwickler der Pidgin IM-Software
, die die Textgröße des Chatfensters in ihrem ändert Programm.
Benutzer empörten sich. Es gibt ein gutes Beispiel für das alte und neue Verhalten mit einigen
Analysen bei CodingHorror.
Jeder war angewidert von der Art, wie die Entwickler
ihr Feedback zu ignorieren schienen. Ihre Wahrnehmung war
dass das Community-Feedback für die Entwickler irrelevant war, weil
sie das Gefühl hatten, dass ihr Design besser war als das alte, unabhängig davon, was
die Benutzer dachten. Jemand hat ein Plug-in geschrieben, um das alte
Verhalten wiederherzustellen. Und dann gab es eine offizielle Trennung. Die Mission
Statement
des resultierenden Forks, ursprünglich „Fun Pidgin“ und jetzt
Carrier Instant Messenger genannt, ist eine interessante Lektüre darüber, wie
sie sich benutzerzentriert fühlen Entwicklung sollte funktionieren.
Jeff Atwoods CodingHorror-Diskussion
darüber schlug vier Möglichkeiten vor, wie ein solcher Fork ausgehen könnte. Er ließ
einen sehr wichtigen aus:die Möglichkeit, dass durch die Aufteilung der
Community-Bemühungen beide Forks sterben würden, ohne dass keiner genügend
Ressourcen hätte, um gegen die Alternativen anzutreten. Während Pidgin
noch nicht tot ist – es ist ein gutes Stück davon entfernt, „den Vorhang herunterzulaufen und sich
unsichtbar
dem verdammten Chor anzuschließen“ – sind sie weniger wichtig als sie
früher waren, und dieses ganze Debakel hat ihrer Sache nicht geholfen. Seit
Ubuntu 9.10 hat Canonical Pidgin als primären IM-Client
abgelöst, der mit dieser sehr beliebten Linux-Distribution geliefert wird. Stattdessen haben sie
GNOME Empathy an seine Stelle gesetzt. Wäre das immer noch passiert, wenn die
Pidgin-Community nicht zerbrochen wäre und mit so schlechter
PR in Verbindung gebracht worden wäre? Möglich, aber das hat ihrem Fall sicherlich nicht geholfen.
Dass die gleiche Art von benutzerignoranten
Entscheidungen in Bezug auf ein beliebtes GNOME-Projekt wie
gnome-terminal getroffen werden, ist amüsant (ich lache eher als Weinen) auf eine
ähnliche Situation zusteuern. Vor zwei Monaten wurde bekannt gegeben, dass Ubuntu
sich deutlich von der Verwendung des vollständigen GNOME-Software-Stacks in seiner nächsten Version entfernt. Achten Sie genau darauf, was dort passiert ist.
Mark Shuttleworth sagt, dass sie professionelle UI-Designer eingestellt,
sie damit beauftragt haben, herauszufinden, ob sie für die Desktop-Benutzererfahrung
besser funktionieren würden, und dann die Ergebnisse dem präsentiert haben GNOME-Community.
Anstatt diese äußerst wertvolle Arbeit zu akzeptieren und Canonical
für diese Forschung zu danken, haben sie genug grundlegende Ideen verworfen, dass
es keinen Mittelweg gab. Ubuntu verzweigt sich jetzt in einem großen
Weg in Richtung des Unity-Projekts, als dem einzigen verbleibenden Weg, „das zu tun, was unsere
Benutzer wollen“. Basierend auf meiner eigenen Interaktion mit den GNOME-Entwicklern
in den Jahren, seit ich auf diesen einen Ärger gestoßen bin, überrascht mich die
Reaktion, die Mark bekam, kein bisschen.
Wir sind immer noch an einem Punkt angelangt, an dem
nicht klar ist, wie diese Unity-Aufteilung am Ende ausgehen wird. Was ich erwarte, ist, dass
diese ganze Sache auch in eine Art Doppelversagen
führen wird. Es wird eine Reihe doppelter Entwicklungen geben, die
an sich zunächst nichts Nützliches hervorbringen. Die ersten
Veröffentlichungen werden eine schreckliche Qualitätskontrolle haben – dieses Zeug braucht
ewig, um richtig zu werden. Und durch die Aufteilung der Entwicklerbasis ist es
gut möglich, dass keine Gruppe genug Leute übrig hat, um
am Ende einen guten Job zu machen, was uns alle mit mehreren schlechten Linux-Desktop-Optionen
(wieder) zurücklässt. statt einer einheitlichen, die sich alle
verbessern wollen. Ich hatte inzwischen gehofft, dass die Art und Weise, wie Nokia die Qt-Lizenz
verbessert hat, endlich darüber nachdenkt, wie man sowohl Qt als auch GNOME
beseitigt. Dass Linux stattdessen noch ein Entwicklungsprojekt
auf die Spitze bekommt und es ausgerechnet Unity nennt, ist ein
schrecklicher Witz.
Aber ich habe über Datenbanken gesprochen… eines
das Interessante an PostgreSQL ist, wie viele Forks
erzeugt wurden. Die großzügige BSD-Lizenz hatte zu mehreren
Closed-Source-Commercial-Forks geführt; Ich habe früher bei einer Firma gearbeitet, die
einen herstellte. Netezza war die erste, die sich schließlich zu einer ernsthaften
kommerziellen Produktion entwickelte. Und die Greenplum-Datenbank wurde kürzlich
von EMC gekauft, es ist ein sehr erfolgreiches Produkt. Was nicht
passiert ist, ist, dass einer der Open-Source-Forks ein brauchbarer Ersatz
für die Hauptdistribution geworden ist. Wenn Sie nicht über die großen
Ressourcen verfügen, die ein großes Unternehmen für die Entwicklung einbringen kann, ist es
einfacher, die Community dazu zu bringen, Ihre Ideen zu akzeptieren, als zu versuchen,
eine unabhängige Implementierung durchzuführen von ihnen. Reine Community
PostgreSQL ist einfach immer die richtige Wahl.
Die PostgreSQL-Community streitet viel,
und steht vielen Dingen, die die Leute verlangen, ablehnend gegenüber; wir haben sogar eine
Liste, die wir nicht machen wollen.
Dies sind zum größten Teil Dinge, die technisch einfach nicht
machbar sind, ohne Nachteile zu bauen, die für
diejenigen, die sie anfordern, nicht immer offensichtlich sind. Wenn ein Benutzer argumentiert, warum eine Änderung
eine bessere Benutzeroberfläche für etwas in der Datenbank bewirken würde, und
es keine technischen Einwände dagegen gibt, warum dies ein Problem verursachen wird,
diese Änderung berücksichtigt wird. Was ich in der Community noch nie gesehen habe, ist, dass sich
ein Entwickler gegen eine einstimmige, eindeutige
Benutzerpräferenz stellt – wo diese Option ohne
Nachteile zur Verfügung gestellt werden könnte – einfach weil sie mag das nicht so. Wenn Sie ein
Entwickler eines Open-Source-Projekts sind, das dorthin wandert, wo Hybris
die Demut so sehr übertrumpft hat, seien Sie nicht überrascht, wenn Ihre Benutzer
verärgert genug sind, um zu forken. Und eines Tages stellen Sie vielleicht fest, dass
die Gabelungen oder Neuimplementierungen, die darauf achten, was die Leute
wirklich wollen, Sie verdrängen werden.
