Nº 199, mayo-junio 2009, año XXXV Nº 199, mayo-junio 2009, año XXXV Nº 199, mayo-junio 2009, año XXXV Nº 199, mayo-junio 2009, año XXXV Nº 199, mayo-junio 2009, año XXXV

Monografía del próximo número: "Calidad del software"

editorialComunicado de Prensa de ATI sobre la creación delConsejo de Colegios de Ingeniería Informáticas (17/6/2009) > 02en resumenUn mundo dinámico donde lo importante es sumar > 02Llorenç Pagés CasasIFIPReunión del TC6 (Communication Networks) > 03Ramón Puigjaner TrepatReunión del TC1 (Foundations of Computer Science) > 03Michael Hinchey, Joaquim Gabarro Vallés

monografíaSoftware libre para empresas(En colaboración con UPUPUPUPUPGRADE)Editores invitados: Jesús M. González-Barahona, Teo Romera Otero y Böjrn LundellPresentación. Software libre para empresas: ¡crea tu producto,alimenta tu comunidad y disfruta tu parte! > 04Jesús M. Gonzalez-Barahona, Teófilo Romera Otero, Björn LundellEl software libre en el mundo corporativo > 08Jesús M. Gonzalez-Barahona, Teófilo Romera Otero, Björn LundellBuenas prácticas para la adopción del software libre > 12Carlo DaffaraConstruir y mantener una comunidad de práctica: método aplicadoa proyectos de software libre > 17Stéphane Ribas, Michel CezonDinamización de comunidades en proyectos de software libre > 21Martin MichlmayrLa Comunidad Morfeo: estrategias Open Source para la Open Innovation > 25Cristina Breña, Andrés Leonardo Martínez OrtizAplicación de los principios del software libre en líneas de producto > 29Frank van der LindenAbordar las necesidades de la industria en Software Libre > 36Jan Henrik ZiesingSpagoWorld, la iniciativa de software libre de Engineering > 39Gabriele RuffattiUna oportunidad para las empresas de software libre: mercado emergente > 44en los países en vías de desarrolloSusana Muñoz Hernández, Jesús Martínez Mateo

secciones técnicas

Enseñanza Universitaria de la InformáticaUn juego de rol para la enseñanza de la profesión informática > 47Agustín Cernuda del Río, Manuel Quintela Pumares, Miguel Riesco AlbizuGestión del ConocimientoDatos, conocimiento, información... en este orden > 51Joan Baiget SoléInformática GráficaTratamiento de geoinformación a nivel peatonal: animación 3D a partir demetainformación Exif > 53Ricardo Navarro Moral, Francisco R. Feito Higueruela, Rafael J. Segura Sánchez,Angel L. García FernándezTecnologías para la EducaciónInfluencia en el rendimiento académico de la interacción en línea de los alumnos:estudio y análisis comparativo entre diferentes modalidades de enseñanza > 59Ángel Hernández García, Santiago Iglesias Pradas, Julián Chaparro Peláez, Félix Pascual MiguelReferencias autorizadas > 63

sociedad de la información

Prospectiva TecnológicaUn metaanálisis de la actividad prospectiva internacional en el campo delos Sistemas y Tecnologías de la Información > 70Víctor Amadeo Bañuls Silvera, José Luis Salmerón SilveraPersonal y transferibleUna paradoja divina > 73Antonio Vaquero SánchezProgramar es crearReconstrucción (CUPCAM 2007, problema G, solución) > 75Enrique Martín Martín, Cristóbal Pareja Flores

asuntos interioresCoordinación Editorial / Programación de Novática / Socios Institucionales > 77

sumario

NováticaNováticaNováticaNováticaNovática, revista fundada en 1975 y decana de la prensainformática española, es el órgano oficial de expresión y formacióncontinua de ATIATIATIATIATI (Asociación de Técnicos de Informática),organización que edita también la revista REICISREICISREICISREICISREICIS (RevistaEspañola de Innovación, Calidad e Ingeniería del Software).NováticaNováticaNováticaNováticaNovática edita asimismo UUUUUPPPPPGRADE, revista digital de CEPISCEPISCEPISCEPISCEPIS(Council of European Professional Informatics Societies), enlengua inglesa, y es miembro fundador de UPUPUPUPUPENET (UPUPUPUPUPGRADEEEEEEuropean NETNETNETNETNETwork).

<http://www.ati.es/novatica/><http://www.ati.es/reicis/>

<http://www.upgrade-cepis.org/>

ATIATIATIATIATI es miembro fundador de CEPIS CEPIS CEPIS CEPIS CEPIS (Council of European ProfessionalInformatics Societies) y es representante de España en IFIP IFIP IFIP IFIP IFIP (InternationalFederation for Information Processing); tiene un acuerdo de colaboracióncon ACMACMACMACMACM (Association for Computing Machinery), así como acuerdos devinculación o colaboración con AdaSpainAdaSpainAdaSpainAdaSpainAdaSpain, AI2,AI2,AI2,AI2,AI2, ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI e HispalinuxHispalinuxHispalinuxHispalinuxHispalinux,junto a la que participa en ProInnovaProInnovaProInnovaProInnovaProInnova.

Consejo EditorialConsejo EditorialConsejo EditorialConsejo EditorialConsejo EditorialJoan Batlle Montserrat, Rafael Fernández Calvo, Luis Fernández Sanz, Javier LópezMuñoz, Alberto Llobet Batllori, Gabriel Martí Fuentes, Josep Molas i Bertran, JoséOnofre Montesa Andrés, Olga Pallás Codina, Fernando Piera Gómez (Presidente delConsejo), Ramon Puigjaner Trepat, Miquel Sarries Griñó, Adolfo Vázquez Rodríguez,Asunción Yturbe Herranz

Coordinación EditorialCoordinación EditorialCoordinación EditorialCoordinación EditorialCoordinación EditorialLlorenç Pagés Casas<pages@ati.es>Composición y autoediciónComposición y autoediciónComposición y autoediciónComposición y autoediciónComposición y autoediciónJorge Llácer Gil de RamalesTraduccionesTraduccionesTraduccionesTraduccionesTraduccionesGrupo de Lengua e Informática de ATI <http://www.ati.es/gt/lengua-informatica/>AdministraciónAdministraciónAdministraciónAdministraciónAdministraciónTomás Brunete, María José Fernández, Enric Camarero, Felicidad López

Secciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónJosé María Gómez Hidalgo (Optenet), <jmgomezh@yahoo.es>Manuel J. Maña López (Universidad de Huelva), <manuel.mana@diesia.uhu.es>Administración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaFrancisco López Crespo (MAE), <flc@ati.es>ArquitecturasArquitecturasArquitecturasArquitecturasArquitecturasEnrique F. Torres Moreno (Universidad de Zaragoza), <enrique.torres@unizar.es>Jordi Tubella Morgadas (DAC-UPC), <jordit@ac.upc.es>Auditoría SITICAuditoría SITICAuditoría SITICAuditoría SITICAuditoría SITICMarina Touriño Troitiño, <marinatourino@marinatourino.com>Manuel Palao García-Suelto (ASIA), <manuel@palao.com>Derecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasIsabel Hernando Collazos (Fac. Derecho de Donostia, UPV), <isabel.hernando@ehu.es>Elena Davara Fernández de Marcos (Davara & Davara), <edavara@davara.com>Enseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaCristóbal Pareja Flores (DSIP-UCM), <cpareja@sip.ucm.es>J. Ángel Velázquez Iturbide (DLSI I, URJC), angel.velazquez@urjc.es>Entorno digital personalEntorno digital personalEntorno digital personalEntorno digital personalEntorno digital personalAndrés Marín López (Univ. Carlos III), <amarin@it.uc3m.es>Diego Gachet Páez (Universidad Europea de Madrid), <gachet@uem.es>Estándares WebEstándares WebEstándares WebEstándares WebEstándares WebEncarna Quesada Ruiz (Pez de Babel) <equesada@pezdebabel.com>José Carlos del Arco Prieto (TCP Sistemas e Ingeniería) <jcarco@gmail.com>Gestión del ConocimientoGestión del ConocimientoGestión del ConocimientoGestión del ConocimientoGestión del ConocimientoJoan Baiget Solé (Cap Gemini Ernst & Young), <joan.baiget@ati.es>Informática y FilosofíaInformática y FilosofíaInformática y FilosofíaInformática y FilosofíaInformática y FilosofíaJosé Angel Olivas Varela (Escuela Superior de Informática, UCLM) <joseangel.olivas@uclm.es>Karim Gherab Martín (Harvard University) <kgherab@gmail.com>Informática GráficaInformática GráficaInformática GráficaInformática GráficaInformática GráficaMiguel Chover Sellés (Universitat Jaume I de Castellón), <chover@lsi.uji.es>Roberto Vivó Hernando (Eurographics, sección española), <rvivo@dsic.upv.es>Ingeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareJavier Dolado Cosín (DLSI-UPV), <dolado@si.ehu.es>Luis Fernández Sanz (Universidad de Alcalá), <luis.fernandezs@uah.es>Inteligencia ArtificialInteligencia ArtificialInteligencia ArtificialInteligencia ArtificialInteligencia ArtificialVicente Botti Navarro, Vicente Julián Inglada (DSIC-UPV)<{vbotti, vinglada}@dsic.upv.es>Interacción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorPedro M. Latorre Andrés (Universidad de Zaragoza, AIPO) <platorre@unizar.es>Francisco L. Gutierrez Vela (Universidad de Granada, AIPO) <fgutierr@ugr.es>Lengua e InformáticaLengua e InformáticaLengua e InformáticaLengua e InformáticaLengua e InformáticaM. del Carmen Ugarte García (IBM), <cugarte@ati.es>Lenguajes informáticosLenguajes informáticosLenguajes informáticosLenguajes informáticosLenguajes informáticosÓscar Belmonte Fernández (Univ. Jaime I de Castellón), <belfern@lsi.uji.es>Inmaculada Coma Tatay (Univ. de Valencia), <Inmaculada.Coma@uv.es>Lingüística computacionalLingüística computacionalLingüística computacionalLingüística computacionalLingüística computacionalXavier Gómez Guinovart (Univ. de Vigo), <xgg@uvigo.es>Manuel Palomar (Univ. de Alicante), <mpalomar@dlsi.ua.es>Mundo estudiantil y jóvenes profesionalesMundo estudiantil y jóvenes profesionalesMundo estudiantil y jóvenes profesionalesMundo estudiantil y jóvenes profesionalesMundo estudiantil y jóvenes profesionalesFederico G. Mon Trotti (RITSI) <gnu.fede@gmail.com>Mikel Salazar Peña (Area de Jovenes Profesionales, Junta de ATI Madrid), <mikeltxo_uni@yahoo.es>Profesión informáticaProfesión informáticaProfesión informáticaProfesión informáticaProfesión informáticaRafael Fernández Calvo (ATI), <rfcalvo@ati.es>Miquel Sàrries Griñó (Ayto. de Barcelona), <msarries@ati.es>Redes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosJosé Luis Marzo Lázaro (Univ. de Girona), <joseluis.marzo@udg.es>Germán Santos Boada (UPC), <german@ac.upc.es>SeguridadSeguridadSeguridadSeguridadSeguridadJavier Areitio Bertolín (Univ. de Deusto), <jareitio@eside.deusto.es>Javier López Muñoz (ETSI Informática-UMA), <jlm@lcc.uma.es>Sistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealAlejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro (DIT-UPM),<{aalonso,jpuente}@dit.upm.es>Software LibreSoftware LibreSoftware LibreSoftware LibreSoftware LibreJesús M. González Barahona (GSYC-URJC), <jgb@gsyc.es>Israel Herráiz Tabernero (UCM), <herraiz@computer.org>Tecnología de ObjetosTecnología de ObjetosTecnología de ObjetosTecnología de ObjetosTecnología de ObjetosJesus García Molina (DIS-UM), <jmolina@um.es>Gustavo Rossi (LIFIA-UNLP, Argentina), <gustavo@sol.info.unlp.edu.ar>Tecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónJuan Manuel Dodero Beardo (UC3M), <dodero@inf.uc3m.es>César Pablo Córcoles Briongo (UOC), <ccorcoles@uoc.edu>.Tecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaDidac López Viñas (Universitat de Girona), <didac.lopez@ati.es>Francisco Javier Cantais Sánchez (Indra Sistemas), <fjcantais@gmail.com>Tendencias tecnológicasTendencias tecnológicasTendencias tecnológicasTendencias tecnológicasTendencias tecnológicasAlonso Alvarez García (TID), <aad@tid.es>Gabriel Martí Fuentes (Interbits), <gabi@atinet.es>TIC y TurismoTIC y TurismoTIC y TurismoTIC y TurismoTIC y TurismoAndrés Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Málaga)<{aguayo, guevara}@lcc.uma.es>

Las opiniones expresadas por los autores son responsabilidad exclusiva de losmismos.NováticaNováticaNováticaNováticaNovática permite la reproducción, sin ánimo de lucro, de todos los artículos, a menos quelo impida la modalidad de © o copyright elegida por el autor, debiéndose en todo caso citarsu procedencia y enviar a NováticaNováticaNováticaNováticaNovática un ejemplar de la publicación.

Coordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridPadilla 66, 3º, dcha., 28006 MadridTlfn.914029391; fax.913093685 <novatica@ati.es>Composición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaAv. del Reino de Valencia 23, 46005 ValenciaTlfn./fax 963330392 <secreval@ati.es>Administración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaVia Laietana 46, ppal. 1ª, 08003 BarcelonaTlfn.934125235; fax 934127713 <secregen@ati.es>Redacción ATI AragónRedacción ATI AragónRedacción ATI AragónRedacción ATI AragónRedacción ATI AragónLagasca 9, 3-B, 50006 Zaragoza.Tlfn./fax 976235181 <secreara@ati.es>Redacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI Andalucía <secreand@ati.es>Redacción ATI GaliciaRedacción ATI GaliciaRedacción ATI GaliciaRedacción ATI GaliciaRedacción ATI Galicia<secregal@ati.es>Suscripción y VentasSuscripción y VentasSuscripción y VentasSuscripción y VentasSuscripción y Ventas <http://www.ati.es/novatica/interes.html>, ATI Cataluña, ATI MadridPublicidadPublicidadPublicidadPublicidadPublicidadPadilla 66, 3º, dcha., 28006 MadridTlnf.914029391; fax.913093685 <novatica@ati.es>Imprenta:Imprenta:Imprenta:Imprenta:Imprenta: Derra S.A., Juan de Austria 66, 08005 Barcelona.Depósito legal:Depósito legal:Depósito legal:Depósito legal:Depósito legal: B 15.154-1975 -- ISSN: 0211-2124; CODEN NOVAECPortada: Portada: Portada: Portada: Portada: Cayendo hacia arriba - Concha Arias Pérez / © ATIDiseño:Diseño:Diseño:Diseño:Diseño: Fernando Agresta / © ATI 2003

novática nº 199 mayo-junio 20094 monografía

monografía Software libre para empresas

Editores invitados

PresentaciónSoftware libre para empresas:¡crea tu producto, alimenta tucomunidad y disfruta tu parte!

En los últimos años la relevancia que elsoftware libre ha ido ganando en diversosámbitos y niveles no ha hecho más que crecer.Está presente en los mercados, en las adminis-traciones públicas y es objeto de estudio yvaloración por parte de académicos, empre-sas e instituciones de gobierno. Se modelanprocesos de desarrollo de software siguiendopautas nacidas en las comunidades de soft-ware libre, se diseñan modelos de negociopara empresas a partir de actividades típicasde los proyectos de software libre, los parti-dos políticos comienzan a preparar accionesal respecto del software libre en sus propues-tas electorales y los gobiernos diseñan leyesrespecto a su uso. E incluso se estudianmodelos económicos alternativos en base alas características que han hecho posible unacomunidad fuerte con capacidad para coordi-nar profesionales, empresas, voluntarios einstituciones públicas alrededor de produc-tos de calidad y disponibles para cualquiera.

Mas allá del software, la cultura libre influyesin duda y a velocidad de vértigo en diversasfacetas de las tecnologías de la información,el arte, la cultura y en definitiva en nuestrasvidas. Elementos como la Wikipedia, la inno-vación abierta, la meritocracia o las licenciasalternativas para el arte y la cultura basadasen los fundamentos introducidos por el soft-ware libre (como las licencias CreativeCommons), las comunidades para compar-tir y crear en Internet como Flickr, y tantasotras novedades han sido absorbidas pornuestra sociedad líquida (que diría ZygmuntBauman) con pasmosa naturalidad y a unritmo imparable.

Los profesionales de las tecnologías de lainformación y la comunicación, así como lasempresas del sector no pueden pasar por altoestas nuevas tendencias y tanto es así queresulta difícil encontrar una sola de estasempresas que no tenga ya una estrategia clararespecto al software libre, bien sea para com-petir con él, para adoptarlo en sus modelos denegocio o para dedicarse en exclusiva a sucreación y explotación.

Este número monográfico especial ha sidoconfeccionado contactando con diferentesexpertos profesionales e investigadores delmundo de la empresa, del software libre y delas relaciones entre empresa y comunidadesde software libre. No pretendemos que seauna recopilación exhaustiva pero sí represen-

tativa del panorama actual en Europa en loque se refiere a casos descriptivos de cómo lasempresas usan y crean software libre, y espe-cialmente cómo se relacionan con otros acto-res (otras empresas, voluntarios y profesio-nales) dentro del mismo escenario.

En un primer artículo introductorio, El soft-ware libre en el mundo corporativo, los edito-res invitados del presente número, Jesús M.Jesús M.Jesús M.Jesús M.Jesús M.González BarahonaGonzález BarahonaGonzález BarahonaGonzález BarahonaGonzález Barahona, Teófilo RomeraTeófilo RomeraTeófilo RomeraTeófilo RomeraTeófilo RomeraOteroOteroOteroOteroOtero y Björn LundellBjörn LundellBjörn LundellBjörn LundellBjörn Lundell, ofrecen su visiónparticular de la importancia de que el mundoempresarial tenga estrategias de acción res-pecto del software libre. Al mismo tiempo,sirve de introducción a los nuevos términos yconceptos a los que se hace referencia en elresto del número, intentando ofrecer unamirada a vista de pájaro de los motivos y losmedios que aplican en este nuevo mundo quees el software libre para empresas.

En su artículo, Buenas prácticas para la

adopción del software libre, Carlo DaffaraCarlo DaffaraCarlo DaffaraCarlo DaffaraCarlo Daffara,reconocido experto en modelos de negociosostenibles con software libre, recoge un com-pendio de consejos y directrices que aseguranuna migración al software libre exitosa paraentornos empresariales. Este artículo abre elmonográfico porque resulta muy representa-tivo de los problemas que las empresas suelenencontrar a la hora de incluir el software libreen sus procesos o en sus modelos de negocioy al mismo tiempo puede servir al lector noiniciado como una extensión de la introduc-ción, puesto que maneja aspectos técnicosque resultan familiares al profesional delsector.

Seguidamente, el artículo Construir y mante-ner una comunidad de práctica: método apli-cado sobre proyectos de software libre mues-tra un método para la creación y gestión decomunidades que puede ser aplicado a lacreación y gestión de comunidades de soft-ware libre y especialmente a aquellas que

Jesús M. Gonzalez-Barahona1, Teófilo RomeraOtero1, Björn Lundell21Universidad Rey Juan Carlos, Madrid;2Centro de Investigación en Informática dela Universidad de Skövde, Suecia

< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >

Jesús M. Gonzalez-Barahona es profesor e investigador en la Universidad Rey Juan Carlos de Móstoles(Madrid). Comenzó a involucrarse en software libre en 1991. Desde entonces ha colaborado en nume-rosos grupos de trabajo, ha desarrollado algunas líneas de investigación y ha comenzado programas deformación diversos en la materia. También colabora con varios proyectos y asociaciones de software libre,escribe en diversos medios sobre temas relacionados con el software libre y lleva a cabo consultoría paracompañías y administraciones públicas sobre software libre, todo ello desde el marco del grupo deinvestigación GSyC/LibreSoft, <http://libresoft.es>.

Teófilo Romera Otero es Ingeniero en Informática por la Universidad Rey Juan Carlos de Madrid, dondeestá actualmente llevando a cabo tareas de investigación para la consecución de su doctorado. Susintereses académicos son el software de fuentes abiertas y cómo las empresas se relacionan con el.También está interesado en el desarrollo de software global aplicado al desarrollo de software de fuentesabiertas y la habilitación tecnológica a través de software de fuentes abiertas. Trabaja para el grupo deinvestigación GSyC/LibreSoft como coordinador de proyectos de investigación nacionales y europeos,algunos de ellos: Calibre, Edukalibre, FLOSSWorld, Morfeo, Vulcano, QualiPSo, FLOSSInclude o Tree.Otras tareas que lleva a cabo en el grupo son consultorías técnicas sobre software de fuentes abiertas yla coordinación docente del Master on Libre Software organizado por GSyC/LibreSoft. Es miembro delQualipso Network Board que gestiona la red de centros de competencia Qualipso y del grupo de trabajosobre Software Libre de la plataforma NESSI. Ha realizado estancias de investigación en la universidad deLeeds en el Reino Unido y en el Irish Software Engineering Research Centre (Lero) de la universidad deLimerick (Irlanda).

Björn Lundell es investigador en el Centro de Investigación en Informática de la Universidad de Skövde.Sus intereses académicos incluyen el software de fuentes abiertas, su evaluación y el soporte de méto-dos. Fue gestor técnico del proyecto de investigación COSI (Codeveloment Using Inner & Open Sourcein Software Intensive Products). Es miembro fundador del grupo de trabajo IFIP 2.13 sobre software librey preside la asociación industrial Open Source Sweeden. Lundell es doctor en Ciencias de la Computa-ción por la Universidad de Exeter.

novática nº 199 mayo-junio 2009 5

Software libre para empresas monografía

monografía

como OW2 o Morfeo implican relacionesentre voluntarios, profesionales y empresas.Los autores, Stéphane RibasStéphane RibasStéphane RibasStéphane RibasStéphane Ribas y MichelMichelMichelMichelMichelCezonCezonCezonCezonCezon, conocen bien tanto la comunidad delsoftware libre como el mundo empresarial ytras su paso por diversas empresasinformáticas han recalado recientemente en elmundo académico, para desde el institutoINRIA seguir ayudando a construir buenasrelaciones entre comunidades de desarrollo yempresas.

En línea con el artículo anterior, MartinMartinMartinMartinMartinMichlmyerMichlmyerMichlmyerMichlmyerMichlmyer nos aporta su trabajoDinamización de comunidades en proyectosde software libre. Se trata de un artículo quecomplementa muy bien tanto al artículo an-terior, sobre la construcción de comunidades,como al que le sigue. Sin duda, se trata de untema muy interesante y novedoso, puesto queaporta una descripción formal de la figura deldinamizador de comunidades en las grandesempresas. Un fenómeno reciente de importan-cia creciente y relativamente poco conocidohasta el momento. No en vano, Martin ha sidoen parte su propio objeto de estudio y observa-ción puesto que su trayectoria como líder dediversos proyectos de software libre de granenvergadura e importancia (incluyendo Debian)le ha llevado a ser contratado por HP paradinamizar y gestionar las relaciones entre laempresa y las comunidades de software libre.

Con una fuerte relación con los dos artículosanteriores, Andrés Leonardo MartínezAndrés Leonardo MartínezAndrés Leonardo MartínezAndrés Leonardo MartínezAndrés Leonardo MartínezOrtízOrtízOrtízOrtízOrtíz y Cristina BreñaCristina BreñaCristina BreñaCristina BreñaCristina Breña, co-fundador yresponsable de comunicación respectivamen-te de la comunidad Morfeo liderada porTelefónica I+D, presentan La ComunidadMorfeo: estrategias Open Source para laOpen Innovation. Morfeo es una comunidadde software en la que participan actores demuy diversa índole y con intereses y capacida-des dispares, y aun así exitosa. Se trata puesde un caso de estudio descriptivo de la historiay peculiaridades de la comunidad Morfeo.

Una vez cubierto el tan interesante tema de las

relaciones entre comunidades de desarrollode software libre y empresas, el número con-tinúa con algunos otros trabajos menos orien-tados a la creación y mantenimiento de comu-nidades pero mucho más enfocados a ladescripción de casos de éxito, oportunidadesy estrategias que las empresas siguen ya otienen a su disposición para la adecuadaexplotación de nuevos modelos de negociobasados en software libre.

Desde su amplia experiencia en Philips, Frank Frank Frank Frank Frankvan der Lindenvan der Lindenvan der Lindenvan der Lindenvan der Linden, reconocido experto en soft-ware libre y líneas de producto, escribe su artícu-lo Aplicación de los principios del software libreen líneas de producto en el que investiga lasdiversas opciones en las que el software libre ylas metodologías de desarrollo asociadas pue-den utilizarse para reducir los problemas deldesarrollo de software global (GSD o desarro-llo distribuido) así como para aumentar lacalidad del software que se desarrolla.

Jan Henrik ZiesingJan Henrik ZiesingJan Henrik ZiesingJan Henrik ZiesingJan Henrik Ziesing, científico investiga-dor del Instituto Fraunhofer en sistemas decomunicación abiertos en Berlín, aporta untrabajo sobre las necesidades de la industriaen el ámbito de software libre y la participa-ción del Instituto Fraunhofer FOKUS en elproyecto Qualipso, el mayor proyecto delprograma marco de la Comisión Europea delos que tratan exclusivamente con el softwarelibre. El artículo lleva por título Abordar lasnecesidades de la industria en Software Libre.Muestra la estrategia que Fraunhofer FOKUStiene preparada para llevar sus modelos yservicios de interoperabilidad tradicionales alámbito del software libre, mediante la crea-ción de un nuevo centro de competencia delsoftware libre que ofrezca servicios al tejidoempresarial de la región de Berlín.

En el siguiente artículo, SpagoWorld, la ini-ciativa de software libre de Engineering,Gabriele RuffatiGabriele RuffatiGabriele RuffatiGabriele RuffatiGabriele Ruffati, director de la unidad deArquitecturas y Consultoría de la división deI+D en Engineering, muestra un caso deestudio basado en la experiencia de la compa-

ñía. Se describen las razones, la estrategia y lasrelaciones de Engineering con las comunida-des, así como los resultados obtenidos por laempresa en sus productos libres.

Por último y para cerrar el número, SusanaSusanaSusanaSusanaSusanaMuñoz Hernández Muñoz Hernández Muñoz Hernández Muñoz Hernández Muñoz Hernández y Jesús MartínezJesús MartínezJesús MartínezJesús MartínezJesús MartínezMateoMateoMateoMateoMateo, profesora y estudiante de doctoradorespectivamente, de la Universidad Politécnicade Madrid (UPM) e investigadores ambos delgrupo de cooperación TEDECO (TEcnologíapara el DEsarrollo y la COoperación), pre-sentan el artículo Una oportunidad para lasempresas de software libre: mercado emer-gente en los países en vías de desarrollo. En élse describen oportunidades y mecanismosmediante los cuales el software libre puedeayudar a la creación del tejido empresarial enlos países en vías de desarrollo.

En definitiva, el presente número especialSoftware libre para empresas pretende mos-trar un panorama actual de las iniciativas,estrategias y acciones que las empresas euro-peas están llevando a cabo respecto al soft-ware libre. Hemos intentado recabar un con-junto de artículos equilibrado y de fuentes yprocedencias diversas, incluyendo Italia, Fran-cia, Holanda, Alemania y España, con auto-res de renombre que se sitúan en la franja,cada vez más amplia, en la que se solapan lascomunidades de software libre y el mundoempresarial, y ofreciendo puntos de vista porparte de universidades, grandes empresas,individuos y organismos públicos. Espera-mos que el resultado sea del agrado del lectory les emplazamos a seguir las evolucionesfuturas de la presente publicación.

AgradecimientosLos editores invitados de este número especial deNováticaNováticaNováticaNováticaNovática quieren agradecer al equipo de ATI yen especial a Llorenç Pagés, por su ayuda y buenhacer. También agradecer a Miguel Vidal suayuda como coordinador de las traducciones y alos traductores del grupo GSyC/LibreSoft por sumagnífico trabajo.

Referencias útiles sobre "Software Libre en la empresa"

Las referencias que se citan a continuación,junto con las proporcionadas en cada uno de losartículos, tienen como objetivo ayudar a loslectores a profundizar en los temas tratados enesta monografía permitiendo contrastar ideas yobtener información actualizada.

LibrosLibrosLibrosLibrosLibrosDan Woods, Gautam Guliani.Dan Woods, Gautam Guliani.Dan Woods, Gautam Guliani.Dan Woods, Gautam Guliani.Dan Woods, Gautam Guliani. Open

Source for the enterprise. O’Reilly Media, Inc.(2005). ISBN-10: 0596101198. Este es ungran libro que explica el software libre desde

el punto de vista empresarial. Ofrece ideasbrillantes sobre la gestión de proyectos y lapaquetización de software libre.

Jan Sandred.Jan Sandred.Jan Sandred.Jan Sandred.Jan Sandred. Managing Open SourceProjects. John Wiley & Sons, 2001. Un ma-nual sobre cómo abordar los principios yventajas de la programación de software libre.

Jesús González Barahona, JoaquínJesús González Barahona, JoaquínJesús González Barahona, JoaquínJesús González Barahona, JoaquínJesús González Barahona, JoaquínSeoane Pascual, Gregorio Robles. Seoane Pascual, Gregorio Robles. Seoane Pascual, Gregorio Robles. Seoane Pascual, Gregorio Robles. Seoane Pascual, Gregorio Robles. In-troducción al Software Libre. Es un libro detexto usado en el tema de Software Libre delprograma de doctorado de la Universidad Rey

Juan Carlos y en algunos otros programas dela Universitat Oberta de Catalunya. Cubreprácticamente todos los temas relacionadoscon el software libre. Este es un libro impres-cindible. <http://ocw.uoc.edu/computer-science-technology-and-multimedia/introduction-to-free-software/materials/>.

Karl Fogel.Karl Fogel.Karl Fogel.Karl Fogel.Karl Fogel. Producing Open SourceSoftware: How to Run a Successful FreeSoftware Project. O’Reilly Media, Inc. (2005).ISBN-10: 0596007590. Este es un libro sobreel aspecto humano del desarrollo de software

novática nº 199 mayo-junio 20096 monografía

monografía Software libre para empresas

libre. Describe cómo operan los proyectosexitosos, las expectativas de usuarios ydesarrolladores, y la cultura del software libre<http://producingoss.com/>.

Chris DiBona, Sam Ockman, MarkChris DiBona, Sam Ockman, MarkChris DiBona, Sam Ockman, MarkChris DiBona, Sam Ockman, MarkChris DiBona, Sam Ockman, MarkStone et al. Stone et al. Stone et al. Stone et al. Stone et al. Open Sources: Voices from theopen source revolution. O’Reilly Media, Inc.(1999). ISBN-10: 1565925823. Una clásica yexcelente compilación de artículos, ensayos yescritos de importantes actores en la escenadel software libre. Entre ellos se encuentranLinus Torvalds, Eric S. Raymond, RichardStallman, Bruce Perens y muchos otros<http://oreilly.com/catalog/opensources/book/toc.html>.

Donald K Rosenberg.Donald K Rosenberg.Donald K Rosenberg.Donald K Rosenberg.Donald K Rosenberg. Open Source:The Unauthorized White Papers. HungryMinds, 2000. ISBN-10: 0764546600. Se tratade una vision general del software libre <http:// w w w . s t r o m i a n . c o m / B o o k /FrontMatter.html>.

Lawrence Rosen. Lawrence Rosen. Lawrence Rosen. Lawrence Rosen. Lawrence Rosen. Open SourceLicensing: Software Freedom and IntellectualProperty Law. Prentice Hall PTR, 2004. ISBN-10: 0131487876. Este libro trata de casi todolo que hay que saber sobre las licencias de

software libre <http://www.rosenlaw.com/oslbook.htm>.

Lawrence Lessig.Lawrence Lessig.Lawrence Lessig.Lawrence Lessig.Lawrence Lessig. Free Culture. PenguinPress HC, 2004. ISBN-10: 1594200068. Estelibro explica cómo los grandes medios decomunicación usan la tecnología y las leyespara bloquear la cultura y controlar la crea-tividad <http://free-culture.org/>.

Karl Fogel, Moshe Bar.Karl Fogel, Moshe Bar.Karl Fogel, Moshe Bar.Karl Fogel, Moshe Bar.Karl Fogel, Moshe Bar. Open SourceDevelopment with CVS. Paraglyph Inc.(2003). ISBN-10: 1932111816. Explica mu-chos aspectos del software libre a través de ladescripción de técnicas y herramientas de de-sarrollo. <http://cvsbook.red-bean.com/>.Otras publicacionesOtras publicacionesOtras publicacionesOtras publicacionesOtras publicaciones

Qualipso Project.Qualipso Project.Qualipso Project.Qualipso Project.Qualipso Project. Qualipso deliverableon OSS business models (2008). Explicamuchos aspectos de los modelos de negociodel software libre junto con el estado del arteactual <http://qualipso.org/sites/default/f i l e s /media /A2/A2 .D1.2 .3%20The%20business%20models%20for%20using%20OS.pdf>.

A. Abella, M. A. Segovia. A. Abella, M. A. Segovia. A. Abella, M. A. Segovia. A. Abella, M. A. Segovia. A. Abella, M. A. Segovia. Libroblanco del software libre en España (2007).<http:// l ibroblanco.com/document/

III_libro_blanco_del_software_libre.pdf>.2020 FLOSS Roadmap. Esta “hoja de

ruta” fue presentada en el OpenWorldForum2008 en Paris. En un documento muy útilcreado de forma colaborativa por un granconjunto de expertos de diferentes empresasy entidades <http://www.2020flossroadmap.org/>.

Rishab Aiyer Ghosh et al. Rishab Aiyer Ghosh et al. Rishab Aiyer Ghosh et al. Rishab Aiyer Ghosh et al. Rishab Aiyer Ghosh et al. Study onthe: Economic impact of open source soft-ware on innovation and the competitivenessof the Information and CommunicationTechnologies (ICT) sector in the EU(FLOSSImpact Report 2006). Este informefue elaborado en el marco del proyectoFLOSSImpact <http://www.flossimpact.eu/> y una gran cantidad de investigadores par-ticiparon en él <http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf>.

