Mentre PostgreSQL Elephant continua
la sua marcia verso l'ennesima versione, ho riflettuto a lungo
sul ruolo che gli utenti del software dovrebbero avere in la sua interfaccia utente
design. Oggi ho proposto qualcosa che rende un parametro di database
di cui le persone dovevano preoccuparsi, e che non era affatto ovvio
come impostare, e rende il suo valore ampiamente automatico. Questo è un cambiamento in avanti piuttosto
non ambiguo; gli utenti erano infastiditi, un buon comportamento predefinito
stabilito e quel comportamento predefinito suggeriva come patch. Se venisse applicato, sarei scioccato nel trovare qualcuno che la consideri una cattiva
decisione.
C'è stata una discussione simile su
come rielaborare l'interfaccia utente attorno ai checkpoint del database. In questo momento
la velocità con cui i dati vengono scritti su disco da un checkpoint è
influenzata da tre valori che l'utente può specificare. L'interazione
tra questi è documentata abbastanza bene, anche se in un modo che
riflette la complessità e alcuni utenti trovano che il comportamento che dà
funzioni bene. È possibile che per rendere le cose
migliori per l'utente tipico, ci sarà una regressione
delle prestazioni in alcuni casi rispetto al codice corrente. L'utilizzo di una
diversa implementazione che modifichi la scala effettiva dei
parametri comporterà lievi modifiche temporali e non
necessariamente tutte saranno positive. In questa situazione, il meglio che possiamo fare
come comunità di sviluppo è raccogliere dati di benchmark sufficienti per effettuare
quella chiamata. È possibile che il miglioramento degli scenari peggiori
distorca leggermente le cose rispetto all'implementazione precedente. Se
il risultato netto risulta essere più facile da regolare, sostituendo più
impostazioni complicate con una sola, come ho suggerito potrebbe essere la
giusta direzione qui, in media dovrebbe essere migliore. A volte
è necessario abbandonare il vecchio approccio per ottenere
uno migliore.
Ma questo è quanto ci preoccupiamo
del comportamento di rottura su cui fanno affidamento gli utenti. C'è una grande attenzione sulla
compatibilità con le versioni precedenti e sull'aggiunta di elementi solo in un modo che non
rimuove il vecchio approccio nello sviluppo di PostgreSQL. A volte non c'è
scelta però:devi spingere verso un nuovo approccio. Nei casi
in cui sia il vecchio che il nuovo comportamento sono completamente legittimi, è difficile
raggiungere anche un'opinione netta della maggioranza. Questo è spesso il
caso nella progettazione dell'interfaccia utente. Anche se puoi confrontarlo con gli
strumenti e professionisti giusti, ma raramente è fatto nella
community open-source. Ottenere il consenso della comunità da quel mix
di opinioni molto personali è difficile.
Mi è tornato in mente come
gestire il feedback degli utenti come sviluppatore ricevendo alcuni aggiornamenti oggi
su una lunga e fastidiosa regressione su come gnome- terminal, il mio terminale da riga di comando
preferito nominale, gestisce l'input da tastiera. Il problema
si è manifestato per la prima volta in un bug report quasi esattamente due anni fa, su un
Ubuntu tracker, solo per migrare alla
fonte sottostante della regressione:un cambiamento intenzionale da parte di uno dei GNOME
gli sviluppatori per eliminare i comportamenti che hanno ritenuto inappropriati. C'è stato un ticket aperto che richiedeva una correzione, ma non è mai stato molto oltre essere offensivo per tutti i soggetti coinvolti.
Sono stato abbastanza attivo nella cronologia di quest'ultimo
ticket da non aver bisogno di ripetere la mia argomentazione qui.
In sostanza, tutto ciò che volevo era un'opzione di configurazione della casella di controllo per
rendere possibile il ritorno al vecchio comportamento. Ho anche iniziato a lavorare
per fare proprio questo, scavando nel codice per suggerire soluzioni alternative,
solo per rendermi conto che non c'era modo che questo sarebbe mai stato unito. I miei
suggerimenti erano incentrati sul tentativo di trovare un terreno comune che potesse
soddisfare tutti. È molto chiaro che agli sviluppatori non interessa
questo però. Stanno facendo le cose come vogliono e
tutti gli altri non hanno importanza. Il fatto che mi sia stato detto che ci sarebbero volute "poche
poche centinaia" di lamentele prima che questo fosse considerato importante
mi sconcerta, considerando che l'uso della chiave di controllo nel terminale
non è esattamente la cosa più popolare . Ci sono state decine di segnalazioni,
ogni singolo reclamo ricevuto è stato unificato nella
risoluzione preferita e l'unica persona che non era d'accordo era uno dei loro
sviluppatori.
Riceviamo alcune lamentele da parte di persone che
la community di PostgreSQL è piena di sviluppatori che preferiscono
soluzioni tecnicamente pure piuttosto che dare agli utenti ciò che vogliono.
Questo è vero in una certa misura, come la continua resistenza all'
aggiungere mostra tabelle come un modo alternativo per trovare il
database nel tuo database. Ma tutta quella discussione ha riguardato
argomenti in cui la discussione dà opinioni molto contrastanti; molte persone
hanno opinioni forti da entrambe le parti. Se ogni utente è d'accordo su un
design, come nel caso di questo problema con il terminale gnomo, rifiutare
quelle opinioni perché ancora non corrette è l'altezza dello sviluppatore
arroganza.
Uno degli esempi più interessanti di
questo genere di cose coinvolge gli sviluppatori del software Pidgin IM
cambiando il modo in cui il ridimensionamento del testo della finestra di chat funziona nel loro programma.
Gli utenti si sono ribellati. C'è un buon esempio del vecchio e del nuovo comportamento con alcune
analisi di CodingHorror.
Tutti sono rimasti colpiti dal modo in cui gli
sviluppatori sembravano ignorare il loro feedback. La loro percezione era
che il feedback della community fosse irrilevante per gli sviluppatori, perché
ritenevano che il loro design fosse migliore di quello precedente indipendentemente da ciò che
pensavano gli utenti. Qualcuno ha scritto un plug-in per ripristinare il vecchio
comportamento. E poi c'è stata una scissione ufficiale. La missione
dichiarazione
del fork risultante, originariamente chiamato "Fun Pidgin" e ora
chiamato "Carrier Instant Messenger", è una lettura interessante di come
si sentono centrati sull'utente lo sviluppo dovrebbe funzionare.
La discussione su CodingHorror di Jeff Atwood
su questo ha suggerito quattro modi in cui un simile fork potrebbe risultare. Ne ha tralasciato
uno molto importante:la possibilità che, dividendo gli
impegno della comunità, entrambi i fork muoiano, senza che nessuno dei due disponga di sufficienti
risorse per competere contro le alternative. Anche se Pidgin non è
ancora morto – è a una certa distanza da “scendere il sipario e si è unito
al coro invisibile” – sono meno importanti di quanto lo fossero
e tutta questa debacle non ha aiutato la loro causa. A partire da
Ubuntu 9.10, Canonical ha sostituito Pidgin come client IM principale
con la distribuzione Linux molto popolare. Invece hanno messo
GNOME Empatia al suo posto. Sarebbe successo lo stesso se la
comunità Pidgin non si fosse fratturata e non fosse stata associata a tali pessime
PR? Forse, ma questo di certo non ha aiutato il loro caso.
Che lo stesso tipo di user-ignorant
decisioni vengono prese riguardo a un popolare progetto GNOME come
gnome-terminal è divertente (rido piuttosto che piangere) dirigendosi verso
una situazione simile. Due mesi fa è stato annunciato che Ubuntu si stava
allontanandosi in modo significativo dall'utilizzo dell'intero stack software GNOME nella prossima versione. Annota con molta attenzione cosa è successo lì.
Mark Shuttleworth dice che hanno assunto designer professionisti dell'interfaccia utente, li hanno messi
al lavoro per capire che avrebbe funzionato meglio per l'esperienza dell'utente desktop
, quindi hanno presentato i risultati al Comunità GNOME.
Invece di accettare questo lavoro estremamente prezioso e ringraziare Canonical
per aver svolto quella ricerca, hanno rifiutato abbastanza idee fondamentali che
non era possibile una via di mezzo. Ubuntu si sta ora biforcando in grande
verso il progetto Unity, come l'unico percorso rimasto per "fare ciò che vogliono i nostri
utenti". Sulla base della mia interazione che ho avuto con gli sviluppatori di GNOME
nel corso degli anni da quando mi sono imbattuto in questo fastidio, la
reazione che Mark ha avuto non mi ha sorpreso per niente.
Siamo ancora al punto in cui non è
chiaro come finirà questa divisione Unity. Quello che mi aspetto è
che tutta questa faccenda porti anche a una sorta di doppia situazione di fallimento
. Ci saranno molti sviluppi duplicati che
da soli non producono nulla di utile all'inizio. Le versioni
iniziali avranno un terribile controllo di qualità:questa roba impiega
eternità per funzionare correttamente. E dividendo la base di sviluppatori, è
abbastanza possibile che nessuno dei due gruppi abbia abbastanza persone rimaste per finire
per fare un buon lavoro, lasciandoci tutti con più desktop Linux scadenti
opzioni (di nuovo) piuttosto che uno unificato, tutti sono in procinto di
migliorare. Speravo ormai che il modo in cui Nokia ha migliorato
la licenza di Qt potesse finalmente fare in modo che si consideri come eliminare
avere entrambi Qt + GNOME. Che invece Linux sia ancora in fase di sviluppo
progetto in cima al mix e lo chiami Unità di tutte le cose, è un
terribile scherzo.
Ma stavo parlando di database... una
delle cose interessanti di PostgreSQL è il numero di fork che ha
generato. La generosa licenza BSD aveva portato a molteplici
fork commerciali closed-source; Lavoravo in un'azienda che ne produceva
uno. Netezza è stata la prima di queste a trasformarsi in una seria
produzione commerciale. E il database Greenplum è stato recentemente
acquistato da EMC, è un prodotto di grande successo. Ciò che non
è successo è che nessuno dei fork open source è diventato un valido sostituto
per la distribuzione principale. A meno che tu non disponga di grandi
risorse che una grande azienda può mettere a disposizione dell'ingegneria, è
più facile convincere la comunità ad accettare le tue idee piuttosto che provare
e realizzare un'implementazione indipendente di loro. Comunità eterosessuale
PostgreSQL continua a essere la scelta giusta.
La comunità di PostgreSQL discute molto
ed è ostile verso molte cose che le persone chiedono; abbiamo anche una
elenco che non vogliamo fare.
Queste sono per la maggior parte cose che non sono tecnicamente
fattibili da costruire senza svantaggi che non sono sempre ovvi per
coloro che ne fanno richiesta. Se un utente fa un'argomentazione sul motivo per cui una modifica
renderebbe un'interfaccia utente migliore per qualcosa nel database e
non ci sono obiezioni tecniche sul motivo per cui causerebbe un problema,
viene considerato quel cambiamento. Quello che non ho mai visto nella community è
nessuno degli sviluppatori schierarsi contro un utente unanime e non ambiguo
preferenza, dove tale opzione potrebbe essere resa disponibile senza
inconvenienti, semplicemente perché non mi piace così Se sei uno
sviluppatore di un progetto open source che va dove l'arroganza ha
trombato così male l'umiltà, non sorprenderti se i tuoi utenti saranno
abbastanza arrabbiati da biforcare. E uno di questi giorni, potresti scoprire che
i fork o le re-implementazioni che prestano attenzione a ciò che le persone
vogliono veramente ti sposteranno.
