Enquanto o PostgreSQL Elephant continua
em sua marcha em direção a mais um lançamento, tenho pensado bastante
sobre o papel que os usuários de software devem ter na sua interface de usuário
design. Hoje eu propus algo que torna um parâmetro de banco de dados
com o que as pessoas costumavam se preocupar, e isso não era nada óbvio
como definir, e torna seu valor amplamente automático. Essa é uma mudança bem
inequívoca; os usuários ficaram irritados, bom comportamento padrão
estabelecido, e esse comportamento padrão sugerido como um patch. Se for aplicado, ficaria chocado ao encontrar alguém que considere isso uma má
decisão.
Houve uma discussão semelhante sobre
como retrabalhar a interface do usuário em torno dos pontos de verificação do banco de dados. Agora
a velocidade na qual os dados são gravados no disco por um ponto de verificação
é impactada por três valores que o usuário pode especificar. A interação
entre eles está bem documentada, embora de uma forma que
reflete a complexidade, e alguns usuários acham que o comportamento
que apresenta
desempenha bem. É bem possível que, para tornar as coisas
melhores para o usuário típico, haja uma regressão
de desempenho em alguns casos em relação ao código atual. O uso de uma
implementação diferente que altera a escala efetiva dos
parâmetros resultará em mudanças sutis de tempo e não serão necessariamente
todas positivas. Nessa situação, o melhor que podemos fazer
como comunidade de desenvolvimento é coletar dados de referência suficientes para
fazer essa chamada. Pode ser que melhorar os piores cenários
dessintonize ligeiramente as coisas em relação à implementação anterior. Se
o resultado final for mais fácil de ajustar – substituindo várias
configurações complicadas por uma única, como sugeri, pode ser
a direção certa aqui – em média, deve ser melhor. Em algumas
vezes é necessário deixar de lado a abordagem antiga para obter
uma que seja melhor.
Mas é com isso que nos preocupamos
com o comportamento que os usuários confiam. Há um grande foco na
compatibilidade com versões anteriores e apenas adicionar coisas de uma maneira que não
remova a abordagem antiga no desenvolvimento do PostgreSQL. Às vezes,
não há escolha:você precisa avançar em direção a uma nova abordagem. Nos casos
onde tanto o comportamento antigo quanto o novo são completamente legítimos, chegar
até mesmo a uma opinião clara da maioria é difícil. Esse é geralmente o
caso no design da interface do usuário. Embora você possa comparar isso com
ferramentas e profissionais certos, isso raramente é feito na
comunidade de código aberto. Obter um consenso da comunidade dessa mistura
de opiniões muito pessoais é difícil.
Lembrei-me novamente de como não
lidar com o feedback do usuário como desenvolvedor recebendo algumas atualizações hoje
sobre uma regressão longa e irritante na forma como o gnome- terminal, meu terminal de linha de comando preferencial
nominal, lida com a entrada do teclado. O problema
consolidou-se pela primeira vez em um relatório de bug quase exatamente dois anos atrás, em um
rastreador do Ubuntu, apenas para migrar para a
fonte subjacente da regressão:uma mudança intencional por um dos GNOME
desenvolvedores para eliminar o comportamento que consideraram inadequado. Houve um ticket aberto solicitando uma correção, mas nunca muito além de ser um insulto a todos os envolvidos.
Eu estive ativo o suficiente no histórico
do último bilhete que não preciso repetir meu argumento aqui.
Essencialmente, tudo o que eu queria era uma opção de configuração de check-box para
tornar possível o retorno ao comportamento antigo. Eu até comecei a trabalhar
para fazer exatamente isso, cavando no código para sugerir soluções alternativas,
apenas para perceber que não havia como isso ser mesclado. Minhas
sugestões foram focadas em tentar encontrar um terreno comum que agradasse
a todos. É muito claro que os desenvolvedores simplesmente não se importam
com isso. Eles estão fazendo as coisas do jeito que gostam, e
todo mundo não importa. Que me disseram que seriam necessárias “algumas centenas” de reclamações antes que isso fosse considerado importante
me confunde, considerando que o uso da chave de controle no terminal
não é exatamente a coisa mais popular . Foram dezenas de denúncias,
cada reclamação recebida foi unificada na resolução
preferida, e a única pessoa que discordou foi um de seus
desenvolvedores.
Recebemos algumas reclamações de pessoas de que
a comunidade PostgreSQL está cheia de desenvolvedores que preferem
soluções tecnicamente puras a apenas dar aos usuários o que eles querem.
Isso é verdade até certo ponto, como a resistência contínua em
adicionar mostrar tabelas como uma forma alternativa de encontrar
banco de dados em seu banco de dados. Mas toda essa discussão tem sido em tópicos
onde a discussão dá opiniões muito divergentes; muitas pessoas
têm opiniões fortes de ambos os lados. Se todos os usuários concordarem sobre um
design, que é o caso desse problema do gnome-terminal, rejeitar
essas opiniões como ainda não estarem corretas é o cúmulo da arrogância
do desenvolvedor.
Um dos exemplos mais interessantes
deste tipo de coisa envolve os desenvolvedores do software Pidgin IM
alterando como o dimensionamento do texto da janela de bate-papo funciona em seus programa.
Usuários revoltados. Há um bom exemplo do comportamento antigo e novo com algumas
análises no CodingHorror.
Todos ficaram impressionados com a forma como os
desenvolvedores pareciam ignorar seus comentários. A percepção deles era
que o feedback da comunidade era irrelevante para os desenvolvedores, porque
eles achavam que seu design era melhor do que o antigo, independentemente do que
os usuários pensassem. Alguém escreveu um plug-in para restaurar o comportamento
antigo. E então houve uma divisão oficial. A missão
declaração
do fork resultante, originalmente chamado de "Fun Pidgin" e agora
chamado de "Carrier Instant Messenger", é uma leitura interessante de como
eles se sentem centrados no usuário desenvolvimento deve funcionar.
A discussão sobre CodingHorror de Jeff Atwood
deste sugeriu quatro maneiras como tal bifurcação pode se tornar. Ele deixou de fora
uma muito importante:a possibilidade de que dividindo os esforços
comunitários, ambos os forks morreriam, sem que nenhum deles tivesse
recursos suficientes para competir com as alternativas. Embora Pidgin ainda não esteja
morto – está a alguma distância de “descer a cortina e se juntar ao
coro sangrento invisível”–eles são menos importantes do que
costumavam ser, e todo este desastre não ajudou a sua causa. A partir do
Ubuntu 9.10, a Canonical substituiu o Pidgin como o principal cliente de IM
enviado com essa distribuição Linux muito popular. Em vez disso, eles colocaram
GNOME Empathy em seu lugar. Isso ainda teria acontecido se a
comunidade do Pidgin não tivesse se fragmentado e se tornado associada a uma
RP tão ruim? Possivelmente, mas isso certamente não ajudou no caso deles.
Que o mesmo tipo de decisões
ignorantes pelo usuário estão sendo tomadas em relação a um projeto GNOME popular como
gnome-terminal é divertido (eu ri um pouco do que chorar) caminhando
para uma situação semelhante. Dois meses atrás, foi anunciado que o Ubuntu estava
se afastando significativamente do uso da pilha completa de software GNOME em seu próximo lançamento. Observe com muito cuidado o que aconteceu lá.
Mark Shuttleworth está dizendo que eles contrataram designers de interface do usuário profissionais, os colocaram
para trabalhar descobrindo que funcionaria melhor para a experiência do usuário
de desktop, então apresentaram os resultados ao Comunidade GNOME.
Em vez de aceitar este trabalho extremamente valioso e agradecer à Canonical
por fazer essa pesquisa, eles rejeitaram ideias fundamentais o suficiente para
não haver meio termo possível. O Ubuntu está agora avançando em um grande
caminho em direção ao projeto Unity, como o único caminho que resta para “fazer o que nossos
usuários querem”. Com base na minha própria interação que tive com os desenvolvedores
GNOME durante os anos desde que me deparei com esse aborrecimento, a
reação de Mark não me surpreendeu nem um pouco.
Ainda estamos no ponto em que não está
claro como essa divisão do Unity vai acabar. O que eu espero é
que tudo isso leve a uma espécie de falha dupla
também. Haverá um monte de desenvolvimento duplicado que
por si só não produz nada útil no início. Os lançamentos
iniciais terão um controle de qualidade terrível – essas coisas demoram
uma eternidade para ficarem certas. E dividindo a base de desenvolvedores, é
bastante possível que nenhum grupo tenha pessoas suficientes para acabar
fazendo um bom trabalho, deixando todos nós com várias opções de desktop Linux
pobres (novamente) em vez de um unificado, todos estão alinhados para
melhorar. Eu estava esperando agora que a forma como a Nokia vem melhorando
a licença para o Qt poderia finalmente considerar como eliminar
ter ambos Qt+GNOME. Que, em vez disso, o Linux ainda está desenvolvendo
projeto no topo da mistura, e nomeá-lo Unity de todas as coisas, é uma piada
terrível.
Mas eu estava falando sobre bancos de dados… uma
das coisas interessantes sobre o PostgreSQL é quantos forks ele
gerou. A generosa licença BSD levou a vários
forks comerciais de código fechado; Eu trabalhava em uma empresa que fazia
um. Netezza foi a primeira a se transformar em uma produção
comercial séria. E o banco de dados Greenplum foi recentemente
comprado pela EMC, é um produto de muito sucesso. O que não
aconteceu é que nenhum dos forks de código aberto se tornou substitutos viáveis
para a distribuição principal. A menos que você tenha o tipo de recursos
grandes que uma grande empresa pode trazer para a engenharia, é
mais fácil fazer a comunidade aceitar suas ideias do que tentar
e fazer uma implementação independente deles. Comunidade direta
PostgreSQL continua sendo a escolha certa.
A comunidade PostgreSQL discute muito,
e é hostil em relação a muitas coisas que as pessoas pedem; temos até uma
lista que não queremos fazer.
Essas são, na maioria das vezes, coisas que não são tecnicamente
viáveis de construir sem desvantagens que nem sempre são óbvias para
quem as solicita. Se um usuário argumentar por que uma alteração
traria uma interface de usuário melhor para algo no banco de dados e
não há objeções técnicas sobre o motivo pelo qual isso causará um problema,
essa alteração é considerada. O que eu nunca vi na comunidade é
qualquer um dos desenvolvedores se alinhando contra uma preferência unânime e inequívoca
do usuário - onde essa opção poderia ser disponibilizada sem
desvantagens - simplesmente porque eles não gosta assim. Se você é um
desenvolvedor de um projeto de código aberto vagando para onde a arrogância
superou a humildade, não se surpreenda se seus usuários
se irritarem o suficiente para fazer um fork. E um dia desses, você pode descobrir que
as bifurcações ou reimplementações que prestam atenção ao que as pessoas
realmente desejam irão deslocá-lo.
