Alors que PostgreSQL Elephant continue
sa marche vers une autre version, j'ai beaucoup réfléchi
au rôle que les utilisateurs de logiciels devraient avoir dans sa conception d'interface
utilisateur. Aujourd'hui, j'ai proposé quelque chose qui rend un paramètre de base de données
dont les gens avaient l'habitude de s'inquiéter, et qui n'était pas du tout évident
comment le définir, et rend sa valeur largement automatique. C'est un changement vers l'avant assez
sans ambiguïté ; les utilisateurs étaient ennuyés, un bon comportement par défaut
a été établi, et ce comportement par défaut a été suggéré comme correctif. Si c'est appliqué, je serais choqué de trouver quelqu'un qui considère qu'il s'agit d'une
mauvaise décision.
Il y a eu une discussion similaire sur
comment retravailler l'interface utilisateur autour des points de contrôle de la base de données. Actuellement, la vitesse à laquelle les données sont écrites sur le disque par un point de contrôle est
affectée par trois valeurs que l'utilisateur peut spécifier. L'interaction
entre ceux-ci est suffisamment bien documentée, quoique d'une manière qui
reflète la complexité, et certains utilisateurs trouvent que le comportement qu'elle donne
fonctionne bien. Il est tout à fait possible qu'afin d'améliorer les choses
pour l'utilisateur type, il y ait une régression des performances dans certains cas par rapport au code actuel. L'utilisation d'une
implémentation différente qui modifie l'échelle effective des
paramètres entraînera des changements de synchronisation subtils, et ils ne seront pas
nécessairement tous positifs. Dans cette situation, le mieux que nous puissions faire
en tant que communauté de développement est de collecter suffisamment de données de référence pour faire
cet appel. Il se peut que l'amélioration des scénarios les plus défavorables
dérègle légèrement les choses par rapport à la mise en œuvre précédente. Si
le résultat net s'avère plus facile à ajuster – remplacer plusieurs
paramètres compliqués par un seul, comme je l'ai suggéré, pourrait être la
bonne direction ici–en moyenne, cela devrait être mieux. À certains
moments, il est nécessaire d'abandonner l'ancienne approche afin d'en obtenir
une meilleure.
Mais c'est à quel point nous sommes préoccupés
par le comportement de rupture sur lequel les utilisateurs s'appuient. L'accent est mis sur la
rétrocompatibilité et sur l'ajout d'éléments d'une manière qui ne supprime pas l'ancienne approche du développement PostgreSQL. Parfois, il n'y a
pas le choix :il faut pousser vers une nouvelle approche. Dans les cas
où l'ancien et le nouveau comportement sont tout à fait légitimes,
il est difficile d'atteindre même une opinion majoritaire claire. C'est souvent le
cas dans la conception de l'interface utilisateur. Bien que vous puissiez comparer cela avec les
bons outils et les bons professionnels, mais c'est rarement fait dans la
communauté open source. Il est difficile d'obtenir un consensus communautaire à partir de ce mélange
d'opinions très personnelles.
On m'a encore rappelé comment ne pas
gérer les commentaires des utilisateurs en tant que développeur en obtenant des mises à jour aujourd'hui
à propos d'une longue régression ennuyeuse dans la façon dont gnome- terminal, mon
terminal de ligne de commande préféré, gère la saisie au clavier. Le problème
s'est d'abord gélifié dans un rapport de bogue il y a presque exactement deux ans, sur un
tracker Ubuntu, pour ensuite migrer vers la source
sous-jacente de la régression :un changement intentionnel par l'un des GNOME
développeurs pour éliminer les comportements qu'ils jugent inappropriés. Il y avait un ticket ouvert demandant une solution, mais ce n'était jamais bien au-delà d'être insultant pour toutes les personnes impliquées.
J'ai été suffisamment actif dans l'historique de ce dernier
ticket pour que je n'aie pas besoin de répéter mon argument ici.
Essentiellement, tout ce que je voulais, c'était une option de configuration de case à cocher pour
rendre possible le retour à l'ancien comportement. J'ai même commencé à travailler
pour faire exactement cela, en creusant dans le code pour suggérer des solutions de contournement,
pour réaliser qu'il n'y avait aucun moyen que cela soit fusionné. Mes
suggestions visaient à essayer de trouver un terrain d'entente qui plaire
à tout le monde. Il est très clair que les développeurs ne s'en soucient pas. Ils font les choses comme ils veulent, et
tout le monde n'a pas d'importance. Qu'on m'ait dit qu'il faudrait "
quelques centaines" de plaintes avant que cela ne soit considéré comme important
m'épate, étant donné que l'utilisation de la clé de contrôle dans le terminal n'est
pas exactement la chose la plus populaire . Il y a eu des dizaines de rapports,
chaque plainte reçue a été unifiée dans la
solution préférée, et la seule personne qui n'était pas d'accord était l'un de leurs
développeurs.
Nous recevons des plaintes de personnes selon lesquelles
la communauté PostgreSQL est remplie de développeurs qui préfèrent
des solutions techniquement pures plutôt que de simplement donner aux utilisateurs ce qu'ils veulent.
C'est vrai dans une certaine mesure, comme la résistance continue à
ajouter afficher des tables comme moyen alternatif de trouver la
base de données dans votre base de données. Mais toutes ces discussions ont porté sur
des sujets où la discussion donne des opinions très mitigées ; beaucoup de gens
ont des opinions bien arrêtées des deux côtés. Si chaque utilisateur est d'accord sur une
conception, ce qui est le cas avec ce problème de gnome-terminal, rejeter
ces opinions comme n'étant toujours pas justes est le comble de l'arrogance du développeur.
L'un des exemples les plus intéressants de
ce genre de chose implique que les développeurs du logiciel Pidgin IM
modifient le fonctionnement de la taille du texte de la fenêtre de chat dans leur programme.
Les utilisateurs se sont révoltés. Il existe un bon exemple de l'ancien et du nouveau comportement avec une
analyse chez CodingHorror.
Tout le monde a été choqué par la façon dont les
développeurs semblaient ignorer leurs commentaires. Leur perception était
que les commentaires de la communauté n'étaient pas pertinents pour les développeurs, car
ils estimaient que leur conception était meilleure que l'ancienne, indépendamment de ce que
les utilisateurs pensaient. Quelqu'un a écrit un plug-in pour restaurer l'ancien
comportement. Et puis il y a eu une scission officielle. L'
énoncé de mission
du fork qui en résulte, appelé à l'origine « Fun Pidgin » et maintenant
appelé « Carrier Instant Messager », est une lecture intéressante sur la façon dont
ils se sentent centrés sur l'utilisateur le développement devrait fonctionner.
La discussion CodingHorror de Jeff Atwood
à ce sujet a suggéré quatre façons dont un tel fork pourrait se révéler. Il a omis une question très importante :la possibilité qu'en divisant les efforts de la communauté, les deux fourches meurent, aucune n'ayant suffisamment de ressources pour rivaliser avec les alternatives. Même si Pidgin n'est pas encore
mort – c'est loin de "courir le rideau et rejoindre
le chœur qui saigne invisibile » – ils sont moins importants qu'ils ne l'étaient, et toute cette débâcle n'a pas aidé leur cause. Depuis
Ubuntu 9.10, Canonical a remplacé Pidgin en tant que client de messagerie instantanée principal
livraison avec cette distribution Linux très populaire. Au lieu de cela, ils ont mis
GNOME Empathy à sa place. Cela serait-il encore arrivé si la
communauté Pidgin ne s'était pas fracturée et n'avait pas été associée à de si mauvaises
RP ? Peut-être, mais cela n'a certainement pas aidé leur cas.
Que le même type de décisions
ignorant les utilisateurs soient prises concernant un projet GNOME populaire comme
gnome-terminal est amusant (je ris plutôt que de pleurer) se dirigeant vers
une situation similaire. Il y a deux mois, il a été annoncé qu'Ubuntu s'éloignait considérablement de l'utilisation de la pile logicielle complète de GNOME dans sa prochaine version. Notez très attentivement ce qui s'est passé.
Mark Shuttleworth dit qu'ils ont embauché des concepteurs d'interface utilisateur professionnels, qu'ils les ont mis au travail pour déterminer ce qui fonctionnerait mieux pour l'expérience utilisateur
de bureau, puis ont présenté les résultats au Communauté GNOME.
Plutôt que d'accepter ce travail extrêmement précieux et de remercier Canonical
d'avoir fait cette recherche, ils ont rejeté suffisamment d'idées fondamentales qu'il n'y avait pas de terrain d'entente possible. Ubuntu est maintenant en train de bifurquer vers le projet Unity, comme le seul chemin qui reste pour "faire ce que veulent nos utilisateurs". Sur la base de mes propres interactions avec les développeurs de GNOME au cours des années depuis que j'ai rencontré ce désagrément, la
réaction de Mark ne me surprend pas du tout.
Nous sommes toujours au point où il n'est pas
clair comment cette scission d'Unity finira par se terminer. Ce à quoi je m'attends, c'est
que tout cela aboutisse également à une sorte de situation de double échec
. Il y aura un tas de développements dupliqués qui
ne produisent à eux seuls rien d'utile au début. Les
versions initiales seront soumises à un contrôle de qualité épouvantable – ces éléments mettent une éternité à se mettre en place. Et en divisant la base de développeurs, il est tout à fait possible qu'aucun des deux groupes n'ait suffisamment de personnes pour finir par faire du bon travail, nous laissant tous avec de multiples options de bureau Linux médiocres (encore une fois) plutôt qu'un unifié, tout le monde s'aligne pour
s'améliorer. J'espérais maintenant que la façon dont Nokia a amélioré
la licence de Qt pourrait enfin faire réfléchir à la façon d'éliminer
d'avoir à la fois Qt+GNOME. Qu'au lieu de cela, Linux obtienne encore un projet de développement
en plus du mélange, et le nommer Unité de toutes choses, est une
terrible blague.
Mais je parlais de bases de données… l'une
des choses intéressantes à propos de PostgreSQL est le nombre de fourches qu'il a
générées. La généreuse licence BSD avait conduit à plusieurs fourches commerciales à source fermée ; J'avais l'habitude de travailler dans une entreprise qui en fabriquait
un. Netezza a été le premier d'entre eux à se transformer en une production commerciale sérieuse. Et la base de données Greenplum a été récemment
achetée par EMC, c'est un produit très réussi. Ce qui ne s'est pas produit, c'est qu'aucun des forks open source ne devienne des remplacements viables
pour la distribution principale. À moins que vous n'ayez le genre de
ressources importantes qu'une grande entreprise peut apporter à l'ingénierie, il est
plus facile d'amener la communauté à accepter vos idées que d'essayer
et de faire une mise en œuvre indépendante d'eux. Communauté directe
PostgreSQL continue d'être le bon choix.
La communauté PostgreSQL discute beaucoup,
et est hostile à beaucoup de choses que les gens demandent ; nous avons même une
liste que nous ne voulons pas faire.
Ce sont pour la plupart des choses qui ne sont tout simplement pas techniquement réalisables sans inconvénients qui ne sont pas toujours évidents pour
ceux qui les demandent. Si un utilisateur explique pourquoi une modification
permettrait d'améliorer l'interface utilisateur de quelque chose dans la base de données, et
il n'y a aucune objection technique quant à la raison pour laquelle cela causera un problème,
ce changement est pris en compte. Ce que je n'ai jamais vu dans la communauté, c'est
l'un des développeurs s'aligner contre une préférence utilisateur unanime et sans ambiguïté – où cette option pourrait être rendue disponible sans
inconvénient – simplement parce qu'ils ne l'aime pas ainsi. Si vous êtes un
développeur d'un projet open source qui erre là où l'orgueil a si mal éclipsé l'humilité, ne soyez pas surpris si vos utilisateurs seront
assez en colère pour bifurquer. Et un de ces jours, vous découvrirez peut-être que
les bifurcations ou les réimplémentations qui prêtent attention à ce que les gens
voulent vraiment vous déplaceront.