Qualipso Project.Qualipso Project.Qualipso Project.Qualipso Project.Qualipso Project. Analysis of mostimportant aspects of Open SourceCompetence Centres. <http://qualipso.org/node/48>.

novática nº 199 mayo-junio 20098 monografía

monografía Software libre para empresas

El software libreen el mundo corporativo

Jesús M. Gonzalez-Barahona1,Teófilo Romera Otero1, BjörnLundell21Universidad Rey Juan Carlos, Madrid;2Centro de Investigación en Informática dela Universidad de Skövde, Suecia

< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< { j g b , t e o } @ g s y c . e s > ,< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >< b j o r n . l u n d e l l @ h i s . s e >

Resumen: el software libre es un nuevo mundo en sí mismo tanto para las empresas como para losprofesionales. Es por eso que comprender cómo encontrar oportunidades en él es cada vez másimportante a medida que los productos de software libre se usan más y más en la industria del softwarey en otros sectores que dependen del software para sus actividades. En este texto, se exploran algunosde los nuevos aspectos que aparecen al aproximarse al software libre y cómo las empresas reaccionan aellos.

Palabras clave: comunidades, empresas, estrategia, FLOSS, OSS, software libre.

Autores

Jesús M. Gonzalez-Barahona es profesor e investigador en la Universidad Rey Juan Carlos de Móstoles(Madrid). Comenzó a involucrarse en software libre en 1991. Desde entonces ha colaborado en nume-rosos grupos de trabajo, ha desarrollado algunas líneas de investigación y ha comenzado programas deformación diversos en la materia. También colabora con varios proyectos y asociaciones de software libre,escribe en diversos medios sobre temas relacionados con el software libre y lleva a cabo consultoría paracompañías y administraciones públicas sobre software libre, todo ello desde el marco del grupo deinvestigación GSyC/LibreSoft, <http://libresoft.es>.

Teófilo Romera Otero es Ingeniero en Informática por la Universidad Rey Juan Carlos de Madrid, dondeestá actualmente llevando a cabo tareas de investigación para la consecución de su doctorado. Susintereses académicos son el software de fuentes abiertas y cómo las empresas se relacionan con el.También está interesado en el desarrollo de software global aplicado al desarrollo de software de fuentesabiertas y la habilitación tecnológica a través de software de fuentes abiertas. Trabaja para el grupo deinvestigación GSyC/LibreSoft como coordinador de proyectos de investigación nacionales y europeos,algunos de ellos: Calibre, Edukalibre, FLOSSWorld, Morfeo, Vulcano, QualiPSo, FLOSSInclude o Tree.Otras tareas que lleva a cabo en el grupo son consultorías técnicas sobre software de fuentes abiertas yla coordinación docente del Master on Libre Software organizado por GSyC/LibreSoft. Es miembro delQualipso Network Board que gestiona la red de centros de competencia Qualipso y del grupo de trabajosobre Software Libre de la plataforma NESSI. Ha realizado estancias de investigación en la universidad deLeeds en el Reino Unido y en el Irish Software Engineering Research Centre (Lero) de la universidad deLimerick (Irlanda).

Björn Lundell es investigador en el Centro de Investigación en Informática de la Universidad de Skövde.Sus intereses académicos incluyen el software de fuentes abiertas, su evaluación y el soporte de méto-dos. Fue gestor técnico del proyecto de investigación COSI (Codeveloment Using Inner & Open Sourcein Software Intensive Products). Es miembro fundador del grupo de trabajo IFIP 2.13 sobre software librey preside la asociación industrial Open Source Sweeden. Lundell es doctor en Ciencias de la Computaciónpor la Universidad de Exeter.

1. El concepto de software libre,(free, open source) softwareSoftware libre es el término que utilizamos eneste artículo para referirnos tanto al "freesoftware" según lo define la Free SoftwareFoundation1 , como al "open source soft-ware" (software de fuentes abiertas) según lodefine la Open Source Initiative2 . Aunqueambas definiciones son diferentes, cubrencasi la misma colección de software. En cual-quier caso, los términos (al menos en inglés)no son intercambiables. Para algunos, lapalabra "free" (que se puede traducir comolibre o como gratis al castellano) se refiere alas libertades que el software libre brinda y poresto mismo, nunca debería ser omitida. Paraotros, el sentido ambiguo de la palabra "free"que puede entenderse también como "gratis"es un problema para el entendimiento delconcepto, especialmente en entornos empre-sariales. Para evitar esta discusión, usaremosel término software libre a lo largo de estetexto.

En cualquier caso, podemos aportar unabreve descripción del software libre mencio-nando las "cuatro libertades". El softwarelibre es aquel que permite a los que lo reciben:ejecutarlo y usarlo; estudiarlo y adaptarlo anecesidades específicas; redistribuirlo a otros;y mejorarlo y añadirle funcionalidad. Todasestas libertades pueden ejercerse una vez queel software es obtenido, sin necesidad depermisos adicionales de los dueños del co-pyright más allá de la licencia que se aplicapara ese software.

Desde este punto de vista, el software libre esprincipalmente un concepto legal. Define al-gunos permisos básicos que los dueños delcopyright garantizan a aquellos a quienes danel software. De hecho, los dueños del copyrig-ht no ceden todos sus derechos. Algunosquedan reservados en forma de cláusulas ycondiciones especificadas en las licencias desoftware libre.

Desde un punto de vista económico y denegocio, es importante remarcar que no seespecifica nada acerca de cómo se obtiene elsoftware. Puede ser obtenido gratis de unrepositorio público en Internet o compradopor un sustancioso precio en una tienda,puede que en una bonita caja.

Desde un punto de vista técnico, el softwarelibre no es una tecnología en sí mismo. Dehecho, la única característica tecnológicacomún para que un programa sea softwarelibre, es que el código fuente ha de estar

disponible (el término "software de fuentesabiertas" hace hincapié en esto). Pero apartede este hecho, existen algunas particularida-des comunes en la manera en que se desarrollael software libre: modelos de desarrollo abier-tos, con más información disponible pública-mente; existencia de comunidades de soporte;mezcla de voluntarios y desarrolladores pa-gados; meritocracia y reglas de gobierno ba-sadas en la comunidad, etc.

Desde un punto de vista ético, la ética hackeres una fuerte convicción para muchos de losparticipantes en los proyectos de softwarelibre, pero no se trata de un aspecto "obliga-torio". De hecho, muchos otros no la recono-cerán o incluso no saben de qué se trata.

Puede que esta breve introducción a la idea de

software libre sea suficiente para mostrarcómo de complejo es este fenómeno, conimplicaciones legales, de negocio, técnicas yéticas. Debido a esta naturaleza diversa y lasinterrelaciones de los diferentes intereses de lagente que participa, no suele ser fácil deentender para los neófitos.

2. Problemas comunes que en-cuentran las empresasEn algún momento una empresa, que puedeestar enfocada a las TIC o bien utilizarlaspara otros propósitos, considera el producir,integrar, usar o mejorar servicios basados ensoftware libre. Existen varias razones quepueden llevarla a este punto. Razones amplia-mente discutidas en otros lugares y que noserán consideradas aquí. En lugar de centrar-se en esas razones, este artículo toma esa

novática nº 199 mayo-junio 2009 9

Software libre para empresas monografía

monografía

decisión de "pasarse al software libre", quecada vez es más común en el mundo empre-sarial, como el punto de partida.

De hecho, una vez que se ha tomado esadecisión es cuando viene la parte más difícil.Las empresas han de lidiar, a partir de esepunto, con algunos aspectos que si son ma-nejados con acierto pueden producir benefi-cios considerables, pero si son pasados poralto, pueden también ser causa de numerososriesgos y problemas. Muchos de estos aspec-tos son someramente discutidos en el resto deesta sección.

2.1. Lidiar con comunidadesEl desarrollo de software libre se suele llevara cabo en comunidades que no sólo incluyena los desarrolladores principales, sino tam-bién a colaboradores esporádicos odesarrolladores de productos relacionados(por ejemplo de ramas alternativas del mismosoftware, para el uso corporativo) y usuariosde diferentes tipos (desde usuarios finales queno saben nada del desarrollo a integradorescon experiencia que conocen el producto casitan bien como los desarrolladores principa-les). Los individuos en estas comunidadespueden ser simplemente voluntarios que de-penden de su propia motivación, profesiona-les contratados por empresas para contribuirde acuerdo a los intereses de estas o inclusoalguna combinación de ambos.

Cualquier compañía que se acerque (o quepretenda crear) a una de estas comunidadesse enfrentará a un entorno bastante diferentede las relaciones contractuales que mantienecon otras compañías o empleados y a las queestá acostumbrada. Por ejemplo, normal-mente no hay contratos que regulen las rela-ciones entre participantes en la comunidad yque puedan comprometer a la gente una vezfirmados. Al contrario, la motivación y lacreación de relaciones fructíferas para todaslas partes es aquí el modus operandi. Adap-tarse a estas nuevas reglas no es siempre fácil.

La imagen corporativa también adquiere unanueva dimensión en estos entornos. Cuandouna empresa (generalmente a través de susempleados) se convierte en miembro de unacomunidad de software libre, losdesarrolladores comienzan a forjarse unaimagen de la empresa, que normalmente sesobrepone a la imagen "tradicional" de dichaempresa. Otros comienzan a considerarla entérminos de cuánto esa empresa contribuye ala comunidad, cuánto se beneficia de ella,cómo colabora con otros participantes den-tro de ella o si es percibida como si estuvieraintentando controlarla. Esta imagen puedeproducir todo tipo de efectos secundarios.

2.2. Asuntos legalesLas licencias de software libre, aunque sebasan en las mismas leyes de propiedad inte-lectual con las que las empresas de TIC estánfamiliarizadas, son utilizadas de modos muydiferentes. Lamentablemente, sigue siendo

poco común encontrar expertos legales conexperiencia y conocimientos plenos en losmodelos de licenciamiento libres. Pero anali-zar los esquemas de licenciamiento con acier-to y comprender no sólo sus implicacioneslegales, sino también las económicas o lastécnicas, es de crucial importancia para lascompañías. Los esquemas de desarrollo, ladiseminación de nuevas tecnologías o losmodelos de negocio se ven normalmente res-tringidos o potenciados dependiendo de laslicencias que entren en juego.

De hecho, las licencias de software libre son dealgún modo el tejido que mantiene unidos atodos los actores interesados en un productode software libre. Dependiendo de la licenciautilizada, de cómo es explicada y cómo se hacecumplir, otros actores podrán estar más omenos interesados en colaborar. Las licen-cias también brindan una serie de garantías aempresas interesadas en un producto y tienenimpacto en muchos aspectos diferentes inclu-yendo la reutilización de componentes o ladependencia estratégica. Por supuesto quetambién muestran una fuerte relación conotros aspectos legales que preocupan a lascompañías, como las leyes reguladoras de lapropiedad industrial (patentes).

A pesar de la importancia de las licencias en elmundo del software libre, su estudio detalla-do no es siempre simple. De hecho, es uncampo que el mundo corporativo suele reco-nocer como potencialmente problemático.

2.3. Nuevos procesos de desarrolloEl software libre puede ser desarrollado usan-do métodos tradicionales, que son comunesen las empresas de desarrollo de software,pero este no suele ser el caso. Las comunida-des de software libre suelen utilizar sus pro-pios procesos, que tienen en cuenta o inclusoaprovechan las características particularesdel equipo de desarrollo. Una de las principa-les diferencias que normalmente encuentranlas compañías es que los desarrolladores noestán atados por contratos o trabajan parauna única compañía.

Al contrario, las comunidades de desarrollode software libre por regla general, estáncompuestas de una mezcla de voluntarios yprofesionales contratados por diferentesempresas. Debido a esta mezcolanza, lasrelaciones entre desarrolladores, y entre lascompañías y los desarrolladores, son bastan-te diferentes a las de los proyectos tradiciona-les, con una jerarquía clara de gestión y res-tricciones contractuales claras si varias em-presas se involucran a un tiempo.

En la mayoría de los proyectos de softwarelibre, la palabra clave es: motivación. Losdesarrolladores no pueden ser "gestionados"en el sentido clásico de la palabra. Por contra,trabajan juntos, con procesos de toma dedecisiones y planificación normalmente basa-dos en el concepto de meritocracia y confianzamutua. Por supuesto esto no significa que no

haya toma de decisiones, o que las opinionesy propuestas de todos los participantes setengan en consideración en la misma medida.Los proyectos de software libre suelen seguirciertas reglas, que en algunos casos existenpor escrito (al menos parcialmente), peropueden ser muy diferentes de aquellas que seutilizan en el mundo empresarial.

Este nuevo entorno suele ser difícil de entenderpara algunos desarrolladores de empresas, quepuede ser que tengan muchos años de experien-cia, pero que pueden ser desconocedores de lasparticularidades de los proyectos de softwarelibre, como por ejemplo las posibilidades de queuna contribución sea aceptada o no o cómohacerla de la mejor manera para que lo sea, quees una de las cosas que puede ser difícil deentender para ellos.

Cuando una empresa adopta un producto desoftware libre o decide lanzar el suyo propio,este tipo de problemas han de ser tenidos encuenta. De cualquier modo, hay diferentesestrategias para lidiar con ellos, desde contra-tar nuevo personal con experiencia en entornosde software libre hasta proporcionar forma-ción al equipo existente, para que aprendan yexperimenten el tipo de situaciones que se vana encontrar.

2.4. Impulsar un productoCuando una empresa lanza un nuevo produc-to de software libre, normalmente está intere-sada en mantener algún tipo de control sobreél y su evolución futura. En el caso del soft-ware propietario, este control se ve garantiza-do por los estrictos términos de las licencias.Pero si se trata de software libre, otros puedentrabajar en él también, mejorarlo (puede quede una manera en que a la empresa no le guste)y redistribuir nuevas versiones, proporcionarservicios basados en él, y puede que, con eltiempo, hacerse con el control del producto(siendo por ejemplo que distribuya la versiónmás conocida y usada).

Para evitar esto, las empresas pueden utilizardiferentes estrategias, pero no dejan de serestrategias en un nuevo entorno para ellas. Dehecho, están basadas en mantener su estatusde productor principal del producto, que nor-malmente depende de cuánto esfuerzo y re-cursos están dispuestas a dedicar al productouna vez ha sido distribuido. Es por esto quehan de planear de antemano si no quierenarriesgarse a perder su posición privilegiada.La situación es más problemática cuando laempresa no es el único productor, sino que seha unido a una comunidad de desarrollo.

Normalmente, son varias las compañías quecompiten en ella por ser consideradas "cabezadel proyecto" Buscar situaciones sinérgicasque involucren a otros actores y entendercomo contribuir a la creación de una comu-nidad sana que asegure la viabilidad del pro-yecto al mismo tiempo que se mantenga uncierto grado de control sobre ciertas decisio-nes, es un juego difícil.

novática nº 199 mayo-junio 200910 monografía

monografía Software libre para empresas

3. Nuevas estrategias para nuevassituacionesEl software libre es un mundo nuevo para lascompañías. Es territorio desconocido no sólopara los que producen software como suprincipal línea de actividad, sino también paraaquellos que necesitan software para susproductos o servicios. Esta última categoría,engloba a una enorme porción de todas lascompañías, puesto que son estratégicamentemás y más dependientes del software.

Por tanto, se necesitan nuevas estrategias ymuchas compañías las están explorando ac-tivamente para beneficiarse del software libre,para usar software libre como medio parareforzar otros fines, o incluso como parteintegral de la política de negocio de la compa-ñía. En esta sección se muestran algunas deestas estrategias, las cuales en muchos casosvienen a describir nuevas maneras de colabo-rar con otros actores.

3.1. Comunidades de empresasLas comunidades de empresas basadas en elsoftware libre son una nueva forma de cola-boración empresarial no basada en relacionescontractuales. El núcleo alrededor del cual seforma la comunidad suele ser un conjunto deproyectos de software libre que pueden estarinterrelacionados o no. Las empresas partici-pan en la comunidad porque tienen algún tipode interés en el software (producirlo, usarlo,proveer servicios alrededor de él, etc.), o inclu-so en la comunidad misma, por las oportu-nidades de negocio que pueden surgir de ella.De alguna manera, estas comunidades estánmodeladas según las comunidades tradicio-nales de software libre pero con la diferenciaprincipal de que están compuestas por com-pañías en lugar de por individuos. No suelenestar sujetas a alianzas institucionales for-males, aunque en algunos casos existe elconcepto explícito de membresía. Los mis-mos principios de meritocracia y "los que máscontribuyen son los que deciden" que se en-cuentran en otras comunidades de softwarelibre, también se ponen en funcionamientoaquí , hasta cierto punto.

Estas comunidades de empresas son en partesimilares a los grupos de interés informalespero con un lazo especial que armoniza losdiferentes intereses: el código que se produceen la comunidad. En este marco, las empresasinteresadas en obtener un producto concretosimplemente empiezan a desarrollarlo, puedeque tras una colaboración pactada con otrosactores. Las acciones de negocio pueden sercoordinadas por varios miembros y en algu-nos casos se encuentra cierto grado de apro-visionamiento común de fondos y recursospara lanzar nuevas ideas. Normalmente setrata de una mezcla de empresas grandes ypymes, junto con organismos públicos deinvestigación y otros entes. Esta peculiarmezcolanza facilita la transferencia tecnoló-gica desde el mundo académico a la industriay la creación de ecosistemas ricos alrededor deproyectos de software libre específicos.

El hecho de que el software producido seasoftware libre garantiza que nadie tiene con-trol absoluto sobre él y que se busquen solu-ciones con las que todos los diferentes actoresse sientan a gusto. Esto de alguna maneraallana el camino y ayuda a establecer algunasnormas, lo que facilita el hecho de que com-pañías competidoras puedan, en algunas cir-cunstancias, colaborar en proyectos específi-cos de su mutuo interés sin el engorro y lacomplejidad de detallados acuerdos legales.Algunos ejemplos de estas comunidades sonOW23 (antiguamente Object Web), construi-da alrededor de tecnologías web, o Morfeo4

que trata con diversas tecnologías.

3.2. Alianzas empresarialesLas alianzas son un caso específico de grupode empresas con un objetivo específico ycomún a todos los participantes, que actúacomo lazo de unión que las mantiene unidas.Este objetivo común es normalmente la pro-ducción o promoción de una tecnología espe-cífica o un estándar basado en el softwarelibre. Las empresas participantes normal-mente firman un acuerdo común e inviertenrecursos en ese fin. En general, no son muydiferentes de otros tipos de alianzas empresa-riales y sus principales diferencias son debidasal hecho de estar construidas alrededor delsoftware libre. De hecho, esto suele ayudar aque la alianza se establezca como un puntoneutral de control, abierto a nuevos actores.Ya que nadie controla la tecnología (puestoque es software libre), en principio el campoestá allanado para que todos los participan-tes compitan según sus capacidades.

Algunos ejemplos de alianzas basadas ensoftware libre son Limo Foundation5 , OpenHandset Alliance6 , y Symbian Foundation7

(todas en el área de los sistemas operativospara dispositivos móviles), o Genivi Alliance8

(dedicada a la producción de una plataformade software para coches).

3.3. Promoción de las comunidadestradicionalesOtra estrategia utilizada habitualmente porlas empresas es la creación y promoción deuna comunidad de desarrolladores y usua-rios, diseñada según las comunidades de soft-ware libre tradicionales. En este caso, unacompañía que lidera un proyecto de softwarelibre intenta que otras compañías e individuosse interesen, usando una estructura basada enla meritocracia, la contribución y la confian-za, de manera similar a lo que ocurre en lascomunidades formadas por voluntarios.

La empresa que promueve la comunidad seposiciona en una figura de promotor benevo-lente, de algún modo renunciando a algunosde los beneficios de ser el principal productor.El hecho de que el producto sea software libretambién proporciona ciertas garantías a otrosactores de que el promotor no mantienecontrol total, lo que hace que sea más intere-sante para ellos el participar. Por regla gene-ral, se encuentran relaciones sinérgicas donde

los promotores consiguen esfuerzo e innova-ción invertido en el producto en cantidadessustanciales, mientras que los actores se be-nefician bien de los recursos del promotor,bien de las oportunidades de negocio que sedan gracias a la escala de la colaboración.

Algunas empresas productoras de distribucio-nes de Linux, como RedHat9 con su comuni-dad Fedora10 o Canonical11 con su comunidadUbuntu12 fueron de las primeras en exploraresta estrategia. Más recientemente, Nokia13 hasido un caso sonado también, con su comuni-dad Maemo14 . Como estos casos ha habidomuchos otros recientemente.

3.4. Involucrarse en comunidadestradicionalesEn algunos casos, la mejor estrategia percibidapor una empresa es unirse a una comunidadtradicional de desarrollo de software libreexistente. En ocasiones, estas comunidadescomenzaron como un grupo de individuos,probablemente voluntarios, con el objetivocomún de compartir esfuerzos para el desa-rrollo y el mantenimiento de algún productode software específico. Pero con el tiempo, eshabitual que desarrolladores contratados porempresas interesadas en el producto acabenpor unirse a la comunidad o que las empresascontraten directamente a desarrolladores dela comunidad, para de algún modo unirse aldesarrollo colaborativo (y en algunos casostratar de influenciarlo). Este ha sido el caso,por ejemplo, de una de las más conocidascomunidades de software libre: Apache15 .Desde sus comienzos, varios desarrolladoresclave han estado trabajando para compañíasmientras participaban en Apache en tiempo detrabajo. La comunidad Apache reconocióeste hecho pero trató de mantenerse comouna comunidad de individuos en la cual losmiembros no se consideran representantes dela empresa para la que trabajan. Aunquesiempre puede haber algún tipo de tensióndebido a intereses empresariales, de cuandoen cuando.

En algún momento, algunas comunidadesformalizan la participación de empresas. Lacomunidad acepta recibir donaciones (enforma de empleados, fondos u otros valorescomo infraestructuras, servidores, etc.) y seestipulan reglas para equilibrar los interesesde las empresas junto con los del proyectocomo un todo.

Normalmente, las empresas tratan de impul-sar el proyecto ya no requiriendo más influen-cia a cambio de sus donaciones, sino produ-ciendo código para las funcionalidades espe-cíficas que están buscando. En algunos ca-sos, esto lleva a la creación de nuevos produc-tos dentro del proyecto. Esto puede distorsio-nar la relación entre voluntarios y empleadosen el proyecto. Pero también produce muchosbeneficios, uno de los cuales puede ser elincremento de los recursos humanos quetrabajan activamente en el proyecto o la solu-ción a problemas específicos en los que los

novática nº 199 mayo-junio 2009 11

Software libre para empresas monografía

monografía

voluntarios podrían no estar tan interesados.Existen varios ejemplos de casos como este.El Proyecto GNOME16 es probablemente elcaso más conocido. A finales de los 90 ycomienzos de esta década, muchas empresas(grandes corporaciones como Sun17 oNovell18 , o pequeñas startups como Eazel19

o Ximian20 ) colaboraron juntas. Un casomás moderno puede ser la relación de laMozilla Foundation21 con varias compa-ñías, especialmente Google22 , de la que recibeuna cantidad considerable de ingresos.

4. El papel de las pymesAlgunas pequeñas y medianas empresas tien-den a ser muy activas en términos de innova-ción y creación de nuevas tecnologías. Nor-malmente son consideradas más ágiles y di-námicas que las grandes corporaciones. Espor esto que no es sorprendente que muchasde ellas hayan sido pioneras en el campo delsoftware libre.

Algunos de los primeros casos se dieron graciasa desarrolladores de software libre que funda-ban sus propias pymes para rentabilizar el tiem-po y esfuerzo invertido en la creación de produc-to de software libre exitoso. En estos casos, eldesarrollo fue comenzado por una comunidadde voluntarios, pero en algún momento, unaparte o todos ellos, decidieron crear una empre-sa que probablemente se encargaba de todo ocasi todo el desarrollo y ofrecía servicios conánimo de obtener beneficios. Un ejemplo muyrepresentativo de esto es el caso de MySQL23 ,donde los principales desarrolladores fundaronMySQL AB, la empresa que lideró a partir deentonces el desarrollo casi al completo. Al mis-mo tiempo, ofrecieron servicios con los queobtenían fondos para financiar el desarrollo.

Este modelo se encuentra en muchos otroscasos antes y después del de MySQL. De hecho,es tan popular que en muchos casos, la empresase establece incluso antes de que el desarrollocomience formalmente, con el objetivo formalde dirigirlo cuando empiece. De algún modo,Red Hat o Ximian siguieron este modelo, sien-do sólo dos de los muchos ejemplos existentes.Con el tiempo, estas compañías pueden llegara ser compradas por grandes corporaciones(como ha sido el caso de MySQL AB, adquiridapor SUN o Ximian, adquirida por Novell), quede esta manera, incorporan innovación en suestrategia corporativa.

En algunas pymes innovadoras losdesarrolladores de software libre encuentrantrabajo con más facilidad. De hecho, paraestas compañías, contratar a estosdesarrolladores es una manera de mostrar suimplicación en los productos y servicios queofrecen (cuando están basados en softwarelibre), y una manera de diferenciarse de lacompetencia. La relación entre pymes y vo-luntarios en algunos proyectos es tan cercanaque los desarrolladores pasan de vez en cuan-do de una pyme a otra, sin dejar de trabajar enel mismo proyecto y viceversa: cambian deproyecto sin llegar a tener que cambiar de

empresa. Desde muchos puntos de vista,muchos proyectos serían simplementeinviables sin la participación de las pymes y losrecursos que invierten en el desarrollo, mien-tras que al mismo tiempo estas pymes noserían viables sin el proyecto exitoso de soft-ware libre con el que trabajan.

La relación de las pymes con las grandescorporaciones en las comunidades de desa-rrollo no es siempre fácil. Las pymes tienenproblemas para crear ecosistemas ricos por símismas, lo que significa que normalmenteagradecen la adhesión de grandes empresas.Pero una vez que entran en juego, puede darseuna situación de desequilibrio para los acto-res más pequeños. Aunque por norma suelenser más activos y dinámicos, el mero volumende grandes actores y la disponibilidad de susrecursos puede dirigir el proyecto en direccio-nes inesperadas. En cualquier caso, cuandoestas capacidades diferentes se utilizan con elánimo de buscar sinergias se puede conseguirun enorme impulso para el proyecto y bene-ficio para todos los actores.

5. El software libre y los profesio-nales informáticosLos profesionales de las TIC se sitúan en elcorazón del desarrollo de software libre. Apesar de lo que todavía digan fuentesdesinformadas, la mayoría de proyectos desoftware libre son liderados por profesionalesexperimentados en el desarrollo de software,normalmente con muchos años de experien-cia. En algunos casos, han estado involucradosen el software libre desde siempre y en otrosvienen de la industria del software tradicional.Puede que empezaran trabajando en proyec-tos de software libre como hobby en su tiem-po libre o puede que lo hicieran debido a unadecisión de su compañía. Pero, en cualquiercaso, ellos como individuos son el pegamen-to que mantiene unidos los elementos de losproyectos.

Como hemos mencionado repetidamente eneste texto, en muchos casos las empresasestán involucradas en proyectos, pero no son"ciudadanos de primera" en ellos. La mayoríade las comunidades de software libre estánbasadas en las relaciones entre personas, noen acuerdos corporativos. Es por esto quenormalmente, el papel de los profesionalesinformáticos que participan en estas comuni-dades sea mucho más importante que el de lasempresas para las que trabajan. De algúnmodo, la mayoría de los proyectos de soft-ware libre están en realidad liderados porprofesionales de las TIC que son reconocidosen la medida en que meriten por ello y seesfuercen en el proyecto.

De hecho, este reconocimiento del mérito y elesfuerzo nos lleva a un nuevo papel para losdesarrolladores profesionales. En lugar deestar restringidos por acuerdos privados yreglas empresariales que les impiden mostrara sus colegas sus capacidades y logros, eljuego en el mundo del software libre es exac-

tamente el contrario. Todo el trabajo es pú-blico, y todas las acciones son trazables. Losprofesionales que hacen un buen trabajo sonreconocidos por sus colegas y se llevan sureputación consigo según se mueven de com-pañía en compañía.

Desde el punto de vista del desarrollo profesio-nal a largo plazo, tan importante para losprofesionales de las TIC, el software libre es unmundo de posibilidades. Al poder leer el código,entender nuevas arquitecturas de programaslibres, nuevas tecnologías y nuevos paradigmasresultan tareas más sencillas. En conclusión, elsoftware libre brinda nuevas oportunidades paraprofesionales. Por supuesto que existen algu-nos riesgos evidentes, como los problemasderivados de exponer públicamente prácticas dedesarrollo deficientes, por ejemplo. Pero engeneral, los profesionales tienen mucho más delo que beneficiarse cuando trabajan con soft-ware libre.

6. ConclusiónEl software libre es un nuevo campo en elpanorama de las TIC, no porque sea unanueva tecnología sino porque brinda nuevosprocesos y posibilidades. Tanto las empresascomo los profesionales pueden obtener bene-ficios si encuentran la manera de aprovecharsus capacidades y pueden alinear sus objeti-vos con los de la comunidad del software libre.De todos modos, como todo nuevo mundo,es crucial entender las nuevas reglas y explorarlas oportunidades emergentes para benefi-ciarse de él. Por supuesto también existenriesgos, especialmente para aquellos que nose den cuenta de que, en muchos aspectos, elentorno ha cambiado.

Notas

1 Free Software Foundation < http://www.fsf.org/>.2 Open Source Init iative <http://www.opensource.org/>.3 OW2 Consortium <http://www.ow2.org/>.4 Morfeo Project <http://morfeo-project.org/>.5 LiMo Foundation <http://www.limofoundation.org/>.6 open handset alliance <http://www.openhandsetalliance.com/>.7 Symbian Foundation <http://www.symbian.org/about/index.php>.8 GENIVI Alliance <http://www.genivi.org/>.9 redhat <http://www.redhat.com/>.10 fedora <http://fedoraproject.org/>.11 CANONICAL <http://www.canonical.com/>.12 ubuntu <http://www.ubuntu.com/>.13 NOKIA <http://www.nokia.com/>.14 maemo.org <http://maemo.org>.15 The Apache Software Foundation <http://www.apache.org/>.16 GNOME: The Free Software Desktop Project<http://www.gnome.org/>.17 Sun microsystems <http://www.sun.com/>.18 Novell <http://www.novell.com/>.19 <http://en.wikipedia.org/wiki/Eazel>.20 <http://en.wikipedia.org/wiki/Ximian>.21 mozilla.org <http://www.mozilla.org/>.22 Google <http://www.google.com/intl/en/corporate/>.23 MySQL <http://www.mysql.com/>.

novática nº 199 mayo-junio 200912 monografía

monografía Software libre para empresas

1. IntroducciónEn una empresa, la decisión de adoptar solu-ciones basadas en software libre (Free/LibreOpen Source Software, FLOSS), o la deintegrar el software libre en sus servicios, sebasa normalmente en los siguientes casos deuso:

Migración/Sustitución básica: consisteen usar el FLOSS en la infraestructura infor-mática, sustituyendo normalmente instala-ciones basadas en software privativo.

Nuevo desarrollo: introducción del FLOSSpara desarrollar un nuevo proyecto de lacompañía (adopción).

Venta de servicios basados en FLOSS.Venta de productos que contienen FLOSS

internamente en una cantidad significativa.

En este sentido, una empresa puede encontrarútil el software libre desde un punto de vistatáctico (cuesta menos dinero implementarlo,con menos dependencia de proveedores, opuede ayudar a introducir productos en elmercado en menos tiempo). Los procesos deadopción interna se suelen modelizar usandoun modelo incremental, desarrollado inicial-mente por P. Carbone [1] y otros. Este mo-delo es un proceso de pasos sucesivos, siendoel primero el más complejo de todos, normal-mente (ver figura 1figura 1figura 1figura 1figura 1).

En todo caso, el proceso de migración yadopción es complejo, con esfuerzosmultidisciplinares que afectan a varias áreasy requieren una comprensión completa de losflujos de trabajo individuales, cómo se ejecu-tan y cómo la gente interactúa con los siste-mas de información en su trabajo diario. Eneste sentido, una migración a software libre esun reto importante y, como muchas otrastareas complejas, puede ir mal. Hay muchosobstáculos que nos encontramos al enfren-tarnos a una migración, pero algunos puedenevitarse fácilmente siguiendo prácticas sim-ples. Muchas de las dificultades no son denaturaleza técnica, sino organizativas, y casitodo el esfuerzo que requerirán vendrá dearriba (del equipo de gestión de la empresa);otro aspecto importante es el impacto socialde la migración (tal como la aceptación de losusuarios de los nuevos sistemas), lo cualrequerirá atención aparte.

2. Pautas de gestiónEl camino a seguir para hacer una migracióncorrecta al uso de FLOSS siempre empiezapor tener un panorama preciso de las funcio-

nes de Tecnologías de la Información (TI) dela empresa, una clara visión de las necesidadesy beneficios de las transiciones y un soportepermanente. Las diferencias con los modelosde desarrollo y soporte en el software librepueden requerir un cambio significativo en lamanera en la que el software y los serviciosson gestionados y, en general, un desplaza-miento de la responsabilidad desde los pro-veedores externos hacia el personal interno.

Asegúrese de gestionar el compro-miso a la transiciónEl soporte de la gestión y el compromiso semuestran repetidamente como las variablesmás influyentes en el éxito de los esfuerzosmás complejos de gestión de TI, y las migra-ciones a software libre no son una excepción.Este compromiso debe mantenerse duranteun período de tiempo suficiente para cubrir lamigración completa. Esto significa que, enlas organizaciones cuyos directores de Infor-mática son cambiados con frecuencia, o don-de la gestión cambia con cierta periodicidad(por ejemplo, en las Administraciones públi-cas donde ocurre a menudo), debe haber unproceso para transferir la gestión de la migra-ción. El compromiso debe también extender-se a la financiación (puesto que tanto loscambios como la formación requerirán re-

cursos, tanto económicos como humanos).La mejor forma de garantizar una coordina-ción constante es asignarle un equipo conexperiencia mixta (gestión y técnica) para daruna realimentación continua y una gestióndel día a día.

