Hace un tiempo me compré una Motorola XOOM con la promoción de Personal. Mi mayor curiosidad era saber para qué me podía servir a mi un dispositivo como este. Dí muchas vueltas para comprarla porque la veía poco útil.

Elegí esta tableta en particular porque traía Android, el sistema operativo más libre (y popular) que conozco para dispositivos móviles… sí, ya sé que está algo lejos de ser bastante libre, pero bueh…

Al tiempo de usarla empezó a tener problemas de software, el cliente de correo que trae crasheaba demasiado seguido y no era la única aplicación que explotaba. Revisando por internet encontré que había dos releases más modernos publicados por Google y mi tableta no los tenía. Lo primero que pensé es que Personal no los había liberado aún, esto fue más bien por desconocimiento del funcionamiento de las actualizaciones en el ambiente Android (sigo sin saber muy bien cómo es, si es que Google libera en su repositorio y todos los dispositivos se actualizan o si esto puede ser manipulado por la compañía de teléfonos o distribuidor del aparato). En fin… la realidad es que estaba clavado en Android 3.0 y ya estaba dando vueltas Android 3.1 e incluso 3.2.

Dado que la tableta es un dispositivo no esencial para mi vida me decidí a actualizarla a manopla.

Como estuve una buena cantidad de horas con esto pensé en escribir un artículo técnico para que otro pudiera hacerlo más velozmente.

Todas estas explicaciones técnicas son para hacer desde un Linux, los usuarios de otros sistemas operativos les puede servir la explicación de cómo funcionan estas cosas.

La tableta parece tener –como las computadoras comunes– dos instancias de booteo, primero ejecutan un software que vendría a ser un “BIOS” y luego cargan el sistema operativo. El “BIOS” de la Xoom está en una región de memoria no escribible fácilmente (por lo menos no encontré cómo, pero eso es bueno, porque de sobrescribir mal esta sección brickeas la tableta y fuiste), este software tiene unas pocas opciones que te permiten:

• Acceder a la imagen de recuperación (esto es un software que se puede modificar)
• Ponerla en modo de Fastboot Protocol (esto sirve para cambiar el sistema operativo que bootea la tableta)
• Y hay un modo RSD que no sé qué es, ni para qué sirve.

El cómo…

Lo primero que hay que hacer es tener un cable USB para la tableta que funcione bien (si no tenes uno podes usar el de los teléfonos BlackBerry o Nexus1), también preparar el Linux para que detecte la tableta al conectarla por el cable USB.

Preparación de Linux

La preparación del Linux es simple:

sudo touch /etc/udev/rules.d/51-android.rules
echo "SUBSYSTEM==\"usb\", SYSFS{idVendor}==\"22b8\", MODE=\"0666\"" |sudo tee -a /etc/udev/rules.d/51-android.rules
sudo /etc/init.d/udev restart

Con esto Linux ya debería ver la tableta al enchufar el USB, más información y con más detalle sobre esto acá.

Herramienta para cargar ROMs

Luego hay que bajar el software de fastboot para Linux. Hay otro que se llama ‘adb‘ que es muy útil, pero está pensado para hacer bastantes más cosas y para quienes desarrollan aplicaciones para Android.

Como solo se necesita fastboot, lo podes descargar de esta página (que te lo dan todo compiladito). Alternativamente podes bajar tooooodo el SDK de Android para Linux (con sus prerequisitos) y luego compilar los fuentes de fastboot.

Bajar ROMs

Motorola publica las diferentes versiones que tiene de Android para tabletas Xoom aća. Yo probé casi todas las ROMs que publican y todas funcionaron en mi Motorola Xoom de Personal (que viene con 3G y wifi), menos la de Verizon. Lo que no sé es si todas las Xoom son iguales a nivel hardware y es el software quien activa el 3G o el wifi. Incluso te da las instrucciones para cambiar las ROM en esa página.

Cada ROM viene con 4 archivos dentro (recovery.img, system.img, userdata.img y boot.img).

Para cargar la ROM lo que hay que hacer es reiniciar la tableta y cuando está prendiendo apretar el botón de “bajar volúmen” (el que está sobre el contorno izquierdo del dispositivo). Cuando aparece la leyenda “Starting Fastboot protocol support.” ya se pueden empezar a ejecutar estos comando:

El clásico WARNING: Aća es donde borras todo y perdes la garantía que tenes del aparato, sabelo porque es exactamente lo que estás por hacer. Además… a no venir con reclamos, si no funciona es tu culpa por hacer cosas que no debes (como no hacerle caso al fabricante ) y no es mi culpa. A quién se le ocurre??? andar hackeando cosas… no hacer lo que le dicen que hay que hacer y caminar por otra senda que la indicada.

Entonces, primero descomprimis el archivo que contiene la ROM (el que trae los cuatro archivos .img) y luego en modo fastboot protocol ejecutas:

fastboot oem unlock

(y seguís las instrucciones de la pantalla de la xoom, luego se reiniciará nuevamente, de nuevo tenes que apretar el botón para bajar el volúmen y cuando esté de nuevo en modo fastboot protocol ejecutas: )

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot flash userdata userdata.img
fastboot erase cache
fastboot erase userdata
#fastboot oem lock (esto no es obligatorio)
fastboot reboot

Al reiniciar va a ejecutar el nuevo sistema operativo y te va a pedir todos los datos que te pidió cuando la compraste y prendiste por primera vez.

Hasta ahora NADA nuevo, porque estas ROMs son las que vienen con la XOOM de fabrica. Si queres la ROM que te permite actualizar (por vía normal, o sea, desde Google) a Android 3.2 tenes que bajarte la ROM del Build HWI69 de esta página. Esta ROM viene con Android 3.0, pero al registrar tu Xoom con tu cuenta de Google empieza a bajarte las actualizaciones (a 3.1 primero y luego a 3.2), pero esta ROM solo es para wifi.

