En el primer artículo de mi serie sobre oficinas de programas de código abierto, profundicé en qué es una oficina de programas de código abierto y por qué tu empresa podría necesitar una. A continuación, analicé cómo Google creó un nuevo tipo de oficina de programas de código abierto. En este artículo, explicaré algunas de las ventajas de tener una oficina de programas de código abierto.
A primera vista, una de las principales razones por las que una empresa que no se dedica al desarrollo de software podría adoptar con más entusiasmo una oficina de programas de código abierto es porque tiene menos que perder. Después de todo, no están jugando con productos de software que están directamente vinculados a los ingresos. Facebook, por ejemplo, puede lanzar fácilmente un almacén de datos de valor clave distribuido como proyecto de código abierto porque no vende un producto llamado «almacén de datos de valor clave empresarial». Eso responde a la cuestión del riesgo, pero sigue sin responder a la pregunta de qué ganan contribuyendo al ecosistema de código abierto. Veamos algunas posibles razones y abordemos cada una de ellas. Observará que coinciden en gran medida con las oficinas de programas de código abierto de los proveedores, pero algunas de las motivaciones son ligeramente diferentes.
Contratación
La contratación es quizá la forma más fácil de vender una oficina de programas de código abierto a la alta dirección. Muéstreles los costes asociados a la contratación, así como el retorno de la inversión, y luego explíqueles cómo el desarrollo de relaciones con ingenieros de talento se traduce en un flujo de desarrolladores de talento que están realmente familiarizados con su tecnología y dispuestos a ayudar a trabajar en ella. No hace falta que profundicemos más: se explica por sí solo, ¿verdad?
Influencia de la tecnología
Hace tiempo, las empresas que no se especializaban en la venta de software no podían influir directamente en los ciclos de desarrollo de sus proveedores de software, sobre todo si no eran grandes clientes. El código abierto cambió por completo esta dinámica y situó a los usuarios en igualdad de condiciones con los proveedores. Con el auge del desarrollo de código abierto, cualquiera podía impulsar la tecnología en la dirección elegida, siempre que estuviera dispuesto a invertir tiempo y recursos. Pero estas empresas aprendieron que la simple inversión en tiempo de los desarrolladores, aunque fructífera, podía ser aún más útil si se vinculaba a un esfuerzo estratégico global -pensemos en la corrección de errores frente a los arquitectos de software-. Muchas empresas envían correcciones de errores a proyectos de código abierto anteriores, pero algunas de estas mismas empresas empezaron a aprender que coordinar un esfuerzo sostenido con un compromiso más profundo daba sus frutos con un desarrollo más rápido de las funciones, lo que podía ser bueno para el negocio. Con el modelo de oficina de programas de código abierto, las empresas cuentan con personal capaz de detectar comunidades de código abierto estratégicamente importantes en las que invertir recursos de desarrollo.
Para empresas de rápido crecimiento como Google y Facebook, liderar los proyectos de código abierto existentes seguía resultando insuficiente para sus negocios en expansión. Enfrentadas a los retos de un crecimiento intenso y a la construcción de sistemas a hiperescala, muchas de las mayores empresas habían construido pilas de software altamente personalizadas para uso exclusivamente interno. ¿Y si pudieran convencer a otros para que colaboraran en algunos de estos proyectos de infraestructura? Así, mientras mantenían sus inversiones en áreas como el núcleo Linux, Apache y otros proyectos existentes, también empezaron a lanzar sus propios grandes proyectos. Facebook lanzó Cassandra, Twitter creó Mesos y, finalmente, Google creó el proyecto Kubernetes. Estos proyectos se han convertido en importantes plataformas para la innovación de la industria, demostrando ser éxitos espectaculares para las empresas implicadas. (Obsérvese que Facebook dejó de utilizar Cassandra internamente después de que necesitara crear un nuevo proyecto de software para resolver el problema a mayor escala. Sin embargo, para entonces Cassandra ya se había popularizado y DataStax se había formado para asumir el desarrollo). Cada uno de estos proyectos ha generado ecosistemas enteros de desarrolladores, proyectos relacionados y usuarios finales que sirven para acelerar el crecimiento y el desarrollo.
Esto no habría sido posible sin la coordinación entre una oficina de programas de código abierto y las iniciativas estratégicas de la empresa. Sin ese esfuerzo, cada una de las empresas mencionadas seguiría intentando resolver estos problemas de forma individual, y más lentamente. Estos proyectos no sólo han ayudado a resolver problemas empresariales internamente, sino que también han contribuido a establecer a las empresas que los crearon como pesos pesados del sector. Por supuesto, Google ha sido un titán de la industria desde hace unos años, pero el crecimiento de Kubernetes garantiza tanto un mejor software, como una participación directa en la dirección futura de las tecnologías de contenedores, incluso más de lo que ya tenía. Estas empresas siguen siendo conocidas por su infraestructura a hiperescala y por ser simplemente grandes incondicionales de Silicon Valley. Menos conocida, pero posiblemente aún más importante, es su nueva relevancia como productores de tecnología. Las oficinas de programas de código abierto guían estos esfuerzos y maximizan su impacto, a través de recomendaciones tecnológicas y relaciones con desarrolladores influyentes, por no mencionar una profunda experiencia en la gobernanza de la comunidad y la gestión de personas.
Poder de marketing
La influencia de la tecnología va de la mano de la forma en que cada empresa habla de sus iniciativas de código abierto. Al perfeccionar los mensajes en torno a estos proyectos y comunidades, una oficina de programas de código abierto es capaz de ofrecer el máximo impacto a través de campañas de marketing específicas. El marketing ha sido durante mucho tiempo una palabra sucia en los círculos del código abierto, porque todo el mundo ha tenido una mala experiencia con el marketing corporativo. En el caso de las comunidades de código abierto, el marketing adopta una forma muy distinta del enfoque tradicional e implica amplificar lo que ya está ocurriendo en las comunidades de importancia estratégica.
Piensa en los primeros esfuerzos de la oficina de programas de código abierto de Google. No se limitaron a aportar código al núcleo de Linux y a otros proyectos, sino que hablaron mucho de ello, a menudo en conferencias magistrales sobre código abierto. No se limitaron a dar dinero a los estudiantes que escribían código fuente abierto, sino que crearon un programa global, el Google Summer of Code, que se convirtió en la piedra de toque cultural del desarrollo del código fuente abierto. Este esfuerzo de marketing consolidó el estatus de Google como uno de los principales desarrolladores de código abierto mucho antes incluso de que se desarrollara Kubernetes. Como resultado, Google ejerció una gran influencia durante la creación de la licencia GPLv3, y los ponentes de la empresa y los representantes de la oficina del programa de código abierto se convirtieron en habituales en los eventos tecnológicos. La oficina del programa de código abierto es la entidad mejor situada para coordinar estos esfuerzos y ofrecer un valor real a la empresa matriz.
Mejorar los procesos internos
Puede que la mejora de los procesos internos no parezca un gran beneficio, pero superar los caóticos procesos internos es un reto para cualquier oficina de programas de código abierto, ya sea del proveedor de software o de la empresa. Mientras que un proveedor de software debe asegurarse de que sus procesos no pisan los productos que publica (por ejemplo, abriendo involuntariamente software propietario), un usuario está más preocupado por la infracción de la ley de propiedad intelectual (PI): patentes, derechos de autor y marcas registradas. Nadie quiere ser demandado simplemente por publicar software. Sin una oficina de programas de código abierto activa que gestione y coordine la concesión de licencias y otras cuestiones legales, las grandes empresas tienen grandes dificultades para llegar a un consenso en torno a los procesos y la gobernanza del código abierto. ¿Por qué es importante? Si diferentes grupos publican software con licencias incompatibles, no sólo resultará embarazoso, sino que también supondrá un obstáculo importante para alcanzar uno de los objetivos más básicos: mejorar la colaboración.
Combinado con el hecho de que muchas de estas empresas siguen creciendo a un ritmo increíblemente rápido, la incapacidad de establecer normas básicas en torno al proceso resultará difícil de manejar antes de lo esperado. He visto grandes hojas de cálculo con una matriz de licencias aprobadas y no aprobadas, así como directrices sobre cómo crear (y cómo no hacerlo) comunidades de código abierto respetando las restricciones legales. La clave es tener algo que los desarrolladores puedan consultar cuando necesiten tomar decisiones, sin incurrir en la sobrecarga legal de una revisión masiva de la propiedad intelectual que ralentice el trabajo cada vez que un desarrollador quiera contribuir a una comunidad de código abierto.
