Entradas con la etiqueta “Open Source”

Linus Torvalds, ‘Nobel’ de tecnología

21 de abril, 2012 - por | | Just for fun, Noticias

Linus Torvalds Nobel de tecnología

Acaban de concederle a Linus Torvalds el galardón que se conoce como ‘Nobel’ de tecnología. Lo otorga la Academia tecnológica de Finlandia a aquellas personas cuyo trabajo ha marcado de alguna forma la tecnología contemporánea.

Me alegra mucho el premio. Soy fan de Torvalds, así que cuando veo cualquier reconocimiento público hacia él, lo comparto totalmente y me hace muy feliz ver que otras personas reconocen en su trabajo cosas verdaderamente innovadoras, no siempre relacionadas con el código y el diseño de programas.

Torvalds ha conseguido liderar el mayor proyecto de código abierto, y al mismo tiempo iniciar otro que va camino de convertirse en algo tan estable y eficiente como el primero. Lo ha hecho siempre siguiendo principios sencillos y pragmáticos, y manteniendo un buen humor envidiable. Hay un montón de hilos de discusión con participaciones suyas que son ya literatura clásica del desarrollo del software, y que deberían enseñarse en las facultades de ingeniería (especialmente en metodología del software, donde se suele pecar de excesiva teoría). Su divertido libro Just for Fun debería ser libro de cabecera de cualquier persona que se dedique profesionalmente al mundo del software.

Torvalds es el gran maestro del siglo XX de cómo organizar, hacer productivos y eficientes programas de código abierto, dejando, a partir de ahí, que se generen las líneas de negocio oportunas. Al mismo tiempo ha conseguido crear ese espacio único, donde los desarrolladores crean por el simple gusto de crear y de divertirse, sin estar únicamente guiados por planes de negocio y objetivos de marketing.

Escribo ésto sobre WordPress, otro proyecto de código abierto de gran éxito, que ha conseguido convertirse en una herramienta diaria para un montón de gente. Linus es el padre espiritual de todo ese mundo de programas de código abierto, en constante evolución, y sobre los que se construyen en nuestros días la mayor parte de los proyectos.

Es mucho. Es un montón de diversión. Es la gran prueba de que las fuentes abiertas son el camino para solucionar los problemas.

¡Felicidades Linus! :)

Lecciones de bazaares

13 de noviembre, 2009 - por | | Open Source

En el libro de Eric Raymond, The Cathedral & the Bazaar, hay una parte que me gusta especialmente: aquélla en la que el autor reconoce cómo de chocante les resultó, incluso a los mismos que se encontraban ya en los círculos del desarrollo abierto entre los 80 y los 90, la forma en que el por entonces emergente linux se organizaba. Es donde mejor se aprecian las diferencias entre los 2 mundos que dan título al libro: la catedral que ellos conocían como forma de trabajar, relacionarse y construir, frente al bazaar linuxero lleno de novedades más sociales que técnicas.

Algunas de las que más me gustan:

  • no hay barreras de entrada, la contribución puede llegar de cualquiera en cualquier momento
  • los usuarios se transforman en co-desarrolladores
  • no tiene sentido no beneficiarse de una base cuanto más grande mejor de beta-testers y co-desarrolladores que a la postre se acaban convirtiendo en otras partes del proyecto
  • las fronteras tradicionales entre los profesionales/especialistas y los “otros” se diluyen

Las sensaciones que debieron tener todos aquellos grupos de ingenieros altamente especializados, que habían conseguido hacerse con un espacio propio donde ellos ponían las reglas y marcaban las distancias respecto de todo lo “externo”, seguro que fueron muy mezcladas. Otra vez, las batas se diluían, como habían hecho ellos a su vez con la generación anterior, para dar paso a una nueva forma de hacer las cosas que encima se demostraba productiva.

La evolución otra vez: les llegaba el turno esta vez a los barbudos que un día jubilaron a los encorbatados. Es algo que aún hoy no se ha acabado de asimilar, y todas las modas de palabras sobre redes sociales, web 2.0, etc. dicen mucho al respecto.

