Hacia un nuevo gestor de Proyectos Libres

From ourproject.org wiki
Jump to: navigation, search


Índice

TableOfContents

Un poco de Historia

Estos tres últimos años de trabajo en ourproject.org han sido muy interesantes, principalmente por el feedback recibido por la comunidad no hacker que ha hecho uso de nuestras herramientas. Nuestros objetivos, siguen siendo los mismos, los expresados en nuestro manifiesto, pero ahora es cuando somos más conscientes que nunca, de las necesidades que tiene la comunidad no hacker para desarrollar proyectos libres, para trabajar en colaboración, para compartir conocimiento, etc.

schema-es.png

Si bien, al principio queríamos desarrollar en ourproject.org una aplicación propia de gestión de proyectos, es ahora cuando realmente somos más conscientes de nuestras necesidades reales para conseguir un gestor de proyectos libres adecuado para personas no técnicas y nuestro movimiento del Copyleft y de los Bienes Comunes.

Comunicación y Usabilidad

Quizás nuestros mayores problemas hayan sido los de la comunicación y los de la usabilidad. Es un error que se comete ad nausea en una comunidad tan técnica como la del Software Libre: pensamos que nuestro discurso y nuestras herramientas, nuestras tecnologías están al alcance de cualquier persona, pero no suele ser así.

Y de esto nos empezamos a dar cuenta muy muy pronto, cuando empezamos a circular nuestra primera versión de nuestro manifiesto y nos dimos cuenta que teníamos que explicar conceptos tan básicos para nosotros como Copyright, Copyleft, Licencias, Software Libre (incluso Software), etcétera.

Según empezamos a usar nuestras primeras herramientas: wikis, listas de correo, gestores de contenidos, foros, etc, integrados en nuestro gestor de proyectos basado en una modificación de gforge, nos dimos cuenta de la dificultad que tenían personas normales con su uso. Aunque trabajamos en facilitar el lenguaje y la usabilidad de nuestras herramientas, hasta ahora no ha sido suficiente.

Cosas que para nosotros era tan sencillas, como un wiki, podían ser todo un tormento para otras personas, lo que al final coartaba la colaboración. Los administradores de los proyectos libres, lo tenían aún más complicado si querían tener un proyecto completo, al tener que manejarse con herramientas de bajo nivel como ssh, ftp, mysql, etc., si querían usar herramientas como gestores de contenidos (CMS).

Es como si fuésemos arquitectos y construyésemos escalones de un metro de tamaño. Hay gente que los puede subir, incluso con agilidad, pero para la mayoría de la población es algo muy dificultoso. Se tiene que construir con escalones de tamaño razonable y adicionalmente construir rampas.

En cuanto a comunicación, es como si quisiesemos tener un diario de gran tirada y escribiesemos con un lenguaje erudito incomprensible para la gente normal.

Objetivos