Con esa ROM vas a tener Android 3.2 pero solamente con wifi.

La alternativa a esto es utilizar la ROM de la gente de Tiamat. Usando esta ROM vas a tener Android 3.2 y además ya está rooteada, por lo que no será necesario poner otros boot.img para permitir ejecutar comandos como root.

Para trabajar con esta ROM hay que hacer algo previo que es cambiar la imagen de recovery (recovery.img). La imagen de recovery no es un backup de tu imagen en uso (que te permite restaurar lo que tenías de fábrica), sino que es un “sistema operativo” que te permite instalar otras ROMs, formatear todo, borrar todos los datos de usuario, básicamente te permite tratar de recuperar el sistema.

Hay un “sistema operativo” de recovery que se llama ClockWorkMod que extiende las posibilidades y te permite hacer cosas como instalar una ROM leyendo la microSD (un disco flash que podes poner y sacar de la tableta y no tener que usar el cable USB), algo indispensable para instalar la ROM de la gente de Tiamat utilizando el archivo .ZIP y no el .IMG (que se usa si lo haces en modo fastboot con la herramienta).

Seguí las instrucciones de esta página y vas a poder cambiar el “sistema operativo” de recovery. Una vez hecho booteas en modo recovery (apretas el botón para bajar el volumen 3 segundos después de que aparece el primer logo al iniciar) y desde este nuevo recovery instalas la ROM de Tiamat.

La ROM de Tiamat no reemplaza toooodo, sino que cambia el kernel y algunas cosas más. Si vas a instalar la ROM de Tiamat hacelo teniendo instalado la ROM de fábrica. A mi me pasó que instalando la ROM de Tiamat no tenía forma de conectarme al 3G de Personal. Esto era porque instalé la ROM modificando una base de ROM de Motorola solo para wifi (que no tiene la posibilidad de configurar 3G). Volví todo atrás, puse la versión de Motorola que tiene 3G y wifi para LATAM y al modificar esa base con la ROM de Tiamat pude usar 3G sin problemas.

Todo muy lindo… pero luego de todo esto, todo este tiempo probando cosas y aprendiendo cómo funcionan y bootean estos dispositivos y teniendo Android 3.2 con todos los chiches… el cliente de correo sigue explotando . Pero ya no me importa tanto.

Suerrrrrte! Espero que te sea útil.

Páginas útiles:

http://yosoyandroid.com/?p=6957

http://forum.xda-developers.com/archive/index.php/t-1049485.html

Los modelos híbridos son –para mi– aquellos que combinan porciones de software libre (FLOSS) y software privativo. En términos reales son los más extendidos. Haciendo uso de las posibilidades que otorgan las licencias libres y la modernización de las arquitecturas de software utilizar software libre en algún módulo, capa o framework de un sistema complejo es cada vez más común.

Pero… ¿son modelos de negocios de software libre?

El software libre (FLOSS) propone justamente la no reinvensión de la rueda, o sea, utilizar software ya escrito y mejorarlo. En vez de escribirlo todo de nuevo.

Ahora, hay muchos caminos para seguir esta premisa. Está el más GPLiano que es el que restringe la posibilidad de cerrar las modificaciones hechas y distribuirlas públicamente sin liberarlas, está también el camino que persigue la linea de la licencia BSD la que permite cerrar el código modificado (y el base/original) y redistribuirlo. Estos tipos de licencia –a mi entender– persiguen el objetivo de mejorar la calidad de los aplicativos producidos en el mundo.

También está el camino de la LGPL, licencia pensada para bibliotecas de funciones (libs) que permite el uso de estas funciones desde software cerrado, o mejor dicho, combinar en formato binario funciones de estas bibliotecas dentro de código privativo (linkeditar que le llaman).

Y por último el camino de usar aplicaciones, o módulos, o frameworks libres enteros que aportan un enorme envión al desarrollo de software.

El último es el camino más común y por ende más extendido ¿Qué empresario en su sano juicio pensaría hoy en desarrollar y mantener software de base con lo costoso que es?

(no tan) Claramente si una empresa desarrolla un pedazo de software y lo cierra con una licencia privativa el modelo de negocios no es libre, pero en la gran mayoría de los casos cuando una empresa utiliza software libre en su sistema y encuentra algún problema en el software libre que utiliza, tiende a arreglarlo y enviar el parche para que sea considerado su aporte.

Son estos los casos que hacen reconsiderar la clasificación. Después de todo la empresa aporta código a los proyectos de los cuales depende y sin esas porciones de software su negocio no existiría.

Desde ya que hay matices, si Oracle solo corriera sobre linux sería impensable –aún así– clasificar su modelo de negocio como un libre. ¿Pero aquellas empresas que desarrollan software privativo para JBOSS o los módulos cerrados de ERPs/CRMs libres?

En CADeSoL creemos que hay que evaluar cada caso y en base a eso clasificarlo de una forma o de otra (de modo que tenga sentido que sea miembro de la cámara), pero el debate definitivamente está abierto.

(publicado en CADESOL)

El viernes 6 de Agosto militantes del PJ Digital invitaron a Cadesol, la Cámara de Empresas de Software Libre, a participar en un encuentro con el fin de comenzar a conformar la “Mesa Federal de Software Público”.

