No existe una definición única de éxito en los proyectos de código abierto.
Todo el mundo está en código abierto en estos días. Microsoft acaba de lanzar su software 3D Movie Maker bajo una licencia de código abierto. Spotify tiene una gran cantidad de proyectos que ha lanzado y a los que contribuye, y acaba de anunciar un fondo para apoyar a los mantenedores de proyectos. Incluso hay un código de motor de juego de la Edad Media (1998) de código abierto.
Código abierto:Cobertura de lectura obligada
Con estos proyectos y millones de otros disponibles, es una buena pregunta… ¿por qué? O más bien, ¿por qué importan la gran mayoría de estos proyectos y para quién? Después de todo, la mayoría de los proyectos nunca serán Kubernetes.
Sin embargo, después de más de dos décadas en código abierto, estoy empezando a darme cuenta de que esta es la pregunta equivocada.
El ejemplo del petardo
Tome Firecracker, un proyecto de microvirtualización de código abierto que AWS lanzó en 2018. Firecracker fue aclamado casi universalmente como una tecnología genial... y luego desapareció en su mayoría de la vista del público. Escribí sobre algunos éxitos tempranos de la comunidad, pero incluso eso (Weave Ignite para mejorar la facilidad de uso de Firecracker, entre otras cosas) provino de un socio cercano de AWS. Para darle a Firecracker más peso en la comunidad, sugerí que AWS siguiera a Google y abriera la gobernanza en torno a Firecracker, no solo su código.
AWS no escuchó pero, no por primera vez, mi opinión no parecía importar. (Esa es una forma educada de decir que tal vez me equivoqué).
Avance rápido hasta 2022, y Firecracker se está utilizando silenciosamente en muchos lugares geniales. Digo “en voz baja” porque, bueno, ¿por qué alguien gritaría su infraestructura desde los tejados? Pero cuando pregunté, surgieron algunos usuarios interesantes, como Stripe, Fly.io, System Initiative y más. Por supuesto, sigue siendo cierto que la mayoría de los colaboradores de Firecracker son empleados de AWS.
Pero incluso si Firecracker hubiera seguido siendo una comunidad de uno (AWS), podría decirse que habría valido la pena. De hecho, eso es esencialmente lo que argumenté mientras trabajaba para AWS, indicando que había razones claras orientadas al cliente para abrir Firecracker, independientemente de la participación de la comunidad. El código abierto aseguró que Firecracker funcionaría bien con la comunidad de Linux y permitió "ganancias de productos compuestos" más estrictas para los clientes.
Millones de petardos
Ahora reproduzca este ejemplo de Firecracker multiplicado por los más de cien millones de repositorios de GitHub (y otros de código abierto). No se trata de ser el próximo Kubernetes. Para cada proyecto de código abierto, se trata de satisfacer las necesidades del desarrollador individual, una empresa o una comunidad más amplia.
A veces esas necesidades pueden ser grandes. En una conversación que tuve con el líder de ingeniería de Lyft y fundador de Envoy, Matt Klein, enfatizó que "para la mayoría de las personas que abren algo de código fuente, en realidad es un neto negativo" porque "si no invierten en ello, si no hacer todas estas cosas [como relaciones públicas, marketing y contratación], solo van a tirar algo por la borda”. Para Klein, obtener una participación significativa de toda la industria en Envoy ayudó a que el proyecto valiera la pena la inversión que él (y, por extensión, Lyft) había hecho.
Pero podría decirse que no todos necesitan obtener ese tipo de retorno. En el caso de Firecracker, la fuente abierta del código y el solo hecho de que los clientes colaboraran habría sido suficiente, como razoné. Para Google, por el contrario, que podría decirse que estaba tratando de avanzar en una realidad multinube a través de Kubernetes, tenía que ir a lo grande. Cada proyecto tendrá diferentes necesidades y diferentes medidas de éxito.
¿Entonces no eres el próximo Kubernetes? Está bien. ¿Tampoco eres el próximo Firecracker? También está bien. Para los desarrolladores de código abierto, la clave es descubrir qué significa un proyecto saludable para sus necesidades particulares y no distraerse con las definiciones de éxito de otros.
Divulgación:trabajo para MongoDB, pero las opiniones expresadas aquí son mías .
Enlace de origen