Rudy Godoy :: an act of subversive playful cleverness

For some time ago I’ve been pondering about this question. As long as GSoC 2009 is about to start and people are looking for project ideas, I’m posting here a very preliminar draft of my findings and an idea for a posible software project. It’s pretty written on-the-fly while I’ve managed to have some minutes between work and uni. Rigurous wording isn’t P1.

Debian’s social contract 4th item states:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.

When we make decisions, either technical, legal and others regarding the operating system we deliver, this is one of the most referred argument. Altough that’s seen as high priority often we don’t have ways to properly know what our users want. While working on translations on the Spanish team we’ve faced this situation. Do our users find them useful? they are able to understand them? they find that a much familiar wording would be bette than high technical details? We didn’t know. Then, the question still exists.

Altough Debian has ways for users to provide feedback (BTS, mailing lists, IRC,  popcon, etc) none of them is designed to offer a way for the user to provide feedback on features, development roadmap and other non-bug aspects that developers and the project can tally and use for prioritize on releases. It’s rather amusing to note that one of the most valuable assets free software community has is user involvement and contribution.

But before we enter in details let’s start on the basics. For using this information we first need to know who our users are? do we? From my findings and interaction with the community I’ve identified two kinds of Debian users who can be clearly named.

1) The derivatives or pure blends, who use the Debian base and framework to build niche distributions.

2) The lead users (using E. Von Hippel’s definition), who are the developers, contributors and a group of users. Debian is, if not the only, one of the projects who is best for fostering lead users. Most of them at some point involve themselves in the development process and some, later become developers.

There is a more diverse group who are end-users but it’s unclear to me how we can group them. Despite that they probably represent the biggest part of the pie.

So, how we do please everyone? can we? In my opinion we can, at some degree. By implementing tools for first: gather user feedback, make statistical data, tally, we later can take informed decisions. In Debian decisions are voted and the set of people who votes are only developers with their own constraints.

I think this would ease the constant that release-decisions-regarding-foo-tech-legal-issue represented on each release iteration, saving time, health and bits.  It could be useful for knowing more about who are the ones we develop things for. I’m thinking of some sort of Dell’s IdeaStorm.com for software.

What do you think? I’m willing to co-mentor this if someone finds that is an interesting project for GSoC. Let me know!.

Hace algunas horas Cristian comentaba acerca del post sobre las lecciones que se pueden tomar del software libre para la gestión de proyectos. Aquí su comentario:

Que tal Rudy te saluda Cristian Villalta acabo de leer el articulo y me parece de mucha utilidad pues justo ando trabajando en una tesis relacionada a la gestion de proyectos y software libre. Queria hacerte un par de preguntas:
Que problemas son los mas comunes, desde tu punto de vista, en la gestion de proyectos … y … cual es el impacto del Sw libre en la gestion de proyectos, desde ya agradecido.

Saludos.

Originally posted as a comment by Criso on a subversive act of playful cleverness using Disqus.

Los problemas que he observado en los proyectos de software tienen que ver generalmente con respecto a la gestión de equipo y recursos. Por otro lado, uno de los temas que presenta muchas situaciones complicadas es la definición del ámbito del proyecto y los requisitos del mismo. De hecho, hoy, existe una rama de software que se dedica específicamente a la ingeniería de requisitos.

Para el primer caso, el software libre tiene la ventaja de que los integrantes del equipo o proyecto trabajan en aspectos que son de su interés, de esta manera el proyecto en global se beneficia teniendo mejores resultados, personas comprometidas y apasionadas con su trabajo. Sin embargo, esto presenta el problema de que, generalmente, se pierde un poco el sentido de visualización integral del proyecto, cosa que se suele mejorar con la incorporación de roles de coordinación, por ejm. lo que hace Linus Torvalds o Andrew Morton en el kernel linux.

Además, gracias a las herramientas que ha adoptado la comunidad de software libre para soportar su desarrollo, los procesos generalmente tiene un soporte adecuado por lo que se hacen, hasta cierto punto, eficientes. A medida de que una organización tenga sus procesos mejor estructurados y estandarizados podrá obtener mejor provecho de las herramientas que tiene disponibles, y no al contrario. Esto último es algo que observo en muchas organizaciones, generalmente adquieren software que puede ofrecerles infinidad de posibilidades, razón por la cual otras empresas lo emplean, sin embargo al no tener la base definida es poco el provecho que obtienen pues no se busca optimizar el proceso a través del empleo herramientas.