En una reunión amena y con una fluida concurrencia, el Secretario General del PJ Digital, Cro. Sebastián Lorenzo, pronunció su discurso remarcando que “Argentina camina hacia un modelo de Software Público como el que propone Brasil y otros países del UNASUR”, y mencionó también que desde el PJ Digital aplauden la iniciativa, al tiempo que explicó que “el modelo de Software Público de Argentina es un proyecto que se construirá paso a paso y caminando juntos los desarrolladores, los empresarios y los políticos, mirando para adelante y dejando atrás cualquier tipo de confrontaciones que puedan haber existido hasta el día de hoy”.

Daniel Coletti, Presidente de CAdESoL afirma que “todos los que formamos la Cámara estamos convencidos que es estratégico para el país que el gobierno nacional abrace el software libre como herramienta de crecimiento tecnológico, ya que no existe otra forma de que el conocimiento quede en el país si éste utiliza software cerrado, del cual sólo se puede aprender a utilizarlo pero no cómo funciona internamente. Peor aún si el software cerrado utilizado es extranjero“.  El Presidente de Cadesol expresó también que “durante años, diferentes grupos relacionados con software libre han estado asesorando a legisladores y gobiernos del país en esta materia con diferentes grados de éxito, que claramente no se han tenido los resultados esperados“.

Aníbal Fernández ha tomado la bandera de la tecnología fuertemente. Y en este impulso puso al software libre entre uno de los temas importantes.

El debate sobre si el Estado debería utilizar únicamente software libre o no es largo, y quizás el hecho de que el jefe de gabinete del  gobierno nacional lo defina como un tema importante permita que este asunto se vuelva a debatir.

Desde CAdESoL estamos convencidos que es necesario que todos los gobiernos deben tener una estrategia tecnológica que les permita la apropiación de la tecnología.

La agenda digital argentina, justamente menciona este tema en su primera página “[...]Que la Ley Nro 25.467 de Ciencia, Tecnología e Innovación estableció el marco general de la actividad y estructura del sistema, fijando responsabilidades del Estado Nacional, entre otras, las de generar las condiciones para la producción de conocimiento apropiables para la sociedad argentina[...]´´.

Comprando software licenciado privativamente[1], o financiando su producción se hace imposible que el conocimiento sea apropiable para la sociedad argentina.

El Estado debe encontrar los medios y formas para que este conocimiento quede dentro de la sociedad argentina.

No parece ser un buen método el que implementa utilizar software extranjero y cerrado como base para nuevos desarrollos que a su vez quedarán cerrados para la comunidad.

Sumado a esto hay temas aún más básicos; como la estandarización de los formatos en que se guarda la información pública.

Implementar formatos y protocolos estándar es la única vía para que el Estado acceda a la información guardada hace décadas.

Ninguna empresa, por más grande que sea y sólida que parezca, está indemne a ser adquirida por otra o que directamente quiebre, dejando sin soporte alguno a todos los usuarios del software que produjo.

A nuestro entender el software libre y los estándares abiertos son el camino para la apropiación del conocimiento, existen muchas formas para que sea económicamente sustentable su producción y desarrollo.

Brasil ya lo está haciendo hace años y Argentina ha firmado la adhesión a la Declaración de Kochi sobre el Software Público emanada de la “Conferencia Internacional sobre Software en el Sector Público, y Software Libre en Educación”.

Esperemos que podamos encontrar los medios para lograr que el conocimiento quede en el país, ayudando así a que los capitales invertidos en tecnología permanezcan en la economía argentina e incluso lleguen nuevos, buscando contratar servicios y tecnología libre de empresas argentinas.

[1] Se utiliza el nombre de software privativo, en vez del término ‘software propietario’, ya que el segundo genera confusión. El software libre también es software propietario (no se pierde propiedad del software al liberarlo).

(originalmente posteado en CanalAr) Hasta hace un tiempo, el software libre (SL) era ofrecido como un servicio relacionado con las instalaciones, brindando soporte, mantenimiento, capacitaciones, migraciones y consultoría. Con el aumento de la demanda de SL por parte de las empresas, se generaron nuevos modelos de negocios para un mercado en crecimiento. Aquí el detalle:

• Suscripción

Mediante esta metodología, las empresas brindan soporte especializado y actualización del software post suscripción. El cliente accederá a estas prestaciones antes que cualquier otro usuario que no esté suscripto a la empresa.

• Desarrollo modular para aplicaciones libres

Se ofrece un servicio de adaptación de software de código abierto ya sea de ERP, CRM u OpenOffice.org. Por lo general, cuando al software no cuenta con una utilidad necesaria para el cliente se brinda un desarrollo personalizado, que después a la vez puede ofrecerse como un SL ya armado, que se seguirá adaptando para otras necesidades.

• Software as a service

Se trata de la posibilidad de utilizar cualquier aplicación que esté en la nube (Cloud Computing) accediendo a ella mediante un modelo de software como servicio. Es decir, acceder “virtualmente” a las aplicaciones necesarias. Así, no existe la necesidad de crear una infraestructura interna ya que el servicio y las aplicaciones estarán en la nube  bajo demanda  y podrá ampliarse o reducirse según las necesidades de cada empresa. La utilización de software libre por las empresas proveedoras genera muchos beneficios económicos y le da mayor flexibilidad al negocio.

• Recursos humanos especializados

Ante la creciente necesidad de la utilización de software libre por parte de las de    empresas,  son cada vez más necesarios recursos especializados, que puedan hacer una evaluación según su profesionalismo y conocimiento.

Puede darse como Técnico asignado- Soporte proactivo, adelantándose a los problemas a través de uno o varios técnicos periódicamente en la empresa del cliente. También se ofrecen recursos a través de un técnico telefónico o remoto, que brindan asistencia en horario de oficinas. Y por último el modelo 24x7x365, donde el cliente puede acceder a la ayuda técnica en todo momento.

• Personalización de instalaciones masivas en redes