Entrevista a Linus Torvalds – Parte I (quinta entrega)

11 de marzo, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la cuarta entrega, ¿a qué esperas?.

Jim Zemlin: Una de las cosas de las que hablaste fue el incremento en la complejidad en la forma en que la interfaz interactúa con el núcleo y cómo los controladores del dispositivo son parte de ésta.

Yo me he preguntado muchas veces, algo que probablemente no te sorprenderá, ¿por qué no el núcleo tiene un controlador de dispositivo ABI estable?

Linus Torvalds: Bueno, la falta de una ABI tiene dos vertientes: una es que realmente, realmente, realmente no quiero una. Cada vez que la gente me pregunta por una ABI estable, creo que la razón principal para querer una ABI estable es que quieren tener su controladores binarios y que no quieren dar a conocer la fuente – no quieren fusionar su fuente con el Kernel o el núcleo estándar.

Esto, a su vez, significa que todas las personas que realmente trabajan en el Kernel no pueden, al mismo tiempo, trabajar con esa pieza de hardware y con los proveedores, ya que si hubiera cualquier error no podría arreglarlos.

Por lo tanto, todos los proveedores comerciales, incluso los que utilizan los controladores binarios, se están trasladando o alejando de los controladores binarios, ya que son completamente insostenibles.

Así que esta es una de las razones. Algunas personas creen que se trata de algo político. Y, probablemente, exista un aspecto político en esta decisión. Sin embargo, hay un aspecto mucho más pragmático y es que no se puede mantener.

Jim Zemlin: Esto suena como otro de esas cuestiones culturales por la que la gente parece apoyar los controladores binarios si hay beneficio sin entender, quizá, el beneficio de contribuir al soporte.

Linus Torvalds: Bueno, no se trata tanto del beneficio de la contribución al soporte como a la distribución del mismo. Quiero decir, puede que no termine teniendo el soporte de la mayoría de los dispositivos, pero acaba siendo el tipo de apoyo que necesito cuando tengo un gran problema.

Y cuando tienes ese tipo de sistema de apoyo distribuído – donde todo el mundo termina estando involucrado en algún momento -, no puedes darte el lujo de tener la situación en la que sólo unos pocos, de hecho, tienen acceso al código que puede estar causando el problema. Necesitas tener el código por ahí, no debido a cuestiones sociales, sino, simplemente, porque no sabes quién va a ser el que tiene que arreglarlo.

Así que hay una verdadera razón por la que necesitamos poder acceder al código fuente, lo que significa que para todos los desarrolladores del kernel, un interfaz binario es, básicamente, una mala cosa. No hay duda alguna.

Pero hay otra razón que es la que hace, realmente, que se desencadenen las cosas, de manera irremediable, en el interior del Kernel y que ha dado lugar al hecho de que, incluso aunque quisiéramos disponer de un interfaz binario, no podríamos. Y es que nos implicaría cambiar el cómo hacemos las cosas internamente.

Y esto es algo que ves en otros proyectos en los que, sí, tienen interfaces binarias por una u otra razón – muy a menudo debido a razones comerciales -. Esto significa que no pueden fijar un diseño fundamental. Ellos no sólo listan los interfaces binarios sino que también listan el diseño exacto tal y como se lo encontraron.

Además hay una segunda razón de peso por la que no se va a desarrollar una ABI estable; de hecho, significa que no garantizamos siquiera una API estable. Así, incluso a nivel de código fuente nosotros decimos: “Okay, este es el API, y si tú tienes drivers externos que la utilizan, te ayudaremos a corregirlos cuando tengamos que cambiar el API, pero no te garantizamos que el mismo API funcionará con todas las versiones”.

Fin de semana en el FOSDEM

11 de febrero, 2009 - por | 1 comentario | Open Source

