A medida que PostgreSQL Elephant continúa
su marcha hacia otro lanzamiento, he estado pensando bastante
sobre el rol que los usuarios de software deberían tener en su interfaz de usuario
diseño. Hoy propuse algo que hace que un parámetro de la base de datos
la gente solía tener que preocuparse, y eso no era nada obvio
cómo configurarlo, y hace que su valor sea en gran medida automático. Ese es un cambio de avance bastante
inequívoco; los usuarios estaban molestos, se estableció un buen comportamiento predeterminado
y ese comportamiento predeterminado se sugirió como un parche. Si se aplica, me sorprendería encontrar a alguien que considere que es una mala
decisión.
Ha habido una discusión similar sobre
cómo modificar la interfaz de usuario en torno a los puntos de control de la base de datos. Justo
ahora, la velocidad a la que un punto de control escribe los datos en el disco
se ve afectada por tres valores que el usuario puede especificar. La interacción
entre estos está bastante bien documentada, aunque de una manera que
refleja la complejidad, y algunos usuarios encuentran que el comportamiento que proporciona
funciona bien. Es muy posible que para mejorar las cosas
para el usuario típico, haya una regresión de rendimiento
en algunos casos en relación con el código actual. Usar una
implementación diferente que cambie la escala efectiva de los
parámetros resultará en cambios de tiempo sutiles, y no
todos serán necesariamente positivos. En esta situación, lo mejor que podemos hacer
como comunidad de desarrollo es recopilar suficientes datos de referencia para hacer
esa llamada. Puede ser que mejorar los peores escenarios
desafina ligeramente las cosas en relación con la implementación anterior. Si
el resultado neto resulta ser más fácil de ajustar, reemplazando múltiples
configuraciones complicadas con una sola, como sugerí, podría ser la
dirección correcta aquí, en promedio, eso debería ser mejor. A veces
es necesario abandonar el antiguo enfoque para obtener
uno mejor.
Pero esto es lo mucho que nos preocupa
el comportamiento de ruptura en el que confían los usuarios. Hay un gran enfoque en
la compatibilidad con versiones anteriores y solo agregar cosas de una manera que no
elimine el antiguo enfoque en el desarrollo de PostgreSQL. Sin embargo, a veces
no hay elección:tienes que empujar hacia un nuevo enfoque. En los casos
en los que tanto el comportamiento antiguo como el nuevo son completamente legítimos,
alcanzar incluso una opinión mayoritaria clara es difícil. Ese suele ser el caso
en el diseño de la interfaz de usuario. Si bien puede comparar eso con las
herramientas y los profesionales correctos, rara vez se hace en la
comunidad de código abierto. Lograr un consenso comunitario a partir de esa mezcla
de opiniones muy personales es difícil.
Recordé nuevamente cómo no
manejar los comentarios de los usuarios como desarrollador al recibir algunas actualizaciones hoy
sobre una regresión largamente molesta en cómo gnome- terminal, mi terminal de línea de comandos nominal
preferido, maneja la entrada del teclado. El problema
se plasmó por primera vez en un informe de error hace casi exactamente dos años, en un
rastreador de Ubuntu, solo para migrar a la
fuente subyacente de la regresión:un cambio intencional por parte de uno de los usuarios de GNOME
desarrolladores para eliminar el comportamiento que encontraron inapropiado. Se abrió un ticket solicitando una solución, pero nunca más allá de ser insultante para todos los involucrados.
He estado lo suficientemente activo en el último
historial de boletos que no necesito repetir mi argumento aquí.
Esencialmente, todo lo que quería era una opción de configuración de casilla de verificación para
hacer posible volver al comportamiento anterior. Incluso comencé a trabajar
para hacer exactamente eso, profundizando en el código para sugerir soluciones,
solo para darme cuenta de que no había forma de que esto se fusionara alguna vez. Mis
sugerencias se centraron en tratar de encontrar un terreno común que
complacera a todos. Sin embargo, está muy claro que a los desarrolladores no les importa
eso. Están haciendo las cosas como les gusta, y
todos los demás no importan. Que me dijeron que tomaría "unos
algunos cientos" de quejas antes de que esto se considerara importante
me sorprende, considerando que el uso de la tecla de control en la terminal
no es exactamente lo más popular . Hubo decenas de denuncias,
todas las quejas recibidas se unificaron en la
resolución preferida, y la única persona que no estuvo de acuerdo fue uno de sus
desarrolladores.
Recibimos algunas quejas de personas que
la comunidad de PostgreSQL está llena de desarrolladores que prefieren
soluciones técnicamente puras en lugar de brindarles a los usuarios lo que desean.
Eso es cierto hasta cierto punto, como la continua resistencia a
agregar tablas de demostración como una forma alternativa de encontrar la base de datos
en su base de datos. Pero toda esa discusión ha sido sobre
temas en los que la discusión da opiniones muy encontradas; muchas personas
tienen fuertes opiniones en ambos lados. Si todos los usuarios están de acuerdo con un
diseño, como es el caso con este problema de la terminal gnome, rechazar
esas opiniones por no ser correctas es el colmo de la arrogancia del desarrollador
.
Uno de los ejemplos más interesantes de
este tipo de cosas implica que los desarrolladores del software Pidgin IM
cambien el modo en que funciona el tamaño del texto de la ventana de chat en sus programa.
Los usuarios se rebelaron. Hay un buen ejemplo del comportamiento antiguo y nuevo con algunos
análisis en CodingHorror.
Todos estaban molestos por la forma en que
los desarrolladores parecían ignorar sus comentarios. Su percepción era
que los comentarios de la comunidad eran irrelevantes para los desarrolladores, porque
sintieron que su diseño era mejor que el anterior, independientemente de
lo que pensaran los usuarios. Alguien escribió un complemento para restaurar el comportamiento anterior
. Y luego hubo una división oficial. La misión
declaración
de la bifurcación resultante, originalmente llamada "Fun Pidgin" y ahora
llamada "Carrier Instant Messenger", es una lectura interesante sobre cómo
se sienten centrados en el usuario el desarrollo debería funcionar.
La discusión de CodingHorror de Jeff Atwood
sobre esto sugirió cuatro formas en que podría resultar una bifurcación de este tipo. Dejó fuera
una muy importante:la posibilidad de que al repartirse los esfuerzos
de la comunidad, ambas bifurcaciones morirían, sin tener ninguna
recursos suficientes para competir contra las alternativas. Si bien Pidgin no
está muerto todavía, está a cierta distancia de "bajar la cortina y unirse
al coro invisible"—son menos importantes de lo que
solían ser, y Toda esta debacle no ayudó a su causa. A partir de
Ubuntu 9.10, Canonical reemplazó a Pidgin como el principal cliente de mensajería instantánea
que se incluye con esa popular distribución de Linux. En cambio, pusieron
GNOME Empathy en su lugar. ¿Habría sucedido eso si la comunidad pidgin no se hubiera fracturado y asociado con relaciones públicas tan malas
? Posiblemente, pero eso ciertamente no ayudó en su caso.
Que el mismo tipo de usuarios ignorantes
decisiones se tomen con respecto a un popular proyecto de GNOME como
gnome-terminal es divertido (me río bastante que llorar) dirigiéndose hacia
una situación similar. Hace dos meses se anunció que Ubuntu
se estaba alejando significativamente del uso de la pila completa de software GNOME en su próxima versión. Note con mucho cuidado lo que sucedió allí.
Mark Shuttleworth dice que contrataron a diseñadores de UI profesionales, los pusieron
a trabajar para averiguar si funcionaría mejor para la experiencia del usuario de escritorio
y luego presentaron los resultados al Comunidad GNOME.
En lugar de aceptar este trabajo extremadamente valioso y agradecer a Canonical
por hacer esa investigación, rechazaron suficientes ideas fundamentales de que
no había término medio posible. Ubuntu ahora se está bifurcando a lo grande
hacia el proyecto Unity, como el único camino que queda para "hacer lo que nuestros
usuarios quieren". Basado en mi propia interacción que he tenido con los desarrolladores de GNOME
durante los años desde que me encontré con esta molestia, la
reacción que tuvo Mark no me sorprende ni un poco.
Todavía estamos en el punto en el que no
está claro cómo terminará esta división de Unity. Lo que espero es
que todo esto conducirá a una especie de situación de doble fracaso
también. Habrá un montón de desarrollo duplicado que
no producirá nada útil por sí solo al principio. Los lanzamientos
iniciales tendrán un control de calidad terrible:estas cosas tardan
una eternidad en salir bien. Y al dividir la base de desarrolladores, es
muy posible que a ninguno de los dos grupos le queden suficientes personas para terminar
haciendo un buen trabajo, dejándonos a todos con múltiples opciones pobres de escritorio Linux
(nuevamente) en lugar de uno unificado, todos están alineados para
mejorar. Esperaba ahora que la forma en que Nokia ha estado mejorando
la licencia de Qt podría finalmente considerar cómo eliminar
tener Qt+GNOME. Que, en cambio, Linux esté obteniendo un proyecto de desarrollo
a la cabeza de la mezcla, y llamándolo Unidad de todas las cosas, es una
broma terrible.
Pero estaba hablando de bases de datos... una
de las cosas interesantes de PostgreSQL es cuántas bifurcaciones
ha generado. La generosa licencia BSD había dado lugar a múltiples
bifurcaciones comerciales de código cerrado; Solía trabajar en una empresa que fabricaba
uno. Netezza fue el primero de estos en convertirse finalmente en una producción comercial seria. Y la base de datos Greenplum fue recientemente
comprada por EMC, es un producto muy exitoso. Lo que no
sucedió es que ninguna de las bifurcaciones de código abierto se convierta en reemplazos viables
para la distribución principal. A menos que tenga el tipo de grandes
recursos que una empresa importante puede aportar a la ingeniería, es
más fácil lograr que la comunidad acepte sus ideas que intentar
y hacer una implementación independiente de ellos. Comunidad directa
PostgreSQL sigue siendo la elección correcta.
La comunidad de PostgreSQL discute mucho,
y es hostil hacia muchas cosas que pide la gente; incluso tenemos una
lista que no queremos hacer.
En su mayor parte, estas son cosas que simplemente no son técnicamente
factibles de construir sin desventajas que no siempre son obvias para
aquellos que las solicitan. Si un usuario argumenta por qué un cambio
haría una mejor interfaz de usuario para algo en la base de datos, y
no hay objeciones técnicas sobre por qué causará un problema,
>ese cambio es considerado. Lo que nunca he visto en la comunidad es
que los desarrolladores se alineen contra una preferencia de usuario unánime e inequívoca
donde esa opción podría estar disponible sin
inconvenientes—simplemente porque no me gusta de esa manera. Si eres un
desarrollador de un proyecto de código abierto que se dirige hacia el lugar donde la arrogancia
ha vencido tanto a la humildad, no te sorprendas si tus usuarios
se enfadarán lo suficiente como para hacer una bifurcación. Y uno de estos días, es posible que descubras que
las bifurcaciones o reimplementaciones que prestan atención a lo que la gente
realmente quiere te desplazarán.
