Comisión Europea. Estrategia de Código Abierto. Fecha: 18/06/2003 Version: Benoit Mercier & Herman Brand. Público: Número de referencia:

Transcripción

1 COMISIÓN EUROPEA PERSONAL Y ADMINISTRACIÓN DE LA DIRECCIÓN GENERAL Junta de Informáticos Sistemas de oficina y soporte técnico Comisión Europea Estrategia de Código Abierto Fecha: 18/06/2003 Version: Autores: Benoit Mercier & Herman Brand Revisado por: Monique Limbos Aprobado por: Jose Marin Navarro Público: Número de referencia: Commission européenne, L-2920 Luxembourg. Telephone: (352) Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/8. Telephone: direct line (32-2) Fax: (32-2) herman.brand@cec.eu.int

2 Historial del documento Versión Fecha Comentarios Páginas modificadas /06/2003 Documento creado por Herman Brand & Benoit Mercier Todas Contactos: Benoit Mercier, Teléfono:(32-2) , Herman Brand, Teléfono:(32-2) , Estrategia de Código Abierto - Versión del documento con fecha 18/06/2003 Página i

3 PREFACE PART I - OPEN SOURCE SOFTWARE - STRATEGY 1. OPEN SOURCE STRATEGY - INTRODUCTION... ERROR! MARCADOR NO DEFINIDO. 2. STRATEGY... ERROR! MARCADOR NO DEFINIDO. 3. JUSTIFICATION... ERROR! MARCADOR NO DEFINIDO. 4. IMPLEMENTATION OF THE STRATEGY: WORKING PLAN OPEN SOURCE Evaluate current use of OSS in the Commission... Error! Marcador no definido Consolidate Linux as a server platform... Error! Marcador no definido Improve OSS product management and use... Error! Marcador no definido Promote Internal OSS community... Error! Marcador no definido Evaluate OSS products and solutions... Error! Marcador no definido. PART II - OPEN SOURCE SOFTWARE - STRATEGY - SUPPORTING DOCUMENT 1. OPEN SOURCE SOFTWARE - INTRODUCTION OPEN SOURCE SOFTWARE DOMAIN CLASSIFICATION ERROR! MARCADOR NO DEFINIDO Operating System... Error! Marcador no definido Technical infrastructure... Error! Marcador no definido Server tools... Error! Marcador no definido Development tools... Error! Marcador no definido Desktop tools... Error! Marcador no definido "Out of the box" tools USE OF OSS AT THE COMMISSION... ERROR! MARCADOR NO DEFINIDO Operating systems... Error! Marcador no definido Server... Error! Marcador no definido Desktop... Error! Marcador no definido Technical infrastructure... Error! Marcador no definido Server tools... Error! Marcador no definido File and print servers... Error! Marcador no definido Web Servers... Error! Marcador no definido Application servers... Error! Marcador no definido Database servers... Error! Marcador no definido Other tools related to technical infrastructure... 6 Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

4 3.4. Development tools... Error! Marcador no definido Desktop tools... Error! Marcador no definido "Out of the box" tools DOCUMENT MANAGEMENT AND ARCHIVING... ERROR! MARCADOR NO DEFINIDO. 5. IMPLICATIONS... ERROR! MARCADOR NO DEFINIDO Product management... Error! Marcador no definido Resources... Error! Marcador no definido Support... Error! Marcador no definido Security... Error! Marcador no definido Development process... Error! Marcador no definido Training... Error! Marcador no definido. 6. WORKING PLAN OPEN SOURCE ERROR! MARCADOR NO DEFINIDO Evaluate current use of OSS in the Commission... Error! Marcador no definido Perform a detailed survey on the OSS used in the DGs Consolidate Linux as a server platform... Error! Marcador no definido Linux/Unix and ETP platform interoperability study... Error! Marcador no definido Definition of a Linux Single Application Host Reference Configuration Error! Marcador no definido Migration of Circa from Unix and deployment on Linux... Error! Marcador no definido Consider classification of Linux as a Class B product... Error! Marcador no definido Evaluate clustering and scalability functionality available under Linux Error! Marcador no definido Improve OSS product management and use... Error! Marcador no definido Adaption of product management guidelines to allow for the particularities of Open Source Software solutions... Error! Marcador no definido Clearly indicate that OSS solutions will be admissible when publishing calls for tender Error! Marcador no definido Promote Internal OSS community... Error! Marcador no definido Creation and leading of the Commission OSS community... Error! Marcador no definido Definition of development best practices for applications based on OSS (continuous integration)... Error! Marcador no definido Evaluate OSS products and solutions... Error! Marcador no definido Evaluate and test Application server solutions: Jboss, Tomcat... Error! Marcador no definido Evaluate and test OSS Database solutions: MySQL and PostGreSQL Evaluate scripting and development languages: PHP, Python Based on evaluations compose a "deployment OSS package" for external deployment and re-use (especially web applications) by external parties like Member States Monitor the OSS Desktop evolution... Error! Marcador no definido. ANNEXE I - OPEN SOURCE DEFINITION

