Premio PFC con Sw Libre

Si nun post anterior falabamos da confianza e a motivación como motores da participación, neste rescatamos as palabras de Benkler..

… when a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation to get any given individual to contribute need only be very small.

… seguido cos resultados do estudio de Niels Jorgensen (Incremental and decentralized integration in FreeBSD) onde se di que o …

.. 65% [of developers] said that their last task had been worked on largely by themselves only, with teams consisting of two or three developers each representing 14%.

… o que representa unha situación habitual nos proxectos de software libre, xa que a alta modularidade do traballo, permite facer as tarefas asíncronamente á vez que un pode variar o seu nivel de compromiso según a dispoñibilidade.

É por isto, que o teu proxecto debe ser altamente modular.

Porque sen dúbida, ésta é unha das condicións principais que se debe ter en conta á hora de conseguir a masa crítica de participantes, que fagan o proxecto sostible a longo plazo.

Mais neste caso, a modularidade do traballo non se consigue con ningunha ferramenta específica nin só a través da propia arquitectura do software, senón que é relativo á organización do traballo e á capacidade de delegación de tarefas e xestión de grupos humanos. E se ben non existen fórmulas máxicas, sí podemos observar unha serie de patróns habituais ou boas prácticas que facilitarán a participación no proxecto:

• Show me the sources! É boa idea publicar un código base a partir do que continuar o traballo. Non te preocupes de que sexa a mellor solución, senón de que sexa un primeiro intento. Deste modo é máis sinxelo que alguén idee melloras sobre a túa solución e decida participar.

• Release early, release often. Non intentes acabar o proxecto e logo abrilo ó público. ¿Quen desexa participar nun proxecto finalizado? Si queres fomenta-la colaboración dende o principio debes face-lo traballo públicamente.

• ToDo. Manter unha lista de tarefas por facer (to do) é altamente recomendable. Existen múltiples maneiras: a través da web do proxecto, nun arquivo chamado TODO no teu repositorio público de código fonte, ter dispoñible un xestor de incidencias (bugs e features) no que calquera poida encontrar tarefas que realizar, …

• Arquitectura orientada a módulos ou plugins: é unha práctica extendida desenvolver un sistema que soporte plugins e que cada característica (feature) sexa desenvolta como tal (o mesmo se podería dicir dos módulos), desaclopando así o desenvolvemento dunha nova característica co mantemento do core da ferramenta.

• Dar soporte a outros linguaxes (realizar bindings): é posible que o teu proxecto dispoña de bindings que permitan programar noutra linguaxe distinta á que ti decidiches usar no comezo. Esto significa que, por exemplo, si o teu proxecto está programado en C, poderías dar soporte para que calquera persoa que traballe en python poida colaborar.

Debido a que o tempo dos posibles participantes no proxecto é limitado e as súas motivacións diversas, o único que un líder de proxecto pode facer é xerar confianza nas posibilidades do proxecto, dividir o traballo en pequenas tarefas, ampliar o rango posible de participantes.. e confiar en que a xente desexe participar.