Las personalizaciones del software para empresas que tienen muchos equipos (servidores de sucursal o estaciones de trabajo) empieza a ser un servicio en sí mismo ya que la flexibilidad del software libre permite que se ajusten las aplicaciones y sus configuraciones exactamente a la necesidad del cliente, luego se utilizan alguno de los múltiples sistemas para hacer replicaciones automáticas, de forma tal de hacer muchas instalaciones en forma simultánea.

• Armado de appliances

Se trata de armar dispositivos combinando las aplicaciones del software basadas en  plataformas Linux o cualquier otro software libre para lograr un paquete listo para funcionar. Así, el experto es quien hace todos los pasos de  instalación e integración para entregar soluciones completas que simplifican la implementación, la gestión y el mantenimiento. Estos dispositivos son para uso específico y muchas veces el cliente no sabe que en realidad está utilizando software libre.

El software libre es un forma de construir tecnología que atrae sectores de los más diversos y heterogéneos. Dentro de su aparente caos genera software, movimientos sociales, políticas, documentación, conocimiento y por supuesto: negocios.

Las personas o grupos de personas que hay detrás de cada una de estas “creaciones” pueden estar unidas –en el mejor de los casos– por un denominador común (alguna de las cuatro libertades o todas ellas), pero en la mayoría de los casos ni siquiera por esto. No están juntos, no están siquiera amontonados, han llegado al mismo barco por diferentes caminos y buscan diferentes cosas.

En una sociedad global que está acostumbrada a buscar un centro, un único referente (un líder, una marca, una empresa, etc.) es muy difícil acostumbrarse a la idea de que en el mundo del software libre no hay semejante cosa. Para bien o para mal el software libre se rige por el esfuerzo de incontables personas, grupos, movimientos, líderes y empresas. Esto lo hace incontrolable, anárquico y –una de sus grandes fortalezas– imparable.

La Cámara Argentina de Empresas de Software Libre (CAdESoL) se formó a mediados de 2009 para llenar el vacío de representación de empresas en el mercado local y es un jugador clave para el continuo crecimiento de esta forma de crear software en el país.

En Argentina la comunidad de usuarios de software libre creció de manera exponencial y su trabajo (nuestro trabajo) ha sido importante en materia de difusión. Gracias a todo este crecimiento –que lleva más de una década– han surgido varias ONGs dedicadas en forma casi exclusiva a la evangelización y también grupos de usuarios en todo el territorio nacional. Afortunadamente las ONGs –por su espíritu altruista– han sabido no involucrarse con los negocios (potenciales o reales) que se desprenden del software libre.

Los negocios tienen que verse como lo que son: ¡negocios!, despojados en gran medida de los conceptos y principios altruistas que se respiran día a día en la comunidad de usuarios. Las empresas, incluso el Estado, hablan con empresas para llevar adelante sus proyectos relacionados con tecnología. Los interlocutores (los proveedores) tendrán mejores oportunidades (y éxito) al ver al software libre como un negocio, donde además de generar dinero, se provee una herramienta de software más ética, con un mejor equilibrio que le permite al cliente, entre otras ventajas, un mayor control sobre los desafíos que emprenden (pudiendo elegir proveedor, roadmap, productos –mal llamados soluciones por los proveedores de software propietario–, etc.).

CAdESoL busca ofrecer un espacio de representación a todas las empresas –con actividad en el país– que entiendan que pueden hacer negocios aplicando software libre; compañias que vean las tantas utilidades que ofrece esta forma de proveer servicios y la reducción de riesgos que conlleva trabajar (y producir) software licenciado de esta manera.

La cámara no busca ser elitista, ni descartar empresas que no apliquen íntegramente el modelo que impulsa, sino que pretende integrar a aquellas que quieran iniciarse en el largo y fructífero camino de la liberación del software (en el correcto sentido de la palabra), tanto como a las que producen software propietario pero que está fuertemente integrado con software libre (y necesitan de él para funcionar) y por supuesto a las empresas que ya están aplicando este modelo de negocios.

Pensar en negocios relacionados con tecnología y no pensar en software libre es quedarse fuera de una tendencia que no deja de afianzarse.

(nota también publicada en CIO América Latina)

Ese discurso que tienen sobre lo mejor es tener la posibilidad que cada uno elija lo que le parezca mejor es realmente una “muletilla” excelente, tiene punch, te arranca una sonrisa instantánea, nadie –a priori– te va a decir “No! lo mejor es obligarle a que elijan esto o aquello”. La neutralidad suena a independencia y todos queremos un país independiente, pero en realidad no te están diciendo taaaaantas cosas detrás de esta muletilla.

El Estado no es una empresa con billetara abultada, parecería ser que eso es lo que entienden las cámaras que insisten y “obligan” con sus sabios consejos a que el Estado sea neutro tecnológicamente, porque, claro… no van a usar la palabra “independiente”. Porque a la hora de elegir software propietario dejas de ser independiente obligadamente. Se depende de la empresa proveedora para cualquier cambio, mejora o arreglo de problema de ese software (entre otras cosas). Usando software libre no perdes la independencia obligadamente, podes optar por no perderla, incluso podes optar por hacerla propia, pero eso claramente va en contra de los intereses de las empresas que producen software propietario y sus cámaras.

El Estado es “una entidad” que nos pertenece a todos, y quienes lo administran tienen que pensar que quizás sea mejor no depender de empresas extranjeras, tienen que pensar que quizás sea bueno no depender del software cerrado (nacional o extranjero), esa caja negra que suponemos que hace lo que nos dicen que hace, que no hay capacidad real de auditarla con recursos propios (del Estado), porque habría que auditar cada una y todas las versiones posteriores (upgrades) que el proveedor diga que son necesarias instalar (suponiendo acceso irrestricto al código, vale la pena aclarar). En el caso de que el software que utiliza sea libre, la auditoría la puede hacer cualquier persona, trabaje para el Estado o no (solo va a necesitar saber exactamente qué versión y qué software está utilizando)

