Magento solía operar como la mayoría de las demás empresas de código abierto: Código abierto, desarrollo cerrado. Hace dos años eso cambió. Esto es lo que pasó.
Video: Las diferencias clave entre 3 licencias de código abierto comunesNo todas las licencias de código abierto son iguales. El colaborador de ConsejoTecnologico.com Matt Asay explica las diferencias entre cada licencia y cómo elegir la solución adecuada para su empresa.
La teoría del código abierto es el desarrollo impulsado por la comunidad. La realidad, sin embargo, suele ser diferente. La mayoría de los proyectos de código abierto en realidad atraen a muy poca comunidad. Así como un proyecto como Linux o Kubernetes atrae la participación profunda de los desarrolladores, la mayoría de los proyectos de código abierto se esfuerzan en la oscuridad, la labor de amor de un solo desarrollador. Para los proyectos comerciales de código abierto que ven contribuciones significativas, como MongoDB o JBoss de Red Hat, prácticamente todas esas contribuciones provienen de desarrolladores en la nómina de una sola compañía.
Por eso Magento es tan profundamente interesante.
Magento, a diferencia de cualquier otro proyecto que he visto en mis 20 años con código abierto, ve que el 50% de su código proviene de desarrolladores que no están en la nómina de Magento. Y lo que es más intrigante, hace tan sólo dos años, el código de Magento fue escrito casi exclusivamente por la propia empresa. Me senté con Max Yekaterynenko, director de ingeniería comunitaria de Magento, y Ramadass Prabhakar, vicepresidente de tecnología de Magento, para entender qué cambió y cómo funciona esta comunidad única.
De los problemas de Jira a las solicitudes pull
Antes de comenzar, es importante notar que mi empleador, Adobe, recientemente completó la compra de Magento. Dados mis casi 20 años de experiencia con el código abierto, estaba encantado de que compráramos una empresa de código abierto. Sin embargo, no fue hasta que me senté con el equipo de la comunidad de Magento que empecé a entender cómo funciona el modelo de código abierto de Magento. Mi interés en Magento, entonces, tiene poco que ver con la compra y todo lo que tiene que ver con la forma en que construye la comunidad.
No es que siempre haya sido así.
VER: Cuadro comparativo de distribuciones de Linux (Tech Pro Research)
Hace dos años, Magento operaba como cualquier otra empresa de código abierto: Principalmente código abierto (un modelo típico de Open Core con un núcleo de código abierto más bits propietarios en una empresa creada para fomentar el pago), y en su mayoría desarrollo cerrado. La comunidad de Magento estaba compuesta en gran parte por integradores de sistemas y socios tecnológicos que construyeron sus negocios alrededor de Magento. Sin embargo, cuando se trataba de influir en el código, los socios en su mayoría sólo registraban los problemas de Jira cuando encontraban un error, y luego esperaban (a menudo en vano) que Magento se ocupara de solucionarlos.
Este proceso debe sonar familiar a cualquier empresa, ya sea propietaria o de código abierto. El genio de Magento fue darse cuenta de que su comunidad de SI, en particular, pasaba mucho tiempo haciendo que Magento funcionara en la producción del mundo real, y podía convertir esa experiencia en un mejor código.
Así que Magento le pidió a su comunidad que dejara de archivar asuntos de Jira y que en su lugar enviara solicitudes de pull.
En conjunto, Magento creó el equipo de Ingeniería de la Comunidad con el objetivo básico de escuchar y revisar las solicitudes de pull. Hoy en día se acepta una gran mayoría de las solicitudes de pull, pero el índice inicial de aceptación fue menor. Con el tiempo, esta iniciativa, que comenzó como un ejercicio de «dejar que la comunidad sea escuchada», evolucionó hasta convertirse en «wow, gran parte de la innovación en Magento está siendo impulsada por nuestra comunidad».
Diferentes tipos de innovación desde diferentes lugares
Más información sobre el código abierto
Magento se comunica con su comunidad a través de una videollamada mensual para destacar en qué están trabajando los ingenieros de la empresa, familiarizando así a los desarrolladores externos con el plan de trabajo de la empresa. Mientras que la comunidad de Magento inicialmente se dedicó a aplastar bichos, con el tiempo la naturaleza de sus contribuciones de ingeniería ha cambiado.
El equipo interno de ingeniería de Magento se centra ahora en grandes proyectos a largo plazo, así como en la calidad/estabilidad. Magento Engineering también construye herramientas que tanto la comunidad como los equipos internos pueden utilizar para maximizar la productividad.
La comunidad maneja muchas de las otras innovaciones (incrementales y de otro tipo), con una gran cantidad de nuevas características que se originan en la comunidad. A través de esta asociación de ingeniería interna y externa, la producción total de código de Magento ha aumentado.
VER GitHub: Una hoja de trampas (ConsejoTecnologico.com)
Sorprendentemente para un tipo de código abierto como yo, los socios de Magento contribuyen al código propietario de la compañía, no sólo al código abierto. Pregunté por qué cualquier socio contribuiría a un producto propietario que ellos (o sus clientes) todavía tendrían que pagar. La respuesta fue que hacerlo facilita el mantenimiento. También les ayuda a impulsar los negocios porque pueden diferenciarse si su código está en la oferta comercial. Al igual que Red Hat posiciona sus contribuciones a Linux o Kubernetes, los colaboradores activos de Magento también se posicionan para poder apoyar mejor a sus clientes si tienen influencia contributiva en la ingeniería.
Magento intenta seguir el mismo proceso para las contribuciones internas y externas. Realmente no les importa de dónde viene el código. El objetivo es mejorar la calidad del código desde donde quiera que empiece, y la aprobación no depende de la insignia de empleado que alguien pueda o no llevar.
Este enfoque no ha estado exento de fricciones, tanto internas como de otro tipo. Pero con el tiempo, los ingenieros internos y externos se han ido sintiendo cada vez más cómodos con el enfoque, me dicen Yekaterynenko y Prabhakar. Es diferente a todo lo que he visto en mis años en el código abierto, y podría ser un modelo para que otras compañías lo adopten, ya sea de código abierto o propietario.
Boletín Semanal de Código Abierto
No se pierda nuestros consejos, tutoriales y comentarios sobre el sistema operativo Linux y las aplicaciones de código abierto. Entregado los martes