A tener en cuenta: si las únicas personas quetrabajan en la migración son personal deldepartamento de informática, probablemen-te no tendrán información suficiente sobre lagestión de más alto nivel, ni planes de finan-ciación para continuar la migración tras losprimeros pasos.

Prepare una panorámica clara de loque se espera de la migración oadopción, incluyendo puntosmediblesLa transición puede empezarse por variosmotivos, incluyendo el mejor control de loscostes de informática, independencia de losproveedores, flexibilidad o soporte de losestándares abiertos. Para asegurarse de que lamigración está produciendo beneficios deforma efectiva, o está yendo de acuerdo alplan de migración, es fundamental conocer deantemano los indicadores que servirán paraevaluar el progreso. Los requisitos deben serrealistas, y, en particular, las expectativas de

Buenas prácticas para la adop-ción del software libre

Carlo DaffaraDirector de I+D de Conecta Research ltd.,Italia

< c d a f f a r a @ c o n e c t a . i t >< c d a f f a r a @ c o n e c t a . i t >< c d a f f a r a @ c o n e c t a . i t >< c d a f f a r a @ c o n e c t a . i t >< c d a f f a r a @ c o n e c t a . i t >

Traducción: Traducción: Traducción: Traducción: Traducción: Juan Jose Amor Iglesias (GSyC/LibreSoft, Universidad Rey Juan Carlos)

Resumen: muchas empresas y administraciones públicas se plantean la adopción del software libre(Free/Libre and Open Source Software, FLOSS) en sus proyectos, o simplemente la migración a este,puesto que les puede implicar menores costes de implementación de nuevos sistemas informáticos o demantenimiento de los actuales. Pero, en general, los procesos de adopción o migración son complejos:se requieren esfuerzos multidisciplinares que cubran diversas áreas, una completa comprensión decómo son los flujos de trabajo internos en la empresa y de cómo interactúan los usuarios con los sistemasinformáticos. Este artículo propone una serie de pautas con el fin de maximizar el éxito de una adopcióno migración a software libre en organizaciones, pautas que se dividirán en tres grupos: pautas de gestión(orientadas a la gestión de mayor nivel en la compañía), pautas técnicas (orientadas al punto de vistatécnico) y pautas sociales (orientadas a características típicas del FLOSS que las compañías querránaprovechar, como la relación con las comunidades de desarrollo o la mejora del soporte técnico graciasa la experimentación y formación internas).

Palabras clave: adopción de software libre, comunidades de software libre, empresas, migración,software libre.

Autor

Carlo Daffara es el miembro italiano del Grupo de Trabajo Europeo sobre software libre. Preside ademásdiversos grupos de trabajo como el grupo de middleware de código abierto del comité técnico encomputación escalable del IEEE y el grupo de trabajo de las PYME del Competitiveness Task Force de laUE. Su actividad investigadora actual se centra en la sostenibilidad de los modelos de negocio basados enel software libre. Actualmente es jefe de I+D en Conecta Research ltd, empresa de consultoría en softwarelibre.

novática nº 199 mayo-junio 2009 13

Software libre para empresas monografía

monografía

reducción del coste total de la propiedad(TCO) deben poderse contrastar con datospúblicamente disponibles.

A tener en cuenta: si la única ventaja que sepercibe es que "el software se baja gratis de lared", puede que tengamos una serie de premisasincorrectas que probablemente desemboca-rán en una opinión negativa sobre la migra-ción.

Asegúrese de que el calendario esrealistaLa introducción de una nueva plataformainformática requerirá siempre mucho tiem-po; por regla general, el tiempo para realizaruna transición completa hacia el FLOSSpuede considerarse comparable al de la intro-ducción de un nuevo software ERP (EnterpriseResource Planning) en la compañía; paratransiciones más pequeñas, el esfuerzo entiempo debe escalarse proporcionalmente.

A tener en cuenta: cuando el tiempo de migra-ción se mide en días, y no se planifica esfuerzopara después de la migración, el procesopuede quedarse detenido forzosamente si losrecursos planificados se agotan.

Revise los procedimientos actualesde obtención y desarrollo de soft-ware o tecnología informáticaPuesto que los esfuerzos de implementaciónse desplazan desde el software comercial ha-cia el libre, los procesos de obtención y desa-rrollo deben ser actualizados conveniente-mente. En particular, la mentalidad de "com-pra" puede que deba cambiarse hacia unamentalidad de "servicio", puesto que se com-

prará menos software "precintado" y estecambio puede requerir diferencias en el repar-to del presupuesto interno para informática.El software desarrollado internamente reque-rirá ser portado o adaptado a un nuevosoftware que será multi-plataforma o accesi-ble usando interfaces estándar (por ejemplo,aplicaciones web), y esto debe tenerse encuenta en el plan informático global.

A tener en cuenta: Cuando no se planificancambios en el proceso de obtención y desarro-llo, es porque no se ha comprendido el alcancede los cambios requeridos para la adopción desoftware libre en la empresa.

Busque consejo o información deexperiencias parecidasDado que el número de empresas y adminis-traciones que han hecho una migración ya esconsiderable, es fácil encontrar informaciónsobre lo que hacer. En este sentido, el proyec-to COSPA ha desarrollado una base de cono-cimiento que es accesible a través de su sitioweb principal [2]; las Administraciones públi-cas pueden también contactar con el centro decompetencias en software libre que tenganmás a mano, para que les proporcione infor-mación y apoyo durante el proceso de migra-ción.

Evite una transición "de golpe" eintente que las migraciones seanincrementalesCasi todas las migraciones a gran escala hansido realizadas de una vez1 (implicando uncambio abrupto entre un entorno informáticoy el nuevo) y suelen venir afectadas por costestécnicos y de soporte extremadamente altos.

Aunque la necesidad de apoyo técnico en másde un entorno a la vez incrementa tanto loscostes de soporte como de gestión, las migra-ciones incrementales o "suaves" suelen traeruna mejor experiencia a los usuarios, asícomo un trastorno mínimo de los procesosde negocio.

Un ejemplo de migración suave sería aquellaque comienza por la migración de las aplica-ciones del lado del servidor, que normalmentesiguen estándares o simplemente basadas enconceptos de red (cliente/servidor) que lashace fáciles de reemplazar, dejando las aplica-ciones de escritorio o de interfaz de usuariopara el final. Un esquema así se mostró en [3](Ver figuras 2 y 3figuras 2 y 3figuras 2 y 3figuras 2 y 3figuras 2 y 3).

Asigne al menos una persona queinteractúe con la comunidad de de-sarrollo e intente encontrar buenasfuentes de información en la redUna ventaja importante del software libre esla disponibilidad en la Red de recursos gratui-tos, en forma de bases de conocimiento, listasde correo, wikis (sitios cooperativos) quepueden proporcionar una cantidad de apoyotécnico que, en muchos casos, es comparablea lo que ofrece un servicio comercial.

El gran problema es la localización de esasfuentes de conocimiento; en este sentido,asignar recursos para encontrar, clasificar einteractuar con esas fuentes de informaciónes una forma de reducir el coste del soporte;una manera de ofrecer de forma unificadaestas fuentes de información es mediante unasencilla página en la Intranet con enlaces arecursos públicos en línea.

Figura 1. Modelo de pasos sucesivos en la adopción de software libre.

novática nº 199 mayo-junio 200914 monografía

monografía Software libre para empresas

Figura 2. Esquema de migración "suave»"comenzando por las aplicaciones del servidor.

Figura 3. Esquema de fases de una migración "suave".

novática nº 199 mayo-junio 2009 15

Software libre para empresas monografía

monografía

A tener en cuenta: vigilar si la gente no sabecómo encontrar información sobre las herra-mientas que utilizan, o cuándo todos tienenque buscar en los sitios web para encontrarayuda.

3. Pautas técnicasUna diferencia que caracteriza las adopcionesde FLOSS es el modelo de desarrollo adop-tado por casi todos los proyectos de softwarelibre, que afecta especialmente a la frecuenciade entregas de actualizaciones o soporte.Esto requiere un cambio en la manera deadoptar el FLOSS y gestionar las actualiza-ciones, para reducir en lo posible los proble-mas de interoperabilidad.

Entienda la manera de desarrollarel software libreCasi todos los proyectos siguen un modelode desarrollo cooperativo, con un grupo cen-tral de programadores haciendo casi todo elcódigo (normalmente desde una empresa) yun gran número de cooperadores adicionales.Este modelo proporciona una gran calidad enel código y rápidos ciclos de desarrollo, perotambién requiere un esfuerzo importante en elseguimiento de los cambios y las actualiza-ciones. La adopción de un paquete de soft-ware libre debe considerarse cuando:

El proyecto en sí mismo está "vivo", esdecir, tiene alrededor una comunidad de desa-rrollo activa.

Hay una clara distinción entre software"estable" e "inestable". En muchos proyectos,hay dos líneas de desarrollo: una, centrada enintegrar los últimos cambios eimplementaciones (la "inestable"), y otra,centrada en mejorar la estabilidad y corregirlos fallos (la "estable"); periódicamente, losprogramadores "congelarán" el desarrollopara convertir una versión "inestable" en otra"estable", creando aparte una nueva rama dedesarrollo con las últimas novedadesimplementadas. Esta distinción permite a losprogramadores satisfacer tanto a los usua-rios que quieren probar las últimasfuncionalidades, como a aquellos que usan elsoftware en sistemas de producción, perorequiere un esfuerzo extra para recolectar lainformación sobre las nuevas versiones.

Si las nuevas funcionalidades o correccionesson necesarias, puede ser más simple pediruna versión con soporte comercial; en mu-chos casos, el proveedor comercial será tam-bién un cooperador económico en el proyectode software libre que vende.

A tener en cuenta: precaución cuando el ges-tor de TI o los desarrolladores creen que elsoftware libre viene a ser como un softwarecomercial que alguien ha puesto gratis en lared y simplemente "funciona".

Prepare una lista completa de soft-ware y hardware que serán afecta-

dos por la migración y quéfuncionalidad está buscando la com-pañíaCuando la situación inicial es poco conocida,la migración puede ser un fracaso. Muchasempresas y Administraciones no tienenimplementadas auditorías de las platafor-mas de software y hardware, y no están capa-citadas para cuantificar las herramientas y elsoftware que deben ser reemplazados o inte-grados en una migración a software libre. Elproceso de elaboración de la lista debe teneren cuenta también el número de usuariossimultáneos, el uso medio en la organizacióny si las aplicaciones utilizan protocolos decomunicación o formatos de intercambioabiertos o cerrados.

Esta encuesta será la base de la decisión sobrea qué usuarios afectará la migración en pri-mer lugar, y para tener en cuenta el coste de laadaptación del software o la migración a unformato de datos diferente. Las herramientasde inventario automático de software estánahí y pueden reducir el coste de realizar elinventario y permitir un control más estrictosobre el software instalado (reduciendo elcoste de mantenimiento).

Algunos aspectos a verificar:El formato de datos usado, a nivel de

intercambio de documentos pero también anivel de base de datos y protocolos de comu-nicación de red.

La lista de aplicaciones en uso, incluyendoaquellas desarrolladas internamente, macrosy documentos.

La funcionalidad disponible.Las deficiencias o los problemas de la

infraestructura actual.

Es fundamental que el software migradocubra los mismos requisitos funcionales de lainfraestructura informática actual, y es prefe-rible que además mejore la misma en térmi-nos de funcionalidad o calidad (disponibili-dad, fiabilidad, rendimiento...).

Utilice la flexibilidad del softwarelibre para hacer adaptaciones loca-lesLo que hace diferente al software libre es laflexibilidad y la libertad que da a los usuariosy programadores para crear nuevas versioneso adaptaciones de cualquier paquete. Estaflexibilidad puede aumentar mucho el valorque se percibe del software libre, por ejemploes posible crear paquetes personalizados quecontienen configuraciones locales, tipos deletra específicos u otro material de interéscomo macros prediseñadas o plantillas que seusen habitualmente en la empresa. Además,la personalización del aspecto visual puedeaumentar la aceptación de los usuarios, alpresentarles un escritorio más atractivo quemantenga a mano los enlaces o elementos demenú más habituales.

Esta personalización puede integrarse de for-ma simple en casi cualquier distribución deLinux, o bien creando un repositorio de soft-ware local. Obsérvese que, en casi todos loscasos, no hay que escribir programas, puestoque la personalización consiste en seleccionarel paquete adecuado, cambiar el aspecto vi-sual o proporcionar plantillas de documen-tos.

Hay mucho más software disponibleque el que se instala por defectoTemas de licencia o el propio diseño son losque limitan sustancialmente la cantidad desoftware que normalmente se incluye en lasinstalaciones predefinidas de las distribucio-nes Linux habituales. Por ejemplo, solo unaspocas incluyen capacidad para reproducir losformatos de vídeo o audio más populares,debido a restricciones de licencia o patente;también es habitual que algunos paquetesque nos parezcan interesantes no estén inclui-dos porque solo los usan una minoría de losusuarios.

Por esta razón, es importante investigar eincluir en las instalaciones predefinidas aque-llos paquetes adicionales que puedan ayudaren el período de transición, como paquetesque incluyan tipos de letra adicionales, herra-mientas multimedia y otros paquetes quepuedan ser útiles en un entorno mixto.

Al seleccionar los paquetes, dé preferenciasiempre a la estabilidad sobre la funcionalidad.Entre los muchos paquetes potencialmenteútiles para cada función, siempre los hay conmás funcionalidades o con más estabilidad.En general, entre los paquetes candidatosdeben elegirse los más estables, o aquellosque sean más populares (pues esto general-mente hace que haya más información desoporte disponible), y también aquellos conmenor variación entre versiones.

A tener en cuenta: Cuidado si el administra-dor de TI siempre quiere poner lo último en losescritorios de los usuarios.

Diseñe la infraestructura de soportepara reducir el número de incompa-tibilidadesCada transición de una infraestructura infor-mática a otra siempre conlleva pequeñas di-ferencias e incompatibilidades; esto puedeverse por ejemplo al convertir documentos deun formato a otro.

La infraestructura general debe reducir elnúmero de estos pequeños problemas, porejemplo rediseñando las plantillas de docu-mento en el formato abierto ODT(OpenDocument Text) en lugar de usar ver-siones previas hechas con herramientas priva-tivas. Esto reduce en gran parte las diferenciasde estilo y formato que se producen al conver-tir un documento de un formato a otro.

novática nº 199 mayo-junio 200916 monografía

monografía Software libre para empresas

Introduzca un sistema de gestión deincidencias2

Una dificultad en cada nuevo despliegue tec-nológico es cómo asegurarse la satisfacciónde los usuarios y el grado de aceptación de lanueva solución, especialmente en compañíasde tamaño medio donde es más difícil obtenerrealimentación de los usuarios. Un sistemade gestión de incidencias puede ofrecer unaforma simple de recolectar los fallos del des-pliegue y ayudar a identificar si los usuariosnecesitan capacitación adicional, por mediodel análisis de las estadísticas de envío deincidencias por usuario. Además puede en-contrar puntos débiles del despliegue, porejemplo cuando se localizan muchas inciden-cias relacionadas con un área concreta.

Recopile los detalles de la migraciónen un diarioUna migración a gran escala requiere unaacción coordinada e información clara y ac-tualizada. La mejor forma de recopilar estainformación es manteniendo un "diario demigración", un lugar donde tener la documen-tación recolectada y preparada para la migra-ción (incluyendo los objetivos, el plan detalla-do y la documentación técnica), y un diagra-ma de tiempos actualizado convenientemen-te de acuerdo con el avance del proyecto. Estoademás simplifica la gestión del proyectocuando hay un cambio en el equipo que dirigela migración.

4. Pautas sociales

Proporcione información generalsobre software libreUn obstáculo habitual en la adopción desoftware libre es la aceptación de los usua-rios, quienes suelen tener pocas nocionessobre software libre y estándares abiertos.Casi siempre, el software libre se percibecomo peor, dado que es "gratis", al poderseobtener fácilmente de la red como muchospaquetes shareware o hechos por aficiona-dos. Es importante acabar con esta percep-ción y proporcionar información sobre cómose desarrolla el software libre y qué ideasgenerales y de negocio subyacen en él.

No fuerce a los usuarios a cambiar,déles explicacionesEl cambio en la infraestructura tecnológicaprovocará un cambio importante en la formade trabajar de los usuarios o en el uso de losrecursos internos; este cambio puede causarresistencia en esos usuarios. Por ello debesimplificarse el cambio, explicando claramen-te el por qué y cómo tendrá lugar y québeneficios se obtendrán a largo plazo, tantointernamente (menor coste, mayor flexibili-dad y seguridad) como externamente (aper-tura, cumplimiento de estándares internacio-nales, menor carga a los usuarios externos).

A tener en cuenta: Hay que tener cuidado

cuando los usuarios creen que la migraciónsimplemente se hace para ahorrar dinero en elsoftware.

Aproveche la migración como unamanera de mejorar las habilidadesdel personalPuesto que la nueva infraestructura requerirácapacitación, se puede aprovechar para mejo-rar las habilidades generales sobre TI. Enmuchas empresas y Administraciones públi-cas, se imparten pequeños cursos formales alos usuarios. Esto no solo incrementa laconfianza, sino que armoniza habilidades enel grupo y en general mejora el desempeño.

Esto puede provocar cierta resistencia porparte de los "gurús de la empresa", que puedeninterpretar esta formación como un mecanis-mo para destronarles como líderes técnicos.La mejor forma de evitar esta resistencia eslocalizar a esos usuarios y sugerirles querepasen el material de formación de mayornivel (que puede estar disponible en un sitioweb, por ejemplo).

Además, puede ser interesante localizar a los"campeones", es decir, entusiastas del soft-ware libre que pueden ayudar dando soportea otros usuarios y ofrecerles formación adi-cional o un reconocimiento a nivel de gestión.

En general, es útil crear una Intranet internacon enlaces a los diferentes paquetes de for-mación.

Facilite la experimentación y elaprendizajeLa libertad de licenciamiento, fundamental enel movimiento del software libre, permite lalibre redistribución del software y los materia-les de formación. En este sentido, entregar alos usuarios distribuciones en CD "live" (queno requieren instalación en el disco duro paraprobarlas) o material impreso que puedanllevarse a casa, puede aumentar la aceptacióngeneral del nuevo software.

AgradecimientosEste artículo se basa en material preparado para losproyectos COSPA, OpenTTT y FLOSSMETRICSfinanciados por la UE. Puede conseguirse másinformación en la guía FLOSSMETRICS paraPyMES (FLOSSMETRICS guide for SMEs),<http://guide.conecta.it>.

Referencias

[1] P. Carbone. Value Derived from Open Sourceis a Function of Maturity Levels, OCRI conference"Alchemy of open source businesses", 2007.<http://www.ocri.ca/email_broadcasts/041907partnership.html>.[2] EU COSPA Project. D6.1 Report evaluating thecosts/benefits of a transition towards ODS/OS.<http://www.cospa-project.org/>.[3] KBSt, Alemania. Migration guide, 2006.

1 Esto enfoque es conocido también como "enfo-que Big Bang" o "adopción Big Bang" <http://en.w i k i p e d i a . o r g / w i k i / P r o d u c t _ S o f t w a r e _Adoption:_Big_Bang_Adoption>.2 Un caso típico de estos sistemas son losllamados "Trouble Ticket Systems" (o también"Issue Tracking Systems") en los cuales se intro-ducen las incidencias como "tickets", que sonasignados a personas o equipos de trabajo que seencargan de resolverlos <http://en.wikipedia.org/wiki/Issue_tracking_system>.

Notas

novática nº 199 mayo-junio 2009 17

Software libre para empresas monografía

monografía

1. IntroducciónEn el dominio de I+D, tecnologías comoWeb 2.0 han fomentado el desarrollo de nue-vos modos de trabajo colaborativo, a menu-do basados en relaciones entre pares (peer-to-peer) que finalmente evolucionan hacia co-munidades más organizadas.

La creación de dichas comunidades ha mos-trado su eficiencia y dinamismo en diversosdominios, más específicamente en el desarro-llo de software libre. Y aún más, el incrementode las conexiones a nivel internacional hagenerado una nueva necesidad de colabora-ción remota entre diferentes comunidades deexpertos alrededor del mundo.

Desarrollado dentro del instituto INRIA,basado en la experiencia del Capítulo Local deOW2 Europa [1] y en la creación de la comu-nidad Aspire-RFID [2], este artículo describeuna metodología para crear y mantener unacomunidad de práctica.

2. ¿Qué es una comunidad?Una comunidad puede ser considerada comoun grupo de personas que comparten uninterés común, las mismas inquietudes o lamisma pasión por algo. Una comunidadpuede estar también basada en roles o espe-cialidades (por ejemplo administrador de re-des, grupos de usuarios de Linux o el grupode usuarios de un sintetizador modular).Estas personas mejoran y profundizan en susconocimientos cuando los comparten, ya searesolviendo problemas para otros,interactuando regularmente con los miem-bros de la comunidad, preguntando y resol-viendo preguntas, o reutilizando buenas ideas[3].

Estos entusiastas participan activamente y secrea una nueva identidad virtual basada en unfuerte vínculo social que es de esperar produz-ca resultados colectivos [4].

3. Tipologías de las comunidadesBrevemente, podemos distinguir cuatro tiposde comunidades [3]: Comunidad de aprendi-zaje (por ej. el Proyecto Plume [5]), comu-nidad de interés (por ej. Audiofanzine [18]),comunidad de apasionados (por ej. adminis-tradores de sistemas participando en la Con-ferencia JRES 2009 [19]), y comunidad depráctica (por ej. Linux User Group [20]).

La comunidad de aprendizaje consiste en un

Construir y mantener unacomunidad de práctica: método

aplicado a proyectos desoftware libre

Stéphane Ribas, MichelCezonCapítulo Local de OW2 Europe, Saint IsmierCedex (Francia)

< { s t e p h a n e . r i b a s , m i c h e l . c e z o n } @ i n r i a . f r >< { s t e p h a n e . r i b a s , m i c h e l . c e z o n } @ i n r i a . f r >< { s t e p h a n e . r i b a s , m i c h e l . c e z o n } @ i n r i a . f r >< { s t e p h a n e . r i b a s , m i c h e l . c e z o n } @ i n r i a . f r >< { s t e p h a n e . r i b a s , m i c h e l . c e z o n } @ i n r i a . f r >

Traducción: Traducción: Traducción: Traducción: Traducción: Daniel Izquierdo Cortázar (GSyC/LibreSoft, Universidad Rey Juan Carlos)

Resumen: tecnologías como la Web 2.0 han fomentado el desarrollo de nuevas formas de colaboraciónen el dominio I+D, evolucionando a menudo hacia la creación de comunidades organizadas. El incre-mento de las conexiones a nivel internacional ha sacado a la luz la necesidad de colaboración remotaalrededor del mundo, lo cual enfatiza la necesidad de organizar la creación y mantenimiento de dichascomunidades. Este artículo presenta un método, desarrollado por el Instituto INRIA, para construir ymantener una comunidad de práctica. Nuestro enfoque, basado en cinco pasos, ha sido evaluado en unproyecto europeo: el proyecto ASPIRE-RFID. Los resultados son aquí revisados, con la convicción de quela transparencia, la confianza y el compromiso de las personas son la clave para allanar el camino hacia eléxito. Crear una comunidad desde cero y desarrollarla satisfactoriamente no siempre surge espontánea-mente sino que ha de basarse en un enfoque estructurado. Presentando este método esperamosfomentar el que cualquier persona que desee crear una comunidad se lance a la aventura de un modomás productivo.

Palabras clave: compartir conocimiento, comunidades, entornos colaborativos, metodología, relacio-nes sociales, software libre, Web 2.0.

Autores

Stéphane Ribas (M.Sc, University of Surrey 1996) ha trabajado 12 años en la industria del software yservicios, mayormente dedicado a tecnologías innovadoras tales como comercio electrónico, sistemasde salud electrónicos, seguridad en las telecomunicaciones, Intranet, sistemas expertos, middleware,aplicaciones de servidor, Java y software libre. Ha trabajado muchos años en varios países europeos y haparticipado en diversos e importantes proyectos ofreciendo soporte y consultoría técnica para grandesclientes. Ha desarrollado importantes cualidades en la construcción y promoción de comunidades enInternet. Gracias a esas experiencias, ha ido adquiriendo un bagaje técnico muy sólido en software.Comenzó a trabajar en INRIA en 2008 para coliderar el Capítulo Local de OW2 Europa y contribuir endiversos proyectos de software libre y grupos de trabajo (Xwiki Concerto, AspireRFID, QualiPSo, NESSIOSS Working Group).

Michel Cezon ha trabajado alrededor de 25 años en industrias y servicios informáticos, mayormente entecnologías innovadoras (inteligencia artificial, NLP, negocios electrónicos, EDMS, Intranet). Lideró nu-merosos proyectos europeos (FP4 EPTO-1993, FP6 SUPREME-1997, FP6 RENAISSANCE-1997, FP6PRORAD-1998) además de grandes consorcios de carácter internacional (FP4 MOVIT-1995, UnitedNations/WIPO-2000), o proyectos multimillonarios para grandes clientes. Graduado como Ingeniero enInformática y especializado en inteligencia artificial, robótica y visión artificial, posee un dominio de lagestión de proyectos y de las habilidades de calidad aprendido en grandes compañías como HewlettPackard o Cap Gemini Ernst and Young. Siendo consciente de las cuestiones de ámbito multicultural,pasó años en Singapur, Estados Unidos y Suiza, viajando frecuentemente alrededor de Europa. Se unió aINRIA en enero de 2007 para gestionar y coordinar proyectos europeos. Actualmente está trabajando endiversos proyectos europeos financiados por FP6 y FP7 (NESSI-Soft, NESSI-Grid, Qualipso, AspireRFID)y colidera el Capítulo Local de OW2 Europa.

grupo de personas que comparten valores ycreencias comunes y que aprenden activamen-te unos de otros. Dichas comunidades hanllegado a ser la plantilla de inicio para otrostipos de comunidades. Se basan en un tipoavanzado de diseño educativo o pedagógicoconsiderado a menudo como un enfoqueinterdisciplinar para la educación superior[6]. Los participantes en comunidades deaprendizaje deben sentir algún tipo de lealtadcon el grupo que dirige sus esfuerzos al

trabajo continuo y a ayudar a otros, influyen-do en lo que ocurre en la comunidad (demanera activa o reactiva). Este tipo de comu-nidades son lo suficientemente flexibles comopara dar la oportunidad a los participantes deexpresar opiniones personales, pedir ayuda oinformación específica y compartir historiasde eventos [4][6].

Una comunidad de interés podría ser conside-rada como un grupo de personas que com-

novática nº 199 mayo-junio 200918 monografía

monografía Software libre para empresas

parten temas que no requieren una comuni-dad formal sino discusiones más hilvanadaspara la colaboración y la compartición deconocimiento. Representan grupos de perso-nas no demasiado unidas entre sí y sin uncompromiso claro en términos de resultados.Están bien al corriente de los desarrollos enlos temas de su interés y se dedican a formulary responder preguntas [4].

Una comunidad de apasionados está forma-da por un grupo de gente con un conjunto deactividades, formas de gobernabilidad y es-tructura más formales. Los miembros tienenun rol en concreto (por ej. "asesor de seguri-dad de redes"), y ayudan activamente a otrosmiembros a encajar y evolucionar en su rol,persiguiendo todos ellos obtener un dominiocompleto de su disciplina [4].

Las comunidades de práctica tienen una es-tructura menos formal y están basadas enespecialidades de trabajo comunes entre susintegrantes. Los miembros tienen un rol par-ticular o una especialidad concreta (por ej.seguridad) enfocado a la adquisición de expe-riencia y desarrollo de facultades en ese rol oespecialidad. Un factor de motivación impor-tante es el aprendizaje sobre la especialidad yla resolución de problemas [4].

La metodología discutida en este artículo sediseño y aplicó a este último tipo de comuni-dad.

4. Método para construir y mante-ner comunidades de prácticaLa metodología está formada por diversospasos, comenzando desde un "objetivo co-mún" hasta la "monitorización" (ver figurafigurafigurafigurafigura11111). Las diferentes fases pueden ser organiza-das en cinco categorías principales [17]: Aná-lisis, construcción, promoción, mantenimien-to y monitorización.

4.1. AnálisisEl objetivo de la fase de análisis [3][4][7]consiste en comenzar el proceso y recoger todala información relevante que permita compren-der lo que queremos hacer, a dónde queremosir, por qué y cómo. Como ya hemos menciona-do, una comunidad puede emerger desde cero,a través de un idea común de un pequeño grupode personas entusiastas, pero que para llegar atener éxito, necesita un poco más de organiza-ción y gestión interna.

En esta fase, debes comenzar "soñando" so-bre: ¿cómo trabajaría la comunidad ideal-mente?, ¿cómo debe estar organizada?, ¿quiénliderará y tomará decisiones? En definitiva,deja volar tu imaginación libremente.

La identificación de la temática y subtemáticaspermitirá aclarar tus ideas y compartirlas contus colegas. Llegados a este punto, identificarel equipo principal también es importante yconocer quién está comprometido y desean-do participar en este viaje.

Una vez que el equipo ha sido definido, debestratar los temas básicos: concretamente¿cómo se va a organizar el trabajo en equipo?Esto implica más pensamiento imaginativo yquizás sesiones de tormentas de ideas y deintercambio de información. Todos estosprocesos abarcarán el gobierno interno, lacomunicación, el ciclo de desarrollo, el entor-no colaborativo, diseminación y promoción.De nuevo papel y lápiz deberán ser reemplaza-dos por algunas herramientas mássofisticadas (preferiblemente software libre)para permitir un mejor y más eficiente trabajoen grupo. Identifica (y usa) las herramientasde la comunidad para organizar tus colabo-raciones, tu contenido y facilitar tus activida-des de diseminación (promoción yconcienciación). Estas herramientas estaráncentradas alrededor una forja de software que

permitirá una interacción y comunicacióndiarias, siendo el repositorio central de lacomunidad y del proyecto. La metodologíapermite usar un conjunto de herramientasque ayuden durante esta fase.

A través de este proceso, debemos llegar a unaidea mejor acerca de qué es lo que intentamosconstruir y llevar a cabo. Podría ser deseableparar en cierto punto y echar un vistazoalrededor para ver si ya existen comunidadeso proyectos que compartan las mismas in-quietudes y temas. Unirse a dichas iniciativaso comenzar desde cero requiere una decisiónbien meditada y conlleva dos hojas de rutadiferentes.

Al final de la fase de análisis debe tomarse unadecisión tipo "go-no-go", es decir, qué hay quehacer y qué no, en base a toda la informaciónrecolectada y a la hoja de ruta planificada.Los criterios para tomar tal decisión puedenser objeto de un nuevo artículo en el futuro.

Una decisión de tipo "no-go" necesitará serexplicada en detalle y cuidadosamente paraidentificar cuales son los mayores impedi-mentos, dado el actual contexto, y evitar asírealizar de nuevo la misma pregunta una yotra vez, cuando la iniciativa o las ganas detrabajar aparezcan nuevamente sobre la mesa.

Una decisión ‘go’ es incluso más difícil por-que el tiempo y el esfuerzo gastado hasta elmomento son más pequeños de lo que real-mente será necesario para iniciar y construirla comunidad. Un compromiso fuerte y unaclara comprensión del camino a seguir y de losesfuerzos necesarios son obligatorios y debenser conocidos por todos los miembros prin-cipales del equipo.

Si seleccionaste la opción de comenzar unacomunidad desde cero, debes pasar ahora a lasegunda fase principal: la construcción.

4.2. ConstrucciónEn esta fase es donde pones toda la carne enel asador. Comienzas codificando, creandodocumentación (por ejemplo guías de usua-rio, APIs, guías de desarrollo, casos de uso,etc.), configuras tu portal (lema de tu proyec-to, licencia de uso, estado de desarrollo,cómo instalar el software, sección de descar-gas, capturas de pantalla, etc.), publicas pa-quetes de software, publicas tareas del pro-yecto y su planificación, gestionas volunta-rios y contribuciones externas [8]. Tus acti-vidades diarias serán guiadas por el gobiernode la comunidad, política de propiedad inte-lectual, ciclo de vida del proyecto y reglas decomunicación (simples y flexibles). Detalla-remos más información sobre esta fase en unartículo futuro.

Una vez completadas estas tareas, es hora dedarte a conocer.Figura 1. Método para crear y mantener una comunidad.

novática nº 199 mayo-junio 2009 19

Software libre para empresas monografía

monografía

4.3. PromociónTienes un equipo trabajando, un código fuen-te base, documentación y un portal donde lagente puede encontrar todo lo que necesitansaber, ya sea para contribuir o para usar tucódigo fuente. ¡Básicamente algo que mos-trar! Tu comunidad se ha establecido, así queahora debes publicitarla: envía artículos alistas de noticias, usa listas de correo y envíamensajes a múltiples personas, usa tu propiared de contactos a tu alrededor y anima a losmiembros de tu comunidad a hacer lo mismo.Pueden publicar noticias en periódicos loca-les e internacionales y revistas online. Podríastambién usar conocidas redes sociales (por ej.LinkedIn) para dar a conocer tu comunidad.Una vez que tu comunidad está a plenofuncionamiento y has llegado a cierto nivel dereconocimiento, podrías acceder a la últimafase: Mantenimiento.

4.4. MantenimientoNecesitas seguir en la cresta de la ola y man-tener ese impulso conseguido y, como conse-cuencia, los líderes de la comunidad deberíandedicar tiempo y liderazgo a animar y estimu-lar la comunidad [14][16]. Recomendamosque lleves a cabo eventos periódicos (por ej.jornadas informativas y de desarrollo, asam-bleas generales), audioconferencias y publi-cación regular de resultados en forma denotas, ser activo en foros, y algunas vecesincluso copiar temas interesantes que pro-vengan de fuentes de datos externas en tusnoticias y foros internos. Recomendamosque seas transparente en cualquier decisión yque además escuches a la gente (permite quesea posible discutir cualquier tema o proble-ma) [9][11].