Con esta “muletilla” dejan fuera cualquier tipo de discusión.

“Lero-lero” parece que dijeran, “¿Para qué se ponen como locos si los estamos incluyendo?” nos siguen diciendo.

Brasil lo entendió y hace rato que está trabajando estratégicamente con la tecnología, haciéndola verdaderamente propia, generando más plata con servicios que con la máquina de imprimir etiquetas/licencias, en Argentina todavía ni nos sentamos a discutir verdaderamente si la tecnología es estratégica para el país, como país, no como si fuera una empresa de billetera abultada. Hasta dicen que los formatos no tienen que ser necesariamente estándar, ni abiertos. Me pregunto de qué se va a disfrazar el funcionario que necesite abrir un documento hecho con Ms-Word 6.0 dentro de 120 años.

Igualmente no tengo duda que en el futuro esto va a ir cambiando, quizás por moda, quizás por presión, quizás solo por inercia, pero definitivamente no porque lo decidimos nosotros.

En fin… vamos a ver qué nos depara el futuro y realmente qué logramos conseguir con CAdESoL.

Qué lindo que es cuando uno se pone viejo y hay gente que lo entiende, pero mejor aún es cuando uno se pone viejo y hay programadores que lo entienden a uno. Será porque un fue (¿?) “programador” y cree que es mejor que te entienda un/a programador/a a la gente. No sé, pero lo cierto es que hace pocas semanas probé de instalar openfire y quedé atónito, creyendome alguien totalmente comprendido, por fin una aplicación libre para servidor que se instala tan fácilmente, se configura aún más facilmente y tiene una interfaz de administración tan bien acabada.

Hace algunos años, muchos desgraciadamente, no podía irme a dormir si no había terminado de configurar ese programa, esa aplicación o esa configuración que hace aquello tan maravilloso. Recuerdo hasta momentos donde me desperté soñando la solución a un bug o una forma diferente de encarar una funcionalidad nueva. Esos tiempos han pasado y ya hace tiempo. Ahora, que estoy más viejo, quiero que las cosas funcionen de una, nada de andar configurando esto para que ande esto otro que justamente es lo que necesita el sistema que (tan solo) quiero probar.

Lógicamente apoyo esto de no tener que reinventar la rueda todo el tiempo ¿Para qué hacer una aplicación accesible vía browser y programar (primero) un servidor web? (existiendo apache) Claro que es un ejemplo burdo, pero hay muuuuchos sistemas, compañías y programadores que caen en esta trampa, generalmente porque no conocen el software libre, su software es software privativo y creen cosas de lo más estúpidas como: si no hay que pagarlo seguramente es una porquería (o algo cercano a ello), si uso un software libre mi software entonces tiene que ser libre también, etcétera, etcétera, etcétera.

Pero es tan lindo cuando uno instala un software de servidor e instantáneamente se lo puede probar. El caso de openfire es uno de ellos, instalas el paquete, levantas el servicio y guala! todo anda. Accedes desde el browser a la interfaz de administración, te bajas el cliente XMPP (Spark) o cualquier otro y lo podes probar, queres ver qué onda alguna de sus extensiones y desde la interfaz web la instalas (el sistema la baja de sitio web correspondiente), la activas y ya está. Ningún shell, ningún comando.

No hay que configurar ningún otro demonio, ninguna base de datos, crear ningún usuario (bueno, lo hace el instalador del paquete) ni preparar nada. Ah! no, miento, hay que tener un JRE disponible (porque está escrito en JAVA).

Este tipo de facilidades solo las he visto en aplicaciones (libres) para el escritorio. Firefox, Thunderbird, OpenOffice.org y muchos otros no requieren más que eso… instalarlos, para empezar a usarlos.

Claro, openfire resuelve algo que está relativamente aislado en lo que se refiere a subsistemas necesarios, es un servidor XMPP. Solo es necesario implementar el protocolo, brindar una interfaz de administración y listo, pero igualmente hay otros servidores XMPP que son muy diferentes en lo que refiere administración e instalación.

Lo pudieron haber escrito en J2EE, como tantas aplicaciones libres escritas hoy (lo que hace muy incomodo de probar algún sistema) o la interfaz web la pudieron haber escrito en PHP y así requerir que apache esté configurado con su VirtualHost correspondiente, lógicamente se requiere guardar algún dato en alguna parte y qué mejor que usar una base de datos MySQL (claro que para eso hay que tener un usuario para esa base y darle los permisos necesarios).

Nada de todo esto es imposible de hacer, siempre está el archivo INSTALL que te dice como hacerlo “en dos patadas”, pero cansa. Si uno está evaluando software para ver si lo evalúa con mayor énfasis generalmente se baja todo lo que parece que hace lo que uno necesita. Si ya para instalarlo hay que dar algunas vueltas, preparar tantas cosas el listado de software posible se va reduciendo solo y las expectativas del testeador bajan.

Para mi una aplicación libre tiene muchas más posibilidades de ser popular si su método de instalación y administración está bien pensado, bien fácil, bien APB (y también tener un modo avanzado para hacer las cosas como se debe sin tantos defaults). Sino se tiene que hacer popular de la manera tradicional, mostrando lo buena que es técnicamente y que la gente (poca inicialmente) hable bien de ella. El camino largo, pero no necesariamente mejor (técnicamente hablando) que el propuesto.

Gracias a la gente de Openfire y espero que muchos programadores de software libre aprendan de esta experiencia.