Ya estamos de vuelta después de un ajetreado fin de semana en Bruselas. Que qué hacíamos allí. Pues además de pasar mucho frío, asistiendo al FOSDEM’09 (Conferencia Europea de Desarrolladores de Código Abierto y Libre) que este año se celebraba en la Universidad Libre de Bruselas.
Después de un largo paseo desde el aeropuerto de Charleroi hasta el norte de la capital belga, llegamos al pabellón central de la ULB donde se celebraba el evento. La multitud de gente que se concentraba en los pasillos del bloque H nos anunciaba que sería una experiencia super interesante tal y como intuíamos al ver el programa de charlas y talleres.
Pasillos repletos de gente
Con tanta cantidad de charlas al mismo tiempo nos costó decidirnos. Así que empezamos con KDE y seguimos con los desarrollos de embedded que nos resultaron muy interesantes y nos confirmaron en la idea de la necesidad de hacer desarrollos adaptados a cualquier dispositivo, ;-).
Aunque nos perdimos la fiesta de la cerveza del viernes que daba por inaugurada la sesión, pudimos difrutar de las hamburguesas con patatas fritas típicas de Bruselas en el Tropic Catering:
amburguesa y patatas fritas

Entrevista a Linus Torvalds – Parte I (cuarta entrega)

4 de febrero, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la tercera entrega, ¿a qué esperas?.

Jim Zemlin: Vamos a hablar un poco más sobre el aspecto técnico del Kernel. Al principio el Kernel de Linux se utilizaba, fundamentalmente, para servidores. Claramente, ahora se utiliza para ordenadores de sobremesa y, cada vez más, para dispositivos móviles y sistemas embebidos. ¿Qué impacto tiene ésto en el Kernel a nivel técnico?

Linus Torvalds: De hecho, se espera más de un impacto. Resulta que los dispositivos móviles han crecido tanto o incluso más que los teléfonos celulares. De media, el teléfono inteligente, probablemente, tenga más potencia que el primer escritorio que se utilizó para ejecutar Linux. Además, no parece que su potencia vaya a parar.

Por lo tanto, creo que sobre todo en lo que respecta al Kernel, la gente se preocupa más de lo necesario. Lo más importante con respecto a los móviles no tiene que ver con el kernel. Quieres dispositivos más pequeños y eficientes. Así que lo que más preocupa al usuario es, en realidad, la interfaz.

Es muy diferente la forma en que te conectas con un teléfono móvil a cómo lo haces desde tu escritorio. Tienes un teclado muy limitado; algunos dispositivos con pantalla táctil; la pantalla suele ser muy pequeña. Así que creo que la cuestión fundamental tiene que ver con las interfaces de usuario.

Por ejemplo, tienes Qtopia que parece tener gran relevancia en el entorno de los móviles. El kernel, sin embargo, nunca ha vivido eso. Puede ser que esté simplificando las cosas y esté aislando algunos temas. Porque es verdad que existen todos esos grupos del kernel móvil con los que no interactúo directamente. Aunque sospecho que toda esa gente se preocupa más del “user space” que del kernel.

Jim Zemlin: Bueno, vamos a hablar de esta segunda parte en la que comentas el hecho de que hay muchos grupos del kernel para móvil. Y sabes que una de las cosas por las que la gente dice que es la razón por la que participan en el proceso de desarrollo de Linux y el código abierto es porque se trata de un trabajo colectivo que reduce costes y que permite, realmente, trabajar juntos de manera efectiva.

Y dado que existen, como ya sabes, este tipo de grupos que se desprenden de la comunidad, ¿qué se puede hacer para mejorar las prácticas cuando pertenecen a compañías de dispositivos móviles?

Linus Torvalds: Creo que el gran problema en el mundo del móvil tiende a ser que todo el mercado está acostumbrado a estar completamente parcelado. Todo el mundo hace algo único, una parte del hardware. Lo que ha hecho que, durante los últimos años, se escriba de nuevo el código y se desarrollen generaciones de móviles completamente nuevas.

Así, se puede invertir mucho tiempo en una generación de hardware que queda pronto obsoleta y se tiende a empezar, básicamente, desde cero para crear una nueva.

Y cuando se trabaja con esa mentalidad, es muy difícil hacer entender el hecho de que se trabaje siguiendo un determinado proceso e intentando integrar los estándares del kernel y de todo el proceso anterior, ya que ellos nunca han trabajado de esta manera.