5 Prefacio Este documento tiene dos partes. La Parte I está dedicada a la descripción de la estrategia de código abierto propuesta. La Parte II contiene información de fondo relacionada con el software de código abierto y con las distintas herramientas que existen. Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

6 Parte I Open Source Software - Strategy Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

7 1. ESTRATEGIA DE CÓDIGO ABIERTO El software de código abierto (OSS) es software cuyo código fuente es publicado abiertamente, el cual está habitualmente disponible sin cargo (licencia), y el cual está desarrollado por voluntarios. Una completa definición ha sido hecha por la Open Source Initiative (Iniciativa sobre el código abierto). Su definición puede ser encontrada en el Anexo 1. Es importante aclarar que a pesar de que muchos paquetes de OSS están disponibles gratis, el OSS no es necesariamente gratuíto, y que el software tampoco es de coste cero. El OSS está empezando a traer cambios fundamentales en el mercado del software, y está probado que no es simplemente un boom, y está reconocido por la Comisión Europea de Directores Informáticos. Internamente, la respuesta de la Comisión al OSS a fecha de hoy ha sido el establecimiento de una estrategia oportuna (Diciembre de 2000) que produjo la recomendación del servidor web Apache como elección en el dominio de los servidores web de Unix y Linux. Como resultado, Systran, una aplicación para traducción, ha estado ejecutándose en el centro de datos bajo Linux durante algunos años. Además Linux ha sido incluido en las peticiones de ofertas (concursos) para servidores hardware. No sólo eso, sino que implementó lo considerado obligatorio en software OSS para todos los procedimientos de adquisición de hardware y software. Los desarrolladores de la Comisión también utilizan herramientas OSS como Ant, CVS o JUnit que ayudan significativamente a mejorar el proceso de desarrollo de software y constituyen la base técnica del modelo de desarrollo OSS. 2. ESTRATEGIA Los puntos clave de esta política son los siguientes: La Comisión formalizará la utilización de OSS donde se espere un claro beneficio. La Comisión continuará considerando tanto soluciones OSS como propietarias en los procedimientos de los IT (Information Technology Tecnologías de la Infomación). Los contratos serán premiados en base a su valor económico 1. Para los futuros desarrollos de IT, la Comisión debe promover el uso de productos con soporte de estándares reconocidos y bien documentados. La interoperatividad es un asunto crítico para la Comisión, y la utilización de estándares abiertos ya reconocidos es un factor a tener en cuenta. Para todo nuevo desarrollo, cuyo despliegue y uso está destinado a partes que estén fuera de la Infraestructura de la Comisión, el OSS será elegido como plataforma de desarrollo y de despliegue. 1 Deben considerarse los costes no sólo de la licencia, sino también de instalación, mantenimiento, soporte y aprendizaje Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

8 3. JUSTIFICACIÓN La justificación de adoptar esta política es que todos los esfuerzos deberían hacerse para reducir los costes y el riesgo de los sistemas de la Comisión. Adoptar esta política ayuda a conseguir esto mediante: Procurar adoptar siempre la solución que reporte más beneficios económicos. Las soluciones OSS serán incluidas siempre en el software a evaluar. El software seleccionado será pues una solución OSS, una propietaria, o una mezcla de ambas. Las decisiones deben ser tomadas según las bases de cada caso. Asegurarse de que la interoperatividad de los sistemas y el mantenimiento se realice mediante estandares abiertos establecidos, lo cual es una garantía de inversión perenne. El OSS es particularmente significativo en este sentido. Reducción o eliminación de la dependencia de un único proveedor de IT. Proveer de más flexibilidad en el desarrollo, mejora e integración de los sistemas. A este respecto, el acceso al código fuente es un factor determinante. Mantener la seguridad e integridad de los sistemas de la Comisión. El OSS debidamente configurado puede ser tan seguro como la línea principal de sistemas propietarios. 4. IMPLEMENTACION DE LA ESTRATEGIA: Las siguientes acciones permanentes serán llevadas acabo para la implementación de esta política: Esta política será puesta a disposición de todos aquellos implicados e interesados en areas de infraestructura de software, desarrollo de aplicaciones y gestión. Los procedimientos de gestión serán adaptados para que las soluciones OSS puedan ser puestas en marcha. El fichero técnico de los procedimientos de selección de productos para cierta infraestructura o dominio de aplicación describirá qué alternativa OSS estaba disponible y cómo ha sido este evaluado. La decisión en el proceso de selección sobre dónde o no incluir soluciones OSS debe estar justificado, igual que se haría para cualquier otro producto. 5. PLAN DE TRABAJO CÓDIGO ABIERTO Los siguientes objetivos han sido asociados al plan de trabajo OSS de los próximos dos años Evaluar el uso actual de OSS en la Comisión Realizar una encuesta detallada del OSS utilizado en las Direcciones Generales Consolidar Linux como plataforma de servidor Estudio de la interoperatividad entre plataformas Linux/Unix y ETP. Definición de una configuración de referencia para puestos con aplicaciones sencillas Linux. Migración desde Circa de Unix y despliegue en Linux. Considerar la clasificación de Linux como un producto de clase B. Evaluar las funcionalidades de escalabilidad y clustering (agrupamiento) disponibles bajo Linux. 7