El primer y principal objetivo, es tener una plataforma de gestión de proyectos libres (y por ello contenidos libres) y de trabajo en colaboración con unos requerimientos fundamentales:

  • Usable por gente normal. Herramientas for human beings usando el eslogan de ubuntu, no solo destinadas para un sector mínimo de población como es la comunidad hacker.
  • Una herramienta abierta y orientada a la comunidad en la que el trabajo realizado es por defecto visible. En otras herramientas de trabajo en grupo o groupware el modelo de funcionamiento es más el desarrollo cerrado de proyectos en un entorno empresarial, que no se ajusta al modelo de proyectos libres. Herramientas como tutos, phpgroupware, phprojekt o basecamp tienen un enfoque más empresarial, más cerrado, en lo que lo primero que te piden es un login para acceder a cualquier información.
  • Que refleje adecuadamente al modelo de desarrollo de proyectos libres, de comienzo de iniciativas, de toma de decisiones, meritocrático, adhocrático, etc. que estamos intentando trasladar desde el Software Libre a otros campos del conocimiento. Por ello debería modelar comportamientos como la facilidad de toma de iniciativas, quien comienza lidera, quien quiere y es aceptado ayuda, concesión gradual de permisos, la comunidad destaca lo importante, y otros comportamientos. Por el contrario, gestores de proyectos convencionales, suelen reflejar modelos más puramente jerárquicos de férreo funcionamiento y toma de decisiones piramidales.
  • Multilenguaje. Todas las herramientas usadas deben de ser muy multilingües, además de permitir que en la gestión de contenidos se use cualquier tipo de caracteres. No se puede tener un único punto de vista anglo-occidental.
  • Se debe reflejar perfectamente quien participa en un proyecto y quien no. Los proyectos libres, se esmeran en dar crédito a sus colaboradoras, no como en entornos empresariales que las contribuciones son siempre menos visibles. Esto sin sacrificar la privacidad de quienes colaboradoran (si por ejemplo estos no desean mostrar su correo u otros datos).
  • Los contenidos deben poder convertirse en públicos y/o privados de una forma sencilla. Aunque la filosofía es gestionar contenidos libres y ser proyectos abiertos a la comunidad, a veces es necesario que estos sean privados por un tiempo (por ejemplo antes de hacer público un documento o cuando este se está redactando).
  • Se debe dar una destacada visibilidad a la imagen propia de los proyectos/grupos permitiendo de una forma sencilla la adaptación de su imagen, logo, dominio, etc en las herramientas ofrecidas. En este caso la visibilidad del gestor de proyectos debería ser mínima (un mínimo banner, o usar una atenuación de colores, por ejemplo) de forma que no restase visibilidad al proyecto libre en cuestión.
  • Administración totalmente web y sencilla de todas las herramientas. Quienes administran los proyectos, deben poder dar forma a los contenidos de sus proyectos de una forma sencilla sin mucha necesidad de conocimientos técnicos informáticos.
  • En la medida de lo posible el uso de herramientas instanciables por proyecto o comunes. Es decir que una misma instalación permita que varios proyectos usen ese software. Esto disminuye el esfuerzo de instalación y mantenimiento, los problemas de seguridad, el uso de recursos, etc.
  • Sencillez de instalación/actualización/activación de herramientas/aplicaciones/extensiones en los proyectos con una nula intervención manual (por línea comandos o incluso por interfaz web). Dado que es muy necesario estar al día con el software usado, ya que este mejora con rapidez y además es necesario solucionar problemas de seguridad de una forma sencilla. Por ello todo el software que se use en el gestor debe estar administrado vía paquetes de fácil actualización con mínimo efecto para el servicio.
  • Para nosotros un proyecto libre, no solo se compone de contenidos libres, si no que también engloba una serie de herramientas para permitir conseguir los objetivos de las personas involucradas en el proyecto libre. Ejemplos de herramientas son la mensajería, la mensajería instantánea (incluyendo salas de charla virtual), los wikis o pizarras, los blogs personales/grupales, los espacios de subida y descarga de documentos, etc. Por ello nos interesa ir más allá del "Documento Libre" o el "Contenido Libre". No queremos limitarnos al uso de una única herramienta como hacen otras iniciativas.
  • Por supuesto se pretende sugerir que los contenidos gestionados por los proyectos tengan una licencia copyleft (si son proyectos de tipo práctico) o al menos licencias de libre copia para por ejemplo contenidos de tipo artístico, trabajos de opinión, etc.
  • Por supuesto todas las herramientas usadas deben ser Software Libre, los protocolos y los formatos de ficheros basados en estándares.

