● Soporte a usuarios: Foros, listas de correo, IRC, tickets.
● Gestión de conocimiento: Bases de datos, wikis.
Gestión de proyectos:
● Planificación, seguimiento de tareas, calendarios.
● Ejemplos: Redmine, Trac, Bugzilla, Phabricator, GitLab.
Otras herramientas:
● Gestión de lanzamientos, integración continua, testing...
Herramientas de soporte a las comunidades (III)
Algunas recomendaciones sobre herramient
1. Comunidades de software libre
Comunidad OpenERP
Jordi Esteve (UPC + Zikzakmedia)
III Jornadas de OpenERP. Universidad de Deusto, 13 mayo 2010
Obra subjecta a una llicència Creative Commons: Reconeixement Compartir Igual (bysa) 3.0
Podeu trobar la informació de la llicència a: http://creativecommons.org/licenses/bysa/3.0/es/deed.ca
*Reconeixement* — Heu de reconèixer els crèdits de l'obra de la manera especificada per l'autor o el llicenciador
*Compartir Igual* — Si transformeu o modifiqueu aquesta obra per generarne una obra derivada, només podreu
distribuir l'obra resultant amb la mateixa llicència, una de similar o una de compatible.
2. Objetivos
¿Qué es una comunidad?
Planificación de una comunidad
Comunicación dentro de la comunidad
Herramientas de soporte
Valorando la comunidad
Comunidad de OpenERP
4. El desarrollo natural es en comunidad
Una comunidad de software libre es:
un conjunto difuso de personas (no instituciones o empresas);
con diferentes grados de implicación a nivel temporal, de
intereses, de gobierno, etc.;
con una estructura bien definida y una “cultura social”
específica de la comunidad;
con liderazgos individuales o colectivos fuertes;
con individuos compartidos entre comunidades.
Son redes sociales muy evolucionadas.
6. Comunidades SWL – Dinámica mercados financieros
● La información fluye sin problemas: Transparencia, proceso, código,
política, errores, discusiones de la comunidad.
● Las personas pueden confiar: La licencia es un contrato social.
● Se fundamenta la competencia: Qué correcciones y características se
aceptan, y cuáles no.
● Los derechos de propiedad están protegidos, pero no sobreprotegidos:
Gestión de los derechos de autor del código y de la licencia.
● Los efectos secundarios perjudiciales para terceros son reducidos: El
gobierno de la comunidad puede limitar los daños a terceros.
● Nadie está trabajando gratuitamente en un sentido económico: El
contribuyente ofrece alguna cosa que valora menos (un fragmento de
código que soluciona una necesidad particular) para una cosa que valora
más (el software en su totalidad).
● La moneda de cambio es el código y el conocimiento.
7. La evolución es rápida y muy entrecruzada
La permeabilidad entre comunidades provoca dinámicas muy
rápidas:
Las ideas pasan fácilmente de un proyecto a otro. Las personas
actúan de canal.
Los proyectos se pueden ver desplazados por otros proyectos
rápidamente. La competencia es muy elevada.
El ritmo de aparición y desaparición de proyectos es elevado.
Mantenerse al día es una tarea que requiere esfuerzo.
A menudo se habla de ecosistema de software libre:
Las comunidades son los organismos, hay competencia y
colaboración, lucha por la subsistencia, etc.
10. Comunidad con éxito: Generación de oportunidad
Una comunidad de software libre suele proporcionar:
Comunicación abierta (canales de comunicación
visibles y accesibles)
Licencia del software y/o contrato social (da confianza
y seguridad la comunidad)
Herramientas libres (herramientas de desarrollo y
documentación libres y abiertas para facilitar el
acceso)
Pero para que la comunidad de PL tenga éxito necesita generar
oportunidad: Creencia que la visión de futuro se pueda materializar.
18. Planificación de una comunidad. Tareas a realizar
● Identificar como podemos dividir nuestra comunidad en equipos.
● Asegurarnos que los equipos pueden comunicarse con claridad
y eficacia.
● Atraer a una amplia gama de contribuyentes a nuestra
comunidad para participar y contribuir con nuestros objetivos.
● Crear un entorno propicio para nuestros objetivos más amplios.
● Definir el alcance de cada equipo, y ayudar a sus miembros del
equipo a entender su ámbito.
● Comprender la extensión y alcance de la colaboración entre
nuestros equipos.
● Fomentar la diversidad y la oportunidad en la comunidad.
● Elaborar un código de conducta.
19. Ejemplo: Código de conducta de Ubuntu
● Ser considerado: Tu trabajo será utilizado por otras personas y tu
dependerás de la tarea de otros.
● Ser respetuoso: Los miembros de la comunidad se tratan unos con
otros con respeto.
● Ser colaborativo: El PL tiene a ver con la colaboración y trabajo
conjunto.
● Cuando no se está de acuerdo, consulta a los otros: Los
desacuerdos, tanto políticos como técnicos, tienen lugar
continuamente, se resuelven de manera constructiva.
● Cuando no estés seguro, pide ayuda: Nadie lo sabe todo, y nadie
no está obligado a ser perfecto.
● Abandona el proyecte con consideración: Los desarrolladores
van y vienen en todos los proyectos. Cuando te vayas o desconectes
del proyecto, totalmente o parcialmente, os pedimos que lo hagas de
una manera que minimice la interrupción del proyecto.
20. Tipología de comunidades
Comunidades básicamente lectoras (disfrutar cosas juntos)
Comunidades centradas en escribir (crear cosas juntos)
Comunidades divididas por una meritocracia
Comunidades divididas por clases (asignación a dedo)
La meritocracia es un sistema de gobierno en el cual sus
miembros se les da responsabilidades y reconocimiento basado
en los éxitos, mérito y talento. Ayuda a propiciar diversidad y
oportunidad a la comunidad.
25. Herramientas de sopore a las comunidades (I)
Seguimiento de errores (Bug tracking). Proporciona:
● Información de errores
● Filtrado y asignación de errores
Documentación:
● Edición colaborativa mediante wikis o documentos compartidos.
● Ejemplo OpenERP: Sphinx
● Documentación del código (extrae la documentación del propio
código y de los comentarios añadidos expresamente):
● Ejemplo: Doxygen Doc. Xerces
26. Herramientas de soporte a las comunidades (II)
Control de versiones (código):
Dos posibles soluciones para la compartición de código:
● Bloquea – Modifica Desbloquea: Poco práctico, no se usa.
● Copia – Modifica – Fusiona: Ampliamente usado:
● Concurrent Versioning System: CVS, Subversion (SVN).
● Distributed Versioning Control System (DVCS): Bazaar, Git.
Permite a los nuevos desarrolladores producir funcionalidad y
correcciones de errores en ramas separadas que se pueden
fusionar con la rama principal.
Virtualización repositorio RubyOnRails 20042009. Observar abril 2008 cambio a GitHub
31. Como implantar las herramientas de soporte
Sistemas autoinstalados y autoalojados:
● Herramientas aisladas: Subversion, Bugzilla, MediaWiki
● Herramienta integrada: Trac, GForge, Redmine
Ventajas Inconvenientes
Control Mantenimiento
Elección Coste
Soluciones SaaS (Software as a Service): Launchpad, SourceForge
Ventajas Inconvenientes
Facilidad Datos
Mantenimiento Limitaciones ancho de
banda
Fiabilidad Elección de
herramientas
34. Valor de la comunidad. ¿Dónde extraer los datos?
● Datos estadísticos:
● Foros y listas de correos: Número de posts y de miembros.
● Sitio web del proyecto: Número de visitas y de descargas.
● Herramientas colaborativas de desarrollo: Número de línias de
código escritas, número de desarrolladores, número de commits.
● Wiki: Número de usuaris y número de páginas.
● Congresos y conferencias: Número de participantes y de temas
tratados.
● Encuestas y opiniones estructuradas: Las preguntas han de ser
simples, cortas y específicas.
Es recomendable informar y documentar los resultados obtenidos de
los datos estadísticos y/o encuestas junto con las conclusiones que
se extraen a la comunidad.
35. Comunidad OpenERP / OpenObject
● OpenERP: Sistema de gestión ERP: vendas, compras, productos,
almacén, facturación, contabilidad, proyectos, fabricación,
RRHH, CRM, TPV, ...
● OpenObject: Entorno de desarrollo rápido de aplicaciones con
tecnología PostgreSQL, Python y XML.
Licencia:
● Licencia GPL (la próxima versión cambia a Affero GPL):
● Servidor + módulos
● Cliente Gtk
● Cliente Koo
● Licencia OPL (OpenERP public license)
● Cliente web (es una MPL con restricciones en los logos)
36. Comunidad OpenERP. Historia
Historia
● 2004 Primeras versiones TinyERP. Fabien Pinckaers crea la
compañía belga Tiny Sprl.
● 2007. Apertura depósito SVN al exterior
● 2008. Migración plataforma colaborativa LaunchpadBazaar
● 2008. TinyERP pasa a llamarse OpenERP. Campaña marketing
● 2009. Mejores procesos colaborativos (organización comunidad)
● 2010. Inversión de 3 millones de euros de capital de riesgo a la
compañía original, que pasa a llamarse OpenERP SA.
Evolución (núm. de módulos):
● Oct. 2006 Enero 2007 Abril 2007 Mayo 2007 Mayo 2008 Abril 2009 Nov. 2009
40 112 185 200+ 250+ 350+ 500+
37. Comunidad OpenERP. Comunidad
Comunidad
● La comunidad de OpenERP es muy joven
● Muchos de los equipos, canales de comunicación y herramientas
colaborativas que se comentan a continuación se han puesto en
marcha durante el 2009 y 2010 y todavía se están definiendo y
ajustando algunos de los procesos de colaboración.
● Desde febrero de 2010, existe la figura del líder dedicado a la
comunidad: Hace de canal de comunicación entre la empresa y la
comunidad, define y documenta los procesos, ..
Ciclo de liberación
● Versiones pequeñas (bugfixes): 1 al mes. Sale a principios de mes
● Versiones grandes (nuevas funcionalidades): 1 al año
aproximadamente
39. Comunidad OpenERP. Herramientas de colaboración
● Código. Mediante sistema control de versiones Bazaar:
● Quality members suben el código directamente
● Otros miembros: ramas propias + solicitud de fusión
● Documentación (inglés + traducciones): Sphinx + Bazaar
● Nuevas características: BluePrints
● Informes de errores: BugTracker
● Traducciones: Translations
● Translation team: Actualiza traducciones
● Otras: sugieren traducciones
40. Comunidad OpenERP. Comunicación
● Portal web:
● www.openerp.com, www.openobject.com
● www.openerpspain.com, www.openerpsite.com
● www.openerp.cat
● Foros: www.openobject.com/forum (marzo de 2010, 50.000 posts
en 25 foros)
● IRC: www.openobject.com/irc (cada mes hay una discusión de la
comunidad con un orden del día)
● Listas de correo:
Asociadas a launchpad (código, revisiones, bugs, faqs)
Asociadas a los foros
Localización española: openerpspain@googlegroups.com
41. Comunidad OpenERP. Proyectos
Oficiales + Comunidad:
● Server
● Cliente Gtk
● Cliente web
● Addons: addons, addonsextra, addonscommunity
Comunidad:
● Localizaciones de cada país
● Koo: Cliente Koo, JasperReports, conector Kettle, ...
● Poweremail (gestión de emails desde OpenERP)
● MagentoConnect (conexión tienda web Magento)
● Invoicing (facturación automática)
● Motores de informes alternativos basados en OpenOffice
● ...
42. Comunidad OpenERP. Gestión código
Versiones:
● 4.2 (anticuada)
● 5.0 (estable)
● trunk (desarrollo, futura 6.0)
Branches (ramas) de módulos:
● addons: 110 módulos. Quality team
● addonsextra: +250 módulos. Commiter team
● addonscommunity: +50 módulos. Community team
● Ramas personales y petición de fusión con las ramas “oficiales”
● ...
Milestones (hitos): ..., 5.0.6, 5.0.7, 5.0.8, 5.0.9, 5.0.10, ...
43. Comunidades de software libre
Comunidad OpenERP
¿Preguntas?
Jordi Esteve (UPC + Zikzakmedia)
III Jornadas de OpenERP. Universidad de Deusto, 13 mayo 2010