9 5.3. Mejorar de uso y administración de productos OSS Adaptación de las guías de administración de productos para permitir las peculiaridades de las soluciones OSS. Indicar claramente que se admitirán soluciones OSS cuando se publiquen las peticiones de propuestas Promocionar una comunidad OSS interna Creación y liderazgo de la comunidad OSS de la Comisión. Creación de infraestructuras para dar soporte a la comunidad (por ejemplo con una intranet además de otras cosas). Definición de las mejores prácticas en desarrollo de aplicaciones basadas en OSS (integración contínua) Evaluar productos y soluciones OSS Evaluar y probar soluciones para servidor de aplicaciones: Jboss, Tomcat. Evaluar y probar soluciones para bases de datos OSS: MySQL y PostGreSQL. Evaluar lenguajes de programación y scripting: PHP, Python. Basado en las evaluaciones, componer un paquete de despliegue de OSS para despliegues externos y para que lo reutilicen (especialmente aplicaciones web) partes externas, como Estados Miembros. Monitorizar la evolución del OSS de escritorio. 8

10 PARTE II Estrategia OSS Documentación de apoyo Open Source Strategy - Page 1 / 12

11 1. OSS - INTRODUCCIÓN El software de código abierto (OSS) es software cuyo código fuente es publicado abiertamente, el cual está habitualmente disponible sin cargo (licencia), y el cual está desarrollado por voluntarios. Una completa definición ha sido hecha por la Open Source Initiative (Iniciativa sobre el código abierto). Su definición puede ser encontrada en el Anexo 1. En diciembre de 2000, la Comisión definió una estrategia oportuna concerniente a este software. Permitió, por ejemplo, el reconocimiento y el uso del servidor web Apache como solución recomendada en sistemas Unix. También se recomendó que continuaran las investigaciones sobre Linux. Ahora, el informe intermedio sobre Linux abre nuevas puertas en el campo de los sistemas operativos comparando Linux con otros tipos de Unix. Ha llegado a considerar Linux como la plataforma preferida para Apache y como posible software base para máquinas con aplicaciones sencillas. La credibilidad en el OSS ha sido públicamente establecida en cuanto gigantes del mercado como HP, IBM y Sun han apostado por este. Cada vez más administraciones gubernamentales y universidades del mundo entero, y particularmente en Europa, están utilizando o pasándose a soluciones OSS para satisfacer sus necesidades. El OSS es actualmente utilizado en muchas direcciones generales pero es difícil de valorar la situación exacta ya que a menudo se considera una actividad subterránea debido al desconocimiento oficial. El presente es el mejor momento para actualizar la estrategia sobre el uso interno de OSS en la infraestructura del departamento de informática de la Comisión. 2. CLASIFICACIÓN DE LOS DOMINIOS DEL OSS En esta sección se hace uso de una clasificación de software para subrayar los dominios en los que existen soluciones OSS disponibles y viables Sistema operativo Linux es el abanderado de entre los sistemas operativos disponibles gratuitamente en internet. Programadores de todo el mundo se agruparon para desarrollar el núcleo original, y después compañías privadas y otros adaptaron el trabajo ya hecho para crear sus propias ediciones únicas de Linux, y a esto se le llama distribución. Estas distribuciones tienen nombres variados, entre los que reincluyen Red Hat, SuSE, Mandrake, Debian, etc. En estos momentos, Red Hat y SuSE han sido evaluadas como las mejores soluciones, seguidas muy de cerca por Mandrake (informe intermediario de estudio y evaluación de Linux). Hoy, algunos de los principales distribuidores se unieron para crear UnitedLinux (Linux Unido). UnitedLinux es una solución estandarizada para todo el mundo de Linux enfocada a los usuarios de negocio y desarrollada por Conectiva, el grupo SCO, SuSE, y Turbolinux. Está diseñada como sistema operativo Linux para empresas de la industria estándar. Esto debería permitir a los vendedores de hardware y software (como a otros) presentar una oferta sencilla Linux muy válida en lugar de muchas versiones distintas. Las distribuciones dentro de la unión sobrevivirán, pero compartirán una base común y podrán llevar la etiqueta UnitedLinux. Open Source Strategy - Page 2 / 12