También necesitas alcanzar una masa críticade miembros [15] que lleven a cabo tusoperaciones diarias (administración de siste-mas, gestores de errores, correctores de erro-res, webmaster, gestor del proyecto, traduc-tores...). Por tanto, tú también necesitas in-crementar el número de personas en tu comu-nidad: propón iniciativas (por ej. concursosde codificación, hackmeeting, encuentros entredesarrolladores y usuarios, reuniones de pro-yecto, etc.), usa las redes sociales, explicacómo la gente puede participar y llegar a sermiembro u ofrece incentivos para unirse. Nodudes en cruzar los límites de tu comunidady recoger buenas ideas de otras comunidades(por ej. comunidades de video-jugadoresonline) [12].

Otros dos factores que son muy importantespara los usuarios externos que vayan a con-tribuir activamente en una comunidad son: elreconocimiento [13] y la compartición deconocimiento. Podrías proponer que los úl-timos usuarios registrados o losdesarrolladores que más errores arreglanaparezcan en la página web de inicio. Después,debes dedicar recursos a organizar el conoci-

miento dentro de la comunidad: propón quehaya maneras de compartir ese conocimiento(por ej. seminarios online [10], talleres, casosde uso, etc.).

Tal como dijimos en la fase de análisis, debesechar un vistazo a tu alrededor y buscarcualquier comunidad o proyecto que puedaestar interesado en usar tu código fuente oque pueda estar interesado en cooperar con-tigo. Identifica esas comunidades, acércate asus líderes y proponles colaboración [3].

4.5. MonitorizaciónPara comprobar el progreso, las tendencias yvalidar los resultados de tus acciones, terecomendamos que definas tu propio siste-ma de monitorización mejor que usar planti-llas predefinidas: identifica el objetivo (¿porqué y qué querrías medir?), define las métri-cas, recoge los datos (analiza), identificaproblemas y tendencias, define consecuente-mente las acciones necesarias para hacer fren-te a ambos, ejecuta esas acciones y valida unavez más la salud del proyecto.

Te recomendamos que monitorices el creci-miento de tu comunidad, pero también lasalud de tu proyecto, usando para ello métri-cas tales como número de errores generados,número de descargas, número de visitas,número de mensajes en los foros e intercam-bios de correos, número de eventos organiza-dos, etc. Finalmente, ten en cuenta que debesmonitorizar también la comunidadglobalmente [9]: ¿Estás en una fase inicial detu comunidad? ¿O en una fase de crecimientode comunidad? ¿O en una fase de madurez?¿O estás en el punto donde la comunidad estádeclinando (o reviviendo)? Una encuestapodría ayudarte a descubrir en qué punto seencuentra tu comunidad de desarrollo. Ofre-ceremos más pautas de actuación en un artí-culo futuro.

5. La comunidad del proyectoAspireRFIDSe trata de un proyecto parcialmente financia-do por la Comisión Europea en su programade I+D FP7. El proyecto ASPIRE se proponeel desarrollo y la promoción de middlewarelibre, ligero, que siga los estándares, escalable,respetuoso con la privacidad e integrado,enfocado al desarrollo, el despliegue y lagestión de aplicaciones basadas en RFID y ensensores.

El consorcio ASPIRE quiso crear una comu-nidad vibrante alrededor de su marco de tra-bajo RFID basado en software libre y asíasegurar el tiempo de vida del código basemás allá del periodo de financiación delproyecto europeo. Por eso surgió la idea decrear una comunidad de práctica (y pasión)alrededor del código base.

Usamos este proyecto como una manera de

comprobar que nuestro método era válido através de la auditoría del proyecto y diversasrecomendaciones. Al mismo tiempo, valida-mos la metodología y afinamos la primeraversión de configuración y herramientas.

Estando implicados en el desarrollo de am-bos proyectos, ASPIRE y la comunidad OW2,encontramos rápidamente un punto de en-cuentro común en el dominio RFID: por unaparte, el proyecto ASPIRE buscaba el desa-rrollo de un marco de trabajo basado ensoftware libre para RFID y por otra parte, lainiciativa RFID fue promocionada por elconsorcio OW2. Lo primero de todo consis-tió en despegar, mientras que el segundo pasoconsistió en buscar nuevas contribuciones.Fue una manera perfecta de trabajar con ungran beneficio mutuo.

Hasta ahora debemos resaltar tres objetivoscumplidos:Incrementar la velocidad de la fase deIncrementar la velocidad de la fase deIncrementar la velocidad de la fase deIncrementar la velocidad de la fase deIncrementar la velocidad de la fase deinicioinicioinicioinicioinicio: mediante la metodología, hicimosuna revisión de la comunidad existente ydescubrimos que el consorcio OW2 podríaayudar en la creación de la comunidadAspireRFID: ellos tienen unas herramientasexcelentes de comunidad que encajan con lasnecesidades, en cuanto a creación de comuni-dad, de AspireRFID. OW2 propuso una forjade tal manera que los desarrolladores pudie-ran ponerse a implementar rápidamente. Ade-más, OW2 propuso también herramientas dedifusión y promoción.Mejorar la diseminación y la promo-Mejorar la diseminación y la promo-Mejorar la diseminación y la promo-Mejorar la diseminación y la promo-Mejorar la diseminación y la promo-ciónciónciónciónción: aplicamos el método y conseguimosresultados rápidamente, gracias a la promo-ción con acciones concretas como artículos,reuniones de desarrolladores, hackmeetings,conferencias de desarrolladores, etc. Encon-tramos que la lista de correo de OW2 fue ungran canal de revalorización y promoción.

Finalmente, el éxito de la diseminación ypromoción incrementó los resultados de ex-plotación: en un estudio comparativo sobreRFID realizado por el consorcio industrialPICOM [21] el marco de trabajo de ASPIREfue puesto a prueba con productos comercia-les. A pesar del hecho de que el proyecto noestaba finalizado y el marco estaba aún endesarrollo, ASPIRE cosechó mejores resul-tados que sus competidores. Podríamos su-poner que el método ayudó a reforzar lavaloración del producto, a publicitar su hojade ruta, a mejorar su reputación y a asegurarla vida del proyecto a largo plazo.

6. ConclusiónComo en todo nuevo proceso, el métodonecesita ajustes y mejoras. Estamos traba-jando para integrar nuestros descubrimien-tos en una versión revisada, pero a continua-ción exponemos los resultados más impor-tantes:

El método debería ser aplicado de manera

novática nº 199 mayo-junio 200920 monografía

monografía Software libre para empresas

correcta desde el principio para maximizar losbeneficios; el proyecto comenzó unos mesesantes de que esta metodología fuera aplicada.

El compromiso de las personas es clave.La comunidad está basada en personas y nohay métodos o herramientas que puedan re-emplazar la buena voluntad y disponibilidad.

Dedicar tiempo a la transmisión de cono-cimiento es importante, así como encontrara personal con cierto nivel de creatividad yliderazgo.

La visión de la comunidad debe ser com-partida entre los miembros y claramentepublicitada.

Los pasos de la metodología no sonsecuenciales; el solapamiento de procesosimpulsará el calendario de trabajo.

El proyecto AspireRFID es un proyectodel FP7 donde el consorcio tiene que llevar acabo ciertos entregables basados en una hojade ruta que puede diferir de los deseos de losmiembros de la comunidad. Los conflictos deintereses deben ser identificados y tratadospúblicamente tan pronto como sea posible.

Definitivamente, el método podría ser mejo-rado: la siguiente versión está en camino.Lanzar una comunidad y desarrollarla satis-factoriamente no es algo que surja espontá-neamente (y por suerte), sino que se basa enun enfoque estructurado que se podría bene-ficiar de una metodología como la presenta-da en este artículo.

7. El consorcio OW2 y el capítulolocal europeoOW2 es una comunidad de software libre decarácter global, cuyo objetivo es el desarrollode middleware distribuido bajo licencias li-bres, presentado en forma de componentesflexibles y adaptables. Estos componentesvan desde marcos específicos de software yprotocolos hasta plataformas integradas. Losdesarrollos de OW2 siguen una aproxima-ción basada en componentes. El consorcio esuna organización independiente sin ánimo delucro abierta a empresas, administraciones

Referencias

[1] OW2 Consortium. Europe Local Chapter,<http://europe.ow2.org/>.[2] AspireRFID Project. <http://fp7-aspire.eu>.[3] Stan Garfield. Implementing a Successful KMProgramme. Ark Group Australia, 2007.<http://stangarfield.googlepages.com>.[4] E. Wenger. Communities of Practice: Learning,Meaning, and Identity. Cambridge University Press,1998. ISBN: 0-521-66363-6.[5] PLUME Project. Promoting economicaL, Usefuland Maintained softwarE for the Further EducationAnd THE Research communities. <http://www.projet-plume.org/en>.[6] P. Goodyear, M. De Laat, V. Lally. UsingPattern Languages to Mediate Theory-PraxisConversations in Designs for Networked Learning.

públicas, universidades e individuos. La mi-sión de OW2 consiste en desarrollar softwarelibre middleware e impulsar una comunidadvibrante y un ecosistema de negocios.

Un Capítulo Local es un grupo decontribuidores que desean unir sus esfuerzosy promocionar los objetivos de un consorciodentro de una comunidad caracterizada porsu geografía o su lengua. Para conseguirrepresentar a OW2 a nivel europeo, el capítulolocal europeo fue aprobado y lanzado por elConsejo de OW2 el 15 de mayo de 2008. Elcapítulo local europeo generó una primeraversión de sus estatutos y ha definido suestrategia través de flujos de trabajo y tareas:impulsar la comunidad de investigación yacadémica de OW2 en Europa, ayudar en eldesarrollo del ecosistema de negocios de OW2en Europa y proporcionar apoyo específico alas necesidades de la comunidad local.

Los objetivos se abordan a través de tresgrandes líneas de acción: Comunicación conla parte académica, concienciación y promo-ción, y puesta en valor del proyecto. Se puedeencontrar más información en <http://www.ow2.org/> y <http://europe.ow2.org>.

ALT-J, Research in Learning Technology. 1741-1629, Volume 14, Issue 3, 2006, pp. 211 – 223.[7] E. Wenger, R. McDermott, W. M. Snyder.Cultivating Communities of Practice.Harvard Business School Press, 2002. ISBN:1578513308.[8] Karl Fogel. Producing Open Source Software,<http://producingoss.com/>.[9] C. Latemann, S. Stieglitz. Framework forGovernance in Open Source Communities, PostdamUniversity, 2005. ISBN 0-7695-2268-8.[10] OW2 Europe Local Chapter. Webinar Platform,< h t t p : / / w w w . o w 2 . o r g / v i e w / A c t i v i t i e s /EuropeLocalChapterWebinars>.[11] M. Gouvêa, C.Motta, F.Santoro.Recommendation as a Mechanism to InduceParticipation in Communities of Practice, UFRJ,UNIRIO, Brazil, 2006. ISBN 978-3-540-32969-5.[12] C. Ruggles, G. Wadley, M. Gibbs. OnlineCommunity Building Techniques Used by VideoGame Developers. Lecture Notes in ComputerScience, 2005. ISBN 978-3-540-29034-6. <http:// w w w . s p r i n g e r l i n k . c o m / c o n t e n t /47dc4v3xej51p5m4/>.[13] C.Cruz, M.Gouvêa, C.Motta, F. Santoro. AProposal for Recognizing Reputation withinCommunities of Practice. UFRJ, UNIRIO, Brazil,2008. ISBN 978-3-540-92718-1.[14] P. Muller. Reputation, trust and the dynamicsof leadership in communities of practice. Journalof Management and Governance, 2006 ISSN 1385-3457 (Print) 1572-963X (Online).[15] Fabernovel Consulting. Modèleséconomiques des logiciels open source et logicielslibres (2007) <http://www.fabernovel.com/businessmodels_opensource.pdf>.[16] L. M. Sama, V. Shoaf. Ethical Leadership forthe Professions: Fostering a Moral Community. Journal of Business Ethics, 2007 ISSN 0167-4544(Print) 1573-0697 (Online).[17] McDermott Consulting. Communities ofPractice, <http://www.mcdermottconsulting.com/communitypractice.shtml>.[18] Audiofanzine. French music webzine, <http://fr.audiofanzine.com/>.[19] JRES 2009. Journées réseaux, <https://2009.jres.org/>.[20] Linux Online. WorldWide Linux User Groups<http://www.linux.org/groups/>.[21] PICOM. Pôle des industries du commerce,Lille-France, <http://www.picom.fr/>.

¿Estudiante de Ingeniería Técnica o Ingeniería Superior de Informática?Puedes aprovecharte de las condiciones especiales para hacerte

socio estudiante de ATIy gozar de los servicios que te ofrece nuestra asociación,

según el acuerdo firmado con la

Asociación RITSI

Infórmate en <www.ati.es>o ponte en contacto con la Secretaría de ATI Madrid

secremdr@ati.es, teléfono 91 402 93 91

novática nº 199 mayo-junio 2009 21

Software libre para empresas monografía

monografía

1. Introducción1. Introducción1. Introducción1. Introducción1. IntroducciónLas comunidades en Internet están reclaman-do cada vez más atención por diversas razo-nes. Una de ellas es la enorme abundancia deconocimiento que los usuarios que partici-pan en estas comunidades han creado deforma colaborativa. Internet ha jugado unimportante papel en la creación de este cono-cimiento al posibilitar que gente con finescomunes se encuentre y compartan sus pasio-nes e intereses. Según Lessig [1], las oportu-nidades de colaboración que ofrece Internethan llevado a una transformación de unacultura predominantemente de sólo lectura auna de lectura y escritura. En otras palabras,menos individuos permanecen como consu-midores pasivos y cada vez más gente com-parte sus ideas de manera activa y crean nuevoconocimiento o productos. En lugar de me-ramente ver televisión, los aficionados usanInternet para discutir acerca de un espectácu-lo con sus amigos; además de leer libros, losfans escriben sus propias versiones de ficcióno remezclas musicales y las comparten conotros.

Incluso en Internet, la mayoría de usuariosson consumidores pasivos pero hay una ten-dencia hacia una dedicación más activa. Estoocurre en parte porque los sitios web sediseñan cada vez más con el objeto de atraeraportación y participación activa de usuariosy clientes. O’Reilly [2] utiliza el término arqui-tectura de la participación para describir "lanaturaleza de los sistemas diseñados para laparticipación de los usuarios".

Hay muchos ejemplos de sitios en Internetque han utilizado esta arquitectura de laparticipación para atraer una base significa-tiva de colaboradores activos. Wikipedia es laafamada enciclopedia que "cualquiera puedeeditar", Flickr es un sitio para compartir fotosque almacena incontables fotos de alta cali-dad (muchas de ellas bajo licencias CreativeCommons), Amazon dispone de una abun-dante cantidad de reseñas de libros contribui-das por los propios lectores y quién no ha oídohablar de YouTube, que permite "emitirse auno mismo". Lo que hace especiales a estossitios, no es la tecnología subyacente quepuede ser replicada fácilmente por cualquiera,sino la comunidad de usuarios que han atraí-do, que contribuye al sitio y hacen del sitio loque es.

Reconociendo la importancia de las comuni-

dades en Internet, Seth Godin, un conocidoexperto en marketing, identificó el papel delorganizador de comunidades en Internet (odinamizador de comunidades1 ) como uno delos más importantes trabajos del futuro [3].Los dinamizadores de las comunidades ayu-dan tanto a la creación de comunidades comoal sustento y crecimiento de comunidadesexistentes. Este artículo discutirá ladinamización de comunidades y el papel dedinamizador de comunidades en el contextode los proyectos de software libre, que seapoyan en comunidades de desarrolladores yotros participantes para crear software. En lasección siguiente se discute el fenómeno de ladinamización de comunidades y los diferentespuntos de vista del puesto de dinamizador decomunidades.

2. Una definición de dinamizaciónde comunidadesLos proyectos de software libre tienen unalarga historia de desarrollo y participación decomunidades. El paradigma del software li-bre fue iniciado por individuos que compar-tían el objetivo común de crear software quediera a los usuarios más libertades que elsoftware propietario [4]. Aunque el softwarelibre puede ser desarrollado por una compa-ñía sin implicación por parte de participantesexternos, la mayoría del mismo es, o biendesarrollado por una comunidad de volunta-rios (que pueden o no estar recibiendo unsalario por parte de una empresa con interésen el software), o por una empresa que lidera

el desarrollo de manera colaborativa juntocon una comunidad de usuarios interesadosen mejorar ese software. La comunidad esuna característica definitoria de la mayoría deproyectos de software libre, junto con lalicencia y las metodologías de desarrollo. Laliteratura académica también asocia los mé-todos colaborativos en los que se basa elsoftware libre con varios aspectos positivos,como los altos niveles potenciales de revisión[5] y la innovación a través de los usuarios2

[6].

Aunque la comunidad siempre ha tenido unpapel importante en los proyectos de softwarelibre, la dinamización de comunidades a car-go de personas con dedicación permanente yel puesto de dinamizador de la comunidad ensí, es un fenómeno relativamente reciente.Esto es en parte debido a que el éxito delsoftware libre ha dado lugar a un enormecrecimiento de su base de desarrolladores yusuarios y esta evolución de la comunidadpuede asociarse a ciertas dificultades en sucrecimiento que necesitan ser gestionadas[7]. Además, los modelos económicos"híbridos" que combinan economías comer-ciales y de compartición están siendo emplea-das de forma creciente en el contexto deldesarrollo del software libre, y lasinterrelaciones entre ambas han de ser gestio-nadas activamente. Lessig [1] define un híbri-do como "o bien una entidad comercial quebusca impulsar el valor de una economíaparticipativa, o bien una economía

Dinamización de comunidadesen proyectos de software libre

Martin MichlmayrOpen Source Program Office, Hewlett-Packard

< t b m @ h p . c o m >< t b m @ h p . c o m >< t b m @ h p . c o m >< t b m @ h p . c o m >< t b m @ h p . c o m >

Traducción:Traducción:Traducción:Traducción:Traducción: Teófilo Romera Otero (GSyC/LibreSoft, Universidad Rey Juan Carlos)

Resumen: la creciente complejidad de las comunidades establecidas alrededor de proyectos de softwarelibre junto con un aumento del interés de la explotación comercial de los mismos, ha llevado a que cadavez más de estas comunidades estén incorporando un puesto de "dinamizador de la comunidad". Eldinamizador de la comunidad actúa como enlace entre empresa y comunidad y se asegura de que hayauna buena relación entre los dos. También promueve la comunidad, ayuda a su crecimiento y cuida deque permanezca sana. Este artículo discute la dinamización de comunidades en proyectos de softwarelibre y ofrece una visión sobre el papel del dinamizador de comunidades.

Palabras clave: colaboración, comunidad, dinamización, software libre, voluntarios.

Autor

Martin Michlmayr ha estado participando en varios proyectos de software libre desde hace más de 10años. Ha sido coordinador voluntario del proyecto GNUstep, Director de Publicidad de Linux Internationaly líder del proyecto Debian. Durante los dos años al frente de Debian, Martin representaba al proyecto yllevaba a cabo importantes tareas de coordinación y organización. Martin ingresó en Hewlett-Packard en2007 donde trabaja como experto en comunidades de software libre y dinamizador de la comunidad deFOSSBazaar. Martin también forma parte del Consejo de Open Source Initiative (OSI). Es diplomado enfilosofía, sicología e ingeniería del software y doctor por la universidad de Cambridge.

novática nº 199 mayo-junio 200922 monografía

monografía Software libre para empresas

participativa que construye una entidad co-mercial para ayudar a sostener sus objetivos".Mozilla, un proyecto de software libre quedesarrolla el popular navegador de InternetFirefox, es un ejemplo de esto último puestoque la organización que lo sostiene ha obte-nido fondos sustanciales a través de diferen-tes asociaciones con diferentes entidades.Existen innumerables ejemplos de empresascuyos modelos de negocio se basan en Linuxy otros proyectos de software libre y quetienen intereses clave en asegurarse de que lascomunidades relacionadas se mantengansanas.

Hay numerosas razones por las que las em-presas quisieran establecer grandes comuni-dades alrededor de los proyectos de softwarelibre que construyen. Además de obtener par-ticipantes que ayudan en el desarrollo y hacenevolucionar el software, el tener una comuni-dad le da a la gente un lugar en el que crear unvínculo con la empresa [8]. Esto, a su vez,puede llevar a una cierta lealtad a la marca,innovación de productos, y usuarios quepueden llegar a ser defensores de la compañíay sus productos y que pueden crear marketingviral. Red Hat (con Fedora) y Novell (conOpenSUSE) son dos buenos ejemplos deempresas de la industria alrededor de Linuxque han establecido proyectos dirigidos porcomunidades de los que las empresas sebenefician de diversas maneras.

Los beneficios de las comunidades y la nece-sidad de promoverlas y gestionarlas han pro-piciado la figura del dinamizador de comuni-dad. Mientras que tradicionalmente el líder deproyecto se encargaba de que existiera unacomunidad fuerte alrededor de su proyecto,actualmente las responsabilidades a menudose reparten entre diferentes personas. El líderde proyecto es típicamente visto como unafigura de tipo técnico que tiene la responsabi-lidad de hacer progresar el software y deocuparse de los desarrolladores. Eldinamizador de la comunidad, por otro lado,se asegura de que hay una comunidad sana enel proyecto, interactúa con los usuarios, losdesarrolladores y otros actores y coordinaaspectos organizativos del proyecto. Cuandouna empresa es la fuerza motriz que impulsaun proyecto, el dinamizador de la comunidadactúa como enlace entre la compañía y lacomunidad y se asegura de que hay una buenarelación entre las dos.

Muchos proyectos de software libre exitososque son dirigidos por empresas o que tienenaltos niveles de implicación empresarial, tie-nen en estos momentos un dinamizador de lacomunidad dedicado. Mientras muchos deellos utilizan el título de "dinamizador de lacomunidad"3 , en realidad hay diferencias sus-tanciales entre las diferentes visiones existen-tes de este papel. Adam Williamson [9], an-tiguo empleado de Mandriva y actualmente

trabajador de Red Hat, hizo la siguiente ob-servación: Es muy interesante observar lasdiferencias existentes en cómo el rol es perci-bido; Yo era una especie de portavoz de lacomunidad de usuarios en Mandriva, Jono[Jono Bacon, dinamizador de la comunidadde Ubuntu] considera "comunidad" esencial-mente a la comunidad de desarrolladores/colaboradores y Zonker [Joe Brockmeier,dinamizador de la comunidad de OpenSUSE]dice que su papel acaba siendo más que nadaevangelización.

Esta observación muestra que las responsa-bilidades del dinamizador de la comunidadson muy amplias. Tienen que tratar con losusuarios, los desarrolladores, los colabora-dores y otros actores. A menudo actúancomo defensores y promotores y llevan a cabomuchas otras tareas (las más importantesserán discutidas en el apartado siguiente).Una de las funciones clave de un dinamizadorde la comunidad es asegurarse de que todo elmundo puede contribuir de manera óptima.Greg DeKoenigsberg [10], arquitecto de lacomunidad de Red Hat, recalcó en una entre-vista que "es una figura que se centra en hacerla vida de los colaboradores individuales tanproductiva y tan sencilla como sea posible".DeKoenigsberg comenta sobre el papel dedinamizador de la comunidad: Quieres hacercrecer la base de colaboradores, como sea.Quieres que tus desarrolladores principales seorienten a la comunidad, por supuesto. Perotambién quieres que pasen la mayor parte desu tiempo haciendo lo que mejor saben hacer,que es (o eso espero) programar. Esto signi-fica que quieres que sea alguien más quien sepreocupe de mantener tu comunidad de cola-boradores feliz y creciente.

Asegurarse de que los colaboradores están agusto y sacan partido de su participación enel proyecto es importante porque de otramanera podrían dejar de contribuir y dirigirsus energías a otros proyectos. En cualquiercaso, esto lleva a preguntarse qué factores yvalores son importantes para los voluntariosen proyectos colaborativos. MarkShuttleworth, fundador del proyecto Ubuntu,sugiere que los voluntarios cuentan con en-contrar las siguientes condiciones [1]:

Respeto: la comunidad y sus colaborado-res han de ser respetados y consideradoscomo corresponde.

Responsabilidad: los colaboradores de lacomunidad deben tener suficiente autoridaden el proyecto. Esto es particularmente im-portante en proyectos liderados por compa-ñías puesto que tienen que equilibrar eseliderazgo con adjudicar a los colaboradoresexternos autoridad e influenciar en la direc-ción del proyecto.

Significado: los colaboradores quierentener la sensación de que el proyecto para elque contribuyen tiene sentido, "quieren sentirque forman parte de algo que es grande,

importante y bonito". Si un proyecto no da alos voluntarios la sensación de que sus apor-taciones y el proyecto en sí mismo tienensignificado, invertirán su tiempo en un pro-yecto que sí lo haga.

Estos valores son importantes porque estánfuertemente relacionados con la motivaciónde los voluntarios y la única manera de in-fluenciar el trabajo voluntario es a través demotivación. Jim Grisanzio [11], antiguodinamizador de la comunidad de OpenSolaris,hizo algunos comentarios en su blog acercade la distinción entre poder y liderazgo que sonimportantes en este contexto: No se puedesustituir liderazgo con poder. Los líderes devoluntarios obtienen cooperación apelando alos valores compartidos de la comunidad yeso es un ejercicio mucho más exigente quedictar ordenes con amenazas o forzar a lagente a echarse atrás.

En otras palabras, los dinamizadores de lacomunidad no tienen autoridad sobre lasactividades de colaboradores voluntarios (nopagados) y tienen que encontrar mejoresmodos que el poder para animarlos a trabajaren ciertas actividades. Han de liderar la comu-nidad escuchando sus necesidades y ayudan-do al mismo tiempo.

En resumen, la figura de dinamizador decomunidades es un desafío que incluye mu-chas tareas y responsabilidades diferentes.Los dinamizadores de la comunidadinteractúan con varios actores y llevan a cabomuy diversas actividades. No tienen podersobre los voluntarios y han de encontrarincentivos interesantes, como ofrecer un sig-nificado al proyecto, si quieren motivar a losvoluntarios.

3. Tareas y aptitudes para ladinamización de comunidadesComo puede deducirse de la descripción de lafigura de dinamizador de la comunidad ex-puesta anteriormente, un dinamizador de lacomunidad ha de llevar a cabo varias y diver-sas actividades, incluyendo:

Habilitación: una de las más importantesresponsabilidades del dinamizador de comu-nidades es la de habilitar a la comunidad dediferentes maneras. Por ejemplo, eldinamizador de la comunidad ha de ayudar aque esta crezca mediante la captación denuevos miembros para el proyecto y ayudán-doles a iniciarse. Además, el dinamizador dela comunidad mantendrá en mente el "pano-rama general" del proyecto de manera quepueda poner en contacto a la gente. Si alguienha trabajado o está trabajando en la solucióna un problema que alguien más está sufrien-do, pero no se conocen el uno al otro, eldinamizador de la comunidad podría poner-los en contacto para que colaboren. Saber quéestá pasando en todo el proyecto también esimportante porque permite al dinamizador de

novática nº 199 mayo-junio 2009 23

Software libre para empresas monografía

monografía

la comunidad sugerir actividades desatendi-das a nuevos miembros del proyecto. Lacomunicación en general es muy importantetanto en pequeños como en grandes proyec-tos y es tarea principal del dinamizador de lacomunidad el hacer circular noticias y mante-ner a la gente informada de lo que ocurre enel proyecto. Finalmente, resulta crucial ase-gurar interacciones saludables dentro de lacomunidad. Muchos proyectos, especialmentecuando llegan a cierto tamaño, atraerán trollsque aportan energía negativa y hacen perdertiempo a los colaboradores. Algunos proyec-tos han adoptado un Código de Conductaque gobierna las comunicaciones y lasinteracciones dentro del proyecto. Es respon-sabilidad de todo el proyecto que este Códigode Conducta sea respetado pero el dinamizadorde la comunidad debería intervenir si nadiemás lo hace.

Delegación: como se ha tratado anterior-mente, la habilitación resulta una responsa-bilidad clave. No es responsabilidad deldinamizador de la comunidad el llevar a cabotodas las tareas del proyecto. De hecho, eldinamizador de la comunidad debería tener laprecaución de no ser demasiado activo enalgunas áreas para no desanimar la participa-ción de voluntarios potenciales. Por ejemplo,si un proyecto tiene un foro de soporte, eldinamizador de la comunidad no deberíaresponder inmediatamente a todas las pre-guntas. En su lugar, es deseable que anime aotros voluntarios a ayudar y que traslade laspreguntas a desarrolladores expertos quepodrían contestarlas fácilmente. Eldinamizador de la comunidad debería asegu-rarse de que el foro sirve de ayuda y puede porsupuesto contestar preguntas de vez en cuan-do, especialmente si nadie más lo hace.

Marketing: los dinamizadores de la co-munidad a menudo llegan a jugar un papel depromotores. Esto podría implicar viajar aconferencias para hablar sobre un proyecto yanimar a nuevos voluntarios a que se unan.También puede incluir hablar con la prensasobre ciertos aspectos del proyecto. Final-mente, los dinamizadores de la comunidadson a menudo encargados de mantener bue-nas relaciones con otros proyectos y empre-sas.

Escucha y observación: una de las venta-jas clave de tener una comunidad grande esrecabar sugerencias y opiniones de un grannúmero de personas con puntos de vistadiferentes. Es responsabilidad del dinamizadorde comunidades escuchar las necesidades ylas ideas de los colaboradores y asegurarse deque esas reflexiones llegan a la gente adecuadadentro del proyecto o dentro de la empresa quelo promueve. Además de escuchar a la comu-nidad, el dinamizador de comunidades ha decomprobar que las sugerencias son tenidas encuenta y que se hace algo al respecto de ellas.

Creación de una visión: como ya se haexpuesto, los voluntarios necesitan una mo-tivación clara para contribuir a un proyecto en

lugar de hacerlo a otro. El dinamizador de lacomunidad ha de ayudar a crear una culturacomún para la comunidad así como unavisión del proyecto. Es importante recogersugerencias de los colaboradores y tenerlas encuenta a la hora de hacer avanzar la comuni-dad en una dirección determinada.

Información: el dinamizador de la comu-nidad ha de estar al tanto e informar a laempresa sobre el estado de salud de la comu-nidad. Al mismo tiempo ha de utilizar estainformación con miras a mejorar la comuni-dad.

Basándonos en estas actividades, las aptitu-des que se pueden derivar como vitales para undinamizador de comunidades son varias:

Comunicación: el dinamizador de la co-munidad es un comunicador. Ha deinteractuar con usuarios, desarrolladores,colaboradores y otros actores interesados oimplicados en el proyecto. Ha de poner al díaa la gente de lo que está ocurriendo en elproyecto y trabajar junto con representantesde otros proyectos, compañías o con la pren-sa. Es esencial tener habilidades para la escri-tura y muy recomendable saber hablar enpúblico. Mas aun, puesto que muchos pro-yectos grandes son normalmente internacio-nales, es muy útil que los dinamizadores decomunidades conozcan y sepan como tratarcon otras culturas de modo que colaborado-res de otras culturas se sientan bienvenidos alproyecto.

Marketing: dar a conocer el proyecto esmuy importante para atraer nuevos colabo-radores y potencialmente también para atraerotros recursos, como financiación. Aunqueno es habitual que el dinamizador de la comu-nidad haga marketing en el sentido tradicio-nal, no es raro que se le haga responsable del"marketing de la comunidad".

Coordinación: organizar actividades va-rias es otra de las responsabilidades clave paralos dinamizadores de comunidades y por esohan de ser buenos coordinadores. Por ejem-plo, puede que tengan que organizar eventostales como reuniones de usuarios, realizar elseguimiento de tareas que han de ser llevadasa cabo e identificar quién está al cargo decuáles.

Habilidades técnicas: aunque eldinamizador de comunidades no es una figu-ra técnica, siempre ayuda saber algunos deta-lles técnicos. Esto es especialmente útil paraentender problemas técnicos o retos dentrodel proyecto y así poder ayudar a nuevosvoluntarios a encontrar el área en que puedenparticipar mejor. Las habilidades técnicaspueden también ayudar cuando el dinamizadorde la comunidad quiere montar un foro nuevoo cualquier otra infraestructura para el uso dela comunidad y el resto de la gente estádemasiado ocupado con otras cosas.

Paciencia y buena disposición: eldinamizador de la comunidad ha de escuchar

a muchos colaboradores e interactuar congente que es nueva en el proyecto y por tantono está familiarizada con sus prácticas y sucultura. Además, hacer crecer la comunidadpuede llevar mucho tiempo [12]. Es por estoque la paciencia y la buena disposición sonvirtudes importantes para un dinamizador dela comunidad.

Estar visible y estar presente: como ya seha comentado, el dinamizador de la comuni-dad no debería contestar todas las preguntasdel foro o resolver los problemas de todo elmundo. Pero ha de estar disponible y visible demanera que los colaboradores sepan quesiempre tendrán alguien a quién recurrir sitienen un problema. Foster [13] argumentaque ser un dinamizador de comunidades no es"un trabajo de 9 a 5", en parte porque ha deresponder inmediatamente cuando hay unacrisis y en parte porque las comunidadesinternacionales a menudo engloban muchaszonas horarias.

4. Actividades para crear comuni-dadExisten muchas maneras de construir y hacercrecer una comunidad. Citamos a continua-ción varias actividades comunes empleadaspor proyectos de software libre para dar unavisión general del tipo de actividades queresultan adecuadas.

Reuniones cara a cara: mientras que eltrabajo diario en proyectos de software librese lleva a cabo típicamente a través de Internet,las reuniones cara a cara han mostrado sermuy útiles por varias razones. Una de ellas esque son muy efectivas, especialmente cuandodan lugar a una lluvia de ideas o a resolverproblemas conocidos. Otra razón es que lasreuniones presenciales permiten que gente,que normalmente interactúa por Internet, seconozca en persona. Esto puede ayudar muchoa la colaboración futura, motiva a la gente yayuda a crear un sentimiento de comunidadmás fuerte.

Stands en conferencias: pueden servir paraconseguir nuevos voluntarios y permiten lainteracción entre desarrolladores y usuarios.Ir a conferencias y ferias puede ser una buenamotivación para los desarrolladores porquepueden conocer a la gente que usa su soft-ware, y también para muchos usuarios resul-ta grato conocer a los desarrolladores delsoftware que utilizan. Encontrarse con losusuarios es también muy buena manera deobtener sugerencias para mejorar el software.