Así que lo que hacen, realmente, muchos de estos fabricantes de móviles es elegir una versión, por lo general eligen la más reciente y se dicen, “bueno, esta es la base”. Después, durante cinco a seis años se aferran a esta plataforma y la mejoran según sus propias necesidades.

Y luego, cuando quieren hacer una nueva versión o una nueva generación de hardware, se encuentran con que el resto del mundo ha estado trabajando el algo novedoso así que todas sus modificaciones son para una versión que se ha quedado casi obsoleta. Y así, acaban haciendo lo que ya habían hecho antes. Tiran su trabajo por completo y comienzan de nuevo.

Y esto no es algo en lo que no podemos ayudar. Creo que el mercado del móvil, en cierta medida, para crecer necesita modificar este mal comportamiento.

Jim Zemlin: De alguna manera se trata de una cuestión cultural, no desde la perspectiva históricas ni geográfica; más bien desde una perspectiva comercial.

Linus Torvalds: Sí. Es una cuestión que tiene que ver con cierta cultura tanto técnica como comercial.

Entrevista a Linus Torvalds – Parte I (tercera entrega)

16 de enero, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la primera y la segunda entrega, ¿a qué esperas?.

Jim Zemlin: Vamos a hablar sobre el proceso de desarrollo del kernel. Cómo es ahora y cómo ha cambiado a lo largo del tiempo. Tengo curiosidad en saber qué opinión te merece.

Hace algunos años se trataba de un proyecto divertido utilizado por unas pocas empresas y no estaba tan extendido como lo está hoy.

Ahora os habéis puesto en marcha con los dispositivos móviles, un campo de implementación enorme y especialmente crítico para las empresas interesadas en la industria; sólo esto supone una participación masiva desde un punto de vista comercial.

Si comparas entre ahora y entonces, ¿cómo ha cambiado el proceso de desarrollo? ¿Ha cambiado la gente? ¿Qué diferencias hay entre lo que se está haciendo y lo que se hacía, digamos, hace tres o cuatro años, cuando se encontraban en Transmeta?

Linus Torvalds: Yo creo que el proceso es, en gran parte, el mismo. Se ha producido algún cambio en los procesos y es de carácter puramente técnico en el sentido de que hemos hecho algunos más explícitos y existen herramientas que apoyan nuestra particular forma de hacer las cosas y que no existían de hace cinco a diez años.

Otra cosa que ha cambiado es que las personas involucradas están más implicadas y, quizás, son más conscientes de lo mucho que pueden fastidiar y el cuidado que tienen que tener – estoy pensando en mí en particular. Era, en cierta medida, más fácil hace diez años cuando podías decir, “- Ey, vamos a probar esto y si no funciona, no pasa nada.”

Ya no tenemos esa libertad; no podemos coger un código experimental completamente nuevo y decir: “- Ey, vamos a ver cómo funciona esto”.

Y como resultado, ahora tenemos múltiples capas de código que no van directamente en mi árbol. Si hay algo que es experimental se desarrolla en un árbol externo y, a continuación, se pasa a, por ejemplo, el árbol de Andrew Morton. Puede estar en su árbol un año hasta que se diga, “- Okey, todo funcionó en aquellos árboles. No se han hecho todas las pruebas porque aún no se ha estado en un árbol especializado, pero todo parece funcionar así que vamos a lanzarlo a un árbol principal”.

Así que hemos cambiado en esto. Muchas cosas han sucedido realmente porque se preveían los problemas. Así que se convirtió en una forma de trabajo. Estaba claro que mi árbol puede ser muy experimental lo cual, a su vez, motivó a otras personas a asumir el mando de otros árboles experimentales.

Jim Zemlin: En cierto modo lo que estás diciendo se parece mucho a cuando te casas para tener hijos y notas un aumento en el sentido de la responsabilidad.

Linus Torvalds: Cierto. Quiero decir que hasta cierto punto se trata de crecer y, sí, existen muchas similitudes aunque hay también muchas diferencias (risas), por lo que no sé si es del todo buena la analogía.

Jim Zemlin: No amas a la comunidad del Kernel, ¿verdad?