12 La situación actual podría resumirse en esto: voluntarios mantienen un núcleocomún Linux y dos distribuciones principales son propuestas: UnitedLinux y RedHat. El sistema operativo Linux sirve para una amplia gama de hardware, desde estaciones de trabajo a servidores multiprocesador agrupados y mainframes Infraestructura técnica OSS relacionado con la infraestructura técnica es numeroso: Red: Servidor DNS (ej. BIND es usado en la gran mayoría de las máquinas que sirven nombres en internet), etc. Conectividad: Servicios de acceso remoto (ej. Radius), etc. Seguridad: Firewall (Suse Firewall, OpenRouter, etc.), proxy (ej. Squid), etc. Implementaciones de distintos protocolos: Samba permiteconectividad entre sistemas Unix y sistemas Windows, etc. Monitorización, etc Herramientas de servidor Herramientas OSS de servidor son ampliamente utilizadas en varios campos: Servidor web: Apache Servidor deaplicaciones J2EE: JBoss, JonAS, Tomcat Otros servidores de aplicaciones como el servidor PHP y Zope Servidor de directorio: OpenLDAP Servidor de base de datos (MySQL, PostgreSQL, FireBird, etc.) Servidor de correo, servidor FTP, servidor de News, etc. Muchas de estas herramientas pueden ser usadas en distintos sistemas operativos (Windows, Unix, Linux, etc). Ejemplos: Apache, PHP, JBoss, MySQL, Firebird, etc Herramientas de desarrollo Esta clase contiene software que permite a desarrolladores y a comunidades trabajar eficientemente: IDE (Integrated Development Environments Entornos de desarrollo integrado) para un lenguaje específico: Eclipse (Java), etc. Repositorios de expedición de proyectos/código fuente: CVS Herramientas scripting en el lado del servidor: Perl, TCL, Python, etc. Y muchas herramientas de estándares de facto que facilitan el trabajo de los desarrolladores e incrementan la calidad global del desarrollo de un proyecto: Ant, JUnit, etc. Muchas de estas herramientas pueden ser usadas en los principales sistemas operativos (Windows, Unix, Linux, etc.). Ejemplos: Eclipse, CVS, Ant, etc. Las librerías de código reutilizable son una parte importante de las herramientas del desarrollador. Las librerías OSS son numerosas y habitualmente se convierten en estándares de Open Source Strategy - Page 3 / 12

13 facto, como la de manejo de XML (Xerces, Xalan, etc.), administración de las sentencias de los logs mediante Java (log4j), adopción de un marco de trabajo MVC en sitios controlados con JSP (Struts, etc.) 2.5. Herramientas de escritorio Hay disponibles un gran número de aplicaciones OSS que cubren casi todas las necesidades de estaciones de trabajo técnicas y no técnicas: navegadores de internet, paquetes de oficina, herramientas de edición y publicación, programas de manipulación de imágenes, etc. Muchas de estas herramientas pueden utilizarse en los sistemas operativos principales (Windows, Unix, Linux, etc). Ejemplos: el navegador de web Mozilla ( Netscape ), el paquete de herramientas de oficina OpenOffice o The Gimp (manipulación de imágenes). Las distribuciones Linux vienen con interfaces de usuario gráficas (GUI) potentes construidas sobre el núcleo original de Linux: KDE y Gnome son los entornos gratuitos de escritorio más fáciles de usar para el usuario, además de servir como marcos de trabajo para potentes aplicaciones para el desarrollador de software. Cada vez más productos tradicionales propietarios existen para estos entornos Herramientas "Out of the box" (Fuera de la caja) Esta categoría de software crece continuamente. Existen soluciones OSS viables en varios campos: Administración de contenidos web: Zope, Plone, PostNuke, etc. Comunidad de desarrolladores: GForge Sistemas de localización de errores: Bugzilla, Scarab, Jira, GNATS, etc. Repositorio de Meta datos: RIB 3. USO DE OSS EN LA COMISIÓN La razón de esta estrategia es formalizar el uso de OSS donde se espere un claro beneficio. Los beneficios pueden ser financieros, técnicos o tácticos. Evidentemente, la estrategia deberá ser aplicada en concordancia con los procedimientos de administración de productos que han traído la harmonización de los productos en la Comisión actualmente. La estrategia previa ha llevado a la amplia adopción del servidor web Apache y a la conclusión de que Linux es un sistema operativo válido para los servidores de aplicaciones y de web. El siguiente paso prioritario es consolidar Linux como plataforma de servidor, incluyendo una configuración de referencia que soporte aplicaciones web y que puedas ser usado como servidor dedicado para propósitos específicos (equipo para aplicación simple). Esto significa que por lo menos lossiguientes productos deben ejecutarse: servidor web Apache y servidor ColdFusion. Servidores Oracle y BEA deberían también ser considerados. Cajas (equipos) completamente OSS deberían ser considerados para problemas específicos (ej: CIRCA). Podrían ser la respuesta a los requisitos de delegaciones y agencias. Y como solución para la interacción con Estados Miembros, incluyendo los nuevos Estados Miembros de Europa del Este. Las siguientes secciones describen áreas en las que el OSS podría jugar un papel importante por su relevancia o no para la Comisión. Open Source Strategy - Page 4 / 12