Respecto al tema de definición de requisitos y ámbito del proyecto, podemos tomar, del software libre, como aspecto relevante la constante interacción con el usuario final a través de sus procesos de retroalimentación y la publicación de versiones en etapa temprana (beta). Esto permite que el desarrollo se realice a medida que se encuentre una necesidad del usuario. Sea un informe de fallo, solicitud de características nuevas, modificación de funcionalidad, etc. estas incidencias son las que usualmente activan los esfuerzos de desarrollo y mantienen una línea de vida constante en el proyecto de software. Si se pierde el interés en el software o no se obtiene esta retroalimentación, usualmente el desarrollo se estanca y suele quedar abandonado.

El software libre, desde sus inicios, ha tenido un estrecho vínculo con la academia. Proyectos como GNU, FreeBSD, Linux, se han gestado en los claustros de conocidas universidades, por sus estudiantes. Hoy en día, una buena parte del software libre, que podemos encontrar en sitios como freshmeat.net, es desarrollado dentro de entornos académicos. Toda esta producción inicial se ha realizado en un entorno pre-ecosistema de software libre, en el que, además del software, también se construyeron las bases de la cultura y prácticas adoptadas por la comunidad.

Hoy, el desarrollo que ha alcanzado el ecosistema de software libre ha permitido que cada vez más organizaciones, empresas, e instituciones adopten las soluciones de software creadas por éste. Por un lado, estudios recientes, como los de Gartner, señalan que para el 2012 gran parte de los productos comerciales de software emplearán componentes de software libre y que por lo menos una tercera parte del presupuesto de las empresas para software de aplicación se destinará a servicios de suscripción.

IDC said “Open Source is the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980’s.”

Gartner predict that “ By 2012, 80 per cent of all commercial software will include elements of open-source technology. ”

A survey of nearly 1000 IT staff in the UK, Germany, France and North America, commissioned by Actuate, showed that fifty four percent of businesses in the UK felt that the benefits of open source outweighed any negative aspects

Another Gartners top predictions for 2008 is that “by 2012, at least one-third of business application software spending will be as a service subscription instead of as a product licence”.

Por otro lado, esto también presenta una situación en la que la demanda de profesionales con conocimiento de tecnologías de software libre se incrementa, mientras que la oferta parece ser cada vez más escasa, según demuestran estudios de Actuate.

Research conducted for Actuate found that six in every ten respondents said there “were serious problems finding the right IT skills to implement and manage open source solutions”

El pasado sábado 22, tuve la oportunidad de ofrecer una charla en mi universidad, la UPC, en la que desarrolle estos temas. El enfoque tenia como objetivo el saber cómo aprovechar, inteligentemente, como estudiantes de computación, las oportunidades y recursos que existen hoy para desarrollarnos profesionalmente haciendo lo que nos apasiona: software libre. En este sentido, conversamos acerca del programa Google Summer of Code como una manera de avanzar hacia tal objetivo, por los beneficios que ofrece a nivel académico y profesional. Además, presenté el proyecto OSS Watch, cuyo objetivo es fortalecer el vínculo entre la comunidad académica y la de software libre a través del desarrollo de material académico que introduzca prácticas de desarrollo de la comunidad en los cursos de computación. A través de esto el proyecto busca mejorar las capacidades de los futuros profesionales que les permitan desarrollar soluciones basadas en tecnologías de software libre.

La charla estuvo organizada por el grupo GNU UPC, conformado por alumnos y ex-alumnos de la universidad, que está en un proceso de reactivación de actividades y retomando proyectos a futuro, de los cuales seguro tendré algún grado de culpa. Las diapositivas de mi presentación están en el wiki que he creado para publicar mis trabajos academicos y proyectos personales.

Now that things have settled among people in Peru regarding OLPC and media attention have gone other directions I would like to elaborate a bit on my views and my personal experiences on this project here in Peru. I’m writing this in English since I consider important that people outside our country have the chance to understand a bit more what’s going on here. Eventually I’ll manage to write some proposals in Spanish.

XOs at Islay - Arequipa

Last August I had the opportunity to visit some OLPC schools in Arequipa together with my wonderful friend Anita Chan, antropologist and Stanford’s professor who is writing a book regarding these issues. We choosed Arequipa due logistics and the city itself, one of the spots I like most in my country, but most important because those schools didn’t got any kind of attention. We thought Arahuay, as being the first one, has got lots of attention and we’ll probably won’t see anything new nor relevant to get more feedback from the field.