Formación en Internet: varios proyectoshan empezado recientemente a organizar even-tos especiales para recién llegados que esténinteresados en conocer más acerca del proyec-to y de cómo contribuir. Por ejemplo, laOpenSUSE Community Week consiste envarias sesiones de formación acerca de diver-sos aspectos de OpenSUSE. La formación seimparte a través de IRC (Internet Relay Chat),un sistema de chat a menudo utilizado por

novática nº 199 mayo-junio 200924 monografía

monografía Software libre para empresas

proyectos de software libre como medio vitalde comunicación.

Reuniones de caza de errores4 : otra mane-ra de facilitar que los recién llegados partici-pen y de conseguir que algunos voluntarioscolaboren de manera regular es organizareventos (presenciales o a través de Internet)durante los cuales se analizan y reparan erro-res en el software. Estos eventos son a menu-do coordinados por algún experto del proyec-to en el control de calidad5 y junto a muchosotros desarrolladores experimentados queayudan a los nuevos colaboradores a empe-zar arreglando su primer fallo en el código.Esto puede convertirse en una muy buenamotivación para los novatos que bien podríandecidir involucrarse más en el proyecto.

Boletín de noticias: publicar anuncios ynoticias sobre el proyecto de manera regulares una estupenda manera de mantener a lacomunidad informada sobre el desarrollo delproyecto. El boletín de noticias puede ademásser utilizado para publicar peticiones de ayu-da o para promover actividades que los usua-rios pudieran encontrar interesante.

Como se ha mencionado anteriormente, es-tos son sólo algunos ejemplos de actividadesque los proyectos de software libre utilizancon éxito para construir sus comunidades. Dealgún modo, las actividades que saldrán biendependerán de las particularidades del proyec-to. Pero parece sensato observar otros pro-yectos para obtener ideas de actividades quepueden llevarse a cabo.

5. ConclusionesLos proyectos de software libre se han apoya-do siempre en comunidades de colaboradoresque mejoran el software. Debido al incremen-to del tamaño de las comunidades y del interéscomercial en las mismas, el papel dedinamizador de la comunidad está ganandorelevancia. Un dinamizador de la comunidadpuede actuar como el enlace entre la empresay la comunidad y puede asegurarse de quehaya una buena relación entre las dos. Lafigura del dinamizador de la comunidad com-prende actividades diversas, desde la habilita-ción hasta la promoción. Este amplio con-junto de responsabilidades se refleja en lasaptitudes que un dinamizador de la comuni-dad debería poder poner sobre la mesa, inclu-yendo muy buenas habilidades para la comu-nicación y la organización así como pacienciay buena disposición.

Notas del traductor

[1] Lawrence Lessig. Remix. BloomsburyAcademic, London, 2008. ISBN: 978-1408113479.[2] Tim O’Reilly. The Architecture of Participation(2004). <http://www.oreillynet.com/pub/a/oreilly/tim/articles/architecture_of_participation.html>.[3] Seth Godin. Jobs of the future, #1: OnlineCommunity Organizer (2007). <http://sethgodin.typepad.com/seths_blog/2007/07/jobs-of-the-fut.html>.[4] Richard Stallman. The GNU Operating Systemand the Free Software Movement. In: DiBona, C.,Ockman, S., Stone, M. (Eds.), Open Sources:Voices from the Open Source Revolution. pp. 53-70 (1999).[5] Eric S. Raymond. The Cathedral and theBazaar. O’Reilly & Associates, 1999. ISBN-10:1565927249.[6] Karim R. Lakhani, Eric von Hippel. How opensource software works: ‘free’ user-to-userassistance. Research Policy, 32(6), 923-943(2003).[7] Martin Michlmayr, Benjamin Mako Hill.Quality and the Reliance on Individuals in FreeSoftware Projects. Proceedings of the 3rd Workshopon Open Source Software Engineering, 105-109(2003).[8] Dawn Foster. Why Companies Should HaveOnline Communities (2008). <http://fastwonderblog.com/2008/04/16/why-companies-should-have-online-communities/>.[9] Adam Williamson. LinuxFest recap (2009).<http://www.happyassassin.net/2009/04/27/linuxfest-recap/>.[10] Greg DeKoenigsberg. Interview with GregDeKoenigsberg, Red Hat Community Architect.LinuxQuestions.org <http://www.linuxquestions.org/questions/interviews-28/interview-with-greg-dekoenigsberg-red-hat-community-architect-725426/>.[11] Jim Grisanzio. The Distinction BetweenPower and Leadership (2009). <http://b l o g s . s u n . c o m / j i m g r i s / e n t r y /the_distinction_between_power_and>.[12] Matthias Stürmer. Open Source CommunityBuilding. Master thesis, University of Bern, 2005.[13] Dawn Foster. What Does it Take to Managea Community? (2007). <http://fastwonderblog.com/2007/09/03/what-does-it-take-to-manage-a-community/>.

1 En el original se utiliza el término communitymanager, que hemos optado por traducir comodinamizador de la comunidad en la versión encastellano.2 Del original user innovation, se refiere al términoacuñado por Eric von Hipple para describir lainnovación llevada a cabo por los usuarios yconsumidores finales en lugar de por los provee-dores.3 Nuevamente,, community manager en el original.4 En el original Bug squashing parties. Hace alusiónal doble sentido de la palabra en inglés bug quegeneralmente se traduce como bicho pero ademássirve como sinónimo de error en argot informático.Por otro lado, el uso que se hace de squash en estecontexto, significa aplastar. De modo que la fraseoriginal se podría haber traducido literalmentecomo "comitiva de aplastamiento de bichos". Perolo que se describe es una reunión en la que losdesarrolladores dedican a buscar y solucionarerrores en el código.5 De las siglas QA (Quality Assurance) en eloriginal.

Referencias

novática nº 199 mayo-junio 2009 25

Software libre para empresas monografía

monografía

1. IntroducciónUna de las mayores contribuciones a la revo-lución tecnológica del siglo XX ha sido lapopularidad que han alcanzado los métodosde colaboración colectiva. Internet y algunosde sus servicios más famosos, como Flickr,Wikipedia o Facebook, son resultados de lacooperación. Asimismo, estos servicios sehan convertido en paradigmas colaborativos[1][2]. Mucho antes, comunidades de códi-go abierto como Debian, Linux kernel, Apa-che, Mozilla u OpenOffice ya habían definidoel modelo de colaboración para el desarrollodel software y produjeron la infraestructurarequerida [3][4] para soportar una comuni-dad de desarrolladores de ámbito mundial.

No obstante, existen todavía muchos proble-mas complejos [5] cuya solución pasa por ladefinición de mecanismos colaborativos en-tre los agentes interesados en resolverlos. Porejemplo, la gestión de la investigación cientí-fica, el desarrollo tecnológico y, aún máscomplicado, los procesos de innovación con-tinúan sin ser resueltos. Así, podemos encon-trar todavía algunos escenarios donde parecedifícil definir modelos de colaboración, comopor ejemplo las colaboraciones entre empre-sas, donde la competitividad parece inherenteal mercado.

Es en este contexto, en la búsqueda de solu-ciones para promover la productividad, laventaja competitiva y las estrategias efectivaspara competir en el mercado del software,donde surgió la Comunidad de software libreMorfeo en la que están implicados todos losinteresados en los procesos de I+D+i.

El proyecto Morfeo [6] es un ecosistematecnológico y económico compuesto porempresas, administraciones públicas, univer-sidades y grupos de investigación, centrostecnológicos y grupos industriales, y peque-ñas y medianas empresas (PYMES). Todasestas organizaciones están implicadas en lainvestigación, el desarrollo y la innovación dela producción tecnológica, y comparten lossiguientes objetivos:

La promoción de estándares abiertos yplataformas de software.

La definición de modelos de negocio ba-sados en las tecnologías licenciadas comoabiertas.

La promoción de los mercados competi-tivos de provisión tecnológica como mediopara lograr soluciones innovadoras, produc-

La Comunidad Morfeo:estrategias Open Sourcepara la Open Innovation

Crist ina Breña, AndrésLeonardo Martínez OrtizTelefónica Investigación y Desarrollo

< { c r i s b b , a l m o } @ t i d . e s >< { c r i s b b , a l m o } @ t i d . e s >< { c r i s b b , a l m o } @ t i d . e s >< { c r i s b b , a l m o } @ t i d . e s >< { c r i s b b , a l m o } @ t i d . e s >

Resumen: Morfeo es una comunidad de Software Libre, cuyos miembros son grandes empresas,administraciones públicas, universidades y centros de investigación, centros tecnológicos y pequeñas ymedianas empresas. Todos ellos comparten el principio de que el Software Libre es una estrategia efectivapara mejorar los procesos de investigación, desarrollo e innovación de la tecnología (software). Elsoftware de plataformas permite definir modelos de negocio viables y relaciones win-win que impulsan lacolaboración. MyMobileWeb, ezWeb y las contribuciones de CENATIC y OpenFwPA, framework de e-Administración del Principado de Asturias, son casos de éxito de producción tecnológica en la Comuni-dad Morfeo. No obstante, la mejora de la comunicación interna/externa, el desarrollo de nuevas herra-mientas que soporten la colaboración entre empresas y la búsqueda de soluciones para otros problemascomplejos de colaboración empresarial tales como la producción de estándares o el desarrollo empresa-rial, constituyen retos actuales de la Comunidad Morfeo.

Palabras clave: fomento empresarial, forjas, innovación abierta, software libre.

Autores

Cristina Breña es estudiante de último curso de periodismo en la Universidad Rey Juan Carlos. Durantesu periodo de estudiante, ha trabajado como locutora de radio y ha obtenido becas para el estudio en elextranjero (Helsinki) en 2007. Actualmente, está haciendo prácticas de periodismo en Telefónica I+D,ayudando en tareas de comunicación. Está a cargo de elaborar estudios de viabilidad a través de redessociales, escribir notas de prensa y artículos, y presentar mejoras y refuerzos del plan de Comunicaciónde la Comunidad Morfeo.

Andrés Leonardo Martinez Ortiz es Licenciado en Informática por la Universidad Politécnica de Madrid.Desde 2007 es especialista en OSS (Open Source Software) en Telefónica I+D. Durante el periodo entre1998 y 2002 fue ingeniero del departamento de I+D de Teldat, un fabricante de infraestructuras y desde2002 hasta 2007 fue miembro activo del grupo de investigación GSyC/LibreSoft de la universidad ReyJuan Carlos, donde era profesor. Empezó en software libre cuando era ingeniero de I+D en Teldat, dondeportó el kernel de Linux a la arquitectura M860. En la actualidad, es miembro del Proyecto Morfeo, dondese encarga de la dinamización de la comunidad y participa en iniciativas como OSS marketplace o ladefinición de programas para la certificación y la formación de tecnologías OSS. Participa en Vulcano yQualipso que tienen objetivos similares: promover la adopción del software libre en la industria. Comoresultado de esta participación, está definiendo y montando el Centro de Competencia de Morfeo, que seincluye en la red de centros de competencia de Qualipso, y gestiona el desarrollo de nuevas herramientasde colaboración. Forma parte de grupos de trabajo en software libre de INES OSS y NESSI OSS, laasociación IEEE y ACM.

ción tecnológica más barata y evitar situacio-nes de oligopolio/monopolio.

Cada miembro tiene su propia motivación(beneficio derivado de la cooperación) paraparticipar en las actividades de la comunidad,como por ejemplo:

Las universidades y grupos de investiga-ción pueden complementar (más o menos)sus investigaciones con actividades de trans-ferencia tecnológica realizadas por grandesempresas y PYMES.

Las administraciones públicas, como gran-des consumidoras de tecnología y a vecestambién proveedoras de ella, necesitan unagran base de proveedores/clientes y mejorar

sus posiciones para definir estándares de ad-ministración electrónica.

Las empresas consiguen masas críticas ensus inversiones tecnológicas reduciendo elriesgo de adopción tecnológica.

Pequeñas y medianas empresas puedenparticipar en la última parte de la cadena devalor disminuyendo el riesgo de crear nuevosservicios y productos. En otras palabras, lasPYMES pueden acceder a las actividades deI+D+i y vencer sus restricciones financieras.

2. El proyecto MorfeoA finales del año 2004, el Proyecto Morfeo fuecreado conjuntamente por Telefónica Inves-tigación y Desarrollo (TID), una compañía

Cristina Breña y Andrés Leonardo Martínez, 2009. Este documento se distribuyebajo la licencia Creative Commons "Reconocimiento-Compartir Igual" dispo-nible en: <http://creativecommons.org/licenses/by-sa/3.0/es>.

novática nº 199 mayo-junio 200926 monografía

monografía Software libre para empresas

que pertenece al grupo Telefónica, la Univer-sidad Politécnica de Madrid (UPM) y laUniversidad Rey Juan Carlos (URJC). Lainiciativa persiguió demostrar la viabilidad nosólo en el uso del software de código abiertoen las industrias sino también en la participa-ción de las compañías en el desarrollo delsoftware de código abierto. La evolución dela comunidad muestra cómo fueron toma-dos diferentes enfoques para alcanzar losobjetivos de Morfeo (ver figura 1figura 1figura 1figura 1figura 1).

Desde mitad del año 2004 hasta elfinal del 2005: liberación de códigoDurante ese tiempo, Telefónica I+D fue ayu-dado por la URJC y la UPM en el proceso deliberación de proyectos de software internos(privativos) para convertirlos en proyectos decódigo abierto. Fueron liberados; TidOrbJ,una implementación en Java de un ObjectRequest Broker de Corba, SmartFlow, unmotor de estados basado en redes de Petri, yMyMobileWeb, un marco para desarrollarcontenidos web para dispositivos móviles.Todos ellos eran productos maduros con

una hoja de ruta cercana al final e intensamen-te validados dentro del grupo Telefónica. Losprincipales retos fueron construir alrededorde esos productos una comunidad (tradicio-nal) dirigida principalmente a desarrolladoresvoluntarios. Para hacer esto, por ejemplo, secreó una forja de comunidad [7], que es unaherramienta colaborativa para el desarrollodel software.

Hoy en día, se puede decir que el éxito de estaestrategia no ha sido uniforme. Mientras quepara TidOrb y SmartFlow fue imposible crearuna comunidad, MyMobileWeb ha tenido unéxito destacable ya que en torno a esta tecno-logía existe una comunidad pequeña, peroactiva formada por desarrolladores en todoel mundo. La conclusión principal que obte-nemos de esta etapa es que es muy difícilmezclar en la misma comunidad socios in-dustriales, sin experiencia en el desarrollo desoftware de código abierto, con miembros dela comunidad OSS (Open Source Software)tradicional, con importantes prejuicios hacialas compañías y sus necesidades e intereses.

Desde 2006 hasta el final del 2007:construir una comunidad de innova-ción abiertaEn la mitad del 2005, el Board de la Comu-nidad Morfeo se dio cuenta de las dificultadesde mezclar la visión tradicional del OSS conla industria en Morfeo. El principal problemafue un desconfianza mutua: los usuariostradicionales de software de código abiertono tenían confianza acerca de la intención dela industria y cómo esta podría contribuir ala comunidad de OSS; por otra parte, laindustria tuvo problemas para adoptar latecnología de código abierto tanto en el so-porte de sus procesos de negocio como en laentrega de servicios y productos, principal-mente debido al poco conocimiento sobre latecnología OSS y su proceso de desarrollo.Por lo tanto, se optó por cambiar de estrate-gia: construir una comunidad de innovaciónabierta [8] para organizaciones que partici-pan en procesos de I+D+i. Así, Morfeoempezó a construir un ecosistema de investi-gación, desarrollo e innovación tecnológicacon suficiente calidad como para ser aceptadabajo criterios industriales. La respuesta fueinmediata: los implicados en I+D+i encon-traron un esquema para resolver el riesgo enla actividades relacionadas con la administra-ción tecnológica. Como resultado, Morfeotuvo que definir nuevas reglas para fomentarla participación con nuevos canales de comu-nicación y nuevas infraestructuras. También,por ejemplo, se hizo una remodelación de lacomunidad adaptada a las nuevas clases demiembros que empezaron a formar parte deella. Esta vez los resultados fueron bastantedistintos. Desde 2006 hasta ahora, Morfeoha incubado muchas propuestas de I+D+i.Muchas de ellas han tenido financiación pú-blica y el total del presupuesto ha estado entorno a los 25 millones de euros. El progresode los presupuestos se puede ver en la figurafigurafigurafigurafigura22222.

Figura 1. Evolución del modelo de la Comunidad Morfeo.

Figura 2. Evolución del presupuesto total de Morfeo (© 2008 Javier Soriano).

novática nº 199 mayo-junio 2009 27

Software libre para empresas monografía

monografía

Desde 2008 hasta ahora: EstrategiaOSS para la innovaciónDesde luego, la historia previa ha mostradocómo la estrategia de software de códigoabierto puede ser usada para crear un esque-ma de colaboración no competitiva entre lasorganizaciones. Por lo tanto, fue lógico abor-dar nuevos desafíos para intentar aplicar es-tas estrategias a otros problemas complejosen las relaciones entre empresas. A finales de2008, los miembros de Morfeo empezaron atrabajar en nuevos problemas: los procesosde estandarización, el desarrollo de serviciosprofesionales basados en la tecnología OSSy el desarrollo de facilidades en las relacionesempresariales para las PYMES. Estas tresiniciativas han recibido los siguientes nom-bres: Morfeo Open Alliance, Centro de Com-petencia Morfeo y Morfeo Base.

Morfeo Open Alliance es una iniciativa paracrear un consorcio de empresas que compar-tan una visión común de las tecnologías y desus arquitecturas asociadas. Además, esteconsorcio acuerda unas especificaciones abier-tas y potencia las implementaciones de códi-go abierto de los componentes en la arquitec-tura acordada. Este modelo de colaboraciónacelera la definición de estándares lo que setraduce en un periodo de tiempo más corto enla comercialización y en un bajo riesgo de

inversión tecnológica. La iniciativa ha sidoprobada en un dominio específico: ServiceFront-end [9].

El Centro de Competencia Morfeo [10] esuna iniciativa para fomentar el desarrollo deservicios profesionales basados en tecnolo-gías OSS. El concepto del centro de compe-tencia en OSS fue introducido por el proyectoQualiPSo [11] como un modo de "dirigirayudas a las industrias y gobiernos en buscade abastecimiento innovador y competitivo,estimulando el uso de software de códigoabierto flexible y de bajo precio para desarro-llar sistemas de información viables einnovadores". El centro de competenciaMorfeo es una propuesta para ser incluida enla Red QualiPSo de centros de competencia.El centro de competencia pretende impulsarla adopción del OSS para fomentar el desa-rrollo de servicios profesionales de tecnolo-gías de OSS que pueden ayudar a reducir elriesgo de la adopción de OSS en la industria.La figura 3figura 3figura 3figura 3figura 3 muestra su estructura y modelode negocio.

Finalmente, Morfeo Base [12] es la iniciativapara aumentar el desarrollo económico de lasPYMES. Morfeo en esta propuesta está tra-bajando en la definición de las estrategias demodulación de las cadenas de valor bajo

aproximaciones colaborativas. Como casoespecial, la comunidad está tratando de desa-rrollar una estrategia específica basada en lacomoditización de soluciones software (laLey de Christensen [13]) y trasladar valoresañadidos desde los productos (vendiendolicencias) hasta los servicios (pago por uso).Esto permitiría crear un ecosistema de lasPYMES alrededor de las comunidades OSS.

3. La estructura de una comuni-dad de innovación abiertaLa estrategia actual del Proyecto Morfeoestá basada en una estructura específica decomunidad. Esto es así porque la Comuni-dad Morfeo no es como el resto de las comu-nidades de código abierto. Morfeo no estácompuesta principalmente por voluntarios ydesarrolladores individuales de software sinopor agentes de los procesos de I+D+i. Tam-bién, la clase de instituciones que formanparte de la comunidad hacen de Morfeo laúnica comunidad con dicha estructura.

La comunidad está organizada en proyectosy capítulos (ver figura 4figura 4figura 4figura 4figura 4). Un capítulo no esmás que una agrupación de proyectos quetienen alguna clase de relación entre ellos.Cada proyecto tiene sus propias reglas debidoa que Morfeo es muy flexible en ese criterio.En el Proyecto Morfeo no hay que pagarninguna cuota por ser miembro, tan sóloseguir estas tres condiciones:1) Tecnología libre: los resultados del proyec-to deben ser libres bajo el criterio OSI [14].2) Gestión de la Propiedad Intelectual defini-da: Así, los contribuidores potenciales pue-den conocer las condiciones de colaboración.3) Fuerte mentor: La propuesta de proyectodeber ser liderada al menos por una organiza-ción como una empresa, universidad o grupode investigación, una administración pública,un centro tecnológico o una PYME.

Incluso para aquellos proyectos que no cum-plen con la tercera condición, Morfeo lesofrece una comunidad más tradicional cono-cida como Morfeo Bazaar. En cualquier caso,para estar en Morfeo, el "futuro" miembrodebe enviar una solicitud de alta de proyectoen la que tiene que rellenar los objetivos y una

Figura 3. Centro de Competencia de Morfeo.

Figura 4. Modelo organizativo de Morfeo.

novática nº 199 mayo-junio 200928 monografía

monografía Software libre para empresas

Referencias

[1] D. Tapscott, A.D. Williams. Wikinomics: Howmass collaboration changes everything. PortfolioHardcover, 2006. ISBN-10: 1591841380.[2] C. Shirky. Here comes everybody: The powerof organizing without organizations. The PenguinPress HC, 2008. ISBN-10: 1594201536.[3] E.S. Raymond. The Cathedral & the Bazaar:Musings on Linux and Open Source by an Acciden-tal Revolutionary. O’Reilly, 2001. ISBN-10:0596001312.[4] K. Fogel. Producing Open Source Software:How to Run a Successful Free Software Project.O’Reilly Media, 2005. ISBN-10: 0596007590.[5] Software Engineering Institute, CarnegieMellon University. Ultra-Large-Scale Systems:The Software Challenge of the Future. <http://w w w . s e i . c m u . e d u / u l s / f i l e s / U L S _Book2006.pdf?bcsi_s can_ 87A666 907766 D0F0=0&bcsi_scan_ filename=ULS_Book2006.pdf>.[6] Morfeo Project. <http://www.morfeo-project.org>.[7] Morfeo Forge. <http://forge.morfeo-project.org>.[8] H. W. Chesbrough. Open Innovation: The NewImperative for Creating and Profiting fromTechnology. Harvard Business School Press, 2005.[9] Morfeo Open Coalition for Service FrontEnds. <http://sfe.morfeo-project.org>.[10] Morfeo Competence Center. <http://cc.morfeo-project.org>.[11] QualiPSo Project. <http://www.qualipso.org>.[12] Morfeo Base. <http://base.morfeo-project.org>.[13] C.M. Christensen, M.E. Raynor. TheInnovator’s Solution: Creating and SustainingSuccessful Growth. Harvard Business SchoolPress, 2003. ISBN-10: 1578518520.[14] Open Source Initiative. Section about OpenSource Definition and Open Source Licenses <http://www.opensource.org>.[15] MyMobileWeb Project. <http://mymobileweb.morfeo-project.org>.[16] ezWeb Project. <http://ezweb.morfeo-project.org>.[17] Morfeo Capítulo CENATIC. <http://cenatic.morfeo-project.org/>.[18] OpenFwPA Project. <http://openfwpa.morfeo-project.org>.

descripción clara del proyecto, el consorcio, lalicencia y la política de gestión de propiedadintelectual. Después de las validaciones, elproyecto se convertirá en un proyecto Morfeoy los participantes en el consorcio del proyec-to entrarán a formar parte de la ComunidadMorfeo.

Cada proyecto tiene un representante en laAsamblea General donde el Board informacada año acerca del estado de la comunidad,comparten roadmap (hoja de ruta), nuevaspropuestas de servicios horizontales, nuevosproyectos y miembros. El Morfeo Board es elcomité ejecutivo de la comunidad formadopor miembros permanentes, como por ejem-plo, los miembros fundadores o permanen-tes, los representantes de proyectos elegidospara ser miembros del Board y consultores,que son profesionales prominentes de OSScon gran habilidad asesora. El Board está alcargo de identificar nuevas estrategias de OSSy de introducir nuevos servicios para fomen-tar la colaboración entre los miembros deMorfeo. Finalmente, la Oficina Morfeo es laencargada de las actividades diarias como sonel mantenimiento de la infraestructura, laadministración de los proyectos que se aprue-ban, las tareas de comunicación, etc. Laoficina Morfeo apoya al Board dándole infor-mación para la toma de decisiones.

4. Produciendo tecnología de in-novación abiertaActualmente Morfeo tiene diferentes proyec-tos tecnológicos, reflejando la evolución de lacomunidad. Así, podemos encontrar los si-guientes tipos de proyectos:

Proyectos heredados: MyMobileWeb [15]"es una plataforma de software de bajo-coste,modular, basado en estándar abiertos quesimplifica el desarrollo de aplicaciones web dealta calidad para móviles y portales. Propor-ciona una mejora en los contenidos y en lasadaptaciones de las aplicaciones". Inicialmentefue desarrollado por Telefónica I+D y libera-do como un proyecto OSS cuando comenzóla comunidad. Después de eso, MyMobileWebha sido capaz de crear una comunidad alrede-dor suyo. Está liderada por Telefónica I+Dy es una de los pocos casos de éxito de estaclase de proyectos.

Proyectos de innovación abierta: EzWeb[16] es una plataforma mash-up que cuentacon mecanismos enriquecidos de comunica-ción entre gadgets y que permite construir elfront-end de una nueva generación de arqui-tectura SOA. Es asimismo la propuesta deMorfeo de front-end de la nueva Internet delfuturo. La plataforma ha sido desarrolladadesde cero en el ámbito de la comunidad.Dentro del proyecto participan muchas orga-nizaciones, principalmente PYMES, pero tam-bién trabajan con universidades y administra-ciones públicas. Este proyecto está lideradopor Telefónica I+D aunque actualmente hayotras empresas que se están implicando en la

tecnología EzWeb. Claramente se puede decirque éste es otro de los logros en los proyectosde la comunidad de innovación abierta.

Proyectos comunitarios: el capituloCENATIC [17] y OpenFWPA [18] son ejem-plos de proyectos comunitarios. En estoscasos las administraciones públicas o lasagencias públicas establecieron un marco detrabajo con la Comunidad Morfeo. Ellosofrecen claras estrategias de adopciones deOSS o tecnología OSS para laimplementación de la administración electró-nica, mientras que Morfeo ofrece una activacomunidad de organizaciones implicadas enprocesos de I+D+i. Esta clase de proyectosno están liderados por ninguno de los miem-bros fundadores, sino por organizacionesexternas que selecciona la ComunidadMorfeo para incubar esta clase de proyectos.Los proyectos comunitarios son un ejemplodel efecto expansivo que tiene la comunidadque se refleja en un entorno de soporte tecno-lógico.

5. ConclusionesEl Proyecto Morfeo ha conseguido algunoséxitos importantes en estos años. Morfeo hasido capaz de definir estrategias efectivas deOSS para la gestión de la innovación. Se haconstruido un entorno de innovación abiertadonde la gestión de la propiedad intelectualabierta y basada en licenciamiento libre es unaspecto fundamental. Además, Morfeo es unreferente en el programa público de I+D+i yaque ha llegado a ser un verdadero entorno detransferencia tecnológico, fomento empresa-rial y crecimiento económico. A pesar de queMorfeo comenzó siendo una iniciativa deámbito español, actualmente, tiene un reco-nocimiento también europeo. La comunidadha empezado a colaborar en Latinoaméricacon la incorporación de una nueva red deoficinas en Iberoamérica (Brasil, Argentina,Uruguay, Paraguay y Chile).

ReconocimientosEste artículo no hubiera sido posible hacerlo sinla experiencia, opiniones y comentarios de algu-nos de los principales contribuidores del Proyec-to Morfeo. Ha sido un placer entrevistar a lassiguientes personas: Pedro Acebes, Juan AntonioCáceres, Jesús M. González, Álvaro Polo, Mar-cos Reyes y Roberto Santos.

novática nº 199 mayo-junio 2009 29

Software libre para empresas monografía

monografía

1. IntroducciónEn las últimas décadas, los proveedores desistemas empotrados han introducido la In-geniería de Líneas de Producto con el objetode mejorar la gestión de la diversidad de susproductos así como para reducir el esfuerzode desarrollo. El movimiento hacia la Ingenie-ría de Líneas de Producto normalmente tienepor objetivo la reutilización a gran escala,llevando a la reducción de costes y del períodode comercialización así como a la mejora dela calidad y la reducción de los costes demantenimiento.

La Ingeniería de Líneas de Producto Softwarees un medio de desarrollar aplicaciones soft-ware usando plataformas y personalizacionesmasivas. Las personalizaciones en masa per-miten la producción eficiente y rápida de unproducto individualizado para el cliente. Losartefactos utilizados para los diferentes pro-ductos han de ser lo suficientemente adaptablespara encajar en los diferentes sistemas que seproducen en la línea de producto. Esto supo-ne la necesidad de gestionar la variabilidad detodos los artefactos de la línea de producción.Específicamente una línea de producto gene-ralmente define la plataforma de una arqui-tectura, sus componentes y las herramientasde apoyo para proporcionar una gestión delcambio (variabilidad) eficiente yestandarizada.

Otras tendencias en la Ingeniería del Softwareno están siempre relacionadas con líneas deproducto software. Sin embargo, la aplica-ción de estas metodologías en una organiza-ción que las desarrolle podría ser beneficioso,Asimismo, otros enfoques de la Ingeniería delSoftware podrían beneficiarse de la introduc-ción de principios basados en el desarrollo delíneas de Producto. Esto último aplica aldesarrollo de software libre como un modeloválido y eficiente de desarrollo de software.

Existen diferentes opciones a la hora de desa-rrollar software libre. Sin embargo, el deno-minador común de todas es que un grupodistribuido de personas trabaja conjunta-mente parar generar software. La principaldiferencia con el enfoque basado en líneas deProducto es que las comunidades de desarro-llo de software libre tienen motivaciones pro-pias y específicas tratándose a menudo dedesarrollos con el único objetivo de ofrecersolución a un problema determinado y decompartir esta solución con otros.

No existe un único beneficio a la hora deaplicar conceptos del software libre a la Inge-niería de Líneas de Producto. Del mismomodo, debido al diverso uso que se hace delsoftware libre, la Ingeniería de Líneas de Pro-ducto puede ser atractiva para las comunida-des de desarrollo de software libre. Sin embar-go, muchas de las prácticas seguidas desde elenfoque de Ingeniería de Líneas de Productono encajan con las seguidas en las comunida-des de software libre. Por ejemplo los proce-sos gestionados no son siempre viables oaceptados. Siempre será beneficioso combi-nar las ventajas de ambos enfoques aunqueesto no será posible si no se eliminan estasincompatibilidades. Actualmente, existe unainteracción limitada entre las comunidades desoftware libre y las de desarrollo de líneas deproducto, aunque este interés ya ha sidoplasmado en anteriores estudios [3].Este artículo investiga las relaciones entre elsoftware libre y el desarrollo de líneas de

producto. Se basa en los resultados obteni-dos en el proyecto COSI de ITEA [5]. A partirde este estudio se pueden establecer las si-guientes conclusiones:

Implantar una línea de producto softwareimplica realizar una gran inversión, planifica-ciones a muy largo plazo, gestión explícita delcambio y desarrollo distribuido.

La industría informática usa el softwarelibre como medio para obtener software decalidad de manera rentable. Esto ayuda areducir costes compartiendo esfuerzos, y dis-minuye el tiempo de desarrollo del proyecto através de metodologías ágiles de desarrollo;todos estos procedimientos constituyen en símismos una manera distribuida de concebiry desarrollar sistemas.

El problema de la paralelización en elámbito del desarrollo distribuido es la princi-pal inspiración para intentar combinar lasprácticas de Software Libre y de la Ingenieríade Líneas de Producto.

Aplicación de los principiosdel software libre

en líneas de producto

Frank van der LindenPhilips Healthcare, Países Bajos

< f r a n k . v a n . d e r . l i n d e n @ p h i l i p s . c o m >< f r a n k . v a n . d e r . l i n d e n @ p h i l i p s . c o m >< f r a n k . v a n . d e r . l i n d e n @ p h i l i p s . c o m >< f r a n k . v a n . d e r . l i n d e n @ p h i l i p s . c o m >< f r a n k . v a n . d e r . l i n d e n @ p h i l i p s . c o m >

Traducción: Traducción: Traducción: Traducción: Traducción: Tomás Aguado Gómez (GSyC/LibreSoft, Universidad Rey Juan Carlos)

Resumen: la Ingeniería de Líneas de Producto mejora la gestión de la variabilidad y la reutilización desistemas empotrados. Ayuda a explotar la personalización en masa con el objeto de presentar al cliente unproducto individualizado. Sin embargo la Ingeniería de Líneas de Producto también ha llevado a procesosde desarrollo muy densos y a la necesidad de una planificación global para un rango completo deproductos (una línea de producto). El desarrollo de software libre no ha tenido un impacto profundo enlas compañías de desarrollo de sistemas empotrados, en parte debido a que la cultura inherente aldesarrollo de software libre no se mantiene demasiado fiel al establecimiento de procesos de desarrollopesados y de planificación global. Sin embargo ambos esquemas de desarrollo necesitan (a menudo) dedesarrollo distribuido, y es en este punto donde ambos pueden aprovechar los logros del otro. Esteartículo investiga las diversas opciones en las que el software libre y las metodologías de desarrolloasociadas pueden utilizarse para reducir los problemas que aparecen en el desarrollo distribuido así comopara aumentar la calidad del software resultante. Una pequeña parte del artículo estudia las opcionesdisponibles para que el software libre se beneficie de las metodologías de gestión de la variabilidad de laslíneas de producto software y de este modo aumentar las posibilidades de personalizar los productosresultantes.

Palabras clave: comercialización, fuente interna, gestión del cambio, líneas de producto software,software libre.

Autor