14 3.1. Sistemas operativos Servidor Linux es un sistema operativo válido para servidores web y de aplicaciones, y es una respuesta conveniente a las necesidades actuales de servidores de pequeñas aplicaciones web. La Comisión continuará considerando Linux como una alternativa viable a Unix en máquinas servidores. Además, las acciones resultantes del informe intermediario de evaluación de Linux están en camino Escritorio Para que la situación sea comparable a la actual, tendríamos que reconstruir una configuración de referencia basada en un sistema operativo de código abierto. Esto traería la necesidad de evaluar funcional y técnicamente los 40 elementos software que lo componen, y que soportan más de 10 configuraciones distintas. Además, las aplicaciones actualmente desplegadas bajo el modelo cliente-servidor, como los SICs u otros sistemas de información local, deberían ser reescritas. El modelo web es recomendado para el desarrollo de aplicaciones, ya que permite mayor independencia del sistema operativo del cliente. La recomendación es continuar monitorizando la evolución de Linux, de administración asociado al mismo, y de herramientas de oficina, pero manteniendo la situación de las estaciones de trabajo de oficina como está ahora. DG Infso está evaluando actualmente sus escritorios Linux (unos 70) para valorarla factibilidad de su uso en el entorno de la Comisión Infraestructura técnica OSS es particularmente completo y fiable en este aspecto. BIND (DNS) y Samba son estándares de facto para la integración de sistemas heterogéneos. OpenLDAP está siendo utilizado el Data Center (centro de datos) como servidor proxy. El uso de herramientas como Amanda, para el backup de sistemas Linux locales, debería revisarse. La Comisión continuará monitorizando el uso de OSS que pueda ser útil en los campos de la infraestructura: servicios de red, seguridad, backup, análisis de logs de web (ej: Analogue), etc Herramientas del servidor Servidores de archivos y de impresión Las utilidades de archivos e impresión son esenciales para todo sistema operativo ya que casi todos los tipos de aplicación hacen uso de sus características. Linux y Samba permiten conectividad con los sistemas Windows existentes (archivos e impresoras compartidas). Sin embargo, los diferentes modelos de seguridad y la necesidad de controladores específicos no permiten un soporte global o una recomendación como modelo general para la infraestructura de la Comisión. No obstante, las principales compañías (HP, IBM, etc) comienzan a vender cajas negras servidores de archivos e impresión Linux. Algunos de ellos, muy convenientemente actualizan los controladores de las impresoras en los escritorios automáticamente. La Comisión debería estar alerta: la opción existe y es válida Servidores web El servidor web Apache está reconocido y es muy utilizado, además de encontrarse en la lista de productos de la Comisión. La Comisión continuará usando Apache como servidor web preferido para sistemas Unix y Linux, y estudiará su recomendación potencial para sistemas Windows NT/W2000. Open Source Strategy - Page 5 / 12

15 Servidores de aplicaciones La Comisión usa actualmente 2 servidores propietarios de aplicaciones: BEA WebLogic (aplicaciones J2EE) y Macromedia Colfusion. Las necesidades están bien cubiertas y estos servicios están ampliamente disponibles para su uso en el Data Centre (centro de datos). Existen soluciones competitivas OSS en los campos de web scripting y J2EE. Servidores de aplicaciones como JBoss o JOnAS y contenedores de servlets como Tomcat son algunos de ellos. PHP es un lenguaje/servidor de scripting de web que ofrece funcionalidades comparables a las de Coldfusion. La calidad y soporte de estándares de estos servidores está ampliamente reconocida. La Comisión está satisfecha con la situación actual y los beneficios de utilizar otros servidores de aplicación no son visibles de momento. No obstante, algún posicionamiento y trabajo de evaluación se hará en este dominio para determinar la viabilidad de servidores de aplicaciones OSS en determinadas circunstancias (a determinar) en las que, por ejemplo, la posibilidad de libre (re)distribución del servidor y de la aplicación es necesaria o donde el coste de la licencia de la solución es crucial. La Comisión tiene que estar abierta y prestar atención a las soluciones OSS disponibles, particularmente para la amplia difusión de aplicaciones Servidores de bases de datos Loa necesidad de un sistema de administración de base de datos está ya cubierto por la Comisión con Oracle, y no hay beneficio directo de cambiar a una solución OSS. Sin embargo, algún posicionamiento y trabajo de evaluación se hará para determinar la viabilidad de bases de datos OSS (MySQL, PosgreSQL, FireBird, etc.) bajo ciertas condiciones (a determinar). La Comisión tiene que estar abierta y prestar atención a las soluciones OSS disponibles, particularmente para la amplia difusión de aplicaciones Otras herramientas relacionadas con la infraestructura técnica Cualquier otra herramienta OSS que pueda ser útil para monitorizar o administrar sistemas, debería ser considerada, particularmente para cajas negras servidores de aplicaciones web antes descritos. La disponibilidad de productos OSS debe ser verificada cuidadosamente en servicios del sistema como de backup, agrupación y monitorización, como también la manera de integrarlo en la arquitectura y con herramientas que estén en él Herramientas de desarrollo Herramientas como Ant, JUnit y CVS son estándares de facto que facilitan el trabajo de los desarrolladores y que mejoran la calidad global del desarrollo de un proyecto. La Comisión promoverá el uso de dichas herramientas para alcanzar una integración continua durante el ciclo de desarrollo. En el campo de las librerías reutilizables, el uso del analizador OSS Xerces, es ahora una recomendación del DI. El uso de estas librerías (Xalan, log4j, JUnit, etc.) será estudiado y recomendado eventualmente siempre y cuando se espere un beneficio claro. En la Comisión, la necesidad de una interfaz de desarrollo Java está cubierta con JBuilder y no hace falta pasar a una solución OSS. Debe hacerse y publicarse un estudio sobre interfaces de desarrollo para Java en el mercado. Open Source Strategy - Page 6 / 12