Continue Reading »

Se aproximaba el final del año 97 u 98 cuando el encargado de coordinación me ofreció pasar a formar parte del grupo de operadores OpenVMS en la BVL/CAVALI. Mis compañeros en TdP me decian que no aceptara, que ahi estaba bien. De hecho, ya estaba mas adaptado y la gente me apreciaba, intuyo que además por ser el más joven del grupo con una corbata terrible. Tendría 18 o 19 años en ese momento.

Finalmente acepte y empece a trabajar precisamente el 1ro de enero del año siguiente. El entorno de la BVL era más tranquilo, no tenían grandes servidores ni cosas sofisticadas; sin embargo tenian algunos elementos que eran bastante interesantes para mi, y creo que claves en mi desarrollo: el proyecto era relativamente nuevo asi que había algunas cosas por construir, había un esquema de telecomunicaciones con los distintos agentes de bolsa a través de un sistema ATM usando el protocolo x25 (antecesor del modelo OSI, TCP) -también conocido como MEGANET en TdP-, el ambiente era tranquilo, teniamos acceso a Internet y el grupo era bastante ameno.

En este lugar es donde logre desarrollar un conocimiento de buen nivel sobre el sistema operativo OpenVMS, a punto que recibia constantes consultas de los nuevos operadores que ingresaban a GMD y de algunos desarrolladores. Mis inicios fueron en el turno de la noche, donde básicamente se procesaba información e imprimia reportes para el día siguiente, ejecutaban respaldos y se aprovechaba parte del tiempo para dormir. Recuerdo que mi primera noche me recoste sobre el sofá que mis compañeros me recomendaron y no desperte hasta las 7am, todavía no me adaptaba; de hecho antes de eso no acostumbraba a desvelarme.
En algún momento pase al turno de la tarde donde tenia que interactuar con usuarios, vestir formal (cosa que jamas me incomodo, salvo cuando me “sugirieron” que use el cabello más corto -obviamente me rebele!-), y sobretodo conocer en persona a los CVL$algo, osea los usuarios, de entre los cuales había algunas guapas chicas; cosa que felizmente parece ser una constante.

Con el pasar del tiempo logré automatizar algunos procesos en los servidores, escribi cientos de programas en DCL, y en algún punto practicamente tenia todo el tiempo libre consecuencia de eso. Logré configurar el stack TCP/IP (ya que esos equipos solo funcionaban en red con el protocolo DECNET), ejecutar y navegar en Mosaic desde el entorno Motif de los servidores Alpha para ingresar a Internet y los servicios en los que ya era ávido usuario (confesión). Descubri todo el mundo detrás de OpenVMS, las conferencias DEC, los grupos de usenet, de los que aprendi, además de incrementar mi interés en conocer el tema en más bajo nivel.

Ocurrio en algún momento que llevamos un curso de Unix, del que ya había oido porque un usuario del chat de Yahoo! lograba hacer cosas que otros no y me dijo que sabia Unix y que debería aprender puesto que todo ese chat estaba sobre Unix. Rápidamente busque en Altavista o Yahoo! y aprendi qué era este Unix.

Luego de la primera clase estuve más seguro de que si queria aprender esto. Lamentablemente desde mi sitio no tenia forma de acceder al servidor en la red de GMD que estaba en el otro edificio. No contento con esa limitación empece a investigar en Internet hasta que encontre la luz: Linux, un sistemas imilar a Unix que se podía ejecutar en una PC. Los siguientes pasos fueron reciclar unos discos duros de 500MB, reducir el espacio usado por Windows 95 en la PC (Pentium 33Mhz, 16MB RAM) que tenia asignado, descargar durante 1 mes -debido a que reiniciaban el equipo y la descarga FTP no tenia “resume”- una distribución de Linux (creo que RedHat 5.x), y tratar de instalar y configurarla, cosa que logré luego de algunos días.

Cierto día buscando información di con la página del Proyecto GNU y leí su manifesto, e inmediatamente coincidi con el mismo. Esto me animó bastante a conocer, usar y promover esto que ahora sabía que se llamaba software libre. Posteriormente supe que habían distribuciones y encontre a mi subsiguiente amor: el Proyecto Debian. Luego de leer su contrato social, manifesto y las directrices, en donde percibi claramente que cualquiera podría contribuir a éste, levante la mano y dije: yo también. Hasta antes de eso no había sentido tan cercano el hecho de que, además de usar algo, también podía hacer cosas para hacerlo mejor y que beneficie a otros como efecto secundario. Esto claramente fue amor a primera vista, de los cuales uno nunca se separa.

