Etiquetado: Software Libre RSS Mostrar/ocultar comentarios | Atajos de teclado

  • Andrés 9:49 el 24 September, 2011 Enlace permanente | Responder
    Etiquetas: , , , , , Software Libre   

    Analysis on free software communities (I): a quantitative study on GRASS, gvSIG and QGIS 

    When selecting an aplication, it’s very common to weight tecnological factors -what the aplication enable us to do?- and economic ones -how money do we need?. And yet, there is a third factor to take into account, the social aspects of the project: the community of users and developers who support it and make it be alive.

    During a serie of posts begin with this, I’m going to show a quantitative analysis of communities from 3 reference projects in GIS arena: GRASS, gvSIG y QGIS. We selected those, as they are viewed as the more mature projects in desktop GIS, they are under OSGEO Fundation umbrella and show some differences on the actors who bootstrapped and manage today.

    What we have done?

    During the more than 25 years of free software movement, it has delighted us with the high capacity for fostering creation and innovation a community-based model has. Along last years, that model proved its viability in other areas too: content creation (wikipedia), cartographic data creation (openstreetmaps), translating books, etc. Yet, few is known on “how to bootstrap and grow a community”. The only thing we can do is observing what others have done and learn from their experience.

    In order to contribute to the understanding on how a community-based project works I’ve work with Francisco Puga and other people from Cartolab to put together some of the public information the projects generate and make some sense from that. The actors in a community interact with each other, and, when that happen through internet, a trail is left (messages to mailinglists have author information and date, code version systems log information about the authors too, …). Basing our work on this available and public information -and standing on the shoulder on giants -i.e: reviewing a lot of research works similar to what we like to build- we have developed a quantitative analysis on the communities supporting GRASS, gvSIG and QGIS.

    How did we make it?

    The first step was to evaluate and gather all the public information a project, for what we like to do it in automated way. But, as we had to compare the 3 projects, the data had to be homogeneous: at least exists in both 3 and be in a comparable format. Taking these constraints into account (and the limited time we had for this!) we have collected information from 2 different systems:

    • Code versions control systems: from every project, we cloned all information available in their repositories to a local git repo, in order to parse the log of changes. This allowed us to study all the history of projects, from the very begining to December 2010.
    • Mailinglists: by means of mailingliststats tool -built mainly by our friend Israel Herráiz, thanks bro!- we gather data from March 2008 to December 2010.

    Some disclaimers:

    • Projects have a number of branches, plugins and so. We focused the study on the main product, what an user get when she downloads it. Further study on the plugins ecosystem is needed, and it will give us more fine-tuning information.
    • Projects have a number of mailinglists more than we have studied (translators, steering committee, other local/regional mailinglists, etc), varying on each case. The analysis was focused on developers and users ones due to we think they are representative enough to mark the trend. We are not interested in giving an exact number (which may be impossible to measure!) but in drawing the long-term fluctuation of participation. Our intuition and past experiences, says that those mailinglists will follow a correlation of participation with the larger community surrounding the projects.
    • In the particular case of gvSIG users mailinglists, we have studied spanish and english mailinglist jointly. It makes sense doing so as the spanish mailinglist still have the core of contributions from hispanoamerican countries and non-spanish people interacts through international mailinglist. It is like the project have two hearts.
    • Unfortunately, quality of data have limited the period in study: the range is from March 2008 to December 2010. Prior to that, not all projects have information due to mailinglist migrations.

    What is it useful for?

    It’s possible to analyze a community from a variety of points of view. Our approach is a quantitative focus by means of a common model which agregate users depending on their level of participation:

    • Leaders: those who build the product and make the decisions.
    • Power users: those who adapt it to their needs and using it intensively.
    • Casual users: those who using it for a concrete task.

    This approach allow us to better understand the size of the community and how they interact, as it’s not the same the value provided by someone who in 6 months only sent 1 mail to a mailinglist than other person who spent that time sending more than 100 patches to the code.


    With these constraints, we managed to built the following indicators:

    • Adoption trend within users and developers: based on mailinglists data.
    • Activity and manpower: based on code contributions (commits).
    • Composition of the community: based on code contributions (commits).
      • Status: still to be published.
    • Generational analysis: based on code contributions (commits).
      • Status: still to be published.

    During next weeks, I will be publishing the results of the study, in order to help us to understand how different free software communities work, and what we can learn from that. Stay tunned!

    Coda

    The results shown here are borrowed from a paper I led jointly with Francisco Puga, Alberto Varela and Adrián Eirís from Cartolab, a GIS university research laboratory based on A Coruña. The results were shown on the V Jornadas de SIG Libre, Girona 2010. If you are fluent in spanish (reading or listening), you can benefit from these resources:

    From those who can’t, I’ll summarize the main points through small posts on each topic’s paper. The original authors have not reviewed the text as published in my blog, so consider any opinion expressed here as my own (have them to review my texts is a boring and time-consuming task I’m sure they prefer to skip). Please, beg my english.
     

    • Markus Neteler 16:36 el 25 septiembre, 2011 Enlace permanente | Responder

      Hi,

      a quick feedback: in table “Tabla 3: Top 10 desarrolladores – GRASS” the committers “markus” and “neteler” are the same person… that’s me. In a future version of the document, maybe put it together
      into one line as “markus|neteler”.

      cheers
      Markus Neteler

      • amaneiro 17:33 el 25 septiembre, 2011 Enlace permanente | Responder

        Yep, we supposed it. Your case is not the only one, though, but we couldn’t find the time to research this in more depth (for example: asking the own users, matching the mails, …).

    • Markus Neteler 16:45 el 25 septiembre, 2011 Enlace permanente | Responder

      A comment concerning the GRASS GIS repository. Of course it is a fact that the first version was published in 1984. But since no civil internet existed nor any distributed versioning system, it is only traceable back till 1999. We decided to put GRASS into CVS the day before the famour “year 2000″ bug… So slide 4 of your presentation should be corrected (likewise the document). See also http://wiki.osgeo.org/wiki/Open_Source_GIS_History

    • Markus Neteler 16:59 el 25 septiembre, 2011 Enlace permanente | Responder

      The “user trends” of just 2.x years (2008-2011) are too short for multi-year projects. Find the mailing list statistics since 1999 (note that the GRASS lists were started in 1992!) here:

      http://markmail.org/search/?q=qgis

      http://markmail.org/search/?q=grass%20gis

      http://markmail.org/search/?q=gvsig

      • amaneiro 17:55 el 25 septiembre, 2011 Enlace permanente | Responder

        Oh, what an amount of data for a research-junkie as me :) I’ll compare that to ours findings. Thanks!

    • Cameron Shorter 3:58 el 2 octubre, 2011 Enlace permanente | Responder

      Hi,
      I’m fascinated by studies such as you have described, as users are regularly asking us at LISAsoft about recommendations on which Open Source project they should use, and I’d love to be able to base my response upon some solid metrics.

      In particular, I’d love to be able to point people at metric results for all the 50 odd projects which have been included on the OSGeoLive DVD. http://live.osgeo.org

      On a related note, I’ve written a more subjective description about the keys to success building the OSGeoLive community here: http://cameronshorter.blogspot.com/2011/06/memoirs-of-cat-herder-coordinating.html

      Cameron Shorter

    • Barend Köbben 7:07 el 6 octubre, 2011 Enlace permanente | Responder

      Putting the Spanish and English lists of gvSIG together is basically cheating… You should have included all non-english lists for all the softwares.

      • amaneiro 8:26 el 6 octubre, 2011 Enlace permanente | Responder

        Barend, I don’t think so. The indicator try to measure the trend, not the exact number. It’s very wrong to see it as it was the user base, which I suppose was your point. If we tried to do the later, summing both lists will be very inappropiate, as you suggest. But if you try the former I think it makes sense, as the community is splitted in both spanish-speaking and english-speaking (which no happens in the other projects). Basically, the project has 2 hearts with activity, and the tendendy in one place can affect to the other.

        Although measuring all mailinglists would be the ideal situation, we couldn’t afford that.

        Nevertheless, the tendency agregating both or taking into account the lists separately is the same, so it supports our initial guesses.

  • Andrés 7:17 el 19 September, 2011 Enlace permanente | Responder
    Etiquetas: , , Software Libre   

    Growing a community: some texts 

    I’m a longer passionate on community-oriented products: I’ve researched on how they work, have led one to their goal and participate in some. It’s not a new story what they are considered a powerful way to build your products (sometimes, a better one than doing in through the market or internally in a firm/closed-group-of-people). Nevertheless, I’m still looking for some good resources to learn more. For those who like the topic, find here someones I found useful (and I’d like hearing your recommendations!):

    • Producing Open Source Software: the best book I’ve read on how to manage free software projects. Not only a good review on several tools, but also take into account the policies, what gives sense and glue together the community. Very practical.
    • Coase’s Penguin, or Linux and the nature of the firm, by Yochai Benkler. The best academic text I’ve ever red on the matter. Benkler tries to explain why in S-XXI communities emerge as a new way to build products. You will find parallelism to the text where Coase explained why firms emerged in the S-XIX and replace local markets as preferred option. I think some more work is needed to formalized this concept in the academic arena, but the paper is clear, understandable and put the basis to further research. It’s a pioneer.
    • Community antipatterns: a good talk by Dave Neary. Although it’s also focused on software development, I think it has lessons for broad communities. Sometimes, and much more in recently discovered fields, we have no idea what have worked, but know what have no worked.
    • Other’s experiences. Particulary, I’ve found very useful these texts:
    In the road to understand how a community fully works, you will review topics as economics, group interaction and even antropology! I find it very intructive. As broad as the theme is, it has plenty of room to learn more of other sciences. So, being involved in a community, study or just read about it’s a good oportunity to learn.
     

  • Andrés 16:45 el 9 September, 2011 Enlace permanente | Responder
    Etiquetas: , , Software Libre   

    Los costes de no trabajar upstream 

    Imagina el siguiente caso: deseas usar una aplicación que es software libre para construir tu propia solución ad-hoc sobre ella. Y lo harás muchas veces para diferentes clientes/productos. ¿Cómo enfocarlo? ¿Construyes tu solución con tus mejoras para ti modificando lo necesario o integras tus mejoras en la versión upstream, en el proyecto original?

    Si ése es tu caso, te recomiendo que leas estos 2 artículos. El primero se centra en los aspectos económicos y sociales, el segundo en los técnicos y sociales:

    • The cost of going it alone, de Dave Neary. Un buen repaso histórico con casos como el de  Softway con GCC (cambios relacionados con Windows NT), Nokia con GNOME (cambios relacionados con Maemo) o Google e IBM con el kernel (el primero por cambios en Android, el segundo por cambios relacionados con drivers para manejar discos virtuales).
    • Working with upstream: an interview with Laszlo Peter, by Stormy Peters. Laszlo Peter era release engineer en Sun, es decir, quien se tenía que preocupar de que en cada nueva release de Solaris todo fuese bien.
    Luego de leerlos, tendrás una visión más clara de si te compensa o no trabajar con upstream. Si lo que deseas es construir una aplicación vertical con una buena integración (y menos costes de mantenimiento) para sucesivas versiones del software base, la respuesta será sí.
     

    • Nacho V 8:24 el 28 septiembre, 2011 Enlace permanente | Responder

      Jim Zemlin (Linux Foundation chief) talking about the issue of contributing back, “[It's] not the right thing to do because of some moral issue or because we say you should do it. It’s because you are an idiot if you don’t. You’re an idiot because the whole reason you’re using open source is to collectively share in development and collectively maintain the software. Let me tell you, maintaining your own version of Linux ain’t cheap, and it ain’t easy.”
      http://www.networkworld.com/news/2011/083011-zemlin-250234.html

  • Andrés 18:13 el 29 July, 2011 Enlace permanente | Responder
    Etiquetas: , , , Software Libre   

    «If we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”»

    Edsger Dijkstra. Quoted on Are all patches create equal? article by Jonathan Corbet, a must read.
     

  • Andrés 13:57 el 5 July, 2011 Enlace permanente | Responder
    Etiquetas: , , Software Libre   

    «We (free software communities) already have a system much better than elections: you can choose which leader(s) you wish to follow and how much. If you want to be a leader, start leading, and see who wants to help.»

    Richard Stallman, during an old interview.
     

  • Andrés 15:25 el 20 June, 2011 Enlace permanente | Responder
    Etiquetas: , , , , Software Libre   

    No os perdáis este post de Tim Sutton, release manager de QGIS que resumen de algún modo los debates en la comunidad en los últimos meses. A resaltar, 2 de los sospechosos habituales: el complejo balance estabilidad VS nuevas funcionalidades y el modelo de financiación del proyecto. Como post de acompañamiento, toca releer cómo y por qué KCube Consulting cedió 6 meses de un desarrollador a la comunidad QGIS.

     

  • Andrés 14:27 el 16 June, 2011 Enlace permanente | Responder
    Etiquetas: , , , Software Libre   

    «Android is, hands down, the most successful Linux distribution ever produced» — James Bottomley

    Con esta frase empezó James Bottomley su charla en la LinuxCon Japón, donde habló sobre la relación entre Android y el Kernel. Los puntos principales? Los forks y el control sobre el producto. James detalla las razones por las que Google decide hacer un fork del kernel y cómo eso les ha permitido manejar los tiempos de comercialización así como incluir sus necesidades rápidamente. Jonathan Corbet nos resume esta relación de amor-odio entre Android y el kernel en Android, forking and control.

     

  • Andrés 14:40 el 15 June, 2011 Enlace permanente | Responder
    Etiquetas: , , , Software Libre   

    Si primero fue chrome y luego firefox, ahora le llega el turno al kernel. Se impone poco a poco en el mundo libre la tendencia a realizar releases periódicas e incrementales, estilo agile. Detrás de ello: el coste y riesgo que supone a nivel técnico y en relaciones públicas el retraso del proyecto. Es de recibo rescatar este artículo de Andy Lester, en 2007, donde habla de cómo afecta a la adopción del lenguaje, el retraso de Perl6 (7,5 años de retraso cuando lo escribió).

     

  • Andrés 15:59 el 16 April, 2011 Enlace permanente | Responder
    Etiquetas: , , , , , , Software Libre   

    Análisis de comunidades de Software Libre (I): resultados de un estudio sobre GRASS, gvSIG y QGIS 

    A la hora de seleccionar una aplicación se valoran habitualmente factores tecnológicos -qué nos permite hacer la aplicación- y económicos -cuánto nos cuesta lo que necesitamos. Y se nos olvida un tercer factor muy a tener en cuenta: los aspectos sociales del proyecto, la comunidad de usuarios y desarrolladores que lo mantienen vivo.

    A lo largo de una serie de post que inicio hoy voy a presentar un análisis de las comunidades de 3 proyectos de referencia en el mundo SIG: GRASS, gvSIG y QGIS. Durante el proceso de selección nos hemos quedado con estos 3 porque consideramos que son los más importantes y maduros SIG de escritorio, están además bajo el paraguas de la Fundación OSGEO y presentan diferencias en los actores que los gestionan.

    ¿Qué hemos hecho?

    En los más de 25 años que tiene el movimiento del software libre, se ha demostrado la gran capacidad de creación que tiene un modelo centrado en la comunidad. Un modelo que, además, ha mostrado su viabilidad expandiéndose a otras áreas: creación de contenidos (wikipedia), creación de datos cartográficos (openstreetmaps), traducción de libros, etc. Pero si bien conocemos su potencia, poco sabemos sobre “cómo crear y gestionar una comunidad“. Lo único que podemos hacer es observar qué han hecho los demás y cómo les ha ido. Probar. Tratar de extrapolar heurísticos de la experiencia de otros.

    Para contribruir al entendimiento de cómo funcionan las comunidades de software libre -Francisco Puga, otra gente del Cartolab y yo- hemos realizado un análisis de las comunidades en base a la información pública que generan. Los actores de una comunidad interactúan entre sí, y, cuando eso ocurre a través de internet, las interacciones dejan rastro:

    • Listas de correo: los mensajes contienen la fecha, el autor, etc.
    • Wiki: es posible obtener información sobre el autor, la fecha de creación, el número de ediciones de una página, etc.
    • Sistemas de control de errores: información sobre quién y cuándo se reportó, si está resuelto o no, etc.
    • Sistemas de control del código: podemos obtener la actividad sobre la aplicación basándonos en el número de cambios (commits), conocer quién los hizo, la fecha, etc.

    Con la base de esta información pública disponible, lo que hemos hecho ha sido un estudio cuantitativo sobre las comunidades que rodean y sostienen a estos proyectos.

    ¿Cómo lo hemos hecho?

    Gracias a la disponibilidad de ciertas herramientas que nos facilitaron el proceso de obtención de información, además de tener en cuenta la calidad de los datos para poder hacer comparativas entre los proyectos, lo que finalmente logramos hacer fue lo siguiente:

    • Sistemas de control de código: hemos volcado toda la información disponible al sistema de control de versiones git para luego parsear su histórico. Esto nos ha permitido estudiar toda la historia de desarrollo de los proyectos hasta diciembre del 2010. Datos para grass – gvsig – qgis
    • Listas de correo: hemos usado para ellos la herramienta mailingliststats -que construyó principalmente Israel Herráiz, thanks bro!- con datos desde marzo de 2008 hasta diciembre de 2010, en base a:

    Algunas aclaraciones sobre el estudio de las listas de correo:

    • Los 3 proyectos tienen muchas más listas para diversos aspectos (traducciones, dirección del proyecto, listas locales, etc). Nos hemos centrado en éstas porque creemos que son suficientes para marcar la tendencia, que realmente es lo que nos interesa; no los números gordos que serían engañosos.
    • En el caso de las listas de usuarios, para gvsig hemos estudiado además de la lista internacional, también la española. Ésta última es donde nació el proyecto y muestra todavía la actividad principal. No hacerlo introduciría sesgos.
    • Por desgracia, la calidad de los datos nos ha limitado el período de estudio: hemos conseguido analizar desde Marzo de 2008 hasta diciembre del 2010.

    ¿Para qué nos vale?

    El estudio de una comunidad tiene diferentes enfoques. El nuestro se basa en el modelo que divide a la comunidad en 3 niveles de participación e implicación:

    • Leaders: aquellos que construyen el producto.
    • Power users: aquellos que lo adaptan a sus necesidades y lo usan intensivamente.
    • Casual users: aquellos que lo usan para una tarea concreta.

    Esta aproximación facilita la comprensión de cómo funciona realmente la comunidad, ya que no es lo mismo la aportación de una persona a través de un único mensaje en una lista de correo a la de alguien que se ha pasado 6 meses creando la aplicación. Nos aporta además, información sobre la adopción de las herramientas así como patrones de participación y actividad entre los distintos actores.


    Con este enfoque y metodología hemos conseguido realizar los siguientes indicadores:

    • Tendencias de adopción entre usuarios: basado en las listas de correo.
    • Tendencias de adopción entre desarrolladores: basado en las listas de correo.
    • Actividad y fuerza de trabajo: basado en contribuciones de código (commits).
    • Análisis de composición de la comunidad: basado en contribuciones de código.
    • Análisis generacional: basado en contribuciones de código.

    En las siguiente semanas iremos publicando los resultados del estudio, de cara a comprender mejor cómo funciona una comunidad de software libre. Stay tunned!

     

  • Andrés 22:25 el 14 March, 2011 Enlace permanente | Responder
    Etiquetas: , , Software Libre   

    Traducción de un libro a 12 manos: mis conclusiones (y III) 

    Luego de las dos primeros post donde hablaba de la infraestructura del proyecto y el día a día de las personas implicadas, toca hacer balance. Y esto es necesariamente subjetivo. Es mi visión. Otros miembros del proyecto pueden tener otra distinta.

    Nuestro principal logro ha sido reunir a 12 personas que no habían trabajado previamente juntas, para traducir al gallego un libro en 1 año.

    Si bien la traducción del libro en sí misma es algo que me emociona y lo que unía al grupo, a nivel personal, me quedo con todo lo que he aprendido: crear, coordinar y participar un proyecto online con gente diversa. Esto ha sido una gozada. A continuación siguen algunas reflexiones:

    Liderazgo y participación a lo largo del proyecto

    En nuestro caso, el proyecto tuvo 3 fases claras: los inicios, la traducción y el proceso final de edición.

    Durante el impulso inicial, Pablo Sanxiao, Francisco Puga y yo mismo -con la colaboración de Adrián Chapela- estuvimos poco más que montando toda la infraestructura necesaria para dar soporte al proceso y hablando, entre cerveza y cerveza, de cómo queríamos que fuese. Aquí las tareas estaban bastante difusas y los conocimientos para realizarlas eran bastante técnicos. Contaban más nuestras ganas por construir algo colaborativo que nuestra experiencia. En esta fase, el liderazgo fue bastante compartido, y estuvimos elaborando el proyecto y dando los primeros pasos a nuestro modo. Fue todo muy sencillo porque éramos pocos. Que las tareas fuesen muy técnicas y estuviesen difusas no nos permitía agregar a más gente alrededor.

    A continuación, durante la etapa de traducción, el trabajo se distribuyó entre diversas personas (hasta un total de 12!). La impresión en esta etapa es que las tareas estaban mucho más claras y requerían menos conocimiento especializado: consistía en traducir una de las partes del libro. Es verdad que, en la mayoría de los casos, la traducción se hacía usando gtranslator -un programa muy especializado de traducción de cadenas- pero su uso es muy intuitivo. Además, aquellos traductores que lo desearon, enviaron sus contribuciones en archivos ODT. Esta flexibilidad favoreció la participación de mucha gente en el proceso. El liderazgo aquí estuvo también repartido: por un lado, yo me encargaba de ver que todo el mundo tuviese cosas que hacer y que los nuevos supiesen por dónde empezar, dividiendo y sugiriendo deadlines y tareas. Por el otro, el enorme esfuerzo de los que traducíamos -principalmente Roberto Vieito- “señalizaba” al grupo y a los nuevos que existía voluntad y actividad alrededor del proyecto. Esto sin duda era igual de importante: nadie desea participar en una comunidad que está muerta.

    En la fase final, las tareas volvieron a estar más difusas y se iban realizando a medida que las detectábamos. En nuestro caso, además, coincidió que esta etapa tenía mucho de contactar con proveedores, lidiar con subvenciones, etc. De nuevo liderazgo compartido: Roberto Vieito tiró del equipo realizando todas las tareas de contacto con proveedores y spónsors, demostrando un compromiso increíble con el proyecto. Por mi parte, me encargué de dividir el trabajo restante en tareas pequeñas, asumibles por cualquiera que lo desease, además de llevar a cabo las tareas de integración derivadas de ese “cortar en pedacitos” el proyecto. Y aquí -en las tareas de edición- conseguimos de nuevo una alta participación.

    Qué he aprendido?

    • Cuando existen tareas claras y delegables es posible agregar a más gente en torno a tu idea. Desconozco la razón concreta. Pero mi inclino a pensar que simplemente uno tiene gratificación más temprana del trabajo hecho, que es el único pago que uno obtiene de las tareas voluntarias, el único combustible de la participación voluntaria.
    • Feedback. Disponer de mecanismos, herramientas y procesos de señalización que indiquen las tareas concretas a realizar y muestren el avance del proyecto me parecen imprescindibles. Viéndolo a posteriori, en nuestro caso creo que funcionó muy bien el timeline de avance de cada capítulo. Esto estaba tanto en la web pública como en un hilo de la lista de correo donde se iba actualizando 1) quién era el responsable de la tarea y 2) el porcentaje de completitud. Esto ayudaba -tanto a nivel público como interno- a saber dónde se podía echar una mano. También la lista de correo donde íbamos comentados cualquier cosa. El feedback, además, ayudaba a que los voluntarios recibiesen gratificación directa y rápida por su trabajo.
    • No todo el mundo colabora en el proyecto de la misma manera. Cada uno ha aportado en la medida de sus posibilidades. Hay gente que ha dedicado un par de días al proyecto, otros han traducido capítulos completos, y luego están los que han tirado del carro en momentos críticos asumiendo un gran porcentaje del trabajo. Es normal que esto ocurra, sobre todo en un proyecto donde el 100% de la gente es voluntaria. Los participantes, bien sea por interés personal, circunstancias temporales, etc se vuelcan en unas tareas u otras: el voluntariado no es una fábrica donde la gente trabaja gratis, sino una fiesta donde cada uno viene y va según sus circunstancias. Ser consciente de ello es primordial para que el proyecto no muera. Una actitud positiva con todas las contribuciones es necesaria.
    • Eventos offline. En cada una de las “crisis” (o no-avances) del proyecto tuvimos una xantanza, una comida de trabajo y confraternización. Para mí, estos fueron los momentos más divertidos. Ese cara a cara, me ayudó a superar esas mini-crisis de fé que siempre a uno le vienen, además de la enorme cantidad de trabajo que se hizo, claro. Posteriormente a esos eventos, la actividad online fue también más intensa. Sin planificarlo previamente, ésta fue de las mejores ideas que tuvimos.
    • El liderazgo es compartido y evoluciona según la energía de cada uno y el tipo de tareas a realizar. En nuestro caso, se puede comprobar claramente con la emergencia del liderazgo de Roberto Vieito -que no había participado en la fase inicial- convirtiéndose al final en una de las personas más importantes para el proyecto. Quizás por ello, para facilitar este cambio de líderes según las necesidades, las estructuras de coordinación y gobierno de proyectos con voluntarios son (y deben ser) flexibles, para dejar que los líderes en cada etapa hagan su trabajo.
    • Dejar hacer a quien lo ve claro. Para el libro, conseguimos contar con invitados de lujo en el proyecto: Karl Fogel, Suso de Toro y Yolanda Castaño. Uno de ellos me hace especial ilusión: el poema de Yolanda Castaño. Tengo que reconocer que nunca lo vi claro, tenía muchas dudas: no confiaba en que se pudiese hacer un poema sobre el software libre, no tenía claro que Yolanda fuese la persona ideal para llevarlo a cabo, … Sin embargo, Roberto y Nacho estaban convencidos. Y Roberto lo intentó. Mi posición aquí, fue de mantenerme al margen. No creía que saliese bien, pero en ningún momento transmití eso y les dejé hacer. ¿El resultado? «O corgo volveuse fonte», un poema precioso sobre el software libre (Gracias Yolanda!!). Lección aprendida: si no lo ves claro, apártate, y no dinamites los intentos de otros.
    • Identifica y elimina cuellos de botella. Nosotros no lo hicimos. El proyecto dependía de mí para integrar las contribuciones y, en unas semanas donde tuve mucha carga por otros lados (trabajo, estudios, asuntos personales, …) no pude mantener el ritmo que exigía la comunidad en torno al proyecto. Esto fue sin duda una fuente de retrasos. Por suerte lo superamos. Pero viéndolo en retrospectiva me hubiese gustado haber delegado y compartido las tareas de integración.

    En resumen: si le das autonomía, herramientas y confianza a la gente, ésta te sorprende. Gracias a todos por participar y traducir al gallego un libro tan importante como éste!

     

← posts anteriores

Newer posts →

c
crear nuevo post
j
siguiente post/siguiente comentario
k
anterior post/anterior comentario
r
responder
e
editar
o
mostrar/ocultar comentarios
t
ir al principio
l
ir a la página de ingreso
h
mostrar/ocultar ayuda
shift + esc
cancelar