Marcelo Lozano, que no es el de la foto pero sí una persona que yo admiro mucho, escribió en su blog que RMS se equivoca, si bien no especificó exactamente en qué se equivoca se entiende (o mejor dicho, yo entiendo) que se equivoca en que todo el software debería ser libre. Cabe destacar que Marcelo defiende el uso de open source —como él y tantos otros prefieren llamarlo— dentro del Estado.

Yo, al igual que Marcelo pienso que efectivamente RMS se equivoca, como se equivocan todos los que están en algún extremo. Y también se equivocan los que pelean a capa y espada por el software propietario. El punto es —para mi— que los segundos se equivocan más que el primero.

El modelo de negocios del software libre es relativamente nuevo y está totalmente demostrado que no es tan lucrativo como el software propietario, por lo menos en su generalidad, o sea, hay sectores o negocios que son más rentables cuando se sigue el modelo de negocios del SL, pero en general, si uno desarrolla software y pretende hacerse rico como Bill Gates solamente lo va a lograr (si es que lo logra) con el modelo de desarrollo propietario.

Además, el modelo de software propietario es mucho más comprensible a simple vista, porque es muy parecido al modelo de negocios industrial, creo algo o hago algo existente (un producto) y vendo muchos. Logicamente, el que dice me voy a poner una empresa de desarrollo simplemente se imagina este modelo, el que ve por todos lados (y el que admira, conciente o inconcientemente, ya que todo el tiempo nos venden lo fácil que es hacerse rico como Bill). Lo que no nos dicen las publicidades y lo que no se cuenta en una charla de bar, es toooooodos los que han intentado este modelo de negocios en software y han fracasado, porque este modelo tiene muchos más riesgos que el modelo del software libre.

Si uno invierte en desarrollar un producto durante digamos… 6 meses, lo saca al mercado al precio que le permite recuperar la inversión rápido y empezar a ganar (preferentemente) mucha plata, tiene que cruzar los dedos a que una empresa más grande (especialmente las MUCHO más grandes) no saquen un producto similar, porque de la noche a la mañana, quedaste afuera, out, y si no hiciste algo como preveer esta posibilidad quedaste además de afuera, quebrado.

Esto con el modelo de sofware libre tiene mucho menos posibilidad de que suceda, porque se parte de la base de que no se tiene algo único e inaccesible a los competidores. Por supuesto que podes quebrar tu empresa, como cualquier negocio, pero si se encara bien el modelo de negocios se puede hacer mucha plata. Lo que es muy importante es que uno entienda bien el modelo y las posibilidades que da ANTES de liberar el software o desarrollar un software libre.

Pero volviendo al tema de si RMS se equivoca o no ¿Debería ser libre todo el software? Idealmente sí, porque que sea libre no implica —por más que muchos digan lo contrario— que siguiendo el modelo de software libre no se puede innovar (o no se puede ganar plata), en realidad es al revés. La clave está en el conocimiento, si lo compartimos no es necesario reinventar la rueda una y otra vez, el tema es que hay que ver el negocio de otra forma y eso les cuesta mucho a quienes ven el desarrollo del software como un modelo industrial. ¿Es necesario que todo el software sea libre? En realidad no, si se hace un software para un nicho localizado o no (o sea que se usa en una región del mundo en particular), en muchas de estas ocasiones no tiene ni sentido liberarlo, porque el costo que conlleva para una empresa liberar el software se convierte en eso, un costo y no una inversión como sería en un software de ámbito general.

Entonces —para mi— RMS se equivoca cuando dice que todo el software tiene que liberarse, sinceramente lo veo impractico y lo impractico es el enemigo número uno de los negocios.

Las Jornadas Regionales de Software Libre terminaron y la verda’… es que estuvieron bárbaras. Esta vez me tocó actuar de coordinador general del evento y a pesar de que uno se “auto pone´´ mucha presión la pasé muy bien. Para los que no me conocen, soy algo chismoso, así que acá les cuento algunas anécdotas y datos “oficiales´´…

Algunos datos oficiales sobre lo que hubo en las JRSL 08:

• Hubo traducción simultánea en casi todas las charlas que se dieron en inglés del auditorio Sarmiento (No hubo en la de Christof Hellwig porque las traductoras no entendían nada de lo que hablaba y la verdad es que no las culpo ;-), así que les dije que no hicieran un HLQP que iba a quedar muy mal)
• Por primera vez tuvimos un sitio diseñado por alguien que se dedica a diseñar sitios ;-).
• Enviamos streaming de audio y video de los dos auditorios principales (Roca y Sarmiento)
• Por primera vez entregamos un programa a colores y diseñado por un diseñador gráfico.
• Tuvimos conexión a internet propia contratada para el evento exclusivamente (con shapper implementado por nosotros para evitar que las mulas corten el streaming).
• Hubo wi-fi en el segundo subsuelo para poder utilizar esta conexión a inet.
• Tuvimos 7 invitados especiales del extranjero.
• Se registraron 2797 personas por el sitio web antes del evento
• Se acreditaron (fueron al evento) 1354 personas
• Vinieron 125 disertantes
• Se dieron 144 charlas
• Hubieron 55 colaboradores presentes en los días del evento (hubo más gente que colaboró en la organización)

Y después, las anécdotas… como verlo al gran maddog Hall vestirse de astronauta para dar la charla en lugar de Mark Shuttelworth, que faltando 4 días para el evento nos canceló su participación (malísimo). Según nos informaron Mark no pudo asistir al compromiso que tenía con nosotros por asuntos que estaban fuera de su control (yoquese, luego nos dijeron las malas lenguas que Mark suele hacer esto, dejar a la gente colgada).

