Retos para el software libre en latinoamérica

Vladimir di Fiore de SOLAR Argentina y Carolina Flores de Software Libre Centroamérica estamos promoviendo una cyber-tertulia llamada: “Retos para el software libre en la actualidad”.

¿De qué queremos hablar?

En principio, nos gustaría conversar sobre el crecimiento del software libre en nuestros países, si somos consumidores o gestores, si la libertad de software se ha visto afectada por el auge del software libre a nivel mundial, cuáles proyectos son estratégicos para la región, entre otros.

Todos los temas serán bienvenidos y esperamos que llegue gente de todos los países de América Latina. Ayúdennos a difundir.


Canal IRC: #sl-centroamerica en freenode
Jueves 8 de marzo
18:30 México y Centroamérica GMT-6
19:30 Panamá GMT-5
21:30 Argentina GMT-3

¿Qué son las CyberTertulias?

Hace unos meses, David Narváez escribió a la lista de Software Libre Centroamérica para proponer las CyberTertulias: reuniones informales en el canal de IRC para tratar “temas que atañen al Software Libre desde el punto de vista del hacktivismo, y están por lo tanto enfocadas al impacto social de este movimiento. En otras palabras, aquí no enseñamos cómo configurar Compiz :)”. Las reuniones están motivadas porque “la comunidad de Software Libre Centroamérica se encuentra dispersa en una amplia región geográfica con poca facilidad de movilización (comparada con otras regiones como Europa) y es, por lo tanto, difícil tener encuentros presenciales donde discutir temáticas que afectan al activismo en Software Libre. Estas reuniones buscan promover el intercambio de opiniones e ideas entre los miembros de SLCA que tienen mayor interés y conocimiento acerca de los aspectos sociales y técnicos del Software Libre, y a la vez permitir que más miembros puedan conocer acerca de estos temas y aportar sus puntos de vista. Son, por lo tanto, reuniones de carácter estratégico y didáctico al mismo tiempo”.

Ya se han realizado varias pero no he podido participar más que en “la sobremesa” sobre ACTA, por el horario de mis clases. Ahora, hemos planeado una tertulia para jueves y ahí estaremos 🙂

Dennis Ritchie: Uno de los grandes de la “Primavera Nerd”

Esta es la traducción que hice del post que Rob Pike colocó en su Google+. Rob Pike (guardando las proporciones con Ritchie) es también un importante gestor de lo que hoy disfrutamos en la computación y actualmente trabaja en Google.

Aún no me ha dado permiso de poner el post pero asumo que no habrá problema. Si me pide quitarlo pues… tristemente lo quitaré.

…………………………………………………

Rob Pike  –  Ayer a la(s) 17:49  –  Público

Fui sorprendido al ver cuántas personas respondieron a mi post en Google sobre la reciente muerte de Dennis Ritchie. Su influencia en la comunidad técnica fue vasta y es gratificante ver que es reconocida. Cuando Steve Jobs murió hubo un lamento muy amplio -y bien merecido fue- pero es válido hacer notar que el resurgimiento de Apple dependió en grande del trabajo de Dennis con C y Unix.

El lenguaje de programación C es muy viejo ahora, pero sigue activo y aún es muy utilizado. Los kernels [núcleos del sistema] de UNIX y LINUX (el de MacOS y pienso que incluso el de Windows) son todos programas en C. Los navegadores de Internet y los servidores más importantes están en C o C++ y casi todo el resto de los ecosistemas de la Internet están en C o en un lenguaje dervado (C++, Java), o en un lenguaje cuya implementación está en C o en un lenguaje derivado (Python, Ruby, etc.). C es también un lenguaje común de implementación para firmware de redes. Y así sucesivamente.

Y todo eso, sólo en cuanto a C.

Dennis también fue la mitad del equipo que creó Unix ( la otra mitad fue Ken Thompson), que de una forma u otra (yo incluyo a Linux) corre en todas las máquinas de los datacenters de Google y probablemente en la mayoría de las granjas de servidores. La mayor parte de los servidores corre sobre kernels Unix; la mayoría de los navegadores web que no son de Micrsosoft corren sobre kernels Unix de alguna manera, incluso muchos teléfonos.

Y hablando de teléfonos, el software que hace correr la red telefónica está escrita mayormente en C.

