Qué debería hacer Canonical para mejorar su contribución al Software Libre

Esta es una traduccion realizada por MDK Trans del articulo de Adam Williamson:

http://www.happyassassin.net/2010/08/05/finishing-up-controversial-crap-week-what-canonical-ought-to...

5 de Agosto de 2010

Terminando la semana de basura controversial: Lo que Canonical debería hacer bien, sólo algo más que necesito sacar de mi sistema. =)

Edición: olvidé incluir la nota aclaratoria de costumbre: como es usual, esta es completamente mi opinión personal y de ninguna manera representa a Red Hat (o cualquier otro).

Segunda edición: Me han señalado algunas contribuciones de Canonical que, hasta cierto punto, cubren las áreas que he identificado. Pronto actualizaré el artículo mas extensivamente, pero por ahora, sólo tengan en mente que Canonical está actualmente activa en algunas áreas más de las que yo he identificado, y eso es ciertamente estupendo.

Leyendo los comentarios de mi artículo anterior, los artículos de Greg, y algunas de las respuestas a ambos, queda claro que muchos lectores no están exactamente seguros de que es lo que yo (y algunos otros en el debate) están sugiriendo. La capa superior del debate es bastante simple - Canonical está/no está contribuyendo a $FOO - pero creo que puede ayudar el pasar un poco mas de tiempo detallando las implicancias.

Una cosa que mucha de gente parece asumir es que ésto es alguna forma de celos o envidia - solo odiamos a Canonical porque están, de alguna manera, venciéndonos (donde "nosotros" es Red Hat o Fedora o cualquiera). Pero, realmente, eso no es todo. Red Hat y Fedora no compiten realmente con Canonical en su hogar - el escritorio de usuario final; el usuario objetivo de Fedora es de hecho diferente del que posee Ubuntu, y ellos pueden coexistir perfectamente felices. Sí, Canonical está iniciando movimientos hacia el mercado empresarial, pero son bastante tempranos. Novell es por lejos un competidor empresarial mas significante para Red Hat, y aún así nadie parece sugerir que el personal de RH está celoso de Novell (o vice versa), y las relaciones entre RH y Novell están bastante bien.

Así que no, no me estoy quejando porque odio a Canonical y quiero quitarle puntos o algo así. El punto es que Canonical se ha establecido a sí mismo como un gran jugador en el mundo F/OSS (Aplicaciones libres/de código abierto), y para hacer mejor el mundo F/OSS para todos en él - incluyendo a Canonical - es importante que todos contribuyan; no sólo para mercadeo o diseño UX o algo por el estilo, sino para la ingeniería fundamental. El argumento no es "¡Canonical no contribuye a $FOO así que son un montón de perdedores, na na na nah!", es "Canonical no contribuye a $FOO y sería mejor para todos si lo hicieran"-

Mírenlo de esta manera- (De nuevo, ésta es mi lectura personal de la situación, no es el evangelio oficial de Red Hat). Cuando Red Hat identifica que algo falta en el mundo F/OSS que va en la distribución que venderá servicios, ampliamente hablando, trabaja para asegurarse de que es resuelto. Usualmente, se traduce en "contratar a alguien para que lo escriba". Tomemos como ejemplo la virtualización. Era obvio que iba a ser una necesidad importante para las compañías que realmente utilizan productos Red Hat y compran servicios Red Hat, así que RH impulsó Xen. Cuando se hizo claro que Xen no estaba funcionando bien del todo, especialmente en términos de integración de kernel, RH compró Qumranet y financió el desarrollo de KVM. Es importante notar que el tema básico aquí es el interés propio. Existe un idealismo en cómo opera RH, definitivamente - existen muchas maneras en las que RH podría de manera perfectamente legal hacer muy complicado para otros tomar ventajas de nuestro trabajo, hacer mucho mas difícil para Unbreakable Linux o CentOS o Scientific Linux o cualquier otro que exista - pero no lo hace. Pero hasta donde la escritura del código concierne, en cierto modo, RH sería estúpido si no lo hiciera. *No* trabajar en una buena capa de virtualización, y apoyarse en la silla y esperar a que alguien más lo escriba de manera que RH pueda utilizar su trabajo, no funcionaría muy bien. Existen páginas y páginas de ejemplos de esto, pero la historia es simple: averiguar qué es lo que se necesita esté en RHEL, luego escribir el código, y contribuir correctamente.