Otros requerimientos a tener en cuenta:

  • Tener en mente siempre temas de accesibilidad web en la medida de nuestras energías, para no excluir a personas con limitaciones físicas.
  • Tampoco excluir a personas con pocos recursos informáticos (ancho de banda, ordenadores anticuados, pantallas no muy grandes). Es decir, las herramientas usadas no pueden ser muy pesadas.
  • Las nuevas posibilidades de las técnicas Web 2.0, permitirían un uso más sencillo y con menos esfuerzo de las aplicaciones. Esto es importante ya que la sencillez fomenta el uso.
  • Aunque para la comunidad no hacker no tiene en principio ningún interés herramientas como las de control de versiones de código, de bugs, etc, podría ser interesante su inclusión para que la comunidad hacker contribuya en el desarrollo de la posible nueva herramienta. O hacer su uso de manera transparente para una usuaria no especializada (como podría ser el historial de una página en un wiki, pero extendiéndolo a diversos tipos de documentos)
  • Otra interesante y divertida manera de mejorar la usabilidad es utilizando técnicas de aprendizaje automático para cuestiones como resaltar lo más frecuentemente usado, poner en contacto a personas con intereses similares ó compatibles y/o cuestiones similares.
  • La herramienta estaría enfocada a entornos abiertos de colaboración y podría ser usada en entornos educacionales o empresariales, en proyectos con esta metodología de trabajo, pero en principio no estaríamos interesados en favorecer esquemas de trabajos cerrados.

Algunos malos y buenos ejemplos

Este apartado intenta solo poner ejemplos de lo que son malas y buenas aplicaciones desde nuestro enfoque y objetivos. No es una selección de aplicaciones a usar, solamente son ejemplos.

Como gestores de listas de correo usábamos mailman. Este software, muy completo, tiene una multitud de opciones que hacen que la herramienta sea difícilmente comprensible/usable por personas normales. Aunque no lo hemos usado en profundidad, parece que Sympa es mucho mejor en este sentido, aunque quizás lo mejor es limitarse a los foros webs (con posibilidad de subscripción por correo).

Como wiki hemos estado usando moinmoin sobre todo por que era bastante multilingüe pero pronto nos dimos cuenta que no era todo lo sencillo que debería ser (aunque esta última versión que usamos es más usable). Sin embargo mediawiki, el software que usa Wikipedia se acerca más a nuestro ideales, y su uso por una amplia comunidad de personas de diferentes perfiles demuestra que es usable, aunque todavía necesita en nuestra opinión mejoras.

Para blogs, destacar Blogger y su "crea tu blog en tres pasos". Con mínimos detalles limables, es muy usable.

En el filo del Vaporware

Hay una nueva variable de complejidad (que corre el riesgo de hacer todo esto vaporware por su dificultad) y es permitir que cualguier persona/grupo puenda montar un servidor de proyectos libres de un plumazo con una distribución live basada en ubuntu (la distro de Software Libre más usable a día de hoy en nuestra opinión).

Permitir que cualquier colectivo se monte su propio gestor de proyectos libres, con su imagen, sin necesidad de tirar de iniciativas centralizadas como ourproject.org para tener sus CMS/blog, foros, etc.

Aquí los requerimientos son más duros sobre todo con el tema de mantenimiento que tiene que ser "a la ubuntu", es decir, pulso un botón y actualizo todo el servidor.

Sería dar un paso más respecto a la distribución live de gforge que en su día ya acometimos, en términos de usabilidad.

Es algo muy interesante, pero asusta el nivel de complejidad que puede añadir.

Futuro

Si bien, durante todo este tiempo, nuestra adaptación de gforge para proyectos libres (no solo de Software Libre), nos parecía que era lo más cercano y realista que podíamos conseguir a día de hoy en base a nuestra energía, llevamos un tiempo planteándonos acometer un nuevo gestor de proyectos con el enfoque y los objetivos antes descritos.

En principio nos apetece primar buenas técnicas de programación, así que estamos pensando un un modelo Orientado a Objetos. Después de evaluar varias tecnologías, parece que nuestra elección se va encaminando más al uso de Ruby on Rails, aunque todavía no hemos cerrado la evaluación.

