Cuando nos planteamos formar parte de un proyecto libre; enfrentamos varios problemas de infraestructura que solo resuelven contar con la ayuda de una hacker experimentada o con una billetera con algún poder bastante interesante de flexibilidad y multiplicación.No es mi caso ni en lo analógico, ni en lo digital donde como minera veo una sucesión de ecuaciones inacabadas.
Aparte también nos encontramos con obstáculos legales y éticos, donde las leyes están construidas y configuradas, para esclavizarnos, someternos a patentes restrictivas, derechos de autora interminables y avasalladores de los derechos de usuaria. Este es uno de los puntos más importantes a considerar; ya que no es raro encontrar a desarrolladoras de “software libre”, que trabajan en plataformas cerradas, donde el modelo de publicación es el de copyright, limitando las posibilidades de compartir el desarrollo y los conocimientos adquiridos con el resto del mundo, todo queda prisionero de herramientas no libres (listas de correo de Hotmail, Google, etc), formatos de archivos y ficheros no libres (.net, .exe, etc), limitando las colaboraciones, etc, etc…
Por eso es muy importante definir la plataforma a utilizar y que esta sea esencialmente libre; una buena opción puede ser ourproject.org, que se basa en los formatos libres de desarrollo y que necesita de la colaboración de todas para continuar con su mantenimiento. Seria deseable que las universidades desarrollaran plataformas libres de conocimientos y producción de herramientas libres. Pero el modelo de pensamiento y producción de las universidades tiende más a formatos privativos-cerrados que al abierto que las originó: no existe institución que se haya adaptado mejor a los requerimientos del capital que la universidad, lo que nos hace ver con desilusión y pesimismo la posibilidad de que estas produzcan y liberen conocimientos.
Por eso; la alternativa más viable es construir nodos de conocimiento que se unan en una red rizomática de producción de pares, que reemplace al modelo de conocimiento privado actual, donde hasta lo que se da gratuitamente, tiene un precio.
Pero para encarar un Proyecto de desarrollo libre debemos tener claridad de que queremos desarrollar y que pasos son los más convenientes para lograr ese fin.
Aquí detallaré los más generales, para que puedan servir de guía a las que quieran iniciarse en este camino.
1. Identifica una necesidad-problema, que necesite de una solución o en algo nuevo que pueda generar soluciones a problemas futuros.
2. Antes de embarcarte en soluciones que tal vez no has meditado suficiente o visto todas las alternativas, busca en profundidad las soluciones ya implementadas, para poder estudiar los proyectos en el mismo sentido. Es más beneficioso que sumes tus recursos a un proyecto ya iniciado, donde encontrarás ya un camino recorrido que empezar a hacer tu propio mapa. Si te encuentras con un equipo poco proclive a integrar nuevas miembras puedes partir de su trabajo e innovar, mejorándolo.
3. Considerando ambas situaciones la de partir de un proyecto existente (fork), como de un proyecto madre donde inician un recorrido totalmente propio desde 0; consideren desarrollarlo bajo una licencia libre que permita a otras leer lo producido y aportar mejoras, y testeos. El desarrollar bajo licencias libres te beneficiará de una gran comunidad ya muy entrenada en aportar este tipo de colaboraciones para el beneficio común y el desarrollo de conocimiento de pares.
4. Elige un nombre para tu proyecto que lo represente. En un momento hice una distribución basada en rpm para organizaciones campesinas y lo bauticé Campesinux. Hoy participo de la reestructuración de UTUTO y le agregamos +COMUNIDAD (Proyecto UTUTO+C) en alusión a la comunidad, al lenguaje C que es la base de todos los otros. La idea es que las otras puedan identificarlo y saber de qué se trata, de solo escuchar su nombre.
5. Como puse al inicio de la nota elige un sitio web-plataforma adecuada al desarrollo que realizas; tal vez lo más recomendable es solicitar un espacio en savannah.gnu.org ;pero si estás comenzando te recomiendo desarrollar en ourproject.org y después solicitar tu inclusión dentro del proyecto GNU. Otra posibilidad es montar su propia estructura, como lo hacen los hacklab y las empresas de software.
6. La WEB es tu principal aliada; usa todas las herramientas posibles para dar difusión a tu trabajo y crear una comunidad que lo continue; si desarrollamos bajo la lógica colaborativa del software libre nuestro trabajo avanzará más rápido y accederemos a soluciones que tal vez no habíamos pensado. La gama de herramientas es muy vasta; desde blogs (wordpress), listas de correo, documentos, mensajería instantánea, chat, wikis, encuestas, foros, y un cada vez más diverso universo de herramientas colaborativas que están a nuestra disposición si garantizamos la liberación de contenidos. (Abajo adjunto una lista de links que nos proveen de estas herramientas)
7. Libera todo tu conocimiento. Compartir no es delito. Compartir salva vidas.
8. Usa formatos libres para la publicación de documentos y archivos.
9. Colocar en un lugar visible la licencia elegida.
10. La difusión es muy importante tanto al planificar el proyecto inicial, como cuando tenemos la herramienta terminada, por eso debemos prestarle una adecuada atención e integrar a quienes quieran hacerse cargo de esta. El software libre no puede destinar millones en campañas publicitarias como Microsoft o Apple.
11. Es muy importante trabajar colaborativamente y compartir soluciones con proyectos similares; es muy importante trabajar con una comunidad de pares interesadas y entusiasmadas en realizar ese trabajo. Software libre es comunidad.
12. Ten en cuenta la opinión de cada usuaria, betatester, colaboradora, escritora de documentos, etc. que conforme tu comunidad. Tu trabajo es para llevar una solución a su labor cotidiana, no para complicársela. A veces una simple opinión como cambiar el color del escritorio de trabajo (GUI por graphic user interface en inglés), es la diferencia entre una experiencia agradable y una que no. Si usamos, foros, listas y betatester es para escuchar y contemplar esas posibilidades; no es una lucha de egos.
13. Abre tu proyecto de forma global, para acceder a conocimientos de muchas realidades y accesos diversos. No seas nacionalista o regionalista cuando hablamos de conocimiento.
14. Siguiendo la lógica anterior usa traductoras e integra colaboradoras que deseen traducir a otros idiomas la documentación y el entorno.
15. Si bien un proyecto libre se basa en producción de pares, asegurate que el desarrollo que iniciaste cuente con las herramientas democráticas que le permitan mantenerse así.
16. Elige el formato de desarrollo: un Equipo Devel dividido por orden de meritocracia donde lideras con algunas de tus colaboradoras el proyecto; o por Producción de Pares donde los aportes son Adhoc y sólo coordinas los aportes dentro del Proyecto.
17. Planifica el desarrollo según sus posibilidades, teniendo en cuenta los recursos de tiempo, experiencia y objetivos con los que cuentan. Cada cual puede hacer lo que desee y pueda; de eso se trata después de todo la libertad. El único limite es cumplir con aquello a lo que decidimos comprometernos.
18. Es muy importante tener bien definidos los objetivos iniciales, las tareas (To-Do, “para hacer” en inglés) y como estas se designarán, prefiero el método Adhoc (o sea, cada una se autoasigna a las tareas que faltan realizar, no habiendo forma de duplicar tareas, ni de dejar tareas huérfanas).
19. Es importante entender que dentro de un desarrollo libre somos todas pares y que quienes toman las tareas saben por qué la toman y que cuentan con recursos para realizarlas.
20. E. Raymond ha escrito sobre la alimentación del ego en la producción libre, poniendo de ejemplo el desarrollo del kernel Linux; prefiero una visibilidad propia de la toma de tareas. Por Ejemplo; Juana toma el desarrollo de un instalador, pero no logra una herramienta estable. Rosa aparece y desarrolla un instalador estable. Según Raymond deberíamos alimentar el ego de Rosa; pero si seguimos su desarrollo vemos que ha utilizado varios de los desarrollos de Juana, entonces ¿que hacemos? ¿Alimentamos el ego de Juana?. Prefiero evitar esta lógica muy usada en el Open Source; por una visibilidad total de quienes integran el proyecto, basado en fraternidad y apasionamiento por lo que hacemos.
21. Escuchar las criticas no significa esclavizarnos de las criticas. Si alguien dice esto no funciona, también debe aportar soluciones, al menos probar las que le suministran nuestro soporte y señalarnos los resultados para poder ser utilizados por otras.
22. Si hay diferencias dentro del proyecto a veces es muy saludable forkear y dar nacimiento a un segundo desarrollo. Fork es tomar lo desarrollado hasta el momento y construir tu propio camino desde hay. Un ejemplo es Mate que es un fork de Gnome.
23. Manten tu desarrollo visible y en contacto con tu comunidad.
24. Si te cansas será tu comunidad, quién lo continue. Por eso es importante el acceso a las fuentes del desarrollo
¡Que tengan un muy feliz desarrollo libre!
Fuentes:
http://libreprojects.org/article.php3?id_article=5&lengua=es
http://www.capaware.org/
https://ourproject.org
https://gitorious.org/
https://about.gitlab.com/
https://bitbucket.org/
https://www.openmailbox.org/
https://riseup.net/
https://mykolab.com/
https://www.mailoo.org/
http://www.autistici.org/
http://www.creativecommons.org.ar/
https://www.gnu.org