Este evento tiene su grado de presión extra, porque no es una CaFeCONF donde el HLQP tiene una fuerte presencia. ¡Son las Jornadas Regionales! Además habíamos peleado bastante por conseguir que se hicieran en Capital Federal (por primera vez), por lo que el estrés de organizarlas era mayor, bastante mayor y el margen de error tenía que ser ínfimo, todo tenía que salir bien.

Pero claro… nunca todo salen bien. ¡Nunca! Para empezar cuando Mark cancela los programas estaban en la imprenta y así comenzaron las primeras “corridas“, tuve cerca de 4 propuestas de charlas alternativas, el amigo lipe que se ofreción con una charla de UBUNTU, lipe es un grande, pero si la gente va a ver a Mark y de repente se aparece un lipe, tomates podridos iba a ser lo menos agresivo que iba a recibir. Después bea -gran integrante del equipo prensa de CaFeLUG y encargada de logística matística de las JRSL- me ofreció un disertante extranjero que estaba por acá y podía acupar el lugar ya que era un muy buen disertante, pero no me puedo acordar quién era (será bueno, pero evidentemente no muy conocido ;-)). borg también llamó, claro, él se encargó de armar la grilla:

– Agarrá y cambia a fulano y ponelo en el lugar de Mark. No, mejor ponelo a mengano, deciles a los de la imprenta que esperen. ¡No! Dejá que les digo yo, ¿Ya llegaste? (yo estaba yendo a pagar unos adelantos)

– ¡Pará! ¡Paráááááá Martín! No vamos a hacer nada, dejá que quede así, si empezamos a cambiar las cosas ahora vamos a hacer más ca[g]adas. Ya fue, nos cag[ó].

Y otras personas que estaban solidaridandose con la causa y estaban al pie del cañon para acudir ante cualquier eventualidad. Está re bueno eso, ver que te llaman ofreciendo ayuda.

Algunos días antes habíamos lanzado nuestro primer Concurso de diseño de remera de CaFeLUG que ganó Patricio Maciel y generó bastante revuelo la decisión final. Si tenes ganas podes ver el archiving de la lista colabora con la discusiones acá, acá y acá del amigo Peter y diabolo (a quien dejé a cargo mienstras me fui a Comodoro y se encargó de mil cosas diferentes) que claro, quién no se pelea con diabolo, y además Peter mostró que puede ser bastante puntilloso (por no decir obse) con las tareas que toma (como este concurso). Yo encima estaba en Comodoro Rivadavia, porque no elegí mejor momento para irme de vacaciones una semanita a conocer la familia de la persona que afirma que soy la luz al final de su tunel ;-)…

¡Bueno! Había sacado los pasajes como 6 meses antes, qué me iba a acordar que era justo 9 días antes de que empezaran las JRSL. Yo cuando cuando duermo hago shutdown, todo lo que está en memoria y no en el disco rígido se pierde (y de tanto en tanto durante el día le pego al botón de reset)

Igualmente todo terminó bien, ganó el amigo Patricio (al cual no mencioné en la clausura del evento como le prometí. ¡Sí! Me resetié más de una vez en ese último día del evento y así queda mi memoria RAM), pero todo bien con Pato, ya quedamos en ir a almorzar.

¡Cuándo llegaron los programas! ejem… debería decir cuando NO llegaron. Primer día, yo re-puteando a diabolo por teléfono: ¿Dónde están los programas? ¿Donde están los carteles? ¿Por qué no están acá? y diabolo diciendo:

– Paráááááááá querido, dejate de romper un cachito, ya vaaaaaaa, ya estamos llegando a la imprenta.

A los 15 minutos llama él.

– (diabolo) Ehhh, ¿Estas sentado?

– (dax) ¿Qué pasó lendoooooo?

– (diabolo) Los programas no están. El flaco dice que no se secaron todavía.

– (dax) ¡Me estas re jodiendo! ¡No te puedo creer! ¡Pero este tipo es un re-pe[l]otudo! Bueno, deja! cagalo a puteadas y preguntale cuando los va a tener listos.

Y le dije a mendieta y a fumachu que hicieran fotocopias del programa que había en la web. Obviamente quedaron malísimos, fue… ahopra que lo pienso: el primer HLQP de las JRSL.

A la hora llegaron borg y diabolo con la cartelería nomás. (¿los programas? al otro día, por supuesto)

Más adentrado en las JRSL, quizás el segundo o tercer día viene el decano de la facultad de ingeniería (Juan Lestani, gran responsable de que las JRSL se lograran hacer en la UB) y le pregunta a lukio uno de los integrantes del grupo de prensa de CaFeLUG -preocupado porque habían robado una cosa más- si tenía un listado de la gente que estaba colaborando, lukio creo que se rió y le dijo

– Mirá, a la mitad la vimos por primera vez acá, te puedo decir sus nicks si queres, pero ni idea

La gente de la UB -después nos enteramos por comentarios del viejo de gacq- estaba completamente sorprendida de nuestra organización, no tanto de lo organizados que eramos, sino de que con tanto caos nosotros podíamos salir totalmente airosos del asunto y con la frente bien alta ¡Claro! Si nos miras desde afuera ves gente que sube, que baja, que va para allá y para acá, y no sabes por qué se dirijen a donde se dirijen, quien los guía, quien ordena, y no es que yo estuviera detrás de ellos. No, para nada, es sentido común (para nosotros). Alguien dice “hace falta una mano acá” y alguien va, quizas más de uno, quizás ninguno (entonces se vuelve a pedir) y finalmente se acude. Sumado a que con los handies hay una cantidad de charlas que solo la escuchan quienes tienen el aparato.

De todas formas, gacq, nuestro encargado de logística en la UB, hizo una gran planilla donde decía quién iba a estar donde durante todo el evento (después de todo teníamos que cubrir 5 pisos y unas diez salas)…