Ésto es lo que Canonical necesita hacer - para el beneficio de todo el mundo F/OSS, sí, pero también para el beneficio de Canonical. Y *existen* maneras en las que ellos parecen entender esto. El ejemplo cardinal de una contribución significante de código de Canonical es upstart, y ese es uno legítimo. Es un proyecto de código abierto correctamente organizado que está financiado por Canonical pero acepta contribuciones de otros y trabaja genuinamente para ser integrado en otros proyectos, y ha sido un amplio éxito, con otras distros adoptándolo (aunque Fedora está actualmente planeando cambiar a systemd con F14, pero ese tipo de cosas suceden, no invalida el valor de upstart). Su trabajo de usabilidad (incluyendo trabajo en conceptos de escritorio de próxima generación como Unity) es, en efecto, un ejemplo de la misma manera correcta de pensar, aunque en algunas maneras lo han estado haciendo mal (ignorando estándares XDG en su nuevo sistema de notificación, por ejemplo, de manera que sólo funciona con aplicaciones que Canonical parcha personalizadamente en Ubuntu, y ellos tienen que entregar el sistema estándar de todas maneras para manejar aplicaciones que no han estado a la mano para ser parchadas aún; lo que no funciona bien desde ningún ángulo). Pero la idea en general es correcta - han identificado usabilidad como un área donde las mejoras serian un beneficio para el producto sobre el cual quieren vender servicios, así que están tratando de hacer ese trabajo, e - incluso no de manera óptima - están tratando de compartir ese trabajo. Así que, nuevamente, ésa es un área donde ampliamente lo han entendido bien.

Esos son todos los ejemplos que se me ocurren. EDITO: David Treumann marca correctamente a Simple Scan como otro buen proyecto de Canonical. Me encantaría ver a SS formar parte de la suite Gnome en el futuro. Mirando por ahí, veo que los desarrolladores de SS también se encuentran involucrados en un administrador de pantalla (seguramente necesitamos otro de esos...) y algo llamado Omsk que se encuentra listado como propietario. Huh. Nunca oí sobre eso. ¿Alguien más lo ha hecho? Miré un poco. Nada en Google. Pueden hallar esta misteriosa página en Launchpad: https://launchpad.net/omsk. Es un proyecto OEM de Canonical. Parece que mucha gente se encuentra involucrada. No hay código que se pueda ver. A juzgar por un par de bugs marcados como que lo afectan, parecería ser alguna clase de variante personalizada de Ubuntu, secreta y para OEMs. Curioso... Así que algunas sugerencias: estas son algunas de las cosas que serían mejor para todos, incluida Canonical, para levantarse y contribuir.

1. Audio. Gracias a Lennart Poettering por señalarme esto. El sonido es uno de los puntos fundamentales en casi cualquier escritorio para consumidor. La mayoría de los usuarios de escritorio no utilizarían una computadora que no reproduce sonidos o que tiene problemas para hacerlo. Aún así, el audio en Linux es "masivamente" insuficiente. Lennart dice que hay tres personas en todo el mundo a quienes se les paga por el audio en Linux -seguramente hay otros Lennart y yo no lo sé o me estoy olvidando, pero seguro que no son muchos. Red Hat contrata a Lennart para escribir PulseAudio (aunque además hace otras cosas también) y a Jaroslav Kysela para trabajar en ALSA. Novel le paga a Takashi Iwai para trabajar, en parte, en ALSA (aunque esto no es un trabajo de tiempo completo). Canonical no le paga a nadie para trabajar en esta área. Es casi irónico -Novel y Red Hat podrían hacer frente mucho mejor a un mundo en el cual el audio de Linux estuviera completamente descuidado de lo que Canonical lo haría. Yo no vendo RHEL así que no soy el mejor informado al respecto, pero sospecho que que a la vasta mayoría de los consumidores de Red Hat y Novell les importa un bledo si sus servidores pueden reproducir Lady Gaga o no. Pero los usuarios de Canonical son más del tipo de los que deberían preocuparse al respecto de la funcionalidad del audio. Así que, ¿por qué RH y Novell se encuentran dando soporte a esta área vital de infraestructura -aún cuando no les es necesario- y Canonical no hace absolutamente nada? Sería de ayuda para todos, pero más para Canonical, si Canonical pudiera tomar dos o tres personas que puedan trabajar en el kernel y en el procesamiento de señales y pagarles para trabajar tiempo completo en ALSA y PulseAudio, y en la integración del sonido en el escritorio. Diablos, puedo sugerir a una persona para comenzar (no sé si se encuentra disponible para tomar un empleo con Canonical)- Colin Guthrie, quien ha estado contribuyendo en PulseAudio desde hace un tiempo.