16 3.5. Herramientas de escritorio Dependiendo de las necesidades locales, como siempre, productos específicos pueden usarse para cubrir necesidades específicas, sin soporte organizado globalmente. Si la iniciativa OASIS de definir un modelo abierto de documento tuviera éxito, la Comisión debería evaluar este formato cuidadosamente y fijar la ganancia que supondría su adopción en términos de independencia e investigación perenne (ver 4). Esto incluye la evaluación del paquete OpenOffice por ejemplo Herramientas Out of the box" (fuera de la caja) Herramientas como Plone, Gforce, Bugzilla, etc. podrían usarse como ayuda al trabajo en equipo de las comunidades de usuarios y/o desarrolladores. Zope (y Plone otra vez) son soluciones muy interesantes en el campo de la administración de contenidos web. Podría considerarse trabajo de evaluación y posicionamiento en este dominio. 4. ADMINISTRACIÓN Y ARCHIVO DE DOCUMENTOS Los documentos son el núcleo y la memoria de una organización como la Comisión. Las herramientas utilizadas para crear estos documentos han estado cambiando y, claro está, el formato técnico también lo ha estado haciendo. Cuando se trata de archivar y administrar contenidos de documentación central, un formato común es necesario. Para resolver este tipo de problema, el uso de formatos estándares no propietarios para guardar los documentos es un factor determinante. El OSS puede ayudar definitivamente en esta área. Notablemente, OASIS (Organisation for the Advancement of Structured Information Standards Organización para el Avance de Estándares de Información Estructurada), ha creado un comité técnico que intentará conformar datos almacenados en documentos de oficina a un formato de archivo estándar basado en XML ( Una de las metas del grupo, llamado Open Office XML Format Technical Comité(Comité Técnico del Formato Abierto XML de Oficina ), es liberalizar datos en formatos propietarios de archivo para que puedan ser accedidos durante años sin importar qué software de oficina está usando una compañía. Los proponentes afirman que hay compañías que guardan datos en formatos propietarios de archivos, como aquellos escritos con Microsoft Word, y que están obligándose a usar ese software indefinidamente ( Matt Berger, 20 th November 2002). Elegir un formato común de documento de oficina y herramientas que permitan trabajar con él puede ayudar a reducir la dependencia con distribuidores informáticos individuales. Se tiene que tomar una decisión sobre qué hacer tanto con los documentos pasados (conversión) como con los futuros documentos(conversión o nueva herramienta). 5. IMPLICACIONES 5.1. Administración de productos La Comisión seguirá la estrategia actual de administración de productos que tiene en cuenta el OSS a la hora de seleccionar cualquier producto, evaluando su comunidad como vendedor virtual Recursos El uso de OSS tal cual requiere generalmente los mismos recursos que los productos propietarios y varía por producto. No obstante, si la Comisión quiere codificar/adaptar algún OSS a sus necesidades o participar activamente en la comunidad de desarrollo de OSS, esta tendrá que aportar los recursos apropiados. Open Source Strategy - Page 7 / 12