Y por supuesto que hay más anecdotas, pero no las voy a publicar. En estos eventos, cuando la gente esta desbordada (yo me incluyo) muestra la hilacha, pero también podes ver cosas que no se ven vía e-mail… cosas de cada personalidad (las buenas, las malas y las desastrosas!)

Mis felicitaciones a todos los que participaron en la organización, realmente he quedado (una vez más) anonadado de la pasión que le ponemos a esto. Y agradecimientos a todos los que asistieron, sin ellos, todo esto no tiene sentido alguno.

dax///

Links de las repercusiones:

Videos:

http://www.vimeo.com/1577167?pg=embed&sec=1577167

http://www.youtube.com/watch?v=CTQNQM13WHI

http://www.youtube.com/watch?v=VnDm5MCur44

http://www.youtube.com/watch?v=qCFxme4vn4M

http://www.youtube.com/watch?v=2HQyNrWoXJ0

Fotos

http://galeria.usla.org.ar/v/JRSL/

http://www.flickr.com/photos/29844022@N04/sets/72157606909784653/

http://komodin.atpic.com/

http://www.flickr.com/photos/mat-/sets/72157606926254975/

Grupo Jornadas Regionales de Software Libre 2008 (Mural) en Flickr

http://www.flickr.com/photos/54757453@N00/sets/72157606915548898/

http://www.tesitura.com.ar/jrsl/

Medios

13.08.08 Página 12 . http://www.pagina12.com.ar/diario/suplementos/espectaculos/2-10907-2008-08-13.html

http://www.pagina12.com.ar/diario/suplementos/espectaculos/subnotas/10907-3414-2008-08-13.html

Crítica de la Argentina - Entrevista con Chris Hoffman http://www.criticadigital.com/index.php?secc=nota&nid=9428

Página 12 Balance de las JRSL http://www.pagina12.com.ar/diario/suplementos/espectaculos/2-11028-2008-08-24.html

Blogs de TN http://blogs.tn.com.ar/internet/archives/2008/08/software_libre_para_todos.html

TN http://contenidos2.tn.com.ar/2008/08/18/dexter18tn.flv

Linux.com http://www.linux.com/feature/146170

Barrapunto http://americas.barrapunto.com/article.pl?sid=08/08/26/1450206

opentechpress.jp (en japonés!) http://opentechpress.jp/opensource/print.pl?sid=08/08/27/0058256

    Para los que no saben qué son las Jornadas Regionales de Software Libre 2008 (JRSL8) pueden leer sobre el tema acá o acá si te manejas mejor con el inglés que con el castellano. El evento no tiene sede confirmada aún, la razón de esto es porque en un principio decidimos sumar el DebianDay a las JRSL8, dado que el Lunes (18/Ago) es feriado en la Universidad de Belgrano (lugar que ya nos dió el OK para que lo hagamos ahí) se complicó y ahora no tenemos más el OK confirmado.

La realidad es que la organización de DebConf no nos puede esperar a nosotros, por lo que el tema del DebianDay dentro de las JRSL es algo lejos de concretarse, pero aún estamos con esperanzas.

    Estamos esperando confirmación de parte del rector para hacerlo en UB, pero por las dudas lanzamos threads a otras universidades. En todos los casos se va a hacer durante la tercer semana de Agosto (pegado a Debconf) y tenemos una fuerte convicción que la semana que viene sabremos exactamente dónde.

¿Quién tiene la coordinación general este año? Este año tengo la coordinación general yo, pero esto no es un show de una sola persona, vamos a tratar de organizar esto lo mejor posible y es por eso que va a haber “cabezas” de cada sector del evento, ya sea en lo que es coordinación previa al evento, como durante.

¿Qué lista se usará para organizar evento? La lista oficial para este tema será la lista de colaboración de CaFeLUG -> colabora@cafelug.org.ar (http://cafelug.org.ar/cgi-bin/mailman/listinfo/colabora)

¿Qué hay para hacer? ¿Dónde se puede colaborar?

Las secciones del evento son más o menos estas:

• Prensa
• Difusión en otros lugares (no en prensa) como universidades, empresas, etc.
• Sponsors
• Comité Académico
• Planificación y Logística
• Actividades extras
• Regalos, premios, y etcéteras

Lo único que tenemos ya en gestación es la parte de diseño web (logos e imagen en gral), seguramente usaremos XOOPS como CMS ppal y agregaremos otro tipo de software para hacer lo que XOOPS no pueda hacer bien. Usamos este CMS porque nos viene dando buen resultado en muchas CaFeCONF que ya hemos organizado.

Estamos organizando los grupos de trabajo, así que es el momento de decir “yo me sumo a XXXX”. Hay que anotarse en esta página de wiki.

Usaremos el wiki de CaFeLUG http://wiki.cafelug.org.ar para ir documentando todo lo organizativo, si no sacaste usuario todavía, anda corriendo a sacar uno que se agotan (?!)

Necesitamos ideas (queremos sumar cosas extra además de SL, como por ejemplo robótica o actividades relacionadas con tecnología para atraer a otro tipo de personas), también gente que sepa escribir/traducir al inglés y portugués (el sitio web tiene que estar actualizado en todos estos idiomas), difusión, contactos nuevos, gente que organice venidas de micros a BsAs para asistir al evento, contactos en hoteles/hostels, presupuestos, gente que suba contenido al sitio, etc.

Bueno, espero que se vayan sumando y no sean tímidos La coordinación de las JRSL8 las haremos a través de colabora@cafelug.org.ar, no vamos a trabajar por otras listas no públicas, pero sí coordinaremos con muchos contactos uno a uno (aka: teléfono o juntadas presenciales).