Aunque como siempre, antes de acometer una gran empresa, como antes de hacer un marathon, o subir una montaña, hay que ser muy conscientes de nuestras propias energías y realizar una concienzuda preparación, para no fracasar en el intento. Veremos que conseguimos.

Sobre este documento

Aunque la primera versión de este documento refleja la visión de lo que ha sido para nosotros nuestra experiencia estos años y un punto de partida sobre nuestros pasos futuros, el camino no está marcado con exactitud, por lo queremos invitar a otras personas y grupos interesadas en solucionar esta problemática, a trazar este camino, por ejemplo, participando en la edición y comentario de este documento inicial y en otras acciones futuras.

Enlaces

Comentarios

Si te apetece, edita esta página y añade tu comentario y opcionalmente tu nombre a continuación:


Betito -- Pues me parece impresionante, más que nada porque yo tenía en mente un proyecto de estas características, que te permitiera gestionar proyectos de una forma sencilla y fácil, orientado a su uso a un amplio espectro de la población y no solo a la comunidad informática. Que fuera un nexo para colectivos (y por extensión grupos, entidades, ...) de carácter social, asambleario, colaborativo, horizontal y realizar una herramienta realmente útil para sus objtetivos. Me apunto a un rayo ardiendo y quiero participar activamente del proyecto, así que te lo comento por mail y hablamos. Un saludete!


QuimGil -- Todo esto va por buen camino, felicidades por el primer paso y animos en los siguientes. Aunque sea por egoísmo voy a estar siguiendo el proyecto y aportando lo que como usuario-administradorzopenco pueda aportar. Mi objetivo es dejar de dar la paliza a Vicente y admistradores eficientes como él con mis tropiezos más allá de ssh *.ourproject.org

Ya que este proyecto se plantea una visión a medio plazo y habla de Web2.0, creo que estaria bien incluir el concepto de tareas de trabajo y administración en este tipo de proyecto realizadas desde aplicaciones corriendo sobre el propio escritorio y que sean capaces de aclararse con servidores y aplicaciones vecinas en los escritorios de mis vecinos. Es decir, la administración web ya es un paso con respecto a la administración sobre la linea de comandos, pero de hecho el paso intermedio de abrir el navegador y lidiar con él tampoco es imprescindible. Ya estamos viendo herramientas que me instalo en local y que me permiten gestionar mi blog, mis fotos en flickr, etc. La cosa creo que va por ahí (y este es uno de los motivos por los que GNOME me interesa cada vez más), y semillas como estas primeras e incipientes aplicaciones combinadas con el gnome-about-me, GPG, P2P y FOAF creo que van a ser un ingrediente imprescindible en esta web 2.0. En fin, una cosa a tener en cuenta y no la más urgente ni importante.

Por otro lado, un enlace: https://wiki.ubuntu.com/UbuntuInstantServer


Xavi -- Enhorabuena, Vicente (y quien más haya detrás) por la iniciativa. Poco tengo a decir. Yo tan solo conozco un poco Tikiwiki (http://tikiwiki.org) como plataforma que facilita la colaboración para el trabajo diario de colectivos (que van desde alumnos universitarios de carreras no técnicas, y otros colectivos diversos y dispersos). Y la nueva versión 1.10 que está al caer trae ya muchas mejoras anunciadas relacionadas con la Web 2.0 (no las he probado aún), a pesar de que en op.o ya usamos la versión 1.10 (cvs) desde hace más de un año. No sé, adelante, y encantado de hacer de "beta tester" de lo que montéis (Sea mejorando aplicaciones existentes: Tiki, Drupal, Plone, etc.) o creándolas de nuevo, etc. Por lo que hace referencia a Tikiwiki, podeis ver una lista actualizada de funcionalidades, autoavaluadas por la comunidad bajo varios criterios (algunas funcionalidades suspenden en usabilidad u otros aspectos, y es "vox populi"), a traves de: http://doc.tikiwiki.org/Features


fulano -- Comentario