17 5.3. Soporte El modelo de soporte OSS es bastante diferente de lo que estamos acostumbrados. La comunidad de código abierto generalmente asegura soporte via internet, mediante listas de correo, grupos de news, etc. La persona que encuentre un problema es responsable de este hasta que se encuentre una solución. El soporte ofrecido está reconocido como muy efectivo y de una alta calidad, al menos en posproyectos principales (Samba, Apache). Además, muchas compañías tradicionales han empezado a vender servicio y soporte de productos OSS (Apache, PHP, JBoss, MySQL, etc.). Nuestro modelo actual de soporte para los productos propietarios de desarrollo está centralizado, con diferentes niveles de intervención dependiendo de la urgencia o importancia del problema, permitiéndonos tener una visión global de los problemas de cada producto y los asuntos pendientes. Tenemos la necesidad de organizar el soporte del OSS de manera que cojamos lo mejor de los dos modelos. Otro tipo de soporte debería de proveerse: una intranet (IntraComm) con acceso a recursos relacionados con OSS. Listado de herramientas OSS seleccionadas para cada categoría, foro, pautas, etc. Esto es responsabilidad de la Comisión de la Comunidad OSS. Tendríamos que contratar compañías integradoras para aportar el soporte necesario Seguridad Al igual que para otros productos, OSS debe ser incluido en proyectos de seguridad como DAVID (Deployment of an enhanced AntiVIrus Defense Despligue de una defensa antivirus mejorada) y HOLMES (un servicio de boletín de seguridad para las Direcciones Generales). Suscripción a fuentes dedicadas a la difusión de información relacionada con futuras implementaciones en materia de seguridad, en línea con las actuales políticas de administración de productos Proceso de desarrollo OSS es desarrollado por comunidades. Estas tuvieron que aprender a trabajar en equipo de manera estructurada y organizada. Entonces desarrollaron potentes técnicas que ayudasen a dirigir el proceso de desarrollo. La independencia ofrecida por el uso de dichas herramientas está garantizado para una investigación segura. La Comisión recomendará el uso de técnicas OSS (integración contínua) para aumentar la calidad de los procesos internos de desarrollo. Esto podría traer importantes mejoras en nuestra dirección de proyectos de desarrollo. La Comisión de la Comunidad OSS proveerá de los medios para tomar ventaja de los avances en desarrollo de la comunidad Entrenamiento La oferta de "FormTech" cubre el entrenamiento en OSS, y provee de lo necesario para cubrir las demandas y consultas potenciales de entrenamiento. 6. PLAN DE TRABAJO CÓDIGO ABIERTO Los siguientes objetivos han de ser asociados al plan de trabajo de OSS de los dos próximos años. Open Source Strategy - Page 8 / 12

18 6.1. Evaluar el uso actual de OSS en la Comisión Realizar una encuesta detallada del OSS usado en las Direcciones Generales El fin de esta encuesta es obtener un inventario completo y detallado de OSS que esté actualmente en uso (o que esté planeado usar) en los sistemas de producción de las Direcciones Generales Consolidar Linux como plataforma de los servidores Estudio de interoperatividad entre plataformas Linux/Unix y ETP Este proyecto está destinado al establecimiento de parámetros de configuración de sistemas de tipo Unix, Linux y configuraciones ETP (seguridad, archivos e impresión compartida, etc.). El estudio está ahora mismo (15/05/2003) en la fase de revisión final Definición de una configuración de referencia para los equipos Linux con aplicaciones simples Linux El objetivo es describir y evaluar el despliegue de Oracle y Coldfusion en servidores Linux para establecer una configuración de referencia de equipos Linux con aplicaciones simples Linux. Esto debería ayudar a construir una arquitectura de despliegue de los sistemas de información más flexible. Este proyecto llevará a Linux a posicionarse como alternativa de Unix para uso interno de la Dirección General Migración de Circa desde Unix y despliegue en Linux El proyecto de migración de Circa consiste en una descripción y evaluación de conclusiones relacionadas con el hardware y el software al pasar de Circa a la plataforma Linux. La conclusión principal es la elección de la configuración del hardware usando el nuevo contrato con Dell, teniendo en cuenta su servicio 24*7 y las implicaciones del despliegue totalmente libre de errores Considerar la clasificación de Linux como producto de clase B Debido a que el uso de Linux está formalizado, la clasificación del mismo como producto de clase B parece el siguiente paso natural del proceso. La manera de conseguir esta clasificación es el objetivo de esta acción que se une a muchas otras descritas en este capítulo. La clasificación supone soporte, entrenamiento y evolución contínua Evaluar las funcionalidades disponibles de agrupamiento (clustering) y escalabilidad bajo Linux Esta acción responderá la siguiente cuestión: es posible configurar máquinas Linux y clusters para alcanzar un alto grado de seguridad y escalabilidad sin implicar hardware especial? 6.3. Mejorar la gestión y uso de los productos OSS Adaptación de las pautas de gestión de productos para permitir las particularidades de las soluciones OSS La actual gestión de productos y los procedimientos de puesta en marcha se van a adaptar para evitar que excluyan ofertas de soluciones OSS porque no encajen con el modelo económico tradicional. La acción consistirá en una primera fase de estudio seguida por la apropiada adaptación de los procedimientos. Open Source Strategy - Page 9 / 12