Reemplace el RedHat por Debian, que por ese tiempo era complicado de instalar; lo instale en la PC de mi casa, que había adquirido recientemente, y decidi enlistarme en el grupo de traducción como punto inicial de mi contribución.

De las anécdotas de ese tiempo recuerdo una cuando el nuevo jefe de sistemas, ex marino, ingreso al centro de cómputo para mostrarlo a una visita y empezo a describir las actividades y equipos que teniamos. Al señalar mi PC, ejecutando GNOME 1.x, con una terminal ejecutando top y alguna otra cosa, dijo: desde aquí monitoreamos todo. Tuve dos sensaciones, la primera la obvia (no tenia idea de lo que estaba pasando allí -ya que yo mismo me autorice a instalarlo-) y la segunda fue un poco de ego que me decia: exacto, tengo el control de todo esto (cosa que tampoco estaba lejos de ser cierto).

En algún momento, años después cuando ya había salido de GMD, fui a ayudar a mi amigo Oscar con un tema de backups y para sorpresa mía se trataba de uno de los programas que hice tiempo atrás. Finalmente llegaron a usarlo (Oscar era reacio porque no quería olvidarse las órdenes y sus parámetros) y replicarlo en otros proyectos, fue bastante halagador :)

Latest months have been of great improvement and empowerment on my life; say by my return to the academic life, more of the crazy corporate and business world and other changes on my own (read self hacks) have been keeping me busy and on constant training. Sadly, and not by intent, this have impacted on my direct contribution to the free software ecosystem and interact and work together with the brave gnu world out there. However I’ve been doing some little work and also finding ways to keep cooperating but now from another position. Today I’d like to present the first of this new form of contribution to the free software ecosystem, and specially to the Debian Project.

In the last couple of months I’ve been working on a paper which intends to offer a (not so) new -as you might notice after reading it- approach to what the Debian Project have been managing to produce and what can be done to keep doing it better in the new escenery that we are and will be living in the upcoming years.

My work describes the way Debian have been sucessfully producing lead-users, as described by Eric Von Hippel’s Democratizing innovation book, since it’s conception and what elements were key to have done so. Previously it takes a look on how the process of innovation is really done. Then it describes the current and future world’s escenery according research and current trends, later it makes links between them and gives some ideas for us to keep fostering innovation and play a key role in the free software ecosystem.

With this work my intention is for us to understand what we are, what are we good doing, and how we can keep rocking! I want Debian to look further and be the free software development cutting edge project and atract bright people to work on what they are passionate about.

Hopefully I’ll be in Mar del Plata to discuss about this and also have some fun with you guys I haven’t seen in years!

I’d appreciate any comment or feedback to this. My intention is to turn this work into a collaborative fashion that allow us to make our project much more wonderful!

The full paper is here to download (pdf): http://stone-head.org/talks/debconf8-fostering-innovation.pdf

El pasado 24 de junio a invitación del Chapter Lima del PMI ofrecí una charla respecto a los aspectos o practicas de gestión de proyectos que las organizaciones o empresas pueden rescatar del ecosistema de software libre e incorporarlos en sus proyectos, en específico los que tienen que ver con desarrollo de software.

La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.

La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:

• Proyectos en sí,
• Usuarios finales: que incluye a personas, empresas, sector público, organizaciones sin ánimo de lucro,
• Asociados de los proyectos, que son las organizaciones que apoyan a dichos proyectos, caso gobiernos o empresas,
• Partners de los proyectos, que pueden ser empresas u otros proyectos que ofrecen infraestructura base a los mismos,
• Comercializadores de los proyectos, que son las empresas que se dedican a dar un soporte y canal comercial a los productos desarrollados bajo este modelo de licenciamiento.

Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.

A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.

Entre estos podemos mencionar a los siguientes:

Confía en tu equipo

Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».

Revisa todo, prueba todo

Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.

Todos los desarrolladores son iguales

Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.

Y finalmente, la premisa que no debemos olvidar:

La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta

Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.

Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.

Fue interesante el aprovechar que me antecedio una charla sobre  SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.

Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.

Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:

• Sitio web del MIT que reune trabajos de post-grado sobre temas de software libre. http://opensource.mit.edu
• Articulo sobre el tema en OnLamp de O’reilly. http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html
• Consultora Stellman Greene: http://www.stellman-greene.com
• Consultora Construx: http://www.construx.com