EDICIÓN: Colin y también Daniel Chen me hicieron notar que en efecto existe un par de desarrolladores de Canonical trabajando en audio, algo que no encontré mientras estuve buscando cosas para este artículo. :) Estoy mirando esto más de cerca para reescribir la sección de arriba, pero por ahora, por favor noten que Canonical sí parece estar haciendo esfuerzos en esta área, lo que es muy bueno.

2. Gráficos. La misma historia que en audio. Red Hat y Novell dan empleo a importantes contribuyentes hacia arriba de la cadena de X.org. Intel paga a gente para trabajar en los controladores de Intel. AMD tiene algunas personas contratadas que contribuyen al trabajo del controlador de ATI. Heck, Mandriva tiene/tuvo pcpa en su personal (no estoy seguro de si el sigue allí) y él trató de asegurarse de tener algún tiempo libre para propagar su trabajo hacia arriba. Canonical tiene un desarrollador X en su personal (Bryce Harrington), y él no tiene tiempo para contribuir hacia arriba en la cadena; él simplemente trabaja a tiempo completo empaquetando X para Ubuntu y administrando reportes de errores. Nuevamente, la misma historia que en audio: Canonical es la que más pierde si el desarrollo de gráficos es descuidado. De nuevo, muchos de los clientes de Red Hat y Novell probablemente podrían operar con VESA sin perder mucho realmente; los usuarios de Canonical son quienes necesitan controladores con una apropiada aceleración 3D y soporte para aceleración de reproducción de video. Así que ¿por qué Canonical no contribuye a este desarrollo? ¿por qué confiarían un componente vital de su producto a gente que trabaja por otras compañías, o voluntarios, y no tomar parte en el desarrollo de X para nada? ¿cómo puede esto ser bueno para ellos en el largo plazo? Existe una gran cantidad de gente calificada que Canonical podría contratar ahí.

3. Red. Empiezo a sonar como disco rayado, pero de todas maneras ésta es un área que es mas vital para Canonical que para otras compañías,
y aún así Canonical es la que menos contribuye. De manera tristemente famosa, Canonical no tiene ningún contribuyente importante para el kernel, donde viven los controladores de red; Red Hat y Novell emplean a desarrolladores del kernel (no estoy seguro de si Novell tiene desarrolladores de controladores de red, pero Red Hat tiene al menos a David Miller, quien está a cargo de la pila de red, y John Linville, quien está a cargo de la pila inalámbrica). Red Hat paga a Dan Williams para ejecutar y escribir la mayor parte del código para el proyecto NetworkManager (el cual usa Ubuntu). Canonical... bien, todo lo que puedo encontrar es un conjunto de commits para NetworkManager de Octubre de 2008 de un tipo llamado Alexander Sack. Nuevamente, ésta es un área que podría decirse es mas importante para Canonical que nadie más, al menos en partes. Probablemente los mayores clientes de Red Hat y Novell usan ethernet principalmente, la cual es un área bastante estática y no requiere mucho trabajo de código; un nuevo controlador de cuando en cuando para un nuevo chipset, pero existen mucho menos chipsets ethernet que chipsets wifi, y los fabricantes a menudo proveen los controladores en estos días. Las áreas de red que realmente necesitan desarrollo son, de nuevo, las enfocadas en consumidores: wifi y banda ancha móvil. Éstas son cosas que los usuarios de Ubuntu realmente quieren que funcionen; la red wifi es uno de los golpes clásicos contra el escritorio Linux, la banda ancha móvil está creciendo y llegando. Nuevamente, no es el personal de Canonical quien hace el trabajo aquí. Dan Williams ha hecho la mayor parte del trabajo de implementación el soporte de banda ancha móvil en NetworkManager; las cosas a nivel de kernel para banda ancha móvil y wifi son hechas por un grupo de personas de un grupo de compañías, pero Canonical no se involucra. Nuevamente, ¿porqué Canonical no está contribuyendo en esta área que es tan vital para sus intereses? ¿Por qué no pueden contratar a tres o cuatro ingenieros que contribuyan a escribir controladores para nuevo hardware de red y ayudar a mejorar NetworkManager? Nuevamente, les ayudaría a ellos más que a cualquier otro.

