La revolución silenciosa de AWS en el mundo del código abierto

Algo ha cambiado en Amazon Web Services (AWS) respecto a su relación, antes tensa, con el código abierto. Aunque siempre fue incorrecto arremeter contra AWS por "minar" el código abierto, como hizo Daisuke Wakabayashi en The New York Times, había suficiente humo en ese fuego como para que la acusación pareciera algo creíble.

Al fin y al cabo, un rápido repaso a los principales proyectos de código abierto de la Cloud Native Computing Foundation, la Apache Software Foundation o cualquier otra organización habría demostrado que Google tiende a encabezar las listas de contribuciones al código abierto, seguido de largo por Microsoft. AWS se situaba a lo lejos, probablemente felicitándose por liberar a los clientes de la "pesada y difusa tarea" de gestionar el código abierto por sí mismos.

Bueno, eso era antes; así es ahora. Los equipos de servicio (producto) de AWS por fin parecen haber entendido que para cumplir con la "obsesión por el cliente", el principio de liderazgo más importante de Amazon (o incluso otros principios como la propiedad, la entrega de resultados, etc.), también tienen que estar obsesionados con las contribuciones de código abierto.

Raro, pero cierto

He mencionado antes que AWS parece estar cambiando su mentalidad en torno a la propiedad. El principio de liderazgo número 2 de AWS ha llevado a algunos equipos de servicio de la compañía a asumir que la única manera de cuidar realmente a los clientes era ser dueño de todos los aspectos de la experiencia. Esto dificultaba la participación de las comunidades de código abierto porque parecía implicar que Amazon estaría a merced de la comunidad para corregir errores, etc.

Algunos equipos de servicios de AWS se mostraban reacios a contribuir para no desvelar demasiado sobre el funcionamiento de sus sistemas o permitir a los competidores corregir errores o características que diferenciaran los propios servicios de Amazon. En el proceso, acumularon deuda técnica, haciendo más difícil dar al cliente lo que realmente quería: una manera fácil de ejecutar Apache Spark, o MySQL o insertar un proyecto de código abierto.

Mientras trabajaba en AWS, vi que esto empezaba a cambiar, aunque lentamente. Ahora parece que se está acelerando con rapidez. Tomemos, por ejemplo, PostgreSQL. Hace unos años, AWS era criticada regularmente (con razón, diría yo) por aprovecharse de PostgreSQL. La compañía ganaba mucho dinero gestionando PostgreSQL para los clientes, pero daba poco a cambio.

Ahora, sin embargo, la página de committers [personas a la que se le permite modificar el código fuente de un proyecto de software que se utilizará en los lanzamientos oficiales del proyecto] de PostgreSQL está llena de empleados de AWS. Algunas de estas personas ya eran committers y fueron contratadas por AWS para trabajar en PostgreSQL (y presumiblemente en servicios de bases de datos de AWS como RDS y Aurora), pero Nathan Bossart, Masahiko Sawada, y otros se ganaron esa distinción a través de sus contribuciones. Me atrevería a decir que AWS es ahora el tercer mayor contribuyente corporativo a PostgreSQL si se suman las contribuciones de sus empleados a PostgreSQL. No estoy en absoluto minimizando el valor de las contribuciones de otros. Más bien, estoy señalando el asombroso incremento en la participación de AWS.

El largo camino

Recordemos que el trabajo de código abierto no ha terminado. Por ejemplo, AWS gana mucho dinero con su servicio Kubernetes, pero apenas llega a figurar entre los 10 primeros contribuyentes del año pasado. Lo mismo puede decirse de otros proyectos emblemáticos de código abierto para los que AWS ha gestionado servicios, como OpenTelemetry, o proyectos de los que dependen sus clientes, como Knative (AWS ocupa el puesto 12). ¿Y Apache Hadoop, la base de AWS Elastic MapReduce? AWS sólo tiene un committer. Para Apache Airflow, las cifras son mejores.

En cualquier caso, esto es pensar con el vaso medio vacío. El hecho de que AWS tenga algún committer en estos proyectos es un indicador importante de que la empresa está cambiando. Hace unos años, no habría habido ninguno en estos proyectos. Ahora hay uno o muchos.

Todo esto indica un destino diferente para AWS. La compañía siempre ha sido excelente en la ejecución de proyectos de código abierto como servicios para sus clientes. Como descubrí cuando trabajaba allí, la mayoría de los clientes sólo quieren algo que funcione. Pero conseguir que "simplemente funcione" de la manera que los clientes quieren (es decir, la versión vainilla de un proyecto de código abierto, no una versión "premium" bifurcada) requiere que AWS se ensucie las manos en el desarrollo del proyecto. Tradicionalmente, los equipos de ingeniería no estaban incentivados para hacerlo; parece que ahora sí lo están.

Todo esto es bueno para AWS, para sus clientes y para el código abierto. Es difícil exagerar lo distinto que funciona esta compañía, dada su escala. A gran escala, las cosas se rompen y AWS ha aprendido a arreglarlas. Si podemos conseguir más de ese know-how infundiendo proyectos de código abierto, esto beneficia a todos y, yo diría, crea mercados mucho más grandes donde AWS puede vender sus servicios.