Pero esperen, hay más.

A finales de los años 70. Dennis se unió a Steve Johnson para migrar Unix a la Interdata. Fuera de contexto es difícil ver cuán radical era la idea de un sistema operativo que se pudiera migrar o mover; en ese tiempo los sistemas operativos se escribían mayoritariamente en lenguaje de ensamblador y estaban firmemente empotrados a marcas específicas de computadoras, tanto en lo técnico como lo mercadológico. Unix, por su inusual posición (aunque no era el único) de ser escrito en un lenguaje de alto nivel, podría correrse en una máquina que no fuera la PDP-11. Dennis y Steve dimensionaron la oportunidad y para inicios de los años 80, Unix había sido migrado por la comunidad de código abierto -la cual aún no se llamaba así- a esencialmente cualquier minicomputadora existente. Eso significó que si yo escribí mi programa en C, éste podia correr en casi cualquier minicomputadora. De repente, la pareja entre el hardware y el sistema operativo se había roto. Unix fue el gran ecualizador, la fuerza que empujó la Primavera Nerd que liberó el programar de las garras de los fabricantes de hardware.

El hardware ya no importaba más, desde que todos corrían Unix. Y como no tenía importancia, el hardware compitió por su dominancia contra otro hardware; el software se daba por sentado. Windows obviamente jugó un papel en el surgimiento de x86, pero la gente de Unix sólo aprovecharon eso. El hardware barato significó instalacones baratas de Unix; todos ganamos. Todo ese desarrollo en red que inició a mediados de los 80 sucedió con Unix, porque ese fue el ambiente en el que se hiceron las cosas que eran realmente importantes. Si Unix no se hubiera migrado a la Interdata, la Internet, si es que hubiera siquiera existido, hoy sería un lugar muy distinto.

Leí en un obituario de Steve Jobs que Tim Berners-Lee hizo el primer desarrollo de la WWW en una NeXT box, creada por la compañía que Job tenía en aquel tiempo. Bueno, ustedes saben cuál sistema operativo corría en las NeXT y cuál lenguaje.

Aún a su manera modesta, creo que Dennis estaba muy orgulloso de su legado. Y con toda razón: pocos logran siquiera una fracción de todo eso.

Hasta pronto, Dennis, y gracias por toda la magia.

Nota: La licencia CC con la que comparto este blog no cubre los posts traducidos. Para conocer la licencia que el autor prefiere deben dirigirse directamente a él.

La motivación es el alimento del Software Libre

Como parte del proyecto que coordino para la Universidad Nacional en alianza con el Programa de Naciones Unidas para el Desarrollo y el Ministerio de Economía, el jueves 28 de abril celebramos por fin el evento EXPOSOL: Soluciones en Software Libre y Open Source, donde más de 15 empresas pudieron mostrar su catálogo de productos y servicios basados en software de código abierto. Esto se complementó con conferencias y experiencias, como la charla de Paul Frields de RedHat que dejó a más de uno preguntándose qué tienen que ver las comunidades con la innovación. Espero que pronto entiendan la relación (las presentaciones de las charlas se pueden descargar de aquí).

Nos ha tomado más de un año organizar el evento. En un principio, porque el manejo de los fondos y la tramitología que el proyecto exige no nos permite obtener los resultados de forma tan ágil como quisiéramos. Pero también, el proceso con las empresas no estaba lo suficientemente maduro. Ha sido pues, una buena casualidad, que hayamos retrasado EXPOSOL hasta este momento.

La idea original ya había surgido en una conversación previa a mi rol como coordinadora del proyecto. En aquel momento varias personas de empresas proveedoras de servicios basados en Software Libre y yo, habíamos imaginado un evento donde se pudiera evidenciar que en el país hay suficientes empresas capaces de responder a las necesidades del mercado y que esas empresas trabajan con seriedad. Existe en el imaginario colectivo la idea de que el Software Libre es cosa de locos idealistas hippies y que si contrato una empresa que administre mis servidores “linux” el día que fallen -bah, eso casi nunca pasa pero es la costumbre- los empleados de la empresa estarán en el Caribe tomándose unas piñas coladas… es la idea de que detrás de una corbata está el conocimiento y que detrás de un bigote está la experiencia que me da confianza…