4. Aplicaciones de escritorio. Aquí es un poco diferente, ya que cualquiera podría mejorar mucho aquí. Los otros grandes vendedores no hacen un enorme trabajo para trabajar en las aplicaciones típicas, que no son de infraestructura. Las grandes como Firefox y OpenOffice.org son principalmente apoyadas por vendedores no-Linux, aplicaciones pequeñas tienden a ser escritas por pequeñas compañías, desarrolladores independientes, o incluso personal de un vendedor de Linux trabajando en su propio tiempo. Existen importantes excepciones - Novell paga a gente para trabajar en Banshee, OpenOffice y Evolution (de hecho, Novell probablemente hace más que nadie mas en esta área), Red Hat apoya el desarrollo de Totem y Rhythmbox en cierto grado, y tiene uno o dos más trabajando en ésta área (RH tiene a un desarrollador de Evolution en su personal, creo, probablemente algunos mas que olvido en este momento). Pero realmente, la historia de vendedores importantes apoyando el desarrollo de aplicaciones de escritorio de Linux es bastante mala, y aún así, es Canonical la que más pierde. Aún así, los clientes de RH y Novell se las pueden arreglar sin estas cosas; los usuarios de Canonical de verdad no pueden. Así, se darán cuenta de que me concentro en los grandes golpes clásicos contra el escritorio de Linux aquí, y éste es uno de los mas grandes. A través de los años hemos escuchado que faltan grandes aplicaciones. En estos días, las que siempre son sacadas a flote son edición de gráficos y edición de video, y hay mucho de verdad en ello. GIMP es bueno pero le faltan cosas de las que dependen los usuarios Photoshop; y nuestra historia en edición de video es terrible.

Quizás el mejor contraste aquí no es uno de los otros vendedores de Linux, sino Apple. Apple se dio cuenta al principio de la era OS X que proveer aplicaciones de escritorio que la gente quiere usar de verdad es una buena manera de vender tu escritorio. Apple desarrolla y soporta el desarrollo de muchas de las mejores aplicaciones para OS X, y las entrega con OS X - el mejor ejemplo es Garage Band - o las vende relativamente baratas. Así que, ¿por qué Canonical no hace esto? Canonical necesita que el escritorio de Linux sea una opción atractiva para que su modelo de negocios de venta de servicios para los usuarios de escritorio de Linux funcione; claro, no hará dinero de manera directa al auspiciar el desarrollo de un editor de video de código abierto que patee traseros, pero _necesita que exista_ un editor de video de código abierto que patee traseros para que su plan de hacer dinero realmente funcione. Éste es el salto conceptual que Canonical necesita hacer más a menudo, a fin de cuentas. Red Hat no necesita hacer dinero directamente auspiciando el desarrollo de partes del kernel de Linux, pero necesita que exista el desarrollo para que su plan de negocios funcione. Canonical necesita salir, encontrar gente trabajando en lapsos de tiempo libre en aplicaciones de escritorio prometedoras pero fundamentalmente incompletas o rotas, contratarlos y pulir esas cosas hasta que brillen. Salir y encontrar el mejor intento de editor de video para Linux, contratar a los cinco desarrolladores mas importantes, darles una oficina y dejarlos desarrollar el proyecto - no en secreto en Launchpad, sino justo en la página existente del proyecto. Al final, mientras Ubuntu sea la distro líder en escritorio Linux, finalmente va a ser Ubuntu la que vea el beneficio más que cualquier otro, incluso si todos los demás llegan a utilizarlo. Encontrar a los cinco desarrolladores mas importantes de GIMP, contratarlos, ir y hacer una encuesta a los usuarios de Photoshop y averiguar qué es lo que necesitan en un editor de fotos de código abierto, y dárselos. Contratar a los contribuyentes mas importantes de Audacity, Jack, Hydrogen, Rosegarden y todo el revoltijo de aplicaciones e infraestructuras de creación de audio de Linux que están desconectadas, juntarlos en una oficina y construir una suite de creación de audio de puta madre. Sólo salir y leer aquellos artículos acerca de las aplicaciones de escritorio claves que Linux echa en falta, y contratar gente para escribirlas. No es ciencia de cohetes, y al final, es interés propio más que nada. Pero es lo correcto para Canonical y lo correcto para el resto del mundo F/OSS.

El presidente de los EEUU dijo algo acerca de lápiz labial y cerdos que se hizo famoso. Sí, los pasos de Canonical en trabajos de usabilidad e interfaz son importantes, pero la más linda interfaz en el mundo hacia un sistema operativo de escritorio no es suficiente si el soporte al hardware subyacente no existe, o las aplicaciones que la gente necesita ejecutar no están disponibles. Es Canonical quien necesita que estas cosas existan, mas que nadie mas; así que ¿por qué no querría Canonical ser quienes las hagan? Esperando que otras compañías o voluntarios las escriban por tí no es el mejor plan, de verdad que no lo es.

Hay cosas que los novatos no saben, no se puede tapar el sol con el dedo.