Acompaña el evento final de la Maratón Behind the Code 2020: 05/12 - Online ¡Inscríbete ahora!

Considere la escala, la gobernanza abierta y la cultura

Estamos emocionados de ver a más empresas adoptar el software de open source y sus principios de funcionamiento. La adopción de open source en la empresa es genial para los ecosistemas de open source que prosperan en la fuerza y la diversidad de la comunidad. Si más desarrolladores corporativos trabajan con open source, producirán tecnología más segura e innovadora para todos.

Entonces, ¿cómo puede usted crear una empresa que adopte el open source? Al convertirse en una empresa de open source, es necesario considerar los riesgos, la escala, la gobernanza abierta y la cultura.

Considere los riesgos. La adopción de open source no viene sin algunos riesgos. Usted necesita tener una estrategia implementada para saber dónde se va a invertir y cómo afectará a su paquete actual de tecnología.

Piense en la escala. Al crear o invertir en proyectos de open source, usted necesita considerar cómo se escalan los proyectos dentro de su empresa. Cuando nos involucramos en un proyecto, nos centramos en aquellos aspectos que más le importan a la empresa: interoperabilidad, portabilidad, seguridad, escalabilidad y accesibilidad.

Solicite una gestión abierta. La gestión abierta garantiza el éxito a largo plazo y la viabilidad de los proyectos que utilizan open source. Nos involucramos en comunidades que adoptan la gestión abierta, donando nuestro código para beneficio de la comunidad mientras se utiliza también el código resultante de nuestros propios productos.

Cree una cultura abierta. Convertirse en una empresa abierta requiere un cambio en la cultura de su empresa. No va a suceder de forma natural, pero hay algunas cosas que usted puede hacer para fomentar una cultura abierta. Entramos en más detalles a continuación.

Obtenga más información acerca de nuestro enfoque hacia la tecnología abierta  
Gente trabajando en una oficina

Elementos esenciales de un programa de open source

En IBM, tenemos seis elementos básicos en nuestro programa de open source que nos ayudan a alcanzar esa cultura abierta. Considere la posibilidad de utilizar o adaptar estos elementos para crear su propia empresa abierta.