Y bueno. Resulta que hay empresas en Costa Rica que basan su oferta de servicios en Software Libre y no son 10 ni 15, son más de 35. Algunas de ellas, son empresas de renombre con más de 15 años de experiencia que hasta ahora se atreven a admitirlo porque en estos tiempos, los clientes empiezan a pedir Software Libre y tener experiencia en aplicaciones de Open Source es una ventaja competitiva, no algo que se deba esconder como hacían antes. Otras, son empresas de jóvenes emprendedores que se han atrevido a crear opciones a partir de lo que mejor saben hacer. Pocas, pero muy valiosas, son las que tienen relación directa con las comunidades de software libre y varias de ellas estarán integrando un capítulo de Software Libre dentro de la Cámara de Tecnologías de Información y Comunicación (CAMTIC), órgano que agrupa a la mayoría de empresas de TI ene l país y que por largo tiempo se ha mirado como lejana al Software Libre.

Habría mucho para decir. Algunas empresas siguen usando corbatas, por ejemplo. Los clientes siguen esperando corbatas, lamentablemente. Otras, usan camiseta y pelo largo y eso no ha restado a su credibilidad. ¿Qué importa el tema de las corbatas? Pues no sé. A mi forma de ver, el rechazo al Software Libre tiene que ver también con que es gente joven la que casi siempre está implementando sus soluciones y nuestra sociedad sigue relacionando la juventud con la informalidad y la falta de compromiso (¡menudo error!). También tiene que ver con que el mercado sigue casado con la idea de que necesita una empresa enorme que le dé respaldo (¡en buena hora que existe RedHat también!). Entonces, lo bueno está en la variedad pero aún queda mucho trabajo por hacer. Las empresas que están vendiendo servicios aprovechando las soluciones que el Software Libre ofrece, deben comprender que la motivación no es un recurso inagotable y que el desarrollo de Software Libre depende de ese componente. Si no se nutre la tierra donde crece, si no se contribuye en retribución (que no siempre es económica) y si no se trabaja fortaleciendo los proyectos de desarrollo y difusión, el Software Libre se concibe como materia prima gratis y eso no es sustentable. Esa es la tarea que sigue, porque por cada batalla que ganamos, surge un nuevo reto. Y en eso estamos.

Firefox 4: mi feedback

Técnicamente no puedo opinar demasiado sobre el Firefox 4 en su versión Beta. Puedo decir que es rapidísimo. De sus otras ventajas aún no he podido disfrutar.

Pero quiero opinar sobre la experiencia como usuaria en el siguiente escenario:

1. Cuando yo toco el botón derecho del mouse en los navegadores que uso (Firefox 3.6, Iceweasel, Epiphany) la opción que aparece de primero es abrir el enlace sustituyendo la página actual y en segundo lugar, abrir el enlace en otra pestaña. La opción de abrir en otra ventana aparece en tercer lugar. En Firefox 4, se ha eliminado la opción 1 y eso hace que continuamente abra una nueva ventana en lugar de una nueva pestaña.

2. Me dirijo entonces a hacer lo que se supone es mi contribución como usuaria: opinar sobre eso para que el equipo desarrollador valore si debe cambiar o no. ¿Cómo hacerlo? Ni idea.

3. Acudo al menú que dice “Help” y me encuentro con una opción que dice “Submit Feedback”. En mi experiencia, enviar retroalimentación es decir qué me parece algo y eso puede se tanto para agradecer o felicitar, como para reportar algo como lo del menú ligado al botón derecho ¿no?

4. El problema, es que cuando pulso para dar retroalimentación aparece una página con este mensaje:

y un espacio de una línea donde caben 140 caracteres. ¡140 caracteres para dar mi mensaje!. Probemos:

Menú botón derecho eliminaron opción 1 confunde usuario abre ventana nueva molesto

me quedan 58 caracteres… pero no es suficiente para que yo tenga una experiencia agradable y sienta que mi retroalimentación es bienvenida. ¿Debería serlo? Tal vez no. Puede que sea un caso de una usuaria equivocando la función de la opción de “send feedback”.

Pero me quedan muchas dudas: ¿por qué el feedback debería ser triste? ¿quién dice que he tenido una mala experiencia con mi navegador? ¿por qué culpabilizar a la persona usuaria y hacer que se arrepienta de comunicarse con quienes pueden mejorar su navegador?