Frank van der Linden trabaja en las oficinas de Philips Healthcare. Recibió su doctorado en Matemáticasen 1984 en la Universidad de Amsterdam y desde entonces ha trabajado para Philips. Sus intereses másrecientes incluyen las metodologías de desarrollo software y arquitecturas, principalmente metodologíasorientadas a componentes y objetos. En 1991 se implicó en el desarrollo de una Línea de Producto dentrode Philips, aspecto en el que ha trabajado hasta el día de hoy. Fue jefe de proyecto en tres proyectos ITEAsucesivos que versaban sobre Ingeniería de Líneas de Producto, y posteriormente en desarrollo distribuidoincluyendo metodologías de desarrollo de software libre. Como parte de estos proyectos fue miembro delcomité organizativo de talleres y conferencias sobre líneas de producto (PFE & SPLC). Entre 2005 y 2008fue líder del proyecto ITEA COSI sobre desarrollo distribuido y prácticas de software libre en la industria desistemas empotrados. En este proyecto ha organizado gran cantidad de talleres sobre Software Libre yLíneas de Producto. Es coautor de diversos libros y numerosos artículos sobre estos temas.

novática nº 199 mayo-junio 200930 monografía

monografía Software libre para empresas

Figura 1. Procesos de Ingeniería de Líneas de Producto.

Figura 2. Pirámide de Variabilidad.

En este artículo se analizan los diferentesaspectos de la Ingeniería de Líneas de Produc-to, y se relacionan con prácticas de SoftwareLibre. El artículo finaliza con un resumen dela aplicación de prácticas de Ingeniería deProductos en el desarrollo de Software Libre.

2. Conceptos básicos de Ingenie-ría de Líneas de Producto

2.1. Dos procesos de desarrolloLa Ingeniería de Líneas de Producto haceénfasis en la separación entre los conceptosconstruir una plataforma robusta y crear enun corto espacio de tiempo aplicacionespersonalizadas para el cliente. Estos dos con-ceptos conducen a dos procesosinterrealacionados de desarrollo. (ver figurafigurafigurafigurafigura11111):

Establecimiento de la plataforma (Inge-niería de Dominio), incluyendo la definiciónde características comunes y de variabilidadde todos los elementos que componen la líneade producto.

Derivación de aplicaciones (Ingeniería deAplicación), incluyendo la vinculación de lavariabilidad en las aplicaciones.

La separación en estos dos procesos tambiénindica la separación de los dos problemas másimportantes relacionados con la gestión delcambio. La Ingeniería del Dominio es respon-sable de asegurar que la variabilidad es laapropiada para el desarrollo de aplicaciones.La Ingeniería de Aplicación se focaliza en eldesarrollo de sistemas individuales sobre laplataforma. Reusa la plataforma y vincula alas aplicaciones. Estos dos procesos estánpensados para funcionar de manera desaco-plada pero sincronizados por las

implementaciones de la plataforma. Debidoa que estos dos procesos están débilmenteacoplados pueden ser gestionados por mode-los de ciclo de vida totalmente diferentes.

2.2. VariabilidadLa Ingeniería de Líneas de Producto Software[16] [11] tiene por objetivo apoyar un amplioespectro de productos, orientados a diferen-tes clientes específicos. En vez de comprendercada sistema individual por sí mismo la Inge-niería de Líneas de Producto Software obser-va la línea de producto como un todo y sobreéste la variación de todos los sistemas indivi-duales. Igualmente importante es conocer lascaracterísticas comunes de todos los compo-nentes que se gestionan en una línea de pro-ducto. A través de esta Ingeniería se debengestionar tanto las características comunescomo la variabilidad. La variabilidad se definemediante la Ingeniería de Dominio y se explo-

ta durante la Ingeniería de Aplicación vincu-lando las variantes apropiadas. La variabili-dad se introduce a lo largo de muchas fasesdurante el proceso de Ingeniería de Dominio.

En cada nivel se refina la variabilidad del nivelanterior y se introducen características adi-cionales que no son resultado de este refina-miento. Este proceso se describe en la figurafigurafigurafigurafigura22222. La variabilidad se define inicialmente du-rante el análisis de las necesidades de todas lasentidades implicadas para ser posteriormenterefinada a lo largo de las siguientes fases dleproceso. A esto se le denomina variabilidadinterna. Las necesidades específicas de cadafase llevan a la introducción de nuevasvariabilidades internas.

Establecer la infraestructura de una línea deproducto no es un objetivo en sí mismo. Elobjetivo primordial es su explotación a lolargo del proceso de Ingeniería de Aplicación.A esto también se le denomina instanciaciónde la variabilidad. Los siguientes términos,que describen entidades autocontenidas entodo tipo de artefactos de desarrollo, sonimportantes en la gestión de la variabilidad:

Punto de Variación: Describe dónde seencuentran las diferencias entre los sistemasfinales.

Variante: Las diferentes posibilidades queexisten para satisfacer un punto de variación.

En la mayoría de los casos los puntos devariación no cambian independientemente.La selección de una variante específica paraun punto de variación dado, influye en lasopciones posibles para otros puntos de varia-ción. Para permitir la gestión de la variabili-dad, es necesario un modelo de variabilidadpara asegurar que se realiza una elecciónconsistente de variantes a lo largo de todoslos puntos de variación. En propuestas tem-pranas de modelado de variabilidad, estemodelado se integraba con la notación sub-yacente (utilizando por ejemplo la herencia).Sin embargo, se admite comunmente que esnecesario establecer una distinción clara entre

novática nº 199 mayo-junio 2009 31

Software libre para empresas monografía

monografía

el modelo de variabilidad y el del propiosistema. Esto hace mucho más sencillo apli-car ajustes complejos, da un apoyo mejoradoa la toma de decisiones y es mucho másescalable [1].

Existen diversas propuestas de modelos devariabilidad. Los grupos más importantesson los Modelos de Variabilidad basados enÁrboles de Características [10] y los Mode-los de Variabilidad Ortogonal (OVM) [16] .

También debe distinguirse entre variabilidaden el tiempo y en el espacio [2]. Ambos tiposde variabilidad son posibles con puntos devariación y variantes diseñados y aplicados demanera apropiada. La variabilidad en el tiem-po está asociada a la evolución de la línea deproducto y representa la existencia de diferen-tes versiones de un artefacto que son válidasen diferentes lapsos de tiempo. Esto últimoestá relacionado con el versionado de los ele-mentos del sistema. La variabilidad en el espacioesta referida a la existencia de un artefacto endiferentes formas dentro del mismo espacio detiempo. Esto lleva a la existencia de diferentesconfiguraciones que conforman sistemas váli-dos al mismo tiempo. Estas prácticas estánrelacionadas directamente con la Ingeniería deLíneas de Producto.

2.3. Software libre aplicado a líneasde productoEl interés de las empresas por el software libretiene su origen en el reconocimiento del hechode que la práctica totalidad del software seestá convirtiendo en una materia prima deprimera necesidad, lo que hace que sea muyinteresante para los desarrolladores de siste-mas empotrados introducirlo tanto en susproductos como en las líneas de productoasociadas.

3. La mercantilización del soft-wareComo consecuencia de la mercantilizacióndel software [13] gran parte del mismo hadejado de estar particularizado para un pro-ducto concreto. De hecho actualmente no escomún que un producto software esté desa-rrollado por una única compañía. Por elcontrario, el software se produce en estrechacolaboración dentro de la propia empresa ymás allá de sus fronteras. Más aun, es muycomún que software de terceros se integrecomo parte del producto propio.

Para la mayoría de los productos y líneas deproducto, únicamente una pequeña parte1

(5%-10%) del software es diferenciador. Estapequeña parte es la que proporciona valorañadido sobre el producto ofrecido por otrasempresas competidoras. El resto del softwarees más o menos común en el dominio, oincluso entre diversos dominios. El desarro-llo de software eficiente y efectivo únicamentese concentra en la producción de módulosdiferenciadores. El software como mercancía(la parte común) puede y debería ser adquiri-do a terceros, implicando desarrollo distri-buido y software de terceros como COTS(Commercial Off The Shelf) o software libre.Como la Ingeniería de Dominio está másinfluenciada por el software puede necesitardiversos caminos para ajustarse a una aplica-ción específica.

La figura 3figura 3figura 3figura 3figura 3 muestra un esquema confron-tando la tecnologías contra las decisionesempresariales de construir o adquirir soft-ware. Las dos esquinas marcadas en la figuradeberían ser evitadas a la hora de desarrollartecnología. La esquina superior derecha de-bería ser evitada a cualquier precio ya queimplicaría regalar el valor añadido propio a

las empresas competidoras. La esquina infe-rior izquierda también debería ser evitada paraahorrar recursos de desarrollo debido a que laparte común de la tecnología puede ser obte-nida de manera mucho más barata comprán-dola en vez de desarrollándola.

Un desarrollo software saludable está carac-terizado por hallarse en el área central de lafigura. El software diferenciador se desarrolladentro de la propia organización y el softwareque da funcionalidades comunes se adquiereen el mercado o se dispone de él sin coste(software libre).

Cualquier software, incluyendo el desarrollode líneas de producto, se desplaza de arribahacia abajo a lo largo de la figura 3figura 3figura 3figura 3figura 3. Elsoftware comienza siendo diferenciador paraalguna de las partes implicadas. Más adelan-te, en un momento dado ese software noproporciona el suficiente valor añadido a losproductos y pasa a la consideración de "bási-co para el negocio". En etapas posteriores elsoftware llega a convertirse en commodity(mercadería sin valor diferencial).

El desarrollo coherente de software tambiénse caracteriza por moverse de izquierda aderecha al mismo tiempo, desde desarrollointerno a colaboraciones abiertas entre em-presas. Para evitar alcanzar las situacionesindeseadas que se han descrito es necesariorealizar estos movimientos de apertura alritmo adecuado. Un ejemplo de este movi-miento es el caso del software DVTk dePhillips Healthcare2 [13] que evolucionó envarias etapas desde software propietario ydiferenciador a software libre y commodityentre 1994 a 2002.

Cada compañía necesita analizar el softwareque desarrolla con respecto a la figura 3figura 3figura 3figura 3figura 3 conel objeto de conocer cuándo cambiar la ma-nera en la que colabora con otras compañías,esto es de especial importancia para las com-pañías que desarrollan líneas de producto.Debido a la larga vida de una línea de produc-to, hay partes de la misma que constantemen-te se convierten en commodity, mientras quela propia línea de producto ha de mantenerseviva y próspera. Esto requiere un esfuerzoadicional durante la fase de planificación ydefinición de recursos. Una complicaciónadicional es el hecho de que las compañíastienen un control limitado sobre el softwarelibre que utilizan en sus desarrollos.

4. Software libre para líneas deproductoDebido al tamaño del desarrollo, las organi-zaciones implicadas en desarrollos de líneasde producto suelen optar por el desarrollodistribuido que tan eficientemente ha funcio-nado en las comunidades de desarrollo desoftware libre. Además, a la hora de reutilizarsoftware es inteligente no ignorar la gran

Figura 3. Desarrollo eficiente y efectivo de software.

novática nº 199 mayo-junio 200932 monografía

monografía Software libre para empresas

cantidad de software libre disponible. Dentrodel proyecto COSI [5] experimentamos concasos de estudio en los que se aprovechaba elsoftware libre de 5 maneras diferentes:1) Adopción de las prácticas de desarrollodentro del desarrollo de la línea de producto(desarrollo interno).2) Uso de herramientas de software libre en eldesarrollo de la línea de producto. Ésta es laforma más sencilla de usar software libre enlíneas de producto.3) Uso de componentes de software libre enlos productos de la línea de producto. Estoimplica una mayor participación y planifica-ción.4) Liberación de productos de la línea deproductos. Productos o líneas completas deproducto que fueron inicialmente desarrolla-dos de manera interna se liberan en comuni-dades de software libre.5) Establecimiento de una relación simbiótica.Desarrollando la línea de producto usandolos recursos de una comunidad de softwarelibre.

4.1. Fuente internaLa fuente interna es una manera de aprove-char las ventajas del desarrollo distribuido dela manera en que lo hace el software libre, perocon el deseo de evitar problemas en la plani-ficación, la propiedad y el control del proyec-to. Diversas compañías han adoptado mode-los de desarrollo basados en fuente interna[9].

En el modelo de desarrollo de fuente internaun conjunto de equipos colaboran en unecosistema cooperativo. De manera similaral desarrollo de software libre el desarrollo defuente interna aplica un modelo de coopera-ción abierto y concurrente. Este modelo im-plica la propiedad y el control distribuido,publicaciones tempranas y frecuentes de lasaplicaciones desarrolladas, y canales eficien-tes y abiertos para realimentación por parte detodos los grupos implicados.

Se hace uso de los mecanismos de organiza-ción que ya están implantados en la empresa,por ejemplo los designados para la gestión deconflictos, definición de tareas, etc. El mode-lo de fuente interna proporciona flexibilidad ala hora de gestionar las colaboraciones (esta-blecerlas, cancelarlas y modificarlas) y tam-bién es muy útil a la hora de coordinar equiposy definir sus prioridades a través de fronterasorganizacionales y geográficas. Las compa-ñías pueden usar este modelo como un pasointermedio para la integración de softwarelibre en sus productos.

El modelo de desarrollo de fuente interna esel establecido dentro de Phillips Healthcare[19]. La compañía entrega una línea de pro-ducto que implica un amplio conjunto deproductos de imagen médica a sus clientes(generalmente hospitales) en varias modali-

dades. El grupo de Ingeniería de Dominioproporciona una plataforma compuesta deun conjunto de componentes reusables yreconfigurables basados en una arquitecturacomún. Este grupo abordó el problema deconvertirse en un cuello de botella de losdiferentes grupos de Ingeniería de Aplicación.Las entregas del grupo de Ingeniería de Domi-nio se planifican en un proceso con grancantidad de personas implicadas, por lo queel calendario de entregas no puede satisfacersiempre la planificación de todos los gruposde Ingeniería de Aplicación. Las dinámicas delmercado pueden forzar a cambios en la pla-nificación de ciertos grupos de productos y sinembargo el proceso de planificación del domi-nio carece de la flexibilidad para adaptarse aestos cambios.

El desarrollo de fuente interna está basado enelementos del desarrollo de software libre,apoyados por un entorno web de desarrolloabierto y colaborativo. Desacopla la Ingenie-ría de Aplicación de la Ingeniería de Dominioya que cada grupo de Ingeniería de Aplicaciónpuede decidir por sí mismo sobre la platafor-ma:

Usarla tal cual. Esperar a la siguienteentrega de la plataforma.

Contribuir con parches. Obtener una ver-sión anterior de un componente y aplicarparches de manera opcional.

Trabajar juntos como un equipo virtual.Asumir la responsabilidad del desarrollo paralos componentes de dominio cruciales para elgrupo.

El principio más importante del desarrollo defuente interna es el de contar con un accesosencillo a toda la información de la línea deproducto. Del mismo modo que en el caso delsoftware libre la política deberá ser publicarrápido y a menudo para favorecer que losflujos de información entre Ingeniería deDominio y Aplicación sean lo más fluidosposible. Los equipos de Ingeniería de Domi-nio poseen y desarrollan los componentes dedominio. A un desarrollador de aplicacionesse le permite modificar componentes de do-minio, pero es responsable de dicho cambio.El cambio que se realiza podrá ser ofrecido "devuelta" a los equipos de Ingeniería de Domi-nio. El equipo encargado de la gestión de laplataforma podrá aceptar el parche comoparte de la propia plataforma, haciéndoseresponsable a partir de ese momento de dichocambio.

Como consecuencia de esto, la implicaciónde los equipos de Ingeniería de Aplicación enlo que respecta al dominio se mejora. Estotiene como efecto colateral que la plataformase usa de manera más extensa que antes y seajusta mejor a las necesidades de los gruposde Ingeniería de Aplicación. La metodologíade fuente interna permitió la publicación denuevos productos desde 2005 y la reducción

del tiempo de comercialización en al menos 3meses.

Sin embargo este modelo no ayuda a introdu-cir software de terceros en la línea de produc-to. La fase de colaboración se limita a lapropia empresa. El control del software es eneste caso muy claro y el desarrollo distribuidoy el mantenimiento se mejora sobre la situa-ción original. La metodología de fuente inter-na proporciona métodos de colaboraciónpara el desarrollo de software sobre métodostradicionales.

4.2. Usando herramientas de soft-ware libreEsta es la forma más sencilla de introducirsoftware libre en líneas de producto. Como elsoftware libre no aparece en el producto final,es muy sencillo para el usuario cumplir conlas reglas de la comunidad de software libre.Muchas herramientas está ya disponiblescomo software libre, aunque un factor encontra es que no existen muchas herramientasde software libre específicamente desarrolla-das para la gestión de líneas de producto. Unalista de este tipo de herramientas puede encon-trarse en las páginas de distribuidores desoftware para líneas de producto3 . La mayo-ría de estas herramientas no son softwarelibre. Algunas herramientas que se utilizan enel proyecto COSI para el desarrollo de líneasde producto y que son software libre son:

Stylebase para Eclipse: Herramientas desoftware libre que sirven para compartir yreutilizar conocimiento sobre arquitecturassoftware.4

Subversion: Proporciona gestión de ver-siones.5

Semantic MediaWiki: Apoya el desarrollocolaborativo de documentos dentro de unentorno de desarrollo colaborativo.6

4.3. Usando componentes de soft-ware libreEl uso de componentes de software libre enlíneas de producto no es un principio muydiferente al de usar cualquier otro software deterceros (COTS) en la línea de producto. Sinembargo existen diversos puntos sobre losque es necesario prestar especial atención. Laplanificación de la introducción de softwarede terceros en una línea de producto siemprese ve afectada por el hecho de que el ritmo dedesarrollo de este software no está controla-do por la propia compañía que lo utiliza:nuevas versiones de la aplicación que mejoranversiones anteriores de modos que no estáncontrolados por la empresa que lo utiliza.Estas mejoras influyen en la línea de produc-to, ya que partes de este software de tercerosse usan dentro de la Ingeniería de Dominioafectado a todos los productos. Por lo tantoesta nueva versión deberá ser incorporada ylas partes propietarias del software deberánser adaptadas. A menudo la nueva versión sebasa en diferentes mecanismos de arquitectu-

novática nº 199 mayo-junio 2009 33

Software libre para empresas monografía

monografía

ra e interfaces con respecto a los que están enuso en la línea de producto. Para solventareste problema la empresa que gestiona la líneade producto necesita saber con antelacióncómo va a evolucionar el software de terceros.En el caso de COTS esto implica tener uncontacto fluido con el proveedor. En el casode un desarrollo de software libre la empresadeberá implicarse en la propia comunidad dedesarrollo, o al menos estar conectada a laslistas de correo en las que se discuten todosestos aspectos. Además, si alguno de losdesarrolladores de la empresa se implica en lacomunidad de desarrollo, la empresa podríainfluir en el modo en el que este software vaa evolucionar, pudiendo incluso llevar a laincorporación de nuevas arquitecturas oestándares en el producto de software libre.En lugar de esperar a nuevas versiones delCOTS y a mantener contacto con el provee-dor, el software libre se adapta de maneramucho más continua. La posibilidad de ob-tener versiones tempranas del nuevo software(aunque pudieran aun tener algunos errores)sería de gran ayuda para comprobar que losnuevos cambios son conformes a la arquitec-tura de la línea de producto, así como paraacelerar la incorporación de la primera versiónestable. De modo recíproco el envío de infor-mes de fallos y correcciones ayudará a mejo-rar la calidad del software que se desarrollapor parte de la comunidad de desarrollo, quesi bien no es ya un elemento diferenciador parala empresa, es de vital importancia para lalínea de producto. Se ha de decidir cuidadosa-mente qué partes (y qué versiones) de soft-ware libre se convertirán en parte de la plata-forma, y qué software libre será únicamenteusado en ciertas aplicaciones. De hecho, po-dría convertirse en una estrategia incorporarlas últimas versiones de software libre única-mente en algunas aplicaciones de prueba,como es el caso del uso de COTS.

Otro problema en el desarrollo de softwarelibre está relacionado con las licencias. Esteproblema podría afectar al modo en el que elsoftware libre puede ser usado dentro de unalínea de producto. Algunas licencias de soft-ware libre harían necesario publicar las fuen-tes del código adicional (el que realmente davalor añadido). Hay opciones técnicas parasolventar este problema prestando especialatención a mantener un acoplamiento débilentre el software libre que se integra y eldesarrollado de manera interna en la empresa.Sin embargo probablemente acabará siendonecesario que la empresa done alguna parte desu software a la comunidad de desarrollopara demostrar su buena voluntad hacia ella[14].

Es necesario tomar precauciones cuando seincorpora software de distintas fuentes en lalínea de producto ya que las licencias particu-lares de cada componente podrían entrar enconflicto. Este aspecto deberá gestionarse

dentro de la propia organización por las si-guientes razones:

Ignorar las cuestiones relacionadas conlas licencias en alguno de los departamentospodría llevar a la necesidad de liberar softwarede otros departamentos de alto valor compe-titivo para la empresa.

El uso de software libre en el desarrollo deaplicación podría indicar un movimiento ha-cia la mercantilización, lo que a su vez origi-naría que ese software debería formar partedel software común. Hay que tener en cuentaque esto no es siempre lo que se pretende, yaque el software libre debería ser utilizadoúnicamente en código específico de aplica-ción para ciertos productos.

Nuevas versiones de los componentesbasados en software libre podrían provocarque algunos módulos de las aplicacionesquedaran obsoletos.

El uso de software libre podrían llevar aestándares internos adaptados en la línea deproducto. El único modo de gestionar esteproblema es a través del acuerdo de todas laspartes implicadas en el desarrollo de la líneade producto.

En el contexto en el que la empresa se implicaen el desarrollo de software libre, ésta podríaintroducir en la comunidad de desarrollo suspropias capacidades de gestión de la variabi-lidad. Esto facilitaría una solución para elproblema de la gestión de la configuración enlas comunidades de software libre. Sin embar-go la propia comunidad podría no valoraresta aportación y descartar las capacidades degestión de la variabilidad. En este caso, laempresa podría asociarse con otra comuni-dad que sí adopte estas herramientas. Estopodría asegurar el mantenimiento de losmecanismos que gestiona el aplicativo desoftware libre utilizado y garantizaría la acep-tación por parte de la comunidad de softwarelibre. No obstante es necesario tener en cuentaque el control sobre estos mecanismos podríaperderse una vez son liberados. La empresadeberá mantener su implicación en la comu-nidad y por ello invertir en personal o econó-micamente en la comunidad de desarrollo conel objeto de mantener el estado operativo delas herramientas.

En caso de conflictos con estándares de arqui-tectura, una opción es usar el conocimientoadquirido para COTS. Crear coberturas pro-pietarias o código de cohesión que conecte losmódulos internos de código con los que seencuentran en el mundo del software librepodría implicar actualizaciones demasiadofrecuentes debido a que ambos módulos evo-lucionan de manera independiente [14].

Otra opción está basada en que la empresaadopte la misma solución arquitectónica quese usa dentro de la comunidad de desarrollode software libre. La principal desventaja esque tanto la Ingeniería de Aplicación como la

de Dominio deberán asumir esta soluciónarquitectónica, lo que podría suponer unesfuerzo demasiado grande. La empresa hade asegurar en este caso que los mecanismosde la comunidad de software libre se adaptana sus necesidades internas, y que a través deellos pueden gestionar la variabilidad inheren-te a la línea de producto.

4.4. Liberando los productos de lalínea de productoMuchas empresas han pasado por experien-cias muy satisfactorias a la hora de liberarsoftware mercantilizado. A pesar de que enprimera instancia pueda parecer que se estáregalando la propiedad intelectual de losmódulos que se liberan, no suele ser el caso.El software que se encuentra en la parteinferior del diagrama de la figura 3figura 3figura 3figura 3figura 3 no suelecontener propiedad intelectual valiosa para laempresa y por esta razón puede ser liberadosin correr un riesgo excesivo. Un recurso másimportante es el conocimiento sobre cómoadaptar el software propio a las necesidadesde los clientes. Éste es un conocimiento queen ningún caso debería ser liberado. Losclientes son conscientes de que es mucho mássencillo y barato contratar a la empresa parainstalar el software y adaptarlo que asumirpor sí mismos la configuración completa.

Para Philips Healthcare la primera experiencialiberando software es la suite DVTk7 [13].Este software da soporte a la verificación dela conformidad de imágenes médicas con elestándar DICOM. Como los clientes conec-tarán equipamiento proporcionado por dife-rentes proveedores es importante que todaslas compañías cumplan con el estándar. Sinembargo, DVTk es únicamente software debase sin valor comercial per se para la compa-ñía. Por esta razón Philips decidió en 2005liberarlo lo que permitió compartir los es-fuerzos de desarrollo y mantenimiento a unaescala mucho mayor. De manera específicallevó a un desarrollo y mantenimiento muchomás rápidos por parte de la compañía, espe-cialmente en aquellas partes de DICOM queson genéricas y no específicas de las necesida-des de Philips.

4.5. Relaciones simbióticasFinalmente, los módulos propios del soft-ware de base pueden ser liberados a la comu-nidad para asegurar que ésta los mantiene yapoya su posterior evolución. Esto lleva auna reducción drástica de los costes de man-tenimiento de la empresa, ya que éstos pasaa compartirse con competidores y personasde otros dominios que también necesitan elsoftware. Las mejoras y pruebas masivas delsoftware serán realizadas por la comunidad yla propia compañía apoyará el desarrollopara asegurar que los problemas que aparez-can se solventan.Esto puede ser particularmente efectivo paraherramientas o componentes que han sido

novática nº 199 mayo-junio 200934 monografía

monografía Software libre para empresas

obtenidos por otras vías. La implicación en lacomunidad permite a la empresa asegurarsede que todos los requisitos internos se consi-deran y resuelven, y que el software sigue lalínea evolutiva más beneficiosa para la empre-sa. Por ejemplo, Philips Healthcare es ahoraparte de la comunidad Subversion8 . El obje-tivo inicial era solventar los problemas queaparecían en la resolución de conflictos en elárbol de versiones. Este enfoque fue de granéxito a través de la donación de una herra-mienta específica que solventaba este proble-ma y que se incluyó como parte de la versión1.6 de Subversion. Mientras tanto Philips seha convertido en usuario experto y miembroactivo de la comunidad Subversion influyen-do realmente en la evolución de este proyecto.

5. Líneas de producto en desarro-llo de software libre

5.1. Prácticas de líneas de productoDesde la perspectiva del software libre, algu-nas investigaciones han explorado proyectosde software libre con el objeto de analizarcómo ciertos principios y prácticas comunesde líneas de producto han sido adoptadas poréstos. Por ejemplo, un análisis del núcleo deLinux "demuestra cómo el núcleo de Linuxha alcanzado algunos de los objetivos que lasguías de las Líneas de Producto Softwareproponen" [17]. Más allá, van Gurp [7] ana-lizó las prácticas usadas en tres grandes pro-yectos de software libre (Eclipse, Mozilla y elkernel de Linux) desde una visión orientada asugerir mejoras en el desarrollo de líneas deproducto. Este estudio concluye con unasugerencia a los propietarios de líneas deproducto software "hay un conjunto de prác-ticas que pueden ser encontradas en grancantidad de proyectos de software libre quehan probado su funcionamiento satisfacto-rio al menos en este contexto".

Chastek et al. [4] han investigado los mode-los de desarrollo de líneas de producto desdeuna visión orientada a analizar cómo hanadoptado este modelo proyectos específicosde software libre. Han usado un frameworkpara pruebas de software de líneas de produc-to9 desarrollado por el Instituto de Ingenieríade la Universidad Carnegie Mellon®(SEI). Ensus análisis del proyecto Eclipse y su comu-nidad, demostraron que "Eclipse ha conse-guido alcanzar un equilibrio estable entre ladirección planificada y las contribuciones in-dividuales; también comparte el reto de laIngeniería de Líneas de Producto de gestionarde manera efectiva la comunicación entreaquellos que desarrollan recursos clave y losque los utilizan". Resumiendo, a pesar de quealgunos proyectos de software libre puedenser analizados como una línea de producto(por ejemplo Eclipse), los principios y prácti-cas de línea de Producto no se usan de manerageneralizada por parte de las comunidades dedesarrollo de software libre.

5.2. Arquitectura y variabilidadUn recurso muy importante en las líneas deproducto es la arquitectura de la plataforma,que define estándares para toda la línea deproducto. Todos los sistemas han de ser con-formes a esta arquitectura para asegurar el usoefectivo de la plataforma y el alcance de losobjetivos de las líneas de producto para reducirel esfuerzo de desarrollo. El problema principales que la arquitectura a menudo no está correc-tamente definida en las comunidades de soft-ware libre y por esta razón la conformidad conla misma es difícil de comprobar [8].

Las comunidades de software libre tienen amenudo otros mecanismos para gestionar lavariabilidad muy diferentes de los utilizadosdentro de una línea de producto. En muchoscasos el software libre nunca fue concebidopara ser usado en líneas de producto, y losproblemas relacionados con los procesos deconfiguración compleja son abundantes den-tro del mundo del software libre. Los puntosde variación y las variantes están (casi) ausen-tes en las metodologías de desarrollo desoftware libre. La variación espacial y tempo-ral no se diferencia de manera clara. La varia-ción se modela tradicionalmente a través delcódigo o de directivas de compilación, lo cualno resulta muy efectivo para las líneas deproducto.

No obstante las comunidades de softwarelibre han desarrollado métodos efectivos detratar con la configuración interna y la cons-trucción del producto final.

5.3. Dos procesosSin embargo dentro de las comunidades desoftware libre no existe una distinción claraentre la Ingeniería de Dominio y la Ingenieríade Aplicación, aunque ambas actividades serealizan dentro de las comunidades de soft-ware libre. Un grupo esencial dedesarrolladores experimentados se ocupan delas actividades que podrían englobarse dentrode la Ingeniería de Dominio. El softwareprincipal que se usa en toda el aplicativo esdesarrollado por estos desarrolladores prin-cipales. Los desarrolladores con menos expe-riencia o menos activos trabajan a menudo enaplicaciones específicas. Sin embargo, delmismo modo que en la Ingeniería de Líneasde Producto, la funcionalidad principal puedeemerger también de estos desarrolladores.Promocionar un recurso desde una aplica-ción hacia el propio dominio es relativamentesencillo en el caso de desarrollo de softwarelibre, y es también una de las ventajas delmodelo de desarrollo de fuente interna.

El ámbito del software libre no está a menudocorrectamente delimitado. Esto lo hace másflexible y amplía sus posibilidades de utiliza-ción. Sin embargo la falta de una arquitecturacorrectamente definida y el modelo de varia-bilidad utilizado hace difícil aplicar el soft-

ware en un entorno específico. Esto lleva aconflictos a la hora de decidir qué mecanis-mos se permiten y cuáles no, reduciendo asíla consistencia de los diferentes módulos.

6. ConclusionesEste artículo ha analizado el uso de softwarelibre en líneas de producto. El modelo dedesarrollo de software libre es inherentementeun modelo distribuido que constituye unmodo muy atractivo y probado de construirsoftware de gran calidad. Las empresas pue-den usar las comunidades de software librepara producir y mantener software de base(sin alto valor diferenciador). Esto liberarecursos de las compañías para producir soft-ware que sí tenga un alto valor específico.

Sin embargo la introducción de software libreen este ámbito no está libre de problemas, yaunque se solventen es necesario mantenerciertos recursos involucrados en la comuni-dad de software libre. Como el control y lapropiedad del software no quedan (en lamayoría de los casos) en la empresa que lousa, ésta ha continuar invirtiendo recursospara aprovechar las ventajas del softwarelibre. La empresa ha de considerar dentro desus procesos de planificación cómo implicar-se y como monitorizar la evolución del soft-ware libre que usa en sus líneas de producto,así como cuándo y cómo se introducen nue-vas versiones. Deben tenerse también en cuen-ta los problemas legales que podrían aparecersi el grupo de Ingeniería de Dominio no tieneconocimiento de los recursos de la línea deproducto que son software libre, así como desus licencias. Problemas similares puedenaparecer si el equipo de Ingeniería de Aplica-ción acopla demasiado el código interno queaporta valor añadido a los módulos de soft-ware libre.

Podrían aparecer problemas si la arquitecturade los módulos de software libre es incompa-tible con alguno de los productos de la líneade producto. La empresa podría utilizar elpoder adquirido a través de su implicación enla comunidad para proponer y llevar a cabolos cambios que adapten esta arquitectura ala suya o incorporar código que recubra estascaracterísticas incompatibles.

Las empresas que usan líneas de productocuentan a menudo con una gran organizacióndistribuida. El desarrollo distribuido generagran cantidad de problemas de coordinación,algunos de los cuales son solventados por elmodelos de desarrollo de software libre. Conel objeto de solventar algunas de las desven-tajas del uso de software libre, puede utilizar-se el modelo de desarrollo de fuente interna.Este último soluciona el problema del desa-rrollo distribuido, pero no ayuda a compartirel esfuerzo que se da cuando componentes desoftware libre se integran como parte de lalínea de producto.

novática nº 199 mayo-junio 2009 35

Software libre para empresas monografía

monografía

Referencias

[1] F. Bachmann, M. Goedicke, J. Leite, R. Nord,K. Pohl, B. Ramesh, A. Vilbig. "A Meta-Model forRepresenting Variability in Product FamilyDevelopment", Proceedings of the 5th InternationalWorkshop on Product Family Engineering (PFE-5),Siena, Italy, 2003, pp. 66-80.[2] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela,H. Obbink, K. Pohl. "Variability Issues in SoftwareProduct Lines". Proceedings of the 4th InternationalWorkshop in Product Family Engineering (PFE-4),Bilbao, Spain, October 3-5, 2001, Springer, BerlinHeidelberg New York, LNCS 2290, 2002, pp. 13-21.[3] Jan Bosch. "The Challenges of Broadening thescope of Software Product Families".Communications of the ACM, December 2006, pp.41-44.[4] G.J. Chastek , J.D. McGregor, L.M. Northrop."Observations from Viewing Eclipse as a ProductLine". En F. van der Linden, B. Lundell (Eds.)OSSPL07 Asia, September 10, 2007, Kyoto, Japan<ht tp : / / i t ea -cos i .o rg /modu les /w ik imod/index.php?page=OssPlas07>.[5] COSI. Co-development using inner & Opensource in Software Intensive systems, ITEA project2005-2008, <http://itea-cosi.org/ and http://www.friprog.no/Laer-mer/Prosjekter/COSI-Library-of-Assets>.[6] B. Fitzgerald. "The Transformation of opensource Software". MIS Quarterly, Vol. 30, No. 3,2006 pp. 587-598.[7] J. van Gurp. "OSS Product Family Engineering".First International Workshop on open source Soft-ware and Product Lines, Maryland, 2006 <http://www.sei.cmu.edu/splc2006/Gurp_paper.pdf>.[8] I. Hammouda, T. Mikkonen. Open sourceContributions as Platform Specialization Units. EnF. van der Linden, B. Lundell, Proceedings on the

