Imagen: iStock

“Uno de los mayores cambios en código abierto en nuestra vida”, señaló Sam Ramji, director de estrategia de DataStax, es la colaboración entre industrias y código abierto en todos industria. El código abierto se ha convertido en nuestra forma predeterminada de trabajar, mientras que alguna vez estuvo reservado a relativamente pocos desarrolladores y un puñado de empresas tecnológicas, como Red Hat. Pero cómo las empresas lo aceptan y lo hacen posible es aún más arte que ciencia. En una entrevista en el podcast Under the Hood of Developer Marketing presentado por Ramji, explicó los principios y prácticas de cómo Google, Comcast y Microsoft trabajan con código abierto, lo que también podría funcionar para su empresa.

VER: Comandos de administración de archivos y directorios de Linux (Premium de TechRepublic)

Índice

¿Es estratégico?

Al considerar abrir o no el código fuente, "los desarrolladores toman la decisión" en Comcast, dijo Nithya Ruff, quien dirige la oficina del programa de código abierto de Comcast. La empresa no impone montañas de burocracia para evitar que el código sea de código abierto. Por el contrario, “el consejo asesor de Ruff es puramente consultivo. Nuestro trabajo es hacer que todo el proceso sea lo más fácil posible y ayudarlos a hacerlo bien.

Chris DiBona, que dirige la oficina de código abierto de Google, confirmó:

Me gusta pensar en mí mismo como un burócrata muy, muy eficiente. Y mi burocracia es tan fácil de usar que siempre querrá hablar con nosotros cuando abra el código fuente, o visite nuestro sitio web interno, o incluso nuestro sitio web externo. Y obtendrá todos estos excelentes consejos. Y tratamos de quitarnos del camino del desarrollador la mayor parte del tiempo.

Pero seguramente estas empresas a veces tienen un proceso más complejo cuando se trata de código estratégico. Sí, dice Ruff: “La gestión del tiempo entra en juego si es un aporte estratégico…[like our] CDN, y queremos contribuir fuera de la empresa por una razón muy estratégica, ya sea para crear un estándar, crear un ecosistema o comercializar un área determinada. Para Google, agregó DiBona, proyectos como Go, Chromium y Android requieren "mucho más tiempo de contacto, dados los problemas, dado el impacto en el desarrollador, dado el impacto en el negocio y las personas que trabajan allí".

Pero me encantó lo que dijo a continuación: "Pero sé que si no [take care of] el ingeniero que solo quiere arreglar algo, lanzar un parche o lanzar un pequeño proyecto... así que cuando quieres hacer estas cosas realmente importantes, es muy, muy difícil. Hay demasiada acción de frenado.

Entonces, quizás la lección n.° 1 sea esta: para las empresas que desean administrar grandes iniciativas estratégicas de código abierto, primero deben asegurarse de que se están ocupando de las actividades cotidianas más mundanas.

Un asiento en la mesa

En el musical "Hamilton", los actores cantan sobre estar en "la sala donde está sucediendo", pero para las empresas que se preguntan por qué deberían contribuir y no solo consumir código abierto, "el lenguaje que atrae a las empresas en general es "tienes un sentarse a la mesa”, dijo Ruff. Ella añadió:

Realmente puedes influir en las cosas si contribuyes. Si no contribuyes, no tienes voz en lo que sucede en la mesa. Y lo entienden, porque es muy similar a los organismos de normalización, con los que muchas empresas saben cómo trabajar. Tienes que estar en la mesa para sumar tu granito de arena. Y la forma en que funciona en la comunidad de código abierto es por contribución de cualquier tipo.

Tales contribuciones incluyen código, por supuesto, pero, como sugirió Stormy Peters de Microsoft, el código no es suficiente. Au-delà des contributeurs au code, "tout bon projet logiciel implique de nombreuses personnes qui y participent, des utilisateurs aux personnes qui écrivent de la documentation, en passant par les personnes présentes aux conférences qui font passer le mot et parlent à d'autres gente". Además, señaló, las empresas pueden agregar roles como gerentes de productos o personas que buscan necesidades de accesibilidad.

Sur cette note à propos du code étant insuffisant, le code n'est pas utile si personne ne connaît le projet, ou le sait mais ne sait pas comment l'utiliser (c'est là qu'une excellente documentation et opérationnalisation du logiciel entrent apuesta) . Como señalaron los panelistas, debemos dejar de pensar en el código abierto solo como código, y el código tiende a ser escrito por una población relativamente homogénea de hombres blancos de mediana edad, como se lamentó DiBona en la entrevista.

VER: 10 formas de prevenir el agotamiento de los desarrolladores (PDF gratuito) (República Tecnológica)

¿Qué pasa con las empresas que intentan encontrar su oficina de programas de código abierto para ayudarlos a navegar por este material de código abierto de décadas de antigüedad pero aún incipiente? Peters tenía una sugerencia muy práctica:

Aquí está el secreto…. Salga y forme su equipo virtual en toda su organización. Estoy seguro de que hay alguien en su empresa, en el equipo legal, que piensa que el software de fuente abierta es fascinante. Ve a buscar a esa persona y reclútala para que te ayude. Estoy seguro de que hay alguien en el CIO o TI que piensa que el software de fuente abierta es fascinante. Ve a buscarlos. Probablemente haya alguien que ya haya introducido software de código abierto en alguna parte de su organización. Encuéntralos.

Encuéntrelos y capacítelos en un equipo virtual entre empresas, que, por supuesto, también es la forma en que ocurre la colaboración de código abierto entre industrias.

Divulgación: trabajo para AWS, pero las opiniones expresadas aquí son mías.