Me encantaría sugerir cosas a quienes se ocupen de eso en Mozilla. De verdad. Creo que es parte de lo que debemos mejorar en todos los proyectos de desarrollo. Necesitamos que las personas usuarias sientan la diferencia entre ser usadas por su software y usar un software que responde a sus necesidades.

¿Qué tal algo como esto?

(ninguna cara, ni feliz ni triste…)

El equipo que construye tu navegador estará agradecido de recibir tus comentarios. Queremos mejorar tu experiencia. Por favor envíanos tu reporte.

Acompañado de una encuesta muy básica que permita reportar algo de forma ágil, útil y esperanzadora. *** Por cierto, el mensaje en inglés es peor que en español porque dice “nuestro navegador” y no “tu navegador” como debería ser.

Ojalá este mensaje llegue a alguien que pueda tocar la puerta correcta en Mozilla. Tal vez, este feedback les sea útil.

PD: Aprovecho para recomendar Limesurvey para las encuestas. Es libre, excelente y mucho mejor que los formularios comunes. El formulario acerca de cuántos navegadores uso y otros temas, no ocultaba las preguntas que no me correspondía responder a partir de las respuestas ya dadas. Eso con Limesurvey sería mucho más elegante y agradable.

Lo bugs que sí y los bugs que no

Leí un correo de Ian Jackson en el que se refería específicamente al error de pensar que todas las personas pueden y deben reportar bugs. Me gustaría traducirlo completo pero ahora mismo no puedo. En resumen, más o menos planteaba -con más sinceridad de la que mucha gente agradece- que para el caso de Debian, si un desarrollador debe gastar dos de sus cuatro horas diarias de programación para responderle a personas usuarias que reportan bugs que en su mayoría, son errores de procedimiento… eso no es beneficioso para el proyecto debian. Para él, “mimar” a las personas usuarias de esa manera no contribuye en nada. Habla de varias falacias muy interesantes y si leen inglés, por favor revisen el correo antes de seguir leyendo aquí (que mi resumen es muy pobre, la verdad).

Aunque puede parecer chocante… la verdad sea dicha: tiene razón. Tiene razón cuando hablamos de proyectos de desarrollo de un sistema operativo o aplicaciones horizontales. Todos los desarrolladores saben cómo debe comportarse un sistema operativo. Es decir, en la mayoría de los casos, los reportes no le dirán nada nuevo y si no los hacen personas con suficientes conocimientos, no contribuirán en mucho a encontrar la solución. –> Hace un año me hubiera pegado por la mano por escribir una cosa así.

¿En dónde sí vale la pena reportar bugs?

No sé… imagino que en desarrollos como Gimp o aplicaciones para sectores u ocupaciones específicas. Ahí sí los desarrolladores no saben qué es lo que se espera del programa (supongo) y ¿se necesita de mucha guía de personas usuarias que sí saben qué es lo que el programa debe hacer o cómo, lo que imaginan, no puede ser implementado a partir de la herramienta?

¿Y entonces, cómo mejoramos el software?

También, es importante reportar el otro tipo de bugs… los bugs generados por la endogamia hacker: ¿qué cosas no son útiles a las personas usuarias? Habría que generar espacios distintos, algo como grupos focales que permitan recibir observaciones sobre cosas que no se reciben bien, errores comunes en una interfaz, campañas equivocadas o actitudes que nos alejan de los proyectos. Es decir, por mucho tiempo las personas que no programamos, hemos pensado que debemos convertirnos en lo que no somos, para poder reportar bugs y ayudar “de verdad”. Tal vez la pista esté en otro tipo de reportes que debemos hacer e incluso, en no reportar nada más, sino involucrarnos de lleno en organizar el cambio. Y ahí es donde topamos con pared: ¿en cuáles espacios podemos mejorar el software quienes no programamos? ¿tenemos que conformarnos con probar versiones nuevas de los programas? ¿tenemos que dedicar nuestra energía a aprender a reportar bugs apropiadamente en lugar de aprovechar las capacidades que ya tenemos?

Para nada de eso tengo respuesta. Yo sólo tengo dudas.

—————————-

Lamentablemente, este post tuve que rescatarlo del cache. Desapareció, seguramente por torpeza mía y se perdieron entonces los comentarios de Gunnar Wolf 🙁