special10_10/perens/index.html>.[16] K. Pohl, G. Böckle, F. van der Linden."Software Product Line Engineering: Foundations,Principles, and Techniques". Springer, 2005. ISBN-10: 3-540-24372-0.[17] J. Sincero, H. Schirmeier, W. Schröder-Preikschat, O. Spinczyk. "Is The Linux Kernel aSoftware Product Line?". En F. van der Linden, B.Lundell (Eds.), Proceedings on the Third InternationalWorkshop on open source Software and ProductLines: OSSPL07 Asia, September 10, 2007, Kyoto,Japan <http://itea-cosi.org/modules/wikimod/index.php?page=OssPlas07>.[18] A. Stellman, J. Greene. Beautiful Teams.O’Reily 2009 pp. 103-111. ISBN: 0596518021.[19] J. Wesselius. "The Bazaar inside the Cathedral:Business Models for Internal Markets". IEEE Soft-ware Vol. 25, No. 3, May/June 2008 pp. 60-66.

1 TPPT Nuestra experiencia en la industria europeadel software se alinea con la vision de Perens [15]quien estima que quizás el 90% del software encualquier empresa no es diferenciador"2 DVTk ( Dicom Validation Toolkit), software libreque soporta el intercambio de imágenes médicas<http://www.dvtk.org/>.3 <http://www.softwareproductl ines.com/resources/vendors.html>.4 <http://stylebase.tigris.org>.5 <http://subversion.tigris.org>.6 <http://semantic-mediawiki.org/wiki/Semantic_MediaWiki>.7 <http://www.dvtk.org/>.8 <http://subversion.tigris.org>.9 <http://www.sei.cmu.edu/productlines/framework.html>.

Notas

Second International Workshop on OSSPL07 opensource Software and Product Lines 2007, June 14,2007, Limerick, Ireland <http://www.itea-cosi.org/modules/wikimod/index.php?page=OssPl07 paper#3>.[9] A.A. Jilderda. Inner Source SoftwareEngineering at MIP fostering a meritocracy ofpeers. Research Report, Philips Research, TheNetherlands, 2004.[10] K. Kang, S. Cohen, J.A. Hess, W.E. Novak,S.A. Peterson. "Feature-Oriented Domain Analysis(FODA) Feasiblity Study", Technical Report, Soft-ware Engineering Institute, Carnegie-MellonUniversity, 1990.[11] F. van der Linden, K. Schmid, E. Rommes."Software Product Lines in Action", Springer Verlag,2007[12] F. van der Linden, B. Lundell. Proceedingson the Third International Workshop on open sourceSoftware and Product Lines: OSSPL07 Asia,September 10, 2007, Kyoto, Japan.<ht tp : / / i t ea -cos i .o rg /modu les /w ik imod/index.php?page=OssPlas07>.[13] F. van der Linden, B. Lundell, P.Marttiin."Commodification of Industrial Software:A Case for Open Source", pendiente de publicarIEEE Software July-August 2009.[14] J. Merilinna, M. Matinlassi. "Product FamilyApproach for Integration of In-house Software andopen source Components". En F. van der Linden,B. Lundell, Proceedings on the Second InternationalWorkshop on OSSPL07 open source Software andProduct Lines 2007, June 14 2007, Limerick,Ireland <http://www.itea-cosi.org/modules/wikimod/index.php?page=OssPl07 paper #2>.[15] B. Perens. "The emerging economic paradigmof open source". First Monday, Vol. 10, No. 10,2005, <http://www.firstmonday.org/issues/

novática nº 199 mayo-junio 200936 monografía

monografía Software libre para empresas

El uso y desarrollo de software libre se hanincrementado significativamente en los últi-mos años. Tomando como punto de partidala investigación y las actividades dirigidas porla comunidad, un nuevo segmento de negocioha sido desarrollado recientemente alrededordel software libre. Mientras algunas de lascompañías más importantes en el mundo delsoftware libre (por ej. RedHat) hasta ahora sehan convertido en los principales agentes delmercado e incluso algunas de las mayorescompañías de software (por ej. IBM, Sun…)han desarrollado sus propios productos yestrategias en software libre, éste ha sidohasta el momento un punto estratégico espe-cialmente para las pequeñas y medianas em-presas. Debido a la participación de empresasorientadas a obtener beneficios económicos,podemos observar una profesionalización enlos procesos de desarrollo y también en térmi-nos de mantenimiento de recursos y continui-dad [1][2][3].

Aunque la profesionalización e industrializa-ción del desarrollo de software libre es unfenómeno ya visible, existen aún prejuiciospor parte de los usuarios y problemas para lasempresas que impiden un uso aún más am-plio y una mayor variedad de ofertas [4].

La agencia de innovación TSB Berlin Gmbhha publicado recientemente un estudio sobreel sector del software libre en Berlín que ofreceuna visión general de la situación actual delmercado alemán en la región de la capital,mostrando las debilidades y las necesidadesde las empresas y los agentes activos, asícomo el potencial de la región [4].

Según el estudio, las principales razones parael uso del denominado Software Libre porparte de la industria de Berlín son las ventajaseconómicas, las preferencias personales yrazones de calidad, que son las tres mencio-nadas por más del 60% de los agentes indus-triales y claramente superan otras motivacio-nes de organización y de imagen, que son sólomencionadas por menos del 30% (ver figurafigurafigurafigurafigura11111).

Las dos limitaciones más importantes parael éxito del software libre en el mercado (am-bas mencionadas por cerca del 60% de losagentes más importantes relacionados con elsoftware libre en Berlín) son el insuficienteapoyo político y los prejuicios existentes res-pecto a la calidad y sostenibilidad del software

libre (ver figura 1figura 1figura 1figura 1figura 1). Además, otroslimitadores menos mencionados serían ladificultad de competir contra los agentesdominantes en el mercado, la falta de mode-los de negocio y financiación (algo por enci-ma del 40%), así como las cuestiones legales(casi el 25%).

El sector del software libre en Berlín se carac-teriza, por un lado, por la alta demanda desoluciones desarrolladas con software libre yuna fuerte relación entre software libre e I+D.Por otro lado, la industria del software libreen Berlín se encuentra muy dispersa y nosuficientemente integrada en una red principalespecializada en software libre [4].

Analizando estas fortalezas, debilidades, opor-tunidades y amenazas para el desarrollo de laindustria del software libre en la región deBerlín capital es reseñable que las oportunida-des más importantes para la industria coinci-den con las principales debilidades y las mayo-res fortalezas con las amenazas (ver figurafigurafigurafigurafigura22222). Una estrategia razonable sería por lotanto abordar las amenazas cuando sea po-sible y fortalecer la industria del software libreen particular cuando se encuentren las opor-tunidades.

Para la región de Berlín, este esfuerzo implicaen especial abordar los prejuicios sobre lacalidad, el fortalecimiento de la integración enla cadena de valor y el fomento de la transfe-rencia de conocimientos de I+D para aplica-ciones industriales.

Mejorar la percepción de la calidad requiereno sólo usar sofisticadas herramientas de

desarrollo orientadas a la calidad y a losprocesos, sino también realizar pruebas delproducto y su evaluación. Las evaluacionesde calidad deberían hacerse visibles medianteel marketing y la comunicación. Un pasoimportante hacia la mejora de la transferenciade conocimientos y la integración en la cadenade valor podría lograrse con una mejor co-nexión en red en la región de Berlín capital, quehasta ahora no ha tenido una estrategia clarani ha sido suficientemente establecida.

Estos pasos, necesarios para el fortaleci-miento de la industria del software libre en laregión de Berlín, coinciden con el enfoque delcentro del proyecto europeo Qualipso, querecientemente ha establecido centros de com-petencia de software libre en Madrid (Espa-ña), Sao Carlos (Brasil) y Berlín (Alemania)y tiene previsto establecer más adelante nue-vos Centros de Competencia en Italia, China,Polonia y Francia.

Estos centros de competencia prestarán ser-vicios derivados de los resultados del proyec-to Qualipso, que están dedicados a mejorarla calidad del software libre en los diferentesaspectos. Estos comprenden las herramien-tas y las mejores prácticas para unaprofesionalización e industrialización del pro-ceso de desarrollo, pruebas de productos yetiquetado, medidas de la interoperabilidad, yevaluación jurídica, así como certificación yformación.

El segundo objetivo de los Centros de Com-petencia Qualipso es construir redes regiona-les. Los Centros de Competencia están habi-litados para conectarse a través de la Red

Abordar las necesidades de laindustria en Software Libre

Jan Henrik ZiesingFraunhofer FOKUS, Centro de Competenciade Qualipso de Berlín (Alemania)

< j a n . z i e s i n g @ f o c u s . f r a u n h o f e r . d e >< j a n . z i e s i n g @ f o c u s . f r a u n h o f e r . d e >< j a n . z i e s i n g @ f o c u s . f r a u n h o f e r . d e >< j a n . z i e s i n g @ f o c u s . f r a u n h o f e r . d e >< j a n . z i e s i n g @ f o c u s . f r a u n h o f e r . d e >

Traducción: Traducción: Traducción: Traducción: Traducción: Miguel Angel Tinte García (GSyC/LibreSoft, Universidad Rey Juan Carlos)

Resumen: el software libre está, además de cosechando un gran éxito, atacando los viejos prejuicios y lastradicionales dificultades del mercado. Para profundizar en estos temas, Fraunhofer Fokus está fusionan-do los resultados del proyecto europeo Qualipso con su demostrado modelo teórico sobre interoperabilidaden el sector público, orientándolo a la industria de las tecnologías de la información. De esta manera,podrá transferir el éxito obtenido y los modelos de negocio teóricos de interoperabilidad al mundo delsoftware libre en la región de Berlín capital.

Palabras clave: interoperabilidad, necesidades de la industria, Qualipso, software libre.

Autor

Jan Henrik Ziesing trabaja como científico e investigador para el Instituto Fraunhofer en sistemas decomunicación abiertos en Berlín. Con una amplia experiencia en la transferencia de investigación aplica-da, Jan se ha incorporado recientemente a las actividades del Centro de Competencia del proyectoQualipso en Berlín.

novática nº 199 mayo-junio 2009 37

Software libre para empresas monografía

monografía

Qualipso, por lo que pueden ofrecer soportea redes, apoyo y capacidad de intercambiarbuenas prácticas no sólo en su región sino entodo el mundo.

Fraunhofer FOKUS (Fraunhofer Institutefor Open Communication Systems), comoimpulsora del Centro de Competencia deQualipso en Berlín, ha adquirido una amplia

experiencia en los últimos años en solucionesinformáticas para los sectores públicos. Untema importante ha sido y sigue siendo elpaisaje heterogéneo existente en las tecnolo-gías informáticas, lo que dificulta el inter-cambio de datos entre diferentes aplicacioneso entidades públicas.

Las aplicaciones utilizadas en el sector públi-

co en Alemania están, en general, altamenteespecializadas para su aplicación en su domi-nio y para ofrecer todas las funciones y servi-cios para este dominio en una única herra-mienta. La interoperabilidad con otras apli-caciones del mismo o de un dominio diferenteno se consideró importante. Para el intercam-bio de datos entre diferentes aplicaciones erabastante común imprimir un documento en

Figura 1. Principales razones y limitadores del software libre en la región de Berlín.

Figura 2. Análisis de la matriz DAFO.

novática nº 199 mayo-junio 200938 monografía

monografía Software libre para empresas

una aplicación y escribirlo de nuevo a manoen otra aplicación.

Hoy en día, se hace evidente una tendenciahacia un eficiente y ergonómico proceso deadministración electrónica basado en la co-nexión e integración de diferentes ámbitos deaplicación. Fraunhofer FOKUS se convirtióen uno de los principales impulsores de estatendencia en Alemania mostrando en su La-boratorio de Administración Electrónica [5]las posibilidades y ventajas de una integracióny orquestación de los diferentes dominiosespecíficos de las aplicaciones software. ElLaboratorio Administración Electrónica sededica a investigar sobre interoperabilidad, aconectar a los principales actores de los sec-tores públicos y a comunicar sus logros.

Otra tendencia en la administración electróni-ca observada por Fraunhofer FOKUS es eldesarrollo de servicios orientados a las arqui-tecturas en el sector público. Esto es especial-mente interesante para la industria del soft-ware libre. La mayoría de las herramientas desoftware libre ofrecen determinados serviciospara la solución de un cierto problema ennumerosos ámbitos de aplicación, en lugar deofrecer un conjunto de servicios integrados en

Referencias

[1] J.-P. Laisné at al. 2020 FLOSS Roadmap,2008.[2] D. Kühni. Kurze betriebswirtschaftliche Analysevon Open Source Software. (i. GmbH, Hrsg.) Bern,Schweiz, 2006.[3] J. Lerner, J. Tirole. Some simple economicsof open source. Journal of Industrial Economics,50 (2), 2002.[4] D.M. Fornefeld, M. Gasper. Potenzialanalyseim Technologiefeld Open Source in derHauptstadtregion Berlin. (T. I. GmbH, Hrsg.) Berlin,Deutschland, February 2009.[5] Fraunhofer FOKUS. Fraunhofer FOKUSeGovernment-Lab. <http://www.fokus.fraunhofer.de/en/fokus_testbeds/egov-lab/index.html>.

una aplicación de un dominio específico.Mediante la transferencia por parte delFraunhofer FOKUS de su interoperabilidad ysus conocimientos sobre el sector, el Centrode Competencia de Qualipso podrá hacerfrente al mercado del software libre en elsector público mediante nuevos escenarios deinteroperabilidad. Estos escenarios ayudarána la industria a desarrollar soluciones especí-ficas de dominio complejo mediante la ofertade mayores facilidades para la integración yorquestación de herramientas interoperablesde código abierto.

Además de centrarse en la interoperabilidad delos servicios para software libre, el reciente-mente inaugurado Centro de Competenciade Qualipso en Berlín fomentará el desarrollode software libre, ofreciendo una forja deúltima generación, así como la creación deredes de comunicación y oportunidades parala industria del software libre. El Centro deCompetencia podrá, por lo tanto, hacer frentea las necesidades más urgentes de la industriadel software libre en la región de Berlín, trans-firiendo un enfoque previamente experimen-tado de Fraunhofer FOKUS al sector delsoftware libre.

Presidente del Comité de Programa:Antonio Vallecillo (Univ. Málaga)

Coordinadora de Talleres: Coral Calero (Univ. Castilla-La Mancha)

Coordinador de Tutoriales:Ernest Teniente (Univ. Polit. Cataluña)

Coordinadores de Publicidad:Gentzane Aldekoa (Univ. Mondragón) José Raúl Romero (Univ. Córdoba)

Coordinadora de la Web:Ana Altuna (Univ. Mondragón)

Presidente del Comité Organizador:Goiuria Sagardui (Univ. Mondragón)

Coordinador de Demostraciones:Juan de Lara (Univ. Autónoma Madrid)

Coordinadora de Divulgaciónde Trabajos Relevantes ya Publicados:Belén Vela (Univ. Rey Juan Carlos)

Coordinadora de actas:Leire Etxeberria (Univ. Mondragón)

TALLERESZOCO - Integración de Aplicaciones Web no DesmantelableADIS - Apoyo a la Decisión en Ingeniería del SoftwarePRIS - Pruebas en Ingeniería del SoftwarePNIS - Procesos de Negocio e Ingeniería de ServiciosDSDM - Desarrollo de Software Dirigido por ModelosWASELF - Autonomic and SELF-adaptive Systems

XIV Jornadas de Ingeniería del Software y Bases de DatosSan Sebastián, 8-11 de Septiembre 2009

http://www.mondragon.edu/jisbd2009/

TUTORIALESAnálisis en líneas de productos: avances, desafíos y lecciones

aprendidasDavid Benavides, Antonio Ruiz y Pablo TrinidadUniv. de Sevilla

Herramientas Eclipse para el Desarrollo de Software Dirigido porModelos

Cristina Vicente y Diego Alonso Univ. Politécnica de Cartagena

CONFERENCIAS INVITADASJean Bezivin, Universidad de Nantes, FranciaDon Batory, Universidad de Texas en Austin, USAHouari Sahraou, Universidad de Montreal,

Canada

Evento Hasta30-junio

Hasta31-julio

Tardía

JISBD 350€ 390€ 430€Taller inscritos JISBD 100€ 115€ 130€Taller no inscritos en JISBD 130€ 145€ 160€Tutorial no inscritos en JISBD 50€ 50€ 50€

Evento Hasta30-junio

Hasta31-julio

Tardía

JISBD 350€ 390€ 430€Taller inscritos JISBD 100€ 115€ 130€Taller no inscritos en JISBD 130€ 145€ 160€Tutorial no inscritos en JISBD 50€ 50€ 50€Presidente del Comité de Programa:

Antonio Vallecillo (Univ. Málaga)Coordinadora de Talleres: Coral Calero (Univ. Castilla-La Mancha)

Coordinador de Tutoriales:Ernest Teniente (Univ. Polit. Cataluña)

Coordinadores de Publicidad:Gentzane Aldekoa (Univ. Mondragón) José Raúl Romero (Univ. Córdoba)

Coordinadora de la Web:Ana Altuna (Univ. Mondragón)

Presidente del Comité Organizador:Goiuria Sagardui (Univ. Mondragón)

Coordinador de Demostraciones:Juan de Lara (Univ. Autónoma Madrid)

Coordinadora de Divulgaciónde Trabajos Relevantes ya Publicados:Belén Vela (Univ. Rey Juan Carlos)

Coordinadora de actas:Leire Etxeberria (Univ. Mondragón)

TALLERESZOCO - Integración de Aplicaciones Web no DesmantelableADIS - Apoyo a la Decisión en Ingeniería del SoftwarePRIS - Pruebas en Ingeniería del SoftwarePNIS - Procesos de Negocio e Ingeniería de ServiciosDSDM - Desarrollo de Software Dirigido por ModelosWASELF - Autonomic and SELF-adaptive Systems

XIV Jornadas de Ingeniería del Software y Bases de DatosSan Sebastián, 8-11 de Septiembre 2009

http://www.mondragon.edu/jisbd2009/

TUTORIALESAnálisis en líneas de productos: avances, desafíos y lecciones

aprendidasDavid Benavides, Antonio Ruiz y Pablo TrinidadUniv. de Sevilla

Herramientas Eclipse para el Desarrollo de Software Dirigido porModelos

Cristina Vicente y Diego Alonso Univ. Politécnica de Cartagena

CONFERENCIAS INVITADASJean Bezivin, Universidad de Nantes, FranciaDon Batory, Universidad de Texas en Austin, USAHouari Sahraou, Universidad de Montreal,

Canada

Evento Hasta30-junio

Hasta31-julio

Tardía

JISBD 350€ 390€ 430€Taller inscritos JISBD 100€ 115€ 130€Taller no inscritos en JISBD 130€ 145€ 160€Tutorial no inscritos en JISBD 50€ 50€ 50€

Evento Hasta30-junio

Hasta31-julio

Tardía

JISBD 350€ 390€ 430€Taller inscritos JISBD 100€ 115€ 130€Taller no inscritos en JISBD 130€ 145€ 160€Tutorial no inscritos en JISBD 50€ 50€ 50€

novática nº 199 mayo-junio 2009 39

Software libre para empresas monografía

monografía

1. IntroducciónEngineering1 es una empresa informáticaglobal, y el mayor operador informático deItalia en el sector servicios, proveedor líder deofertas completas e integradas en toda lacadena de valor del software: diseño, desarro-llo, servicios externalizados, productos y so-luciones privativas verticales, consultoría es-tratégica e informática… ajustadas a losmodelos de negocio de nuestros clientes entodos los mercados.

Hace ya más de cinco años desde queEngineering decidiera desarrollar y gestionardirectamente proyectos de software libre, enlugar de simplemente colaborar con variascomunidades de software libre, o usar direc-tamente sus resultados. SpagoWorld2 , laprincipal iniciativa de software libre deEngineering, constituye un ecosistema quereúne empresas, integradores, vendedores, ins-tituciones y usuarios operando de una mane-ra efectiva para añadir valor al dominio delsoftware libre.

La construcción de un ecosistema de soft-ware libre efectivo requiere algunos aspectosclave:

Colaboración con las comunidades desoftware libre a nivel internacional.

Realización de proyectos efectivos en elámbito de las tecnologías actuales más estra-tégicas, presentando al mismo tiempo unavisión innovadora.

Éxito comercial.

En la actualidad, SpagoWorld es unecosistema de software libre basado en pro-yectos que se enfocan en inteligencia de nego-cios y dominios de gestión de procesos denegocios (SOA, Service-OrientedArchitecture), los cuales han sido identifica-dos por Engineering como los más promete-dores en el mundo del software libre. Losproyectos se alojan en la comunidad globalOW23 y añaden un enfoque original a lascapacidades estándar de sus dominios espe-cíficos, que se caracteriza por una especialatención a las necesidades de los usuarios,siendo ésta la razón del incremento de surendimiento comercial.

La iniciativa SpagoWorld no es sólo coope-ración tecnológica; su objetivo principal espromocionar las comunidades de los proyec-tos, a la vez que se asegura la libertad delsoftware desarrollado a tiempo y de las cola-

boraciones con empresas, de manera que seconsolida un modelo de negocio diversificadoy basado en un enfoque comercial del soft-ware libre. Los aspectos más destacados deeste enfoque son: desarrollo de solucionesadaptables con énfasis en los requisitos de losusuarios, desarrollo de soluciones a nivelempresarial, soporte a los servicios ofrecidos,atención prestada a las demandas de las co-munidades de software libre y la comunidadacadémica, y, finalmente, todo lo que concier-ne al crecimiento de un ecosistema que creanuevo valor para todos sus participantes.

SpagoWorld es un ejemplo efectivo deecosistema de negocios que actúa con unmodelo de negocio específico, basado en eldesarrollo y la promoción de soluciones par-ticulares (mediante la venta de soporte aservicios y proyectos de software relaciona-dos) y al mismo tiempo sostiene el sistemaentero en un verdadero entorno decoopetición4 . El dominio del software libre esparticularmente apropiado para el desarrollode una estrategia colectiva que incrementa elvalor en un contexto que puede ser definidocomo "ecológico", donde las ganancias nomonetarias y difícilmente cuantificables pue-den ser más beneficiosas que las monetarias,porque son beneficios a largo plazo en uncontexto de sostenibilidad.

2. Engineering y el software libreEngineering lleva a cabo la definición de solu-ciones con arquitecturas innovadoras, y larealización de proyectos complejos para laadministración publica, instituciones finan-cieras y grandes empresas, usando tanto soft-ware libre como soluciones privativas.

Después de una primera fase centrada en elapoyo a iniciativas de software libre y lainvestigación de comunidades, desde el año2004 Engineering ha definido una estrategiaenfocada en el desarrollo, implementación yentrega de soluciones basadas en softwarelibre como una oportunidad tecnológica y denegocio en los servicios que ofrece a susclientes, siendo sus objetivos principales lossiguientes:

Uso industrial del software libre en lasactividades de integración de sistemas, y pro-visión de un soporte completo a los serviciosofrecidos.

Contribución activa en varios proyectosde software libre.

Presencia activa en comunidades interna-cionales.

Desarrollo y apoyo de iniciativas de soft-ware libre.

En la actualidad, la compañía cree que elsoftware libre es un factor acelerador para la

SpagoWorld, la iniciativa desoftware libre de Engineering

Gabriele RuffattiDirector de Arquitecturas y Consultoría, Gru-po Engineering I+D, Italia

< g a b r i e l e . r u f f a t t i @ e n g . i t >< g a b r i e l e . r u f f a t t i @ e n g . i t >< g a b r i e l e . r u f f a t t i @ e n g . i t >< g a b r i e l e . r u f f a t t i @ e n g . i t >< g a b r i e l e . r u f f a t t i @ e n g . i t >

Traducción: Traducción: Traducción: Traducción: Traducción: Israel Herraiz Tabernero (Universidad Complutense de Madrid)

Resumen: este artículo muestra un caso de estudio basado en la experiencia de una empresa informáticaen el desarrollo y la gestión de proyectos de software libre. En la primera parte, presentamos la compañíay su papel en actividades relacionadas con software libre. Después, el artículo presenta las razones y laestrategia corporativa para entrar en el mundo del software libre, y el modelo de negocio de SpagoWorld,la principal iniciativa sobre software libre de Engineering. Finalmente, se investiga el doble papel que juegaen actividades comerciales y creación y gestión de comunidades, con énfasis en la sostenibilidad delmodelo.

Palabras clave: empresas informáticas, estrategias corporativas, software libre.

Autor

Gabriele Ruffatti es director de la unidad de Arquitecturas y Consultoría en la división de I+D deEngineering. Con más de 27 de años de experiencia en el ámbito de la informática, ha ejercido variospuestos de gestión en diferentes áreas dentro del Grupo Engineering, como por ejemplo el desarrollo deproductos complejos y de proyectos para importantes firmas y para el sector público, en procesos demejora de calidad de software y de aseguramiento de calidad, además de en la definición de solucionesinnovadoras. Además, contribuyó al inicio y desarrollo del sistema corporativo de calidad, y ayudó aconseguir las certificaciones CMMI e ISO 9001:2000. En 2004 lanzó la iniciativa de software libreSpagoWorld. Además, Gabriele coordina las actividades de software libre en Engineering. Es miembro delConsejo de SpagoWorld y del consorcio OW2. De 2006 a 2008, participó como profesor asociado,impartiendo clases sobre software libre, en el Departamento de Matemáticas, Física y Ciencias Naturalesde la Universidad de Padua, dentro del programa de Máster en Informática.

novática nº 199 mayo-junio 200940 monografía

monografía Software libre para empresas

consecución de objetivos estratégicos críti-cos en la empresa.

La compañía proporciona a sus clientes suexperiencia y conocimiento para la selección,integración, validación y soporte de los mejo-res componentes de software libre, incluyen-do sus propias soluciones, ofreciendoles losbeneficios completos de un mayor ratio devalor monetario, gracias a atractivos esque-mas de licenciamiento de software libre, y a larobustez como resultado de un intenso escru-tinio del código fuente.

El enfoque sobre el software libre es racionaldesde un punto de vista ingenieril: analizar lasventajas e inconvenientes, y tomar decisionesadecuadas mejor que ideológicas. Engineeringestá convencida de que un uso adecuado delsoftware libre puede ayudar a generar altosretornos para sus clientes, a la vez que semejora la calidad de los sistemas.

3. El proceso de liberación de soft-ware de Engineering: razones yestrategiaEn los últimos 30 años, Engineering ha ope-rado en los mercados de desarrollo de soft-ware e integración de sistemas. Hace seisaños, la compañía comenzó a pensar que elsoftware libre era útil para los negocios. Enaquella época, el software libre no estaba tanextendido en el mercado como lo está ahora,y la cuestión era si el software libre tenía elpotencial para proporcionar beneficios en elmercado de integración de sistemas. Pararesponder a esta cuestión, la compañía ana-lizó las características particulares del soft-ware libre, y determinó que, por varias razo-nes, era posible elaborar un modelo de nego-cio válido para los integradores de sistemas,que podían aprovecharse de estas caracterís-ticas.

Resumiendo, la completa ausencia de costesde licencia puede liberar recursos financierosque el cliente puede dedicar a la adquisición deservicios y de soluciones a medida, aspectosfundamentales ambos del negocio de unintegrador de sistemas. La disponibilidad delcódigo fuente permite al integrador de siste-mas extender su oferta en las áreas de soportey servicios al mantenimiento de soluciones desoftware libre. Este mercado potencial tieneuna barrera de entrada muy baja, de modo queno existen posiciones dominantes.

Además, hay que tener en cuenta que laprincipal característica de un profesionalinformático, que tiene que encontrar la mejorsolución para su propio cliente, está represen-tada por su competencia adquirida gracias ala experiencia. Por tanto, es inevitable que lapreparación en el dominio del software libre sehaga haciendo, es decir mediante la gestión yparticipación activa en proyectos de softwarelibre.

Orazio Viele, gerente de I+D en Engineering,escribió en 2005: "El software libre representamás una oportunidad que una amenaza paraun integrador de sistemas. En la actualidad,no podemos establecer cuál es el valor poten-cial de mercado estimulado por el softwarelibre. Sin embargo, las características de estefenómeno son tales que podemos predecir uncrecimiento progresivo en los próximos años.El reto para un integrador de sistemas consis-te en una excelente preparación, porque éstaes la única manera de tomar ventaja de losmejores resultados provocados por esta re-volución". [1].

Tras examinar estas razones, se hizo necesa-rio definir cómo enfocar esta oportunidad ydefinir una estrategia para posicionar conéxito a Engineering en este mercado.

Durante estos últimos seis años, Engineeringha mejorado esta estrategia, basándose en lossiguientes principios:

Tomar una posición líder en el mundo delsoftware libre, desarrollando sus propiassoluciones y creando un ecosistema alrede-dor de ellas. Esto diferencia a la compañía deotros integradores de sistemas, que sólo usansoluciones desarrolladas por otros. La inicia-tiva SpagoWorld es una acción concreta, parallevar a cabo esta estrategia. Todo esto hizoposible que Engineering fuera percibido comoun productor de soluciones de software libre,especialmente fuera de Italia.

Ser parte y contribuir a las comunidadesinternacionales de software libre, para crearuna red colaborativa que enriquezca su ofertaal mercado de soluciones y servicios. El sermiembro del consorcio OW2 y las contribu-ciones a diferentes comunidades son pruebasclaras de esta estrategia.

Seleccionar soluciones de software librede alta fiabilidad, para ofrecerlas a sus clien-tes y satisfacer sus demandas. Dos herra-mientas adoptadas para alcanzar este objeti-vo son la creación de un centro de competen-cia dedicado en exclusiva a explorar solucio-nes, y la definición de una metodología paraevaluar software libre.

La estrategia adoptada por Engineering res-pecto al software libre está centrada en dosaspectos más:

Desarrollo de software libre y gratuito,teniendo en cuenta que Engineering no adop-ta un esquema de licenciamiento dual, sinoque desarrolla y gestiona software liberadoúnicamente con licencias libres (como la li-cencia Apache o la GNU GPL/LGPL5 ), evi-tando cualquier política que asemeje el soft-ware libre al modelo privativo6 .

Un modelo de negocio centrado en elproyecto, donde el proyecto es más importan-te que las soluciones tecnológicas que seadopten, y donde se explota la capacidad paradiseñar y desarrollar sistemas complejos ca-paces de satisfacer las demandas de los clien-

tes. En este modelo, el uso de software librese convierte en una herramienta para mejorarlas habilidades de diseño y el know-how téc-nico de un integrador de sistemas.

Esta estrategia no se planeó a priori, sino quederiva de un análisis de resultados, y de sucrecimiento y adaptación en el tiempo. Así,tras algunos años de actividad, podemosdecir que hemos vivido la experiencia de inte-grarnos en un entorno ecológico competiti-vo, donde el concepto estratégico ha cambia-do respecto al previamente conocido. "Para eldesarrollo de una estrategia, normalmente esimportante fijar objetivos a corto, medio ylargo plazo, y definir un plan, llamado estra-tégico, a través del cual podamos alcanzaresos objetivos, definiendo los medios másadecuados, y suponiendo que siempre seráninsuficientes. Adaptar un enfoque ecológicodel valor supone tanto abandonar la parte decerteza que se deriva de la posesión de un plandefinido para desarrollar un cierto conjuntode objetivos, como cambiarlos debido a nues-tra capacidad de exploración continua denuestra existencia en el mundo y al sentido quetenemos que asignarle a este hecho. El obje-tivo es mejorar la calidad de nuestra condi-ción, experimentando todos los posibles po-tenciales distintos." [2].

4. El modelo de negocio de soft-ware libre de EngineeringEngineering considera en su modelo de nego-cio que en la actualidad el software libre no essimplemente un modelo de desarrollo y distri-bución de software, sino que estácorrelacionado con la naturaleza de las co-municaciones, con su evolución en el tiempojunto a los modelos de negocio, y con suestructura ecológica (Véase [3] para unacomparación entre ecosistemas de negociosy ecosistemas biológicos).

En la actualidad, Engineering es un agenteinformático global, aunque es principalmen-te un integrador de sistemas con característi-cas particulares, cuyos resultados se valoranen el mercado como los resultados de unaempresa informática con rendimientos efec-tivos de desarrollo, comenzando por:

La capacidad "genética" para el diseño.Un énfasis importante en la adquisición de

conocimientos de primera mano (primero"testea", luego propón a los clientes y final-mente desarrolla), crecientes en el tiempomediante experiencia y evaluación.

Independencia de la solución elegida yadoptada.

Flexibilidad con respecto a las diferentessituaciones, y una actitud natural para adap-tar cada solución a distintos contextos, demodo que se generen soluciones y productoscon un alto nivel de adaptación al cliente.

Un enfoque industrial que hace énfasis enla adopción de los resultados en el mundo"real", de una manera efectiva.

novática nº 199 mayo-junio 2009 41

Software libre para empresas monografía

monografía

Estas características también se aplican alcaso del software libre, especialmente en eldiseño y desarrollo de soluciones, con unaactitud independiente y un enfoque en la uti-lidad industrial.

Como resultado, el modelo de software librede Engineering es un modelo empresarial desoftware libre, en lo que respecta al desarrollode proyectos y soluciones abiertas, y un mo-delo profesional de software libre en lo querespecta a la certificación de competencias yservicios de soporte a soluciones abiertas.