Profundice en cada elemento y descubra cómo puede crear de manera abierta.

  • Antes de trabajar con open source — sea durante el tiempo personal o en la empresa, los empleados deben tomar nuestra capacitación anual. Esta capacitación garantiza que todos tengan una comprensión sólida de open source y de sus beneficios y riesgos.

    Debido a que estamos perfeccionando constantemente nuestros procesos de open source, los IBMistas deben completar la capacitación anualmente mientras estén participando activamente en el desarrollo u otras actividades que impliquen open source. Más de 60.000 IBMistas completan esta capacitación cada año.

    Elementos esenciales de capacitación de open source

    Algunos de los elementos clave que cubrimos en nuestras capacitaciones incluyen:

    • Definición de open source: cualquier empleado que trabaje con open source necesita entender lo que es y lo que no es open source. Una vez que se establece una definición clara, es más fácil hablar acerca de cómo utilizarlo de manera eficaz.
    • Ventajas del open source: se destacan las ventajas del open source para animar a los empleados a contribuir.
    • Riesgos potenciales: : nuestras charlas de capacitación acerca de los riesgos comunes asociados con open source. Queremos empleados que sean capaces de detectar los riesgos, pero nuestro proceso de aprobación también está habilitado para descubrir y reducir los riesgos potenciales al principio del ciclo de desarrollo.
    • Licencias de open source: es fundamental comprender todos los permisos concedidos por licencias, obligaciones de licencia y cómo manejar correctamente los paquetes de open source según la licencia. Esta comprensión garantiza que nuestra propiedad intelectual esté protegida y que se respeten los términos de la licencia, lo que ayuda a proteger nuestra reputación como buenos ciudadanos de la comunidad de open source.
    • Formas de trabajar con open source: la capacitación incluye nuestra política de trabajar con open source en tiempo personal, consumir open source internamente, consumir open source en productos y servicios, manejar open source de un proveedor o cliente y contribuir al open source.
    • Open source y estrategia corporativa: comprender qué papel desempeña el open source en nuestra estrategia corporativa proporciona el contexto para ayudar a los desarrolladores a entender cómo sus contribuciones de open source funcionan en beneficio de nuestra empresa.
    • Proceso de gestión de open source: explicamos los pasos, las herramientas y las partes implicadas en el proceso.

    Tanto nuestro proceso como nuestro material de formación se revisan periódicamente, en la medida en que recibimos retroalimentación sobre qué funciona bien y qué podemos mejorar.

  • Reconocer y recompensar a los contribuyentes

    Queremos que todos nuestros desarrolladores estén involucrados con open source. Cada año, reconocemos a los empleados de IBM que contribuyen al open source con premios en efectivo, e promocionamos individualmente a cada ganador en toda la empresa.

    Nuestras categorías de premios incluyen creadores de proyectos, contribuyentes significativos y los líderes de proyecto en las principales comunidades de open source.

    Este programa persuadió a los desarrolladores de open source para que hagan su primera contribución y se conviertan en contribuidores constantes. Además de nuestro programa de incentivos, también tenemos mentores de open source disponibles para colaborar con los desarrolladores y ayudarles a realizar su primera contribución.

  • Escala con herramientas y automatización

    Debido a que nuestro uso de open source en nuestros productos y servicios aumenta un 30 % año tras año, debemos automatizar las soluciones para que se mantengan al día. Hemos desarrollado herramientas internas que se pueden lanzar en cadenas de herramientas de DevOps para automatizar la gestión de open source.

    Al montar una cadena de herramientas para gestionar open source, hay varios puntos a considerar. Enfoque sus herramientas y la automatización en los siguientes aspectos fundamentales:

    • Identificación de open source: ¿Qué es el open source en la compilación, incluyendo todas las dependencias?
    • Identificación de licencia: ¿Cuáles son las licencias de open source en la compilación? A veces hay más de una licencia en un paquete de open source. Si hay más de una licencia, ¿las licencias son compatibles? ¿La licencia contiene términos exclusivos?
    • Exploración del open source: Podemos explorar el código fuente de los paquetes de open source para identificar posibles problemas de IP como otras licencias de terceros en el código (incluyendo software comercial), posibles problemas de patentes y las prohibiciones para uso comercial. También podemos realizar un análisis exhaustivo para identificar dependencias que podrían tener las licencias que no sean compatibles con el paquete principal.
    • Un almacén de datos centralizado: Tenemos un repositorio centralizado para el análisis interno de paquetes de open source, por lo que los equipos pueden compartir los resultados de análisis y no duplicar esfuerzos. Tenemos más de 60.000 exploraciones únicas disponibles.
    • Análisis automatizado de las nuevas versiones: Si una nueva versión no es muy diferente de una versión previamente digitalizada de un paquete de open source, no requerimos de una nueva exploración de código.
    • Automatización, métricas y seguimiento del flujo de trabajo: Nuestras herramientas admiten personalización de los flujos de trabajo de aprobación con base en el riesgo y las necesidades de la unidad de negocios. Apoyamos todo tipo de casos de uso, algunos donde no se requieren aprobaciones y otros donde los ejecutivos empresariales y legales deben aprobar. Utilizamos el flujo de trabajo para realizar un seguimiento de qué tecnología de open source se utiliza en qué productos y servicios a lo largo de todo nuestro portafolio.
    • Seguimiento de contribuciones: A menudo nuestros colaboradores personales tendrán GitHub ID y un IBM GitHub ID. Utilizamos herramientas para realizar un seguimiento de las contribuciones en ambos ID, para garantizar que todo el mundo obtenga crédito hacia nuestro programa de reconocimiento. Respetamos la necesidad de individualidad de nuestros desarrolladores y el open source con el que han contribuido bajo un ID personal los representa a ellos y a su currículo.
  • Cree una organización de gestión dedicada

    Nuestro proceso de gestión de open source reúne a los participantes de negocios, legales y técnicos. Organizativamente, un equipo de open source central gestiona el proceso y consulta a los equipos de desarrollo para responder preguntas y asegurarse de que el proceso se ejecute sin problemas. Nuestro equipo dedicado cuenta con décadas de experiencia y conocimiento de open source, y ofrece capacitación, asesoría y gestión de políticas y procesos para equipos de IBM.

    El equipo de open source trabaja estrechamente con nuestros equipos de DevOps responsables de herramientas y automatización para ampliar y mejorar nuestra gestión de open source y el proceso de revisión. Nuestras herramientas personalizadas incluyen herramientas de identificación y exploración, flujo de trabajo de revisión para el uso del producto y las solicitudes de contribución, y las bases de datos y portales para compartir eficazmente información y directrices a lo largo de todas nuestras unidades de negocios.

    Tener una imagen precisa de todo el open source en todo nuestro portafolio es la base para la gestión de vulnerabilidades de open source. Nuestras herramientas de proceso de open source interno pueden realizar el seguimiento de las vulnerabilidades, de modo que los equipos de producto pueden abordarlas rápidamente.

  • Defina un proceso para consumir open source

    Es importante establecer procesos claros de cómo consumir tecnología open source, tanto el que se compila internamente como otros proyectos que se adopten desde fuera de la compañía. Aquí presentamos nuestras directrices generales.

    Consumo de open source dentro de IBM

    Para el open source que los IBMistas solo utilicen en experimentos, herramientas de desarrollo, herramientas de productividad y compilaciones internas; nuestra regla es que mientras el open source tenga una licencia que esté en nuestra lista interna de licencias aprobadas y el paquete no esté en nuestra lista de paquetes prohibidos para uso interno, entonces el open source no necesitará aprobación formal.

    Tenga en cuenta que si hay un Acuerdo de Licencia de Usuario Final (EULA) u otros términos necesarios para descargar el software, no es open source y esos términos tendrían que examinarse más a fondo.

    Consumo de open source fuera de IBM

    Cuando hablamos de open source utilizados fuera de IBM, queremos decir que el código está incluido en el software o en la oferta de servicios, ya sea desplegado en nuestra nube o en los sistemas locales de los clientes. Los ejemplos comunes incluyen productos de software y hardware, software como servicio (SaaS) y las soluciones de nube. Cuando usamos tecnología de open source en un producto o servicio, debemos seguir un proceso formal que garantiza que cumplimos con las obligaciones de licencia de open source y hace el seguimiento de qué open source es usado en cada uno de nuestros productos y servicios. Esto también es importante para garantizar que podemos identificar y abordar las vulnerabilidades de seguridad.

    Nuestro proceso es lo más transparente posible para los desarrolladores. La mayoría de los equipos utilizan un modelo de entrega continua, a veces entregando varias veces al día. Este proceso permite a los equipos enviar cambios a su lista de materiales de open source mensualmente, por lo que el proceso de aprobación no es un obstáculo para la entrega.

    Aquí están los pasos:

    • El nuevo open source añadido a una compilación es identificado por las herramientas. Las capacidades de generación de informes en la herramienta identifican el nombre del paquete, la versión, la(s) licencia(s) asociada(s) y si el código de origen para ese paquete se ha explorado previamente.
    • Para cualquier open source que no haya sido previamente explorado o que no esté estrechamente relacionado con una versión previamente explorada, se realizará una exploración de código y se guardará como referencia para otros equipos.
    • El gerente de versión envía la solicitud, que puede incluir varios cientos o incluso varios miles de paquetes de open source.
    • La herramienta de flujo de trabajo calcula automáticamente el número de aprobadores requeridos y envía el formulario después de cada firma. Más del 90% del tiempo, las solicitudes son aprobadas por un administrador de primera línea y el responsable de administración de open source para la unidad de negocios. En algunos casos, por ejemplo cuando una licencia requiere código de licencias por separado, son necesarios aprobadores tanto legales como ejecutivos.
    • Este proceso se repite para las nuevas tecnologías de open source añadidas a la oferta. Una vez que el open source ha sido aprobado para una determinada oferta, no necesita ninguna aprobación adicional para futuras versiones.

    A lo largo del camino, nuestros líderes de gestión de open source están disponibles para contestar preguntas y asesorar a nuestros equipos en el canal interno de Slack.

  • Ser contribuyentes responsables de open source

    Creemos que contribuir a proyectos de open source no es solo algo bueno, sino que forma parte de nuestra responsabilidad como líderes de open source.

    Invertimos en el código comunitario para tecnologías estratégicas y nos aseguramos de que las correcciones y nuevas características se transmitan en lugar de ramificar código comunitario y crear nuestra propia versión de un proyecto. Por ejemplo, la Cloud Foundry que integramos en IBM Cloud es el mismo código que se libera en Cloud Foundry Foundation, y el mismo que es usado por HPE, Pivotal y SAP. Similarmente, el Docker incluido en IBM Container Service es el mismo Docker que dicha comunidad lanza.

    Cuando queremos agregar extensibilidad para que se puedan usar las capacidades particulares de IBM, trabajamos dentro de la comunidad para crear la API o SPI necesaria. Además, invertimos en garantizar que no se abuse de los puntos de extensión para crear un potencial de aprisionamiento.

    Seguimos desarrollando nuestro proceso para alentar a nuestros desarrolladores a participar y contribuir a las comunidades de open source. Nuestras áreas de enfoque de contribución incluyen:

    • Contribuir a una comunidad destacada. IBM lidera muchos proyectos de open source que son estratégicos para nuestro negocio y nuestros intereses de desarrollo. Animamos a todos los desarrolladores a hacer correcciones de errores o pequeñas mejoras. Un comité de dirección interno para una determinada comunidad revisa los principales cambios o mejoras.
    • Publicación de fragmentos de código y aplicaciones de ejemplo. Con la aprobación de un gerente, animamos a publicar fragmentos de código en sitios de desarrolladores y contribuir con ejemplos de aplicaciones y de uso de producto.
    • Correcciones de errores y pequeñas mejoras en los proyectos existentes. Se alientan las correcciones y las mejoras a lo largo de una amplia variedad de comunidades de open source y, en la mayoría de los casos, no requieren aprobación formal.

    Proposición de nuevos proyectos. Se llevan a cabo revisiones para nuevos proyectos, que van desde patrones de código en IBM Developer, IBM @ GitHub, hasta la creación de amplias iniciativas comunitarias como Hyperledger y Apache OpenWhisk.

Encuentre un asociado de open source

Probablemente no tenga tiempo para revisar las comunidades de open source en busca de respuestas o intentar comprender las dependencias entre pilas de tecnología. Para sacar el máximo provecho de sus inversiones de open source, necesita recurrir a un asociado de soporte que le ayude a mitigar los riesgos relacionados con el open source en su empresa. Con nuestros servicios de soporte, usted dispone de un único lugar para ir y obtener soporte para todo su ecosistema de open source.

Póngase en contacto con nuestros servicios de soporte  
Ciudad con redes interconectadas

Aviso

El contenido aquí presentado fue traducido de la página IBM Developer US. Puede revisar el contenido original en este link.