A desalambrar el software libre

defences

Imagen: Defences become fences N°2, de Enrique T

Para actualizar y ser justa: ya casi estamos terminando la traducción de la campaña http://windows7sins.org gracias a la ayuda de Gabriel Molina, un mexicano con el que he podido trabajar en conjunto superando la barrera del repositorio. Gabriel accedió a trabajar “a pie” y hemos revisado juntos todos los textos. Gracias Gabriel.

Constantemente digo en mis conferencias, que no hace falta ser experto para ser parte del desarrollo del software. Es decir, si no sabemos programar, los usuarios y usuarias podemos dejar de ser entes pasivos y convertirnos en gestores del software, colaborando en actividades de difusión y activismo, pero también traduciendo, documentando y reportando bugs. Son tareas menospreciadas, pero bien importantes.

Lo lamentable, es que eso es falso en la mayoría de los casos. Los proyectos de software libre siguen siendo espacios pensados por y para informáticos, quienes muchas veces piensan que es relativamente simple seguir su lógica. Les tengo una mala noticia: NO LO ES.

La primera y única vez que reporté un bug, lo hice a la gente de KDE por un problema con el Aamarok 2. Me respondieron más o menos, que si no sabía reportar un bug correctamente, mejor los dejara en paz. Nunca más reporté un bug en mi vida (al menos, directamente) y me quedé con el Amarok anterior. Yo quisiera, lo juro, poder reportar un bug de una manera tan hermosa como esta (vía magus) pero es imposible para mis capacidades. De manera que los bugs quedan descartados, bajo la premisa de “lo que no sirve, que no estorbe”. Ok. Puedo vivir con eso.

Si no puedo reportar bugs, puedo traducir… ¿cierto?

Puedo traducir con enorme felicidad y satisfacción si lo hago para Drupal. El sistema que usan es en línea y es sencillo, maravillosamente sencillo colaborar. En los translation sprint que hemos organizado en la RCSL llevamos dos módulos completos traducidos al español, en un trabajo que ha sido divertido y enriquecedor. Jamás frustrante.

En otro vecindario, la traducción de la campaña Windows7sins de la Free Software Foundation, no me ha traído más que tristezas. Desde hace dos meses tenemos los textos traducidos y revisados por tres personas, pero se decidió usar subversion, pedir llave pública, entrar por ssh y de ahí, ya no sé qué sigue. El caso es que los textos los tradujimos al mejor estilo cavernícola (con openoffice.org) y ahora tocaría meter línea por línea dentro de los archivos html que hay en savannah. Si hubiéramos tenido archivos .po ya todo estaría listo… tampoco estoy pidiendo milagros… pero con este sistema ha sido imposible para Eva y para mí -las que más nos hemos comprometido con el asunto- de manera que la campaña sigue sin estar traducida al español, y así seguirá hasta que alguien pueda hacerlo y se publique otra traducción no revisada. ¿Nuestro trabajo qué? Bien gracias, guárdemoslo de recuerdo.

Entonces… ¿cuál es la verdadera posibilidad que tenemos los y las usuarias de software libre, de convertirnos en gestores y gestoras del cambio? ¿cuál es nuestro papel, más allá de dar conferencias, vender camisetas o escribir en un blog? Dar conferencias no debe subestimarse, porque implica conocer bien los temas, estar preparada para responder muchas preguntas diversas y saber exponer claramente conceptos complejos… pero eso no basta. Sobre todo, cuando interactuamos con proyectos de desarrollo donde lo que vale es el código y no cuántas personas escucharon una charla e instalaron software libre después.

Yo, de todas maneras aprecio mis contribuciones y creo que son bien importantes, pero definitivamente creo que tenemos que hacer un mejor trabajo si queremos realmente trabajar por la libertad de los usuarios y usuarias. Ni todos somos poetas, ni todos somos programadores. Tendríamos que generar espacios y niveles de acción, que permitan que más personas se acerquen y hagan tareas que son capaces de hacer. Muchas podemos traducir, pero por favor, quítennos los alambres de púas.

Me fui de polizón en el barco del Drupal Tour ;-)

