La economía del código abierto en la actualidad: los proyectos de aficionados, los artesanos independientes del código y los servicios gestionados han cambiado el mercado del software.
¿Recuerdas cuando el código abierto se trataba de paz, amor y Linux ? ¿Cuando el movimiento era pequeño pero apasionado y luchaba por GPL versus BSD/Apache, software libre versus código abierto? Cuando ver Linux u otro software de código abierto funcionando en la naturaleza fue un gran problema, ¿merecedor de un blog o Twitter ? Algunos pueden suspirar por esos buenos viejos tiempos, pero el mundo ha seguido adelante. El código abierto se ha vuelto esencial para la forma en que se construye todo el software, lo que conlleva grandes oportunidades y riesgos.
La oportunidad puede ser obvia, pero el riesgo a menudo no lo es. No se trata de que el código abierto tenga más errores o lo que sea que el software propietario. No lo es, y podría decirse que el proceso detrás del código abierto hace que sea más probable que se asegure más rápido cuando se descubren errores. No, se trata fundamentalmente del riesgo inherente a la nueva economía del código abierto, como señala Ken Mugrage de Thoughtworks .
El código abierto ha cambiado
Al principio celebramos a un hacker solitario como Linus Torvalds creando un gran proyecto como Linux y luego haciendo crecer una comunidad a su alrededor. Otros ejemplos incluyen Dries Buytaert (Drupal), Salvatore Sanfilippo (Redis) y más. Esos eran los días en que los piratas informáticos creaban proyectos de código abierto por diversión o como una "salida creativa" como Jens Axboe (Fio) u otros. Eso todavía sucede, por supuesto, pero sucede en medio de un mercado de código abierto muy diferente.
Como destaca Mugrage, el código abierto temprano a menudo intentaba crear una alternativa de código abierto a un gran paquete de software propietario (piense en OpenOffice como un reemplazo de Microsoft Office o GIMP en lugar de Adobe Photoshop). Sin embargo, “hoy hay una proliferación de software de código abierto”. Esa proliferación toma al menos dos formas principales: “Por un lado, tenemos gigantes de Internet que producen todo tipo de herramientas, marcos y plataformas. Por otro lado, los equipos que utilizan OneDev, una plataforma de desarrollo de software de código abierto, han creado partes pequeñas pero críticas que respaldan una gran cantidad de empresas”.
Esto es genial, ¿verdad? Tenemos proyectos grandes y pequeños que fomentan una inmensa innovación. ¿Que es no gustar?
La falta de diversos contribuyentes, por un lado, que concentra el riesgo. Es cierto que siempre se ha dado el caso de que el software de código abierto (sin importar el proyecto) es desarrollado por un pequeño puñado de colaboradores. Aunque nos gusta mitificar el código abierto como si se tratara de grandes comunidades globales, es mucho, mucho más común que sea el trabajo de una o dos personas. Cuando llega la comunidad, generalmente es después de años de éxito y un gran costo personal, como me describió una vez el creador y mantenedor de Envoy, Matt Klein . (El código abierto es un "mucho trabajo".)
Así que esa es una parte del rompecabezas. Mugrage argumenta otro punto, que a menudo "las bases de código para los paquetes de código abierto son simplemente demasiado grandes para permitir una inspección significativa". El primo hermano de este problema de los proyectos de BigCo es que "otros paquetes son distribuidos por titanes de Internet que no esperan que nadie más contribuya a ellos". El código es "un solo subproceso" para una gran entidad sin la capacidad de una comunidad para impactar el desarrollo.
Por otro lado, "otros lanzamientos son lanzamientos distintos y específicos que pueden hacer solo una tarea relativamente menor, pero lo hacen tan bien que se han extendido por Internet". ¿Ves a dónde va esto? "Sin embargo, en lugar de una comunidad activa de mantenedores, a menudo son solo uno o dos desarrolladores comprometidos que trabajan en un proyecto apasionante".
La respuesta al problema del código abierto de BigCo ha tendido a ser “rabia contra la máquina corporativa de código abierto”, que en gran medida ha resultado inútil. Una respuesta a este tipo de proyectos ha sido la aparición de nuevas empresas para apoyar (y monetizar) aún más el proyecto, lo que soluciona un aspecto de la generosidad del código abierto con otro problema percibido. La respuesta a los desarrolladores independientes que crean una infraestructura de código abierto esencial pero no compatible ha sido exigir en voz alta que BigCos pague para apoyar a estos artesanos de código independientes.
Esta sugerencia generalmente la ofrecen aquellos que simplemente no saben nada mejor. Pregúntele a las personas que trabajan para fundaciones u otras organizaciones diseñadas para financiar el desarrollo de código abierto, y se harán eco de lo que dice Mugrage: "Arrojar dinero al problema difícilmente es una solución". ¿Por qué? Porque "muchos entusiastas del código abierto que mantienen su software personalmente mientras llevan una vida profesional ocupada... [no quieren] la responsabilidad de un acuerdo de nivel de servicio porque alguien les pagó por su creación".
¿Qué hacer?
Cobertura de apuestas de código abierto
Muchas empresas han buscado hacer sus vidas de código abierto más fáciles mediante la compra de servicios administrados. Es una gran solución a corto plazo, pero no resuelve el problema a largo plazo de la sostenibilidad. No, los hiperescaladores de la nube no son mineros al descubierto, que se aprovechan de manera nefasta del código de desarrolladores desprevenidos. Pero con demasiada frecuencia , algunos equipos no planean contribuir a los proyectos de los que dependen. Hago hincapié en algunos , ya que esto tiende a no ser un problema de toda la corporación, sin importar el proveedor. He detallado esto anteriormente. De todos modos, las empresas que ofrecen estos servicios gestionados tienden a no tener ningún control sobre las hojas de ruta de los proyectos. Eso no es bueno para las empresas que quieren controlar el riesgo. Google es una excepción notable: tiende a contribuir mucho a proyectos clave.
Tampoco pueden necesariamente contribuir directamente a los proyectos. Como indica Mugrage, para empresas como Netflix o Facebook (Meta) que abren grandes proyectos de código abierto, estos "lanzamientos de código abierto son casi una cuestión de marca del empleador, una forma de mostrar sus habilidades de ingeniería a los empleados potenciales", lo que significa "tú". Es probable que tenga muy poca influencia sobre los desarrollos futuros”. Realmente no necesitan sus contribuciones.
¿Qué pasa con los proyectos mantenidos por aficionados? “Una vez que comienza a buscar partes cruciales de su pila de software en las que depende de los aficionados, sus opciones comienzan a disminuir”. ¿Por qué? Debido a que es poco probable que tenga el tiempo o los recursos para contribuir con el código, es posible que no quieran su dinero en efectivo, y hay proyectos importantes (como Log4J) en los que necesita confiar en sus proyectos, independientemente. En este caso, sugiere Mugrage, el simple hecho de ser consciente del riesgo a través de una auditoría del software del que depende puede ser útil.
Nada de esto debe tomarse como una indicación de que confiar en el código abierto es imprudente. El código abierto es inevitable y es increíblemente bueno. Más bien, el consejo de Mugrage parece sabio: sea consciente y reflexivo sobre el código abierto que utiliza, y planifique en consecuencia. Al igual que con los servicios en la nube, a veces la estrategia absolutamente correcta para su empresa es estar "atado" a ciertos servicios o software. La clave es hacer esta elección con los ojos bien abiertos.
Fuente: infoworld | somoslibres