Cuando Richard Stallman, graduado en física por la universidad de Harvard que trabajaba como programador del laboratorio de inteligencia artificial del MIT, decidió renunciar a éste para iniciar su trabajo con el proyecto GNU en donde define las bases de lo que hoy conocemos como software libre a través del manifiesto GNU, posteriormente formalizado en una licencia, que básicamente expone un esquema de trabajo y un modelo de licenciamiento.

Este esquema de trabajo intenta mantener la cultura hacker de aquellos años donde se daba un valor muy alto al compartir y a la colaboración, aspectos que él observo se estaban perdiendo y deseaba mantener. Es por esto que inicia el proyecto GNU bajo el precepto de desarrollar un sistema operativo desde cero bajo este modelo de manera que se cuente con un base sobre el cual desarrollar un sistema computacional que se mantenga bajos los preceptos enunciados y resguardados por la licencia GNU GPL.

Este hecho pues, no represento más que una determinación por seguir con un modelo que a su criterio tendría más beneficios frente a los otros que empezaban a aparecer en la industria. En ningún momento el proyecto tuvo como objetivo el innovar, desarrollar nuevas tecnologías, o servir de arma contra las grandes corporaciones o el sistema.

Durante los años siguientes este espíritu se ha mantenido tal cual, en diversas ocasiones Richard ha vuelto a reafirmar que el propósito no es hacer el mejor software o usar las técnicas más avanzadas de la computación. El objetivo es mucho más simple: tener software que se pueda copiar, modificar, compartir y distribuir libremente (léase sin restricción).

Por esto, el software libre representa sencillamente un modelo de licenciamiento que tiene detrás un esquema de trabajo particular. Ciertamente alguno de los aspectos de este esquema de trabajo han tenido y tienen un gran impacto en la propia industria de software, pero en otros no son más que réplicas de entornos o prácticas desarrolladas en los entornos académicos, en donde nació.

Por ende, si nos restringimos a los aspectos técnicos de la gran mayoría del software desarrollado bajo este modelo, está fuera de lugar calificar al software libre como “nueva tecnología”, “tecnología emergente”, u otros calificativos que hagan referencia de que esto es algo nuevo técnicamente, debido a que son aspectos totalmente distintos. Hablar de nueva tecnología queda fuera de lugar si vamos a mostrar a Linux, Apache, Firefox, etc. que son proyectos que replican algo ya existente: un sistema operativo, un servidor web, un navegador web. Ninguno de estos ha sido innovador ni mucho menos emergente, como si lo fue por ejemplo el primer navegador web Mosaic, desarrollado (como dice su autor Marc Andreesen) como un proyecto “renegado” de investigación académica.

Por el otro aspecto, que tiene más que ver con valores y sociedad, y en donde algunas personas parecen haber encontrado el eslabón perdido al etiquetarlo como “filosófico” para usarlo como trampolín para propalar sus propias ideas políticas, tampoco se tiene como objetivo el realizar dichas actividades o propalar mensajes de cierta índole. Desde la existencia de la humanidad el acto de compartir ha sido una práctica valorada y que ha sido esencial para la subsistencia de la misma. Asimismo, las prácticas que están relacionadas con el proceso de desarrollo de software son en gran medida aplicación de trabajos desarrollados en el entorno académico.

Sin embargo, lo que ha hecho el software libre y el movimiento FLOSS es ponerlas en práctica, hacer evidente que se puede hacer cosas interesantes bajo este modelo, ha hecho voltear los ojos a la industria de software, a las empresas, a la sociedad. Hoy no existe alguna actividad que haya acogido alguna de las prácticas generalizadas como “opensource” dentro de su propio trabajo, desde Wikipedia, las comunidades de eR&D, el modelo de las aplicaciones 2.0, las empresas, los políticos, etc. Hoy se habla de Enterprise 2.0, Politica 2.0, eGov 2.0, y tal. Hoy podemos decir que este 2.0 tiene un 1.5 de ingredientes gracias al software libre.

Un modelo de licenciamiento, junto a un esquema de trabajo han hecho esto posible. Es por eso que personalmente es un orgullo formar parte de su desarrollo y aportar algo a la sociedad del futuro. Y es la misma motivación que me llevo a involucrarme en esto luego de leer el manifesto GNU hace algo más de 10 años, sólo eso, nada más.