19 Indicar claramente que las soluciones OSS serán admitida cuando se publique una petición de oferta Los que hagan la oferta deberían ser informados de que la Comisión está preparada para evaluar y usar OSS. Esto animará a las compañías integradoras responder a la petición de oferta con ofertas que incluyan soluciones OSS. La manera de hacerlo tiene que ser definida e implementada Promocionar una comunidad OSS interna Creación y conducción de la comunidad OSS de la Comisión El objetivo es crear y animar a crear un lugar donde compartir experiencias relacionadas con las prácticas y productos OSS en la Comisión, y garantizar su promoción y visibilidad en todos los cuerpos de la distribución. El modelo OSS de trabajo será promocionado en la comunidad también para soluciones/productos/proyectos que no sean OSS. Muchas unidades de I+D están envueltas en esta acción: STB, ISIQ y SSI son las principales. Esta acción implica la creación de una infraestructura de apoyo a la comunidad (comopor ejemplo una intranet y otras muchas cosas) Definición de las mejores prácticas de desarrollo de aplicaciones basadas en OSS (integración continua) Hay muchas cosas que aprender del modelo inherente al OSS de desarrollo en colaboración que puede ser tremendamente valioso para cualquier proyecto de desarrollo. El objetivo de esta acción es proponer una manera de de dirigir proyectos de desarrollo, desde el punto de vista técnico, basado en herramientas y métodos que hicieron que tuvieran éxito numerosos proyectos OSS. Esta proveerá esencialmente a las Direcciones Generales de unas pautas para el desarrollo de aplicaciones que propondrán un conjunto de productos y una manera de trabajar para desarrollar aplicaciones Java/J2EE basadas en el IDE de Java recomendado (JBuilder) y un conjunto de productos o tecnologías de código abierto (CVS, Ant, JUnit ) Evaluar productos y soluciones OSS Estas acciones son parte del trabajo continuado de la unidad de I+D, encargada del reloj tecnológico. La evaluación de servidores de aplicaciones, bases de datos o lenguajes OSS ayudará a una mejor comprensión de sus particularidades, y conducirá a algunas recomendaciones de uso en determinadas situaciones Evaluar y probar soluciones de servidores de aplicaciones: Jboss, Tomcat Evaluar y probar de soluciones de bases de datos OSS: MySQL, PosgreSQL Evaluar lenguajes de scripting y desarrollo: PHP, Python Basado en las evauaciones, componer un paquete de despliegue al OSS para despliegues externos y reutilizarlo (especialmente aplicaciones web) las partes externas, como los Estados Miembros Monitorizar la evolución de los escritorios OSS Open Source Strategy - Page 10 / 12

20 ANEXO I DEFINICIÓN DE CÓDIGO ABIERTO Introducción Código abierto no sólo se refiere al código fuente. Los términos de distribución de software de código abierto deben cumplir con los siguientes criterios: (1) Redistribución gratuíta La licencia no debe restringir a ninguna parte de que venda o del software como componente de una distribución de software agregado que contenga programas de muchas fuentes distintas. La licencia no debe requerir un royalty u otro tipo de pago por dicha venta. (2) Código Fuente El programa tiene que incluir el código fuente, y tiene que permitir la distribución tanto en formato código fuente como compilado. Cuando se de el caso de un producto que no sea distribuido con código fuente, debe haber una explicación clara de cómo obtenerlo sin un coste mayor del razonable para su reproducción, o la posibilidad de descarga via internet sin cargo alguno. El código fuente debe encontrarse en un formato en el que el programador pueda modificarlo. El código deliberadamente ocultado no está permitido. Los formatos intermedios como pueda ser la salida de un pre-procesador o traductor no están permitidos. (3) Trabajos derivados La licencia debe permitir modificaciones y trabajos derivados, y debe permitir que sean distribuidos bajos los mismos términos que la licencia del software original. (4) Integridad del código fuente del autor The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (5) No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. (6) No Discrimination Against Fields of Endeavour The license must not restrict anyone from making use of the program in a specific field of endeavour. For example, it may not restrict the program from being used in a business, or from being used for genetic research. (7) Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. (8) License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. (9) The License Must Not Restrict Other Software Open Source Strategy - Page 11 / 12

21 The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. (10) *The License must be technology-neutral No provision of the license may be predicated on any individual technology or style of interface. Origins: Bruce Perens wrote the first draft of this document as "The Debian Free Software Guidelines", and refined it using the comments of the Debian developers in a month-long conference in June, He removed the Debian-specific references from the document to create the "Open Source Definition." Copyright 2003 by the Open Source Initiative A list of Open Source Initiative approved licenses can be found at: Open Source Strategy - Page 12 / 12