La semana pasada tuve el enorme placer de unirme al Drupal Tour Centroamérica que Josef Dabinger (@dasjo) comenzó el 1° de agosto en Nicaragua. El tour terminó ayer, con un taller más en Cancún.

A Josef lo conocimos en el Primer Encuentro Centroamericano de Software Libre, donde llegó junto a Felix Delattre (quien va para Costa Rica pronto, a completar el tour… porque dasjo no fue a tiquicia 🙁 ésta vez).

Gunnar Wolf me invitó a participar en el taller que se realizó en uno de los laboratorios del Instituto de Investigaciones Económicas de la UNAM. Pude escaparme del trabajo para ir a compartir un día y medio aprendiendo cómo funciona el Marco de Gestión de Contenidos Drupal (porque eso lo aprendí también, que Drupal es un Framework, no un System). Colaboró en esta ocasión, Israel Elizarrarás, diseñador… a quien convencí de liberar su compu (ya casi lo llamo a ver si cumplió).

Lo más importante del taller -en mi caso- fue perderle el miedo a Drupal. Desde hace ya bastante tiempo es mi opción favorita para construir sitios web, por su dinamismo, solidez, comunidad y flexibilidad… pero del respeto no pasaba. Ahora, ya entiendo cómo funciona su lógica y cuáles módulos pueden faciltarme el trabajo. De ahí salió un sitio bastante modesto para Dialogía, en el cual estaré trabajando como madre orgullosa de la critatura.