Cada uno de los otros temas se desarrollan en su propio entorno por quienes tiene interés en hacerlo, no hay que mezclar las cosas. Siempre es bueno volver revisar los fundamentos sobre lo que se construye algo.

El pasado 14 de marzo ofreci una charla en el Linux Week 2008 organizado por Linux-IDES de la PUCP. por invitación de Genghis. La temática estaba abierta asi que tuve un momento de incertidumbre acerca de qué hablar. Mis opciones estaban entre algo super técnico, tipo sistemas operativos, o algo relacionado con la empresa, por la naturaleza del evento académico.

Finalmente, y gracias a una sugerencia, decidi hablar sobre algunos temas relacionados a las cosas en las que estoy involucrado en estos últimos meses. Así que me propuse hablar del estado del arte del software libre en la empresa. Sin embargo, durante el proceso de trabajar mi charla, que también tuvo su propia historia, me animé por abrir un poco el panorama y hablar de innovación y las tendencias actuales en el sector de empresas de tecnología.

Ya había tocado el tema en la conferencia Día Debian en la UNI, así que esta vez tenía que escalar un poco más y ofrecer algo más interesante que sirva a los asistentes. Me propuse, entonces, ensayar el famoso método Lessig para las presentaciones de apoyo y con el fin de controlar mis tiempos.

En mis últimas charlas he ido dejando de utilizar presentaciones en forma progresiva, incluso la de la UNI la hice bajo el precepto de que: si voy a mostrar cosas de la red, las muestro directamente y no hago ninguna presentación. Mi presentación es la propia actividad que hay en la red. Aquella vez, solo fui con una lista de los enlaces que mostré.

Para esta charla quize apoyar mi «speech» con material visual que ayude a reforzar la idea que estoy transmitiendo. Estoy convencido de que el utilizar las presentaciones de una manera distinta, como por ejemplo para leer el «speech» u otros, es una falta de respeto al público (que también sabe leer).

Ya que iba a utilizar el método Lessig tendría que esforzarme más, primero para tener un mejor orden en la transmisión de las ideas y segundo para controlar los tiempos y tratar de estar sincronizado con la presentación de fondo. Asi que estuve ensayando dos días para tener eso bajo control, creo que el resultado ha sido bastante bueno para esto que llamo «experimento». Me gusta experimentar el hacer las cosas de mejor manera cuando se puede, y he quedado contento (no conforme) con el resultado.

Volviendo al tema de la charla, me ha gustado lo que preparé. Empece con una reseña del inicio del software libre (rms, Linus, Ian), el modelo de negocio que existía en ese momento, las primeras empresas que se formaron. Luego, explique el tema de innovación disruptiva, para posteriormente hacer la relación con el modelo de desarrollo y negocios que se ha formado en torno al software libre.

Posteriormente revisamos el uso de este tipo de esquemas de desarrollo en entornos empresariales, donde cada vez son más importantes los conceptos de e-R&D, innovación, desarrollo de comunidades, el cambio del rol del consumidor a pro-sumidor. Tome como ejemplo a los startups 2.0 y explique cómo estos emplean estos modelos y conceptos que han hecho que sean mucho más exitosos que sitios similares pero con el enfoque tradicional (digg vs. slashdot, myspace vs. mtv.com, etc).

Revisamos la relación empresa-academia, algo que particularmente me interesa, y fue uno de los motivos por los que esta charla en la PUCP fué de particular importancia para mi. También trate el tema del Microsoft de hoy, que parece muy animado a promover el software libre, junto a otras empresas tradicionales. Finalmente hubo una interesante rueda de preguntas donde conversamos sobre innovación, oportunidades para estudiantes, modelos de negocio, realidad virtual, teletrabajo y los beneficios del publicar código.

He quedado muy contento con esta charla, ya puedes notarlo, y espero que se vuelva a repetir en algún momento y sirva para acercarnos más entre academia y empresa. Nuevamente agradezco la oportunidad a Genghis y el grupo Linux IDES.

Hoy me enteré que ya se ha publicado el vídeo de mi presentación, asi que aquí lo pongo. Las diapositivas no son «usables», ya que han tenido otro enfoque y son cerca de 200 (una cada 5 segundos, y de acuerdo al cáculo termine en media hora).

Si te interesa el material o los datos de referencia de temas que trate dejame un mensaje y actualizaré este post o te escribiré directamente.

Charla en la PUCP, Linux Week 2008