Linus Torvalds: Bueno, a algunas personas con las que trabajo, quiero decir, cuando se trabaja con personas durante cinco o diez años, quizá no las amas de esa manera pero, al menos, confías en ellos en un sentido muy real, a nivel personal.

Jim Zemlin: Una de las cosas que están pasando -para seguir hablando de la comunidad- es que Linux está empezando a ser más relevante en el mundo – ya sea por parte de los gobiernos que lo ven como una manera estratégica para crecer con la industria de software, como por los fabricantes de dispositivos móviles en Taipei, o (el proyecto) One Laptop Per Child, y otros.

Una de las cosas que la gente se pregunta es por qué no hay una participación en el proceso de desarrollo más global. En otras palabras, los observadores dicen que eso del kernel es muy de América del Norte o del centro de Europa.

Me interesa oir lo qué piensas: a) ¿por qué es así? y, b) ¿alguna idea sobre cómo podemos obtener más participación de gente de otros lugares.

Linus Torvalds: Bueno, hemos hecho algunos estudios, a lo largo de los últimos seis años para comprobar de dónde provienen los desarrolladores y una de las cosas más obvias es que no todos proceden de países muy poblados pero sí de países que tienen una mayor densidad de conexión a internet.

Quiero decir que puedes decir, con facilidad, que, sí, en China hay millones de personas, hay millones de personas en la India. Pero China e India no son representativas en la comunidad de desarrolladores.

Pero si realmente – en lugar de tener en cuenta únicamente el número de personas, tienes en cuenta el número de personas que tienen un buen acceso a Internet. China e India, simplemente, no son grandes en cuanto a la conectividad.

Jim Zemlin: Pero proporcionalmente, participan como mayoría o hay más…

Linus Torvalds: Hay otras muchas cuestiones y, claramente, la lengua y las barreras culturales son una de los grandes temas además de algo tan simple y evidente como la educación.

Así que las barreras lingüísticas tienden a ser un gran problema – bueno, en realidad, tal vez lo son más aún las diferencias culturales – para que tengamos a personas de los países asiáticos. En algunos de ellos Internet tienen gran presencia y educación, sin embargo, no contribuyen mucho al código abierto, ni al Kernel, ni a otros proyectos en general.

Y esto parece ser al menos en parte cultural y así es realmente difícil para personas con barreras culturales y lingüísticas participar activamente. Puede ocurrir. Pero seguramente esto explica muchas de las razones por las que Europa Occidental y los EE.UU. son los principales protagonistas en el área del desarrollo.

Jim Zemlin: Es algo en lo que la comunidad del núcleo del Kernel piensa. ¿Cómo podemos conseguir más gente implicada? ¿Cómo podemos hacer más fácil y más accesible la implicación de la gente?

Linus Torvalds: Aparece de vez en cuando. No creo que nadie sepa, realmente, la respuesta. Hemos añadido algunos documentos. Por lo general, del tipo “léame”: ¿dónde participar?, ¿cómo comportarse?; y que esté disponible en varios idiomas.

No sé si es la solución o no lo es. Sospecho que no. Pero también sospecho que puede hacer posible que más personas, al menos, echen un vistazo al proyecto. Tal vez las personas se asustan menos cuando pueden ver en qué consiste el proyecto en sí. Al menos, tratamos de acercarnos a ellos. Las personas en Asia podrían sentirse así, “Bueno, no estoy luchando por esto y puedo tener problemas” pero, por lo menos, pueden acceder a los conocimientos y desarrollarlos en cierta medida. Así pues, esta es una de las cosas que hemos estado viendo.

Con esto quiero decir que yo, realmente, creo que la barrera cultural es mayor que la barrera lingüística y la razón por la que digo esto es que, especialmente en América del Sur, la implicación en el proyecto ha sido alta, así que no se trata, necesariamente, en que todos hablen inglés. Creo que culturalmente están más cerca de Europa y de EE.UU., y es ésto lo que hace que nos sea más fácil entrar.

Por tanto – y como creo que se debe a diferencias culturales, no sabemos cómo enfocarlo.