Más en detalle, el modelo de desarrollo desoftware libre puede calificarse como centra-do en el proyecto, porque "el alcance deldesarrollo de una solución específica com-prende la realización de proyectos de softwarebajo las demandas de diferentes clientes, quese pueden beneficiar de una solución de soft-ware libre, ofreciendo mejores característicasque una solución propietario en términos dedisponibilidad, apertura, modificabilidad,modularidad, integración, adaptabilidad,reusabilidad y escalabilidad. Resumiendo, elproyecto tiene más valor que la soluciónadoptada" [4].

Según este modelo, las soluciones basadas ensoftware libre hacen posible el desarrollo deproyectos; estos proyectos, de hecho, posibi-litan el crecimiento del software libre. Porotro lado, el software libre favorece la conse-cución de los requisitos de los clientes, demodo que se logra la mejor solución adapta-da a sus necesidades; por otro lado también,la comunidad se beneficia de estos nuevosrequisitos, nuevo código, testeo,realimentación y contribuciones externas.

En este contexto, el integrador de sistemas esel facilitador que activa las relacionessinérgicas, y uno de los principales actores,gracias a su capacidad "genética" para traba-jar de esta manera.

5. La iniciativa SpagoWorld: unpoco de historiaLa iniciativa SpagoWorld es un ejemplo decómo Engineering dirige su modelo de nego-cio de software libre centrado en proyectos.

Surgida en 2004, la iniciativa cuenta ahoracon cuatro proyectos principales:

SpagoBI: la plataforma para businessintelligence (BI).

Spagic: la platforma empresarial de inte-gración SOA/BPM.

Spago4Q: especialización de SpagoBI paracalidad de software.

Spago: una plataforma empresarial Java.

Todos estos proyectos adoptan el mismomodelo de licenciamiento (se distribuyen bajouna licencia GNU LGPL, sin versiones "pro-fesionales" o "enterprise" por las que es nece-

sario pagar), y se alojan en el consorcio OW2,que proporciona un soporte independiente ya largo plazo gracias a una comunidad glo-bal.

Los proyectos comparten una visión común,basada en:

Soluciones flexibles: integrando compo-nentes ya existentes y desarrollando nuevosmódulos, con un enfoque de integración en laplataforma, de modo que se identifican lassoluciones más adecuadas para las necesida-des de los usuarios.

Nivel empresarial: las soluciones resultande la experiencia en proyectos a nivel empresa-rial, donde las aplicaciones son críticas, y hayque garantizar la funcionalidad y un altorendimiento.

Enfoque en el desarrollo de proyectos: lacapacidad para entender las necesidades rea-les de los usuarios, además de los requisitosde los diferentes proyectos, convierten a lassoluciones de SpagoWorld en la mejor op-ción para comenzar el desarrollo de un nuevoproyecto de software.

Uso comercial: las soluciones de softwarelibre adoptan un esquema libre de licencia-miento, que permite el uso de las solucionesde SpagoWorld en diferentes categorías deproductos y servicios.

Servicios de soporte: cada solución esentregada, bajo demanda, incluyendo unasolución completa de servicios de soporte.

Enfoque en la comunidad y la investiga-ción: todos los proyectos tienen un alto com-promiso con las necesidades de la comuni-dad, e incorporan resultados innovadores deinvestigación.

Creación de un ecosistema de valor: lainiciativa SpagoWorld participa en la crea-ción de un ecosistema de valor añadido paratodos los miembros de la comunidad: empre-sa, desarrolladores, investigadores y usua-rios.

6. SpagoWorld y el mercado co-mercial de software libreLas soluciones SpagoWorld son descarga-das desde diferentes países alrededor delmundo. Esto confirma que son conocidas (yprobablemente usadas7 ) en un contexto glo-bal, sin ceñirse a un mercado geográficoespecífico.

Aunque el éxito comercial significa otra cosadiferente. Este aspecto debe considerar dospuntos preliminares, uno particular a cadaproyecto y otro que tiene que ver con lasolución como un todo.

La premisa específica consiste en el hecho deque cada solución tiene que enfrentarse acompetidores específicos en un contexto desoftware libre, donde la reputación otorgadapor la comunidad es crucial (por ej., Spago,el framework Java, apenas puede competircon otras frameworks Java más conocidos;

Spago4Q es una solución nueva y única, sincompetidores reales, pero necesita alcanzaruna reputación suficiente; Spagic, una solu-ción bien recibida por la comunidad, necesitaalgo de tiempo para demostrar su eficacia enel uso en casos reales alrededor del mundo;SpagoBI, la más popular, es reconocida so-bre todo como un producto software libre).

La premisa general se refiere a diferentesaspectos:

Engineering, desarrollador de todas lassoluciones, es un integrador de sistemas queactúa en los mercados y dominiosinformáticos, y que está siguiendo una tra-yectoria internacional todavía sin finalizar.Los competidores de software libre son em-presas que actúan en un dominio específico(como Pentaho, Jaspersoft y Actuate en eldominio de business intelligence, o Intalio yMuleSource para soluciones SOA/BPM)ofreciendo soporte a nivel mundial. Contra-riamente a un integrador de sistemas de pro-pósito general, el mercado informático perci-be a estas empresas como más eficaces cen-trándose en un único dominio que es críticopara su éxito, e invirtiendo cantidades signifi-cativas en actividades de marketing.

Especialmente en Europa, los grandesintegradores de sistemas que dirigen el mer-cado informático prefieren no usar las solu-ciones de otro integrador de manera explícita,para invadir "intrusismos";

La falta de soporte constante y universalen regiones como Europa, EE.UU., Asia yLatinoamérica no facilita la inserción de lassoluciones de SpagoWorld en las listas "top",a pesar de sus funcionales y sus innovadorascaracterísticas.

No obstante, tanto SpagoBI como Spagicgozan de una buena reputación (su recienteinclusión en Gartner Research [5][6] confir-ma este punto), y han obtenido pronto ciertosresultados comerciales, de modo que se hanconvertido en dos activos de software libre delgrupo Engineering: Spagic está ganando im-pulso en el desarrollo de proyectos SOA/BPM para clientes de Engineering, algunos deellos multinacionales; las actividades de desa-rrollo de SpagoBI se sostienen gracias a losbeneficios que proporcionan las ventas deservicios de formación y soporte, principal-mente en Francia y mercados relacionados.Además, los servicios de soporte de SpagoBIse ofrecen tanto en Latinoamérica como enAsia.

7. SpagoWorld y la comunidad desoftware libre: lecciones aprendi-dasEl primer resultado significativo deEngineering en el software libre proviene desus actividades en algunos proyectos de inves-tigación en Italia y Europa.

Las colaboraciones en este campo con em-

novática nº 199 mayo-junio 200942 monografía

monografía Software libre para empresas

presas, universidades e institutos de investi-gación han proporcionado oportunidades paradesarrollar soluciones y componentes libres,entre los que podemos mencionar bxModellerpara el modelado de procesos de negocio, queproviene de los resultados de los proyectos deinvestigación DISCoRSO, X@Work yTEKNE; las soluciones del proyecto Brickspara bibliotecas de herencia cultural digitales;SeCSE para sistemas centrados en serviciosy ETICS, para el desarrollo de software ycalidad en entornos grid.

Cuando Engineering decidió comenzar a de-sarrollar y gestionar proyectos de softwarelibre gratuitos a nivel industrial, se tomarondos importantes decisiones:

La elección de no hacerlo solos, sinoconectados a una comunidad internacionalya existente.

Ser consecuentes con el hecho de que en lascomunidades de software libre los tiemposhan cambiado.

De hecho, mientras que la naturaleza delsoftware libre ha cambiado en el tiempo,desde el campo de las infraestructuras haciael middleware primero, y hoy en día hacia unentorno aplicativo, se han creado nuevas co-munidades con diferentes connotaciones (porejemplo, las Fundaciones de Linux, Apache yEclipse, el consorcio OW2, etc.).

Desde aquellas primeras comunidades deindividuos movidos por la ética hacker noshemos desplazado a la tercera generación decomunidades de software libre que aglutinandiferentes entidades legales, compañíasfederadas, vendedores, clientes, administra-ciones públicas e individuos. El modelo denegocio de estas meta-organizaciones es co-lectivo: el núcleo de su valor se orienta haciael incremento del valor de la organizacióncomo un todo, y consiste en la estimulaciónde la colaboración entre sus miembros paraalcanzar diversas metas que son útiles paratodos los miembros.

La naturaleza cambiante de estas comunida-des está influyendo también en el desarrollo delos actuales proyectos de investigación deEngineering. Algunos ejemplos de estas co-munidades son:

Qualipso8 , una alianza internacional deempresas informáticas, PYMEs, investiga-dores e instituciones públicas y académicas,cuyo rol consiste en ayudar a la industria y alos gobiernos en el fomento de la innovacióny la competitividad con software libre.

El Grupo de Trabajo sobre Software Li-bre de NESSI9 que da soporte a la NetworkedEuropean Software and Services Initiativepara construir una plataforma tecnológicaeuropea dedicada al software y a los servicios.Apoya a NESSI en la definición de una estra-tegia global sobre software libre, enfocada aempresas que quieran implementar o adoptar

software libre, además de a comunidades desoftware libre que quieran colaborar y parti-cipar en NESSI, proporcionando el apoyo, laayuda y la información necesarios paraposicionar al software libre como el canalprincipal de comunicación de los logros deNESSI, asegurando niveles adecuados decalidad, dependencia y seguridad.

Incluso cuando Engineering estaba buscan-do una comunidad de referencia para susproyectos de software libre, eligió una comu-nidad que prestaba atención especial a losrequisitos de los usuarios finales y las empre-sas del ecosistema, sin ignorar el papel de losindividuos y los desarrolladores en la comu-nidad. La adhesión al consorcio ObjectWeben 2005 ha representado la elección particularde entrar en una comunidad caracterizada poruna identidad precisa que persigue promocio-nar y afirmar un ecosistema sostenible y du-rable basado en soluciones software libre.Estas características pueden ayudar a lasempresas del consorcio a conseguir sus obje-tivos de negocio y a las administraciones y alos usuarios a satisfacer sus demandas.

La participación en ObjectWeb también harepresentado la oportunidad de compartir sutransformación en el consorcio OW2, unnuevo consorcio internacional más fuerte,guiado por una filosofía abierta y que persi-gue la promoción de soluciones tecnológicasy una nueva manera de hacer negocios. Naci-do en enero de 2007 como una consecuenciade la integración de las comunidades europeaObjectWeb y china OrientWare, OW2 es hoyun consorcio industrial independiente dedica-do al fomento de un vibrante ecosistema denegocio, que cuenta con más de 100 organi-zaciones y 6.000 desarrolladores distribuidosen Europa, Asia y América, además de alber-gar más de cien proyectos tecnológicos.

La adhesión a OW2 ha sido una muestra dela estrategia de software libre de Engineering,cuyo objetivo es compartir proyectos con lacomunidad e integrarlos con otras solucio-nes, buscando de manera continua nuevasoportunidades. El software SpagoWorld estáalojado en la forja de OW2, de modo quepermite a la comunidad participar usandoherramientas específicas (listas de correo,foros, repositorios, área de descargas), yproporcionando una gestión independientedel software publicado. Esta colaboración vamás allá de un apoyo notorio al crecimientode toda la gama completa de software deOW2, y representa la participación en uno delos ejemplos más exitosos de comunidad desoftware libre de tercera generación.

En la actualidad, Engineering es co-fundadory miembro estratégico del consorcio OW2.Además, es particularmente activo en la vidadel consorcio, siendo miembro del ConsejoRector, de todos los consejos de apoyo a los

ecosistemas (Consejo del Ecosistema, Con-sejo Tecnológico y Oficina de Gestión), ypermanece activo en muchas iniciativas (es ellíder de la iniciativa de Business Intelligence,y forma parte de las actividades del CapítuloLocal Europeo).

Con el tiempo, la colaboración se ha extendi-do también a otras comunidades. Graciasprincipalmente al desarrollo de la plataformaSpagic, Engineering participa en la comuni-dad Eclipse en el desarrollo del proyecto Eclip-se STP/Intermediate Model, junto al institu-to francés de investigación INRIA, y en lacomunidad Apache como contribuidora alproyecto ServiceMix.

Engineering usa sus propias competencias engestión de software libre, incluso usandosoluciones software libre de terceros comocomponentes importantes de sus propiosproyectos, o cuando necesita extenderlos,adaptarlos o resolver sus defectos de soft-ware. En este caso, Engineering proporcionalas mejoras que realiza a la comunidad, ob-teniendo un doble beneficio:

El soporte (de) y la participación activa enel ecosistema de software libre.

La protección de la inversión del clientepara el que se ha realizado el proyecto. Dehecho, si la contribución ofrecida es aceptadacomo parte de una nueva versión de la solu-ción de software libre, hay claros beneficios entérminos de mantenimiento y evolución futu-ra.

Entre estas contribuciones, en el caso dedesarrollos en Java, arquitecturas SOA yBusiness Intelligence, podemos nombrar losproyectos eXo Platform, Cimero, Jpivot,Harvard JHOVE, además de los menciona-dos previamente Eclipse STP y ApacheServiceMix.

La historia de las relaciones de Engineeringcon las comunidades muestra que:

No sólo la participación en la comunidad,sino también la "construcción de comunidad"son cruciales, tanto en las comunidades yaexistentes como en la creación de nuevascomunidades. Esto permite extender el "efec-to red", facilitar la reputación global, inter-cambiar conocimiento y experiencias, y supo-ne la aportación de contribuciones reales.

La gestión de la comunidad, en la cual laempresa juega un papel líder en la gobernanzadel proyecto, representa un elemento crítico ysuperable, especialmente cuando el proyectopresenta características especiales en térmi-nos de novedad y efectividad. Incluso en laexperiencia de Engineering, es difícil construiruna comunidad formada por actores que sonactivos en el soporte y la gestión del crecimien-to del proyecto. El problema de las relacionesde confianza en la comunidad, entre la empre-sa y firmas de diversos tamaños, necesitatodavía más investigación, puesto que es un

novática nº 199 mayo-junio 2009 43

Software libre para empresas monografía

monografía

Referencias

[1] O. Viele. Software Libero, opportunità ominaccia per i system integrator?, HomepageEngineering Ingegneria Informatica Anno VII n.8,Roma 2005 (en italiano)[2] A. Ganzaroli, L. Pilotti. En R. Fiocca "Rileggerel’Impresa" (Capitolo 15 «Quali reti oltre ilnetworking»), ETAS, 2007 (en italiano).[3] M. Iansity, R. Levien. Keystones andDominators: Framing Operating and TechnologyStrategy in a Business Ecosystem. Harvard Busi-ness School, Working Paper #03-061, 2004.[4] G. Ruffatti. Ecosistemi di business in azione.Il caso Engineering. Quaderni di management – n.33, E.G.V. Edizioni, May-June 2008, pp. 37-48 (enitaliano). Disponible también en: <http://www.spagoworld.org/ecm/faces/public/guest/home/community/resources>.[5] A. Bitterer. Who’s Who in Open-SourceBusiness Intelligence. Gartner Research, abril2008. [6] M. Pezzini, L.F. Kenney, J. Lennard. CoolVendors in Platform and Integration Middleware.Gartner Research, marzo 2008.

1 Engineering <http://www.eng.it/>.2 SpagoWorld Initiative <http://www.spagoworld.org>.3 OW2 Consortium < http://www.ow2.org/>.4 El término coopetición significa la presenciacontemporánea de relaciones de cooperación ycompetición.5 En la iniciativa SpagoWorld, que está basada enla estrategia comercial sobre software libre deEngineering, se requiere que el software se publi-que bajo la licencia GNU LGPL.6 El licenciamiento dual es un modelo híbrido, queincluye tanto una licencia libre (generalmente dela familia de licencias GNU) y su venta, o la ventade extensiones, bajo una licencia privativa si-guiendo un esquema EULA (End User LicenseAgreement). Algunos elementos de este modeloparecen más cercanos al modelo propietario queal del software libre. Por ejemplo, la presencia deinversores institucionales en las empresas que loproducen, el casi total control de la empresa quedesarrolla la solución, y las características mis-mas de la solución, generalmente más típicas deun producto que de una plataforma.7 El número de descargas (esto es, el número deveces que un fichero es descargado por un usuariodesde la web hasta su ordenador) se consideranormalmente un número correlacionado con eléxito de un proyecto de software libre. Sin embar-go, no tiene demasiado significado, porque existenmuchos factores que pueden influir en este fenó-meno, y tampoco dice mucho acerca del númerode descargas que realmente se instalan y usan.8 Qualipso <http://www.qualipso.org/>.9 NESSI Open Source Working Group <http://www.nessi-europe.com/Nessi/WorkingGroups/A d o p t i o n W o r k i n g G r o u p s /NESSIOpenSourceSoftwareWorkingGroup/tabid/269/Default.aspx>

Notas

aspecto fundamental en la construcción deuna verdadera ecología de valor.

Las relaciones con las comunidades sonprocesos de creación de valor respaldados porredes complejas de relaciones sociales y denegocio, de valores compartidos, y deinterdependencias entre los diferentes miem-bros. El valor obtenido es alto, aunque prin-cipalmente no cuantitativo (por ej., no mone-tario). Es una colaboración en una red indus-trial basada en el conocimiento, que compar-te esfuerzos promocionales y un fuerte com-promiso en las decisiones cruciales, en elfomento de la innovación, en la competiciónabierta y en la libertad para formar parte de lasdiferentes actividades.

8. Sostenibilidad del modelo: unaaproximación ecológicaLa iniciativa SpagoWorld proporciona uncontexto donde su comunidad y los diferentesactores (empresas, vendedores, integradores,consultores en BI, instituciones públicas, clien-tes, académicos e individuos) cooperan paradesarrollar una infraestructura de solucionesmadura y fiable, y compiten para conseguirsus objetivos, creando un entorno activo yestimulante. De este modo, todos aquellosque adopten SpagoWorld pueden encontrarun entorno de referencia para su estrategia deadquisición de software libre, y una oportu-nidad para contribuir al crecimiento de unaestrategia colectiva que pretende incrementarvalor en un contexto ecológico. La coopera-ción (en asuntos no-monetarios) y competi-ción (en el mismo mercado) simultáneasposibilitan relaciones complejas que fomen-tan el ecosistema (ver figura 1figura 1figura 1figura 1figura 1).

Desde este punto de vista, la iniciativaSpagoWorld es un ejemplo efectivo de pro-

moción de un ecosistema de negocios queactúa como el modelo de negocio específicode Engineering, y que se basa en el desarrolloy promoción de sus soluciones (vendiendoservicios de soporte y los proyectos de soft-ware correlacionados), y que al mismo tiem-po apoya el sistema completo en un entornode verdadera coopetición. En el contexto delsoftware libre, los retornos indirectos y nomonetarios pueden ser de más valor que losmonetarios porque suponen beneficios en uncontexto sostenible a largo plazo.

Figura 1. De la colaboración a la coopetición: Situando el software libre a nivel denegocio.

novática nº 199 mayo-junio 200944 monografía

monografía Software libre para empresas

Una oportunidad para lasempresas de software libre:mercado emergente en los

países en vías de desarrollo

Susana Muñoz Hernández,Jesús Martínez MateoFacultad de Informática, UniversidadPolitécnica de Madrid

< { s u s a n a , j m a r t i n e z } @ f i . u p m . e s >< { s u s a n a , j m a r t i n e z } @ f i . u p m . e s >< { s u s a n a , j m a r t i n e z } @ f i . u p m . e s >< { s u s a n a , j m a r t i n e z } @ f i . u p m . e s >< { s u s a n a , j m a r t i n e z } @ f i . u p m . e s >

Resumen: durante los últimos años el negocio del software ha cambiado en muchos aspectos. Lascompañías de software han evolucionado desde producir aplicaciones software y vender su códigopropietario, a proporcionar aplicaciones de código abierto y centrar su negocio en ofrecer serviciosrelativos a su adaptación, instalación, mantenimiento y formación de usuarios. Las compañías de soft-ware libre emplean un modelo de negocio que proporciona nuevas oportunidades en mercados dondeel software privativo es inviable. En este artículo describimos una interesante oportunidad de negocio queestá surgiendo para estas compañías: las necesidades de software de los países en vías de desarrollo.Estos países están creando un mercado emergente para el desarrollo de software especialmente intere-sante porque si sus necesidades y limitaciones especiales son tenidas en cuenta son un escenarioperfecto para el enfoque del software libre. Finalmente, será también discutida la influencia de algunoscatalizadores que están realmente actuando en este mercado objetivo.

Palabras clave: mercados emergentes, oportunidades de negocio, países en vías de desarrollo, soft-ware libre.

Autores

Susana Muñoz Hernández es Doctor en Informática por la Universidad Politécnica de Madrid (UPM),tiene un máster en Gestión de las Tecnologías de la Información por la universidad Ramón Llull deBarcelona y un grado en Relaciones Internacionales por la Sociedad de Estudios Internacionales deMadrid. Ganó el primer premio en el concurso nacional para jóvenes talentos de la Universidad de La Sallede Madrid en 2003. Tras varios años de experiencia profesional trabajando en empresas privadas, comen-zó a trabajar como profesora asociada en la Escuela de Informática de la Universidad Politécnica de Madriden 1998 donde lleva a cabo su actividad investigadora en el grupo BABEL. Es responsable de difusión ycomunicación de la plataforma nacional española de software y servicios, INES. Ha establecido el grupode cooperación TEDECO (Tecnology for Development and Cooperation) en 2006 y ejerce como directoradesde entonces. Desde TEDECO, lidera la iniciativa Morfeo-CODE para la aplicación de software libre a laCOoperación para el DEsarrollo en la comunidad Morfeo.

Jesús Martínez Mateo es estudiante de doctorado en Informática en la Universidad Politécnica de Madrid(UPM). Tiene un máster en Matemáticas de la Computación por la UPM. Desarrolla su actividad investi-gadora en el laboratorio de informática en la sección departamental de Análisis Numérico como integrantedel grupo de investigación en Información Cuántica y Computación. Contribuye a varios proyectos, entreotros el proyecto Cenit Segur@ financiado por el Ministerio de Comercio e Industria de España para elestudio y diseño de una Red de Distribución Clave Cuántica Metropolitana. Compagina su trabajoinvestigador con el desarrollo de software libre (ej. Lan Core) y la participación en el grupo TEDECO(Tecnology for Development and Cooperation), siendo un miembro activo que ha participado en dosmisiones de campo en Burundi.

1. El software libre en los merca-dos occidentales

¿Por qué luchar contra el mercado?Es bien conocido que el software libre y decódigo abierto1 tiene que ganar una durabatalla contra el software propietario paraencontrar un espacio en el mercado occiden-tal. Algunos de estos problemas, quizá todosellos, son específicos de este mercado dondeel negocio del software tiene una historiaconsolidada. Por otra parte, existe un escena-rio donde puede ser evitada esta cultura tribal;en los países en vías de desarrollo muchos deestos problemas simplemente no existen. Engeneral, el desarrollo y el despliegue del soft-ware en los países en vías de desarrollo tienenuna corta tradición. Esto es una considerableventaja para la expansión del software libre enaquellos mercados con una concepción másmoderna en relación con el software [1].

La bondad de los mercadosExisten varios casos en los que una nuevatecnología ha tenido menos problemas paraestablecerse en un mercado emergente que enlos ya consolidados. Por ejemplo, a finales delsiglo diecinueve era más sencillo abrir el mer-cado a las locomotoras eléctricas en aquelloslugares donde los trenes de vapor no eran aúnhabituales. Esto es similar, hoy día, dondemuchos lugares aislados de países en vías dedesarrollo han comenzado a utilizar directa-mente comunicaciones móviles sin haber te-nido cualquier infraestructura previa de tele-fonía fija. En estos países se ha producido unabrecha tecnológica en algunas generacionesen relación con la revolución industrial, elhardware, o las comunicaciones entre otras;entonces… ¿por qué no también con el soft-ware? Aunque quizá una pregunta más apro-piada sería: ¿puede ser el software libre latecnología del futuro en el desarrollo de soft-ware? Probablemente sí, en cuyo caso la histo-ria podría volver a repetirse de una forma similarpara ignorar el software propietario en beneficiodel software libre en los países en vías de desa-rrollo. Bajo este supuesto es posible que lospaíses en vías de desarrollo se conviertan en unserio candidato para adoptar una estrategianacional a nivel de gobierno en relación con elsoftware libre, sin pasar por la fase previa de laera del software privativo. Actualmente, si-guiendo esta sospecha, algunas comunidadesde software libre [2] se han dado cuenta de queexiste un crecimiento y una oportunidad denegocio para ellos en estos países.

¿Tradición o PCI (Progreso, Cambioe Innovación)?El problema más importante del softwarelibre en las grandes compañías es que éstas yatienen la mayoría de sus aplicaciones desarro-lladas utilizando software propietario. Latradición es una poderosa desventaja puestoque las migraciones de software pueden im-plicar inversiones a corto plazo y las compa-ñías raramente confían en las ventajas que amedio y largo plazo les puede suponer unamigración a software libre, u otros produc-tos. Por el contrario, encontramos algunasinstituciones, organizaciones y compañías en

los países en vías de desarrollo que estáncomenzando a generalizar el uso de aplicacio-nes software [3]. En estos casos, y por razo-nes evidentes al tratarse de países en vías dedesarrollo, el presupuesto para la compra desoftware es considerablemente reducido, detal forma que la adquisición de software libreno es una opción sino una necesidad. Encualquier caso, el software libre es muchomás económico que la compra de una aplica-ción propietaria convencional, por lo que lasdesventajas tradicionales son oportunidadesen los mercados de software de los países envías de desarrollo.

novática nº 199 mayo-junio 2009 45

Software libre para empresas monografía

monografía

Comercio justoEl comercio justo es un movimiento socialorganizado y un enfoque del mercado quetiene como objetivo ayudar a los productoresen los países en vías de desarrollo al mismotiempo que promueven la sostenibilidad. Elcomercio justo no es tan sólo prestigiosodesde el punto de vista moral, sino tambiénpor su rentabilidad. En 2007, las mercancíasetiquetadas como comercio justo tuvieronun nivel de ventas por valor de aproximada-mente 2,3 billones de euros en todo el mundo(3,62 billones de dólares americanos), con unincremento del 47% de un año para otro.

Ha existido un debate en un foro especializa-do acerca de las similitudes entre el softwarelibre y el comercio justo [4]. El origen de estadiscusión fue una presentación de MatthewEdmonson del proyecto gubernamental OpenIT Up que dio en el Reino Unido unas confe-rencias para proveedores de asistencia tecno-lógica2 . En realidad, existen bastantes seme-janzas teniendo en cuenta que ambos impli-can una elección y una preocupación por laspersonas. James Davis dice que como usua-rios de software libre esperamos que se nosconceda la libertad de hacer lo que nosotrosqueramos con nuestro software, siempre ycuando no se restrinja lo que los demáspueden hacer con nuestro software modifica-do.

A pesar de que no estemos de acuerdo con estadeclaración (puesto que podemos encontraralgunas diferencias sustanciales entre el soft-ware libre y el comercio justo [5]) este es unpunto muy positivo para el software libre, elser comparado en un debate público con tanprestigiosa empresa como es el comerciojusto.

2. Catálisis del software libre enlos países en vías de desarrollo

Las TIC en los países en vías dedesarrolloLejos del ancestral concepto de "coopera-ción", mucho más cercano a la caridad, en losúltimos cinco años los proyectos de coopera-ción están orientados al desarrollo de lospaíses receptores. Aparte de los campos tra-dicionales de cooperación (salud pública,educación, o el suministro de alimentos entreotros) existen nuevas áreas donde la coope-ración está jugando un rol decisivo, y lasrelacionadas con las Tecnologías de la Infor-mación y la Comunicación (TIC) son proba-blemente las más importantes. De hecho, lacooperación en TIC está directamente aplica-da al resto de áreas de cooperación tradicio-nales.

Software libre para el fortalecimien-to institucionalLa mayoría de los proyectos de cooperaciónque incluyen desarrollo de software han opta-do por el uso de software libre. Esto es muyinteresante si tenemos en cuenta que estesoftware va a ser parte de muchas institucio-nes clave (Administración o Educación entreotras) de los países en vías de desarrollo [6].El e-Gobierno está siendo especialmente pro-movido y muchos gobiernos de países en víasde desarrollo están apostando por el softwarelibre siguiendo el consejo de consultores ex-ternos independientes y Organizaciones NoGubernamentales (ONG) [7][8]. Es evidentela influencia que este hecho tendrá en el desa-rrollo de software en el resto de los sectoresde estos países.

Siguiente generación de programa-dores de primera categoríaEn la actualidad, sin otra opción, las tenden-cias actuales en software libre y propietario enlos países en vías de desarrollo vienen depaíses extranjeros. Sin embargo, se espera queen un futuro cercano sus primeras generacio-

nes de ingenieros informáticos sean los res-ponsables del desarrollo, pero sobre todo delmantenimiento y uso del software. Este esotro punto a favor del software libre. Losesfuerzos en educación están concentradosen el campo del e-learning y el desarrollo de laeducación superior. La influencia del soft-ware libre en la educación de las nuevas gene-raciones de programadores y profesionales delos países en vías de desarrollo está siendoreforzada por el trabajo de las ONGs y lacooperación de las universidades occidenta-les [9].

3. Países en vías de desarrollo:mercados de software libre emer-gentesEl software libre es una alternativa consolida-da para el desarrollo de software profesionalque es altamente recomendada para los paí-ses en vías de desarrollo. Durante los últimosaños existen estudios y esfuerzos desde estospaíses que apuestan por el software abierto ylos modelos de software libre [10]. Unosquince países africanos ya han publicadorecomendaciones de software libre frente asoluciones de software propietario (por ej,Angola, Benin, Kenia, Senegal, Sudáfrica,Tanzania, Uganda y Zambia entre otros).Esto puede ser aplicado a muchas áreas peroes especialmente importante para tres: Edu-cación, enfocado principalmente en las bi-bliotecas digitales [11], desarrolladores desoftware, o soporte TIC para la educacióngeneral; Administraciones Públicas, con es-pecial interés en el despliegue del e-gobierno;y Salud, no sólo proveyendo software parainstituciones de salud sino también para de-sarrollar el crecimiento de la e-Salud y suutilización en áreas aisladas [12].

Aparte de estas áreas en las que la introduc-ción del software libre ya ha comenzado, elsector privado está dispuesto a desarrollar un

Figura 1. Proceso de catálisis del software libre en los países en vías de desarrollo.

novática nº 199 mayo-junio 200946 monografía

monografía Software libre para empresas

Referencias

[1] J. Lerner, J. Tirole. "The Simple Economicsof Open Source". National Bureau of EconomicResearch, Inc., NBER Working Papers, No. 7600,2000. <http://ideas.repec.org/s/nbr/nberwo.html>.[2] Morfeo-code. Iniciativa para el uso de soft-ware libre en la cooperación para el desarrollo,<http://tedeco.morfeo-project.org/>.[3] G. Camara, F. Fonseca. "Information Policies

Notas

software de apoyo confiable y seguro, y susdecisiones al elegir el tipo de software que vana utilizar está muy condicionada por el crite-rio de la Administración Pública y los sectorespúblicos en general.

Teniendo en cuenta las características espe-ciales de los países en vías de desarrollo, sufalta de reticencias a la hora de usar el soft-ware libre, el efecto catalizador de la coopera-ción y el previsible crecimiento de la industriade software en estos países (ver figura 1figura 1figura 1figura 1figura 1),podemos concluir diciendo que la aparicióndel mercado de software en los países en víasde desarrollo representa una oportunidad denegocio para las empresas de software libre.

and Open Source Software in Developing Countries".Journal of the American Society for InformationScience and Technology, 2007.[4] D. Wilcox. Is Open Source Software Fair Tradefor Nonprofits? Designing for Civil Society.<http://partnerships.typepad.com/civic/2007/02/is_open_source_.html>.[5] J. Davis. How Free Software is not Fair Tradefor non-profits. Free web hosting for UK charitiesand non-profit organizations.<http://www.freecharity.org.uk/2007/02/08/how-free-software-is-not-fair-trade-for-non-profits/>.[6] S. Weber. "Open Source Software in DevelopingEconomies". Social Science Research Council,USA. <http://www.ssrc.org/programs/itic/publications/ITST_materials/webernote2.pdf>.[7] United Nations Economic y SocialCommission for Asia and the Pacific (ESCAP)."ICT Policy database," <http://www.unescap.org/icstd/policy/db/>.[8] Programa para el Desarrollo de las NacionesUnidas (United Nations Development Programme,UNDP) y el Centro Internacional de Investigaciónpara el Desarrollo (International DevelopmentResearch Centre, IDRC) de Canada. InternationalOpen Source Network (IOSN) – Software FreedomFor All, <http://www.iosn.net/>.[9] TEDECO: Tecnología para el Desarrollo y laCooperación. <http://tedeco.fi.upm.es/>.[10] Bridges.org, CIPESA. Free/Open SourceSoftware (FOSS) policy in Africa: A toolkit forpolicy-makers and practitioners, <http://

www.cipesa.org/files/FOSSPolicyToolkit.pdf>.[11] I. Witten, M. Loots, M. Trujillo, D. Bainbridge."The Promise of Digital Libraries in DevelopingCountries" Communications of the ACM, 44 (5),pp. 82-85, 2001.[12] Fundación EHAS: Enlace Hispano America-no de Salud. <http://www.ehas.org/>.

Fecha de revisión de los enlaces web: mayo de2009.

1 En este artículo, hemos decidido utilizar el términosoftware libre siguiendo la definición de la FreeSoftware Foundation (FSF) en lugar de otrostérminos comunes, y seguramente más popula-res, como FOSS, del inglés Free and Open SourceSoftware, o OSS, del inglés Open Source Soft-ware.2 Nota del editor: En la referencia aportada por losautores se comenta que Matthew Edmonson diouna conferencia a "circuit riders" que dan soportetecnológico a empresas sin ánimo de lucro. Estetérmino (también se puede usar "eRiders" en sulugar), tiene su origen en el movimiento metodistay se refiere a proveedores de asistencia tecnoló-gica que atienden a pequeñas organizaciones sinánimo de lucro de sectores económicos concretospara la resolución de problemas o el soporte anecesidades tecnológicas particulares de dichasorganizaciones <http://en.wikipedia.org/wiki/Circuit_rider_(technology)>.