Y bueno, como soy “pata de perro”, decidí acompañar a dasjo a la continuación de su tour en Xapala y el puerto de Veracruz. Ahí nos recibió Iván Mejía (http://drupalmexico.com), un desarrollador de sitios web que usa Drupal y le saca el jugo de verdad como pueden ver aquí. Como Iván vive en Coatepec, pudimos comprar el maravilloso Café de Avelino… que aún no tiene sitio web… ¿qué pasó Iván? 🙂

En el puerto, nos recibió Mauricio Hernández de Veralinux. En el taller conocimos también a otros compañeros de ese grupo y a algunos informáticos que quieren usar Drupal pero no conocían mucho acerca del Software Libre. Josef me abrió un espacio y pude compartir con ellos algunos minutos de la charla básica acerca del SL, centrándome en temas de licenciamiento y cómo las empresas que usan SL deben contemplar alguna retribución. No es lo mismo aprovecharse del Software Libre, que utilizarlo contribuyendo a la comunidad o destinando recursos para el desarrollo del software. Si no, es como cortar la rama sobre la cual estamos sostenidos. En ese tema, espero trabajar más en los próximos meses

Las gracias a Josef Dabernig, Gunnar Wolf, Israel Elizarrás, Iván Mejía y a Mauricio Hernández por organizar esta última parte del tour. Por supuesto, gracias a la vida porque pude ser parte del viaje “diacachimba”.

PD: Lo bloqueé por completo… interesante fenómeno del inconsciente freudiano… también asistimos a una reunión de twitteros de Xalapa. Saludos a todos (ya saben, pásense a identi.ca). Aquí hay fotos (por cierto, está muy buena la galería de Iván).

Cursos de Informática para personas adultas mayores (México)

Mientras hacía fila para inscribirme en el curso de Introducción a la Programación, escuché que el señor que estaba adelante quería ingresar a alguno de los cursos. Como es exalumno de la UNAM le dan un 10% de descuento, pero su cara de alegría verdaderamente se le transformó cuando le dijeron que a las personas de la “tercera edad” les dan el 50% de descuento en todos los cursos.

Entonces, dejo aquí la información antes de echarme el resto del cuento:
Centros de Extensión en Cómputo y Telecomunicaciones UNAM
Cursos de computación básica y avanzada, administración de redes, diseño gráfico y web… (algunos cursos son en sistemas de GNU/Linux pero esos hay que buscarlos con lupa).
Descuento de 10% a estudiantes y exalumnos de la UNAM
50% a adultos mayores presentando credencial del Inapam.

———————————————————————–

Hasta aquí el comercial (ya veremos la calidad del curso a ver si sigo o no anunciándolos). El caso es que de pronto me imaginé cuántos señores de esos habrá por ahí… que han estudiado informática en los tiempos aquellos de las tarjetas perforadas… y lo maravilloso que sería que retomaran sus estudios y dedicaran su valioso tiempo al Software Libre… ¡No hay nada mejor, que cuando una persona pensionada se vuelve a sentir útil! (no porque no lo sea, sino porque se tiende a mirar el trabajo remunerado como la única actividad productiva en la vida).

Creo que sería maravilloso… no sencillo, pero maravilloso.

Soñar no cuesta nada, si soñamos tod@s

Hoy, Debian cumple 16 años. Un 16 de agosto de 1993, Ian Murdock envió un mensaje, anunciando una nueva distribución de Linux.

No sé si en este caso, se vale decir ¿qué sería del mundo, de nosotros, sin Debian? porque tal vez, más tarde o más temprano, alguien hubiera tenido una idea similar y de todas maneras, muchas personas podríamos tener sistemas operativos libres que podemos usar sin tener que ser expertas. Tal vez Slackware hubiera jugado ese papel, nadie lo sabe.

Sin embargo, el mérito es de Ian Murdock en principio, pero de todos los que estaban antes que él y de todos los que están adelante. Al Proyecto Debian, mis mayores respetos, y toda mi admiración. Y a mis amigos centroamericanos que aún no contribuyen con el proyecto, no se pierdan de colaborar para que nuestra MiniDebConf sea una realidad.

Feliz Cumpleaños Debian (y millones de gracias).
Children Distros… ¿ya le dieron las gracias a mamá? 😛

———————————————

Esta es una traducción libre de “Debian: A Brief Retrospective. Debian a Decade Ago” por Ian Murdock publicada por LinuxPlanet el 15 de agosto de 2003. Envié una consulta para confirmar que puedo publicar. Pediré perdón si la respuesta es no (así que lean antes de que tenga que quitar este post).

Hace diez años, yo envié un mensaje anunciando un nuevo proyecto de Linux:

From: Ian A Murdock (imurdock@shell.portal.com)
Date: August 16, 1993 6:09:59 PST
Newsgroups: comp.os.linux.development
Subject: New release under development; suggestions requested

[Inicia traducción de la cita que hace Murdock]

* Release se ha traducido como distribución *

Compañeros Linuxeros,

Esto es sólo para anunciar la inminente conclusión de una distribución de Linux totalmente nueva, a la cual he llamado la distribución de Debian Linux. Esta es una distribución que he realizado básicamente desde cero; en otras palabras, no sólo le hice algunos cambios a SLS y lo he llamado una distribución nueva. Para realizar esta versión, me inspiré después de correr SLS y estar generalmente muy insatisfecho. Después de hacerle muchas alteraciones a SLS decidí que sería más sencillo empezar desde cero. La base del sistema ahora está virtualmente completa (a pesar de que aún estoy buscando cómo asegurarme de haber tomado las fuentes más recientes para todo), y me gustaría obtener alguna retroalimentación antes de agregarle las cosas “bonitas”.

(El mensaje completo disponible aquí)

Cuando envié ese mensaje, hace una década, Linux estaba siendo usado por tal vez apenas decenas de miles de personas en el mundo, y la mayoría de esas personas estaban usando su propio sistema Linux hecho en casa o el SLS de Peter MacDonald, el Sistema Linux Softlanding. Red Hat Software era apenas un brillito en el ojo de Marc Ewing.

Yo había usado Linux por algunos meses, desde enero de 1993. No mucho después, yo estaba enganchado. Como muchos de los otros primeros entusiastas de Linux, lo que me enganchó no fue Linux en sí mismo, sino más bien, la comunidad que se formó alrededor suyo.

Es difícil recordar, porque los proyectos de código abierto y desarrollo abierto son una trivialidad ahora, pero en 1993, lo que yo miraba que estaba sucediendo era completamente ilógico. Cómo podía la gente, sin un plan maestro, de diferentes partes del mundo, hablando diferentes idiomas y sin recibir pago, reunirse para construir algo tan complejo como un sistema operativo? Lo fascinante del asunto es que funcionaba.

El software que provenía del proyecto GNU era bastante conocido y similar en muchas maneras. También era libre y vivía en la Internet. Pero el software GNU se desarrolló a la antigua, con equipos pequeños, cerrados, tejidos ajustadamente detrás de puertas cerradas (como Eric Raymond mencionó con gran fama, años después en su ensayo “La Catedral y el Mercado Persa”) [“The Cathedral and the Bazaar”+]. Linux se había desarrollado en una forma forma llamativamente distinta y aparentemente casual.

Después de unas pocas semanas de meter el pie en el agua (como dice el proverbio), fui barrido por todo lo que estaba pasando, y se hizo patente el poder que tenía aquello con lo que me había tropezado. Invariablemente, un chico universitario como yo correría hacia Linux (frecuentemente, buscando correr UNIX en casa para ahorrarse las caminatas invernales hacia el laboratorio de cómputo), echaría un vistazo, sentiría asombro por lo que estaba pasando, y entonces lo probaría. Usualmente, eso era lo único que se necesitaba.

El instinto de devolver, de contribuir con la comunidad que no te conocía pero que ya de hecho te había dado tanto, era palpable. A mediados de 1993, encontré mi nicho: Vi la necesidad de una “distribución” de Linux bien empaquetada, aunque desde mi mensaje inicial el 16 de Agosto de 1993, al parecer este término no estaba siendo ampliamente utilizado aún.

Como mencioné brevemente antes, en esos años, la gente generalmente lanzaba [bootstrapped from the ground] sus propios sistemas Linux o usaban la distribución SLS. Unas pocas distribuciones adicionales estaban disponibles, notablemente MCC Interim del Centro de Cómputo de Manchester y TAMU de la UNiversidad A&M de Texas, pero esos esfuerzos estaban mayormente inactivos en los tiempos en los que encontré Linux. A inicios de 1993, SLS era el rey.

Yo usaba palabras fuertes para referirme a SLS, pero no puedo enfatizar en esto lo suficiente: SLS logró un punto de quiebre, porque representaba la primera vez que Linux se había empaquetado para una audiencia más amplia que sus desarrolladores. Las distribuciones previas tendían a detenerse en el kernel, las utilidades básicas, y el conjunto de herramientas para desarrollo. SLS incluía un sistema de ventana, herramientas para formatear documentos, juegos, y otras herramientas que pudieran ser apreciadas por una comunidad más amplia.

Pero así como fue un punto de quiebre, SLS tenía muchos defectos, y para mi forma de pensar, estos problemas se interponían en el camino hacia hacer que Linux fuera apropiado para la audiencia ampla que SLS estaba tratando de alcanzar. Así que intenté arreglar esos problemas, primero con una serie de parches a SLS, después, desde cero, lo que se convirtió en Debian. Esto fue cerca del momento en el que envié el mensaje inicial el 16 de agosto. Slackware tenía similares inicios al mismo tiempo.

Siendo el chico de 20 años que yo era en ese tiempo, me imaginaba que construir una mejor distribución no sería un reto para mi intelecto y mis habilidades superiores. Esto es visible si vemos algunos de mis primeros berrinches [blusters], como “inminente conclusión” (lo cual, hasta donde yo sé, aún es cierta diez años después). Después de varios mensajes posteriores de “casi listo”, llegué a la humillante realidad de que no sería posible hacerlo todo yo solo. Al mismo tiempo, comencé a a darme cuenta de que Peter MacDonald tenía el mismo problema. Recordando mis impresiones iniciales sobre el poder del desarrollo distribuido y abierto, decidí adoptar la idea del desarrollo abierto para mi proyecto de distribución. ¿Por qué no?

El 27 de agosto, envié otro mensaje:

From: Ian A Murdock (imurdock@shell.portal.com)
Date: August 27, 1993 8:22:14 PST
Newsgroups: comp.os.linux.development
Subject: Debian: a brief status report

[Inicia traducción de la cita que hace Murdock]

[…]

Quisiera hacer notar aquí que me gustaría que esta distribución de desarrollara de la misma manera que muchas de las demás que Linux ha desarrollado. En otras palabras, quiero que todos *contribuyan* a este esfuerzo y no simplemente que usen algo que un equipo de un sólo hombre ha edificado. Esta distribución será mejorada por la comunidad Linux como un todo, y yo serviré simplemente, como coordinador de ese esfuerzo”.

[…]

(El mensaje completo disponible aquí.)

————————- FIN ————————————–

+ La palabra bazaar se traduce como “bazar“, pero su definición remite a un mercado al estilo árabe, que popularmente llamamos “mercado persa”.