Hace unos días , el artículo de @Xuanwo [1] " La operación de código abierto es cuando la historia no importa" [2] discutía que el plan de exterminio del código de TEngine [3] no respetaba la ley de colaboración de código abierto, pero solo eliminó por la fuerza el código abierto a través de operaciones de mercado.Errores cometidos por los desarrolladores.
Este artículo comienza con este ejemplo y analiza más a fondo qué tipo de contribuciones de código necesita la comunidad de código abierto.
Las contribuciones del código deben rechazar el formalismo.
El mayor problema de esta actividad de TEngine es que viola el sentido común del desarrollo de software.
1. Problemas que pueden resolverse completamente a través de linter, pero en lugar de "criar piratas y autoestima" para generar constantemente problemas de estilo en la rama principal para "esperar a ser resueltos".2. Para problemas que se pueden resolver a voluntad, como corregir errores tipográficos, etc., en su lugar, cree problemas o incluso realice actividades para encontrar miembros "externos" para hacerlo.
Me he aferrado a esta opinión en varias ocasiones de que el propósito de la sinergia de código abierto es producir software de alta calidad. Sin mencionar la libertad de software que brinda el código fuente abierto, operamos una comunidad de desarrolladores para crear conjuntamente software que resuelva problemas prácticos, cruzar los límites de diferentes empresas, organizaciones y nacionalidades, y colaborar con desarrolladores en toda la industria.
El enfoque de TEngine es el opuesto, y el propósito es obviamente señalar la cantidad de problemas y colaboradores, en lugar de un mejor software. El software de código abierto no mejorará automáticamente porque participe más gente, y los problemas que se crean en busca de la cantidad incluso reducen la eficiencia del desarrollo.
El Arte de la Operación Comunitaria [4] menciona repetidamente que siempre se debe evitar el formalismo. El formalismo no solo hace que la comunidad funcione de manera ineficiente, sino que también frustra a los miembros que se concentran en resolver problemas y tratan de involucrarse, porque no pueden manejar el problema de manera óptima o no pueden hacer nada mientras observan cómo la comunidad se agota inútilmente.
También es el problema de tratar con Linter, y el enfoque de TiDB es mucho más normal.
Haz que algunos linters sean realmente felices [5] Este problema primero presenta la herramienta golangci-lint y luego la divide en diferentes subtareas debido a la gran carga de trabajo, y da la bienvenida a otros participantes para que la completen juntos.
Sin embargo, TiDB también tiene problemas con el formalismo. En lugar de coordinar los flujos de trabajo de desarrollo para que parezcan "abiertos", los planes de trabajo trimestrales se publican una vez y luego se ignoran. Tal operación no tiene sentido.
Por ejemplo, Convocatoria de participación: Plan SIG-Planner 2020/Q1 [6] Este problema de hace dos años aún no se ha resuelto, y no sé si los subproblemas están resueltos o no.
Entre los 2.400 números abiertos de TiDB, bastantes fueron creados por varios movimientos "abiertos", y luego quedaron huérfanos. Este intento de activar los medios de contribución del código ha quedado inconcluso una y otra vez, y finalmente agotó la paciencia de todos los participantes.
Las contribuciones del código deben originarse en las necesidades reales
El software siempre es definido por sus usuarios. Las funciones y optimizaciones realizadas a puerta cerrada pueden separarse fácilmente de la realidad y flotar en el cielo. Al desarrollar software de código abierto, es importante explicar cómo se utiliza el software. Debido a que el software en sí está diseñado para resolver el problema, si la optimización y la función no pueden resolver el problema mejor, o incluso si no saben cuál es el problema, se convertirá en un castillo en el aire, llamativo. Además de evitar el formalismo, las contribuciones del código también deben derivarse de las necesidades reales.
Por ejemplo, Apache BookKeeper propone e implementa la gestión de metadatos basada en etcd porque etcd se usa mucho y, en un entorno de implementación en la nube, es probable que haya un servicio de etcd listo. La integración de etcd puede servir para tales escenarios de usuarios y puede reducir la sobrecarga de implementar un clúster adicional de ZooKeeper.
Por ejemplo, Apache ZooKeeper discutió si los relojes no pueden ver todos los eventos, pero si es necesario mejorar la semántica de un solo disparador. Ted Dunning dio una respuesta muy clásica.
Si quieres ver todos los eventos, usa Kafka. [7]
Esta respuesta también fue respaldada por el autor del proyecto, Patrick Hunt. Cada software tiene su propio posicionamiento para resolver el problema para el que está diseñado. Los usuarios nunca pueden resolver todos los problemas en un solo software. La combinación adecuada de diferentes software para formar soluciones es el trabajo de los ingenieros de aplicaciones. Para la comunidad de código abierto, esto también significa que no siempre puede esperar resolver todos los problemas, sino que debe crear bloques de construcción básicos componibles y unir fuerzas activamente con otras comunidades. Si intenta resolver todos los problemas, a menudo resulta que no todos los problemas se resuelven bien.
Para un requisito para una nueva característica, los antecedentes y la motivación, quién y por qué, por lo general, deben discutirse primero, y preferiblemente con los usuarios reales, como el propio proponente. El modo de aplicación FLIP-85 Flink [8] en el que participé, el diseño y la implementación se basó en las necesidades reales de implementación, operación y mantenimiento del trabajo de Flink en varias empresas en ese momento. Después de implementar la función, se puede probar y poner en producción inmediatamente.
Para la reparación de defectos, en primer lugar, se debe reproducir el problema y, después de confirmar que el problema es válido, ubicar el problema y luego repararlo. Si el problema no funciona, no es necesario enviar código para solucionarlo. Por ejemplo, no se puede reproducir, el diseño es así o el método de uso es incorrecto, simplemente responda al problema y ciérrelo. Si se trata de un problema efectivo y serio, por lo general será resuelto directamente por los miembros principales. Casos como Log4Shell [9] y SpringShell [10] son imposibles de publicar y esperar a que lleguen nuevos desarrolladores y los resuelvan.
Incluso si el problema no es grave, por lo general, el procesador del módulo correspondiente puede resolverlo por sí mismo. Para problemas que no son difíciles, si hay muchos miembros activos en la comunidad y hay nuevos miembros que necesitan ejercitarse, pueden ser empujados al grupo correspondiente para que los inviten a resolver. Por supuesto, dado que es un problema real de corrección de errores, no bloqueará la espera de otros. Una vez que tenga tiempo, o se acerque la fecha de lanzamiento, lo hará usted mismo. Si alguien más intenta arreglarlo pero no lo hace, también debe ser amable y hacerse cargo.
Si un error de software identificado no se aborda de manera proactiva y no persisten problemas similares, es posible que el problema no sea un problema real. Wu Sheng, el fundador de SkyWalking, mencionó en Twitter que "Nosotros en SkyWalking creemos que las características que nadie contribuye son características inútiles". Del mismo modo, un problema que nadie soluciona es probable que sea un problema que no necesita ser solucionado.
Para la refactorización, lo primero que hay que preguntar es la necesidad. Siempre hay más de una forma de escribir código, y la conversión de sinónimos no tiene un significado directo para el desarrollo de los valores fundamentales del software.
Un tipo de refactorización significativa es la refactorización de módulos dirigida por expertos. De hecho, cualquier desarrollador tendrá en mente un modelo cognitivo al desarrollar un software. Diferentes personas tienen diferentes modelos cognitivos. En un software desarrollado por varias personas, no es raro que una persona se sienta incómoda leyendo otra pieza de código, por lo que no puede desarrollar nuevas funciones o corregir errores. Esta es también la razón por la cual, después del traspaso de los desarrolladores de software, los sucesores a menudo refactorizan primero el código original. Solo en línea con el modelo cognitivo de los desarrolladores principales, se puede mejorar la eficiencia del desarrollo de software. Por otro lado, si el autor del parche que envía la refactorización no necesita estar profundamente involucrado en el desarrollo del módulo, entonces es difícil que la razón de la refactorización sea independiente, porque la persona que realmente está desarrollando el código probablemente a disgusto tal refactorización. Esta es en realidad una prueba de la comunidad de código abierto Gana autoridad por contribución.
Otra refactorización significativa es aquella que resuelve un problema real. Por ejemplo , el principal punto de partida de la refactorización del marco de prueba en el problema de seguimiento para las pruebas de reestructuración [11] que inicié en TiDB es que el marco de prueba actual no se puede integrar con GoLand [12] , y el costo de ejecutar pruebas localmente es demasiado alto, lo que hace que los desarrolladores tiendan a no escribir Testing o escribir pruebas simples, y el software que carece de cobertura de prueba, es difícil fusionar con confianza los cambios de código, porque nadie puede decir si solo los parches compilados presentarán problemas adicionales.
Durante el desarrollo de software de código abierto, la migración de un marco a otro a menudo puede generar mucho trabajo. Por ejemplo, cuando se cambió el motor de ejecución de TiDB al framework de ejecución basado en Chunk, se crearon decenas de nuevos participantes.
• Serie Conviértase en colaborador en diez minutos | Ayudando a que el rendimiento informático de expresión de TiDB mejore 10 veces [13]• Diez minutos para convertirse en colaborador de la serie | Segunda viñeta de actividad de expresión vectorizada de TiDB [14]
Del mismo modo, la migración del marco de prueba de pingcap/check a testificar ha generado docenas de nuevos desarrolladores. Algunos de ellos ingresaron a la comunidad TiDB desde aquí y se convirtieron en la plataforma TiDB; algunos regresaron a la comunidad TiDB y encontraron sus intereses nuevamente.
De hecho, tales actividades pueden no tener una buena "tasa de retención". Pero, ¿por qué la comunidad de desarrolladores debería buscar la retención? Lo que he concluido en el proceso de participación en el desarrollo de múltiples software de código abierto es que si estoy muy satisfecho con el software y no encuentro ningún problema que deba resolverse, entonces no tendré que crear requisitos deliberadamente para resolver los requisitos. Mantener una comunidad de código abierto requiere la inversión a largo plazo de los miembros principales y los desarrolladores senior, es decir, la retención, pero alguien que pueda resolver un problema específico para el software, incluso si solo resuelve este problema, nunca volverá a aparecer. ¿estar perdido?
Por ejemplo, Gyula Fora [15] , el autor principal de la API Apache Flink DataStream , casi desapareció durante seis años después de completar este trabajo en 2014-2015. Después de ser contratado recientemente por Apple, el desarrollo intensivo del Operador Flink Kubernetes [16] comenzó de nuevo, impulsado por nuevas demandas e influencia en el campo del código abierto . Las contribuciones de código que hizo provenían de sus propias necesidades y también satisfacían las necesidades de los usuarios de la comunidad de Flink. Las contribuciones de código enviadas por tales razones pueden evitar el formalismo y los malentendidos de hacer las cosas, enfrentar las necesidades y resolverlas.
Los participantes en la comunidad de código abierto van y vienen. Como mantenedor del proyecto, durante el mantenimiento del proyecto, solo necesita asegurarse de que el proyecto avance como un todo, y no necesita preocuparse demasiado por el por qué un determinado persona vino y por qué se fue. Además, el desarrollo de software nunca cree en el mito del hombre y el mes, no es que cuanta más gente haya, mejor se puede desarrollar el software. Dicho de otro modo, incluso en los proyectos de nivel superior de Apache Software Foundation, solo hay 6 proyectos con más de 100 Committers [17] . Para la comunidad de código abierto que afirma tener cientos y miles de desarrolladores ahora, la proporción de miembros principales es extremadamente baja, ¿no es normal?
Cuando inicio o participo en tal actividad, solo presto atención a si la tarea de desarrollo vinculada a la actividad se resuelve de manera eficiente en la forma de la actividad. En cuanto a si los participantes pueden encontrar intereses comunes con la comunidad después del evento y permanecer y crecer juntos, al menos no es una tarea que el evento en sí pueda lograr.
Sin embargo, las actividades basadas en necesidades reales tienen el potencial de introducir sangre nueva a la comunidad de código abierto debido a la experiencia de resolver problemas con los participantes.
@Xuanwo participó en la comunidad TiKV del evento CNCF Community Bridge. Implementó el empuje hacia abajo de múltiples operadores como Enum para TiKV, y aún presta atención a la comunidad TiKV.
Uno de los principales desarrolladores del motor de almacenamiento de la base de datos de flujo RisingWave de código abierto recientemente, @skyzh, también participó en la comunidad TiKV a través de CNCF Community Bridge. Desarrolló principalmente AgateDB, un motor de almacenamiento basado en LSM Tree, en TiKV, aunque este proyecto TiKV no continuó, continuó su espíritu en el motor de almacenamiento de RisingWave. La serie recientemente lanzada de @skyzh sobre Type Gymnastics con Rust [18] , creo que también está relacionada con el diseño de expresiones RPN para el coprocesador TiKV.
Apache SkyWalking atrajo la participación de @fgksgf [19] a través de las actividades de GSoC y se convirtió con éxito en miembro de Apache SkyWalking Committers después de completar el trabajo relacionado. Su poderosa capacidad para transportar mercancías trajo Apache SkyWalking Eyes al proyecto TiDB, y fue por esta razón que me enteré de este proyecto y promoví aún más la experiencia de alta calidad de Apache SkyWalking Eyes al verificar automáticamente el encabezado de licencia. Muy feliz de verlo liderar el lanzamiento de Apache SkyWalking CLI 0.10.0 [20] recientemente .
De hecho, este artículo no necesita explicar una simple verdad: el propósito de la colaboración de código abierto es producir software de alta calidad . Las contribuciones de código generadas para este propósito son las contribuciones de código que necesita la comunidad de código abierto. Permitir que los miembros de la comunidad sientan que están participando en la creación de un gran software es la única forma de mantener el atractivo de la comunidad.
Referencias
[1] @Xuanwo: https://github.com/Xuanwo[2] "La operación de código abierto debería ser una historia sin corazón": https://xuanwo.io/reports/2022-13/[3] Plan de control de plagas del código TEngine: http://web. archive.org/web/20220403062947/https://mp.weixin.qq.com/s/mssWF5AoUG-vt-b5_QMtRA[4] El arte de la operación comunitaria: https://book.douban.com/subject/26976995/[5] Haz algunos linters realmente feliz: https://github.com/pingcap/tidb/issues/22979[6] Convocatoria de participación: Plan SIG-Planner 2020/Q1: https://github.com/pingcap/tidb/issues/14609[7] Si desea ver todos los eventos, use Kafka.: https://lists.apache.org/thread/fz9bkndvbntfjwxm952clh9vky3nwyd5[8] FLIP-85 Modo de aplicación Flink: https://cwiki.apache.org/confluence/display/FLINK/FLIP-85+Flink+Application+ Modo[9] Log4Shell: https://en.wikipedia.org/wiki/Log4Shell[10] SpringShell: https://www.microsoft.com/security/blog/2022/04/04/springshell-rce-vulnerability-guidance-for-protecting-against -and-detecting-cve-2022-22965/ Problema de[11] seguimiento para pruebas de reestructuración: https://github.com/pingcap/tidb/issues/26022[12] El marco de prueba no se integra con GoLand: https://internals.tidb.io/ t /topic/141[13] Conviértase en colaborador de la serie en diez minutos | Ayudando a TiDB Expression Computing Performance a mejorar 10 veces: https://pingcap.com/zh/blog/10mins-become-contributor-of-tidb-20190916[14] Conviértase en colaborador de la serie en Diez minutos | TiDB La segunda ronda de actividad de expresión vectorizada: https://pingcap.com/zh/blog/10mins-become-tidb-contributor-20190930[15] Gyula Fora: https://github.com/gyfora[16] Operador de Flink Kubernetes: https://github.com/apache/flink-kubernetes-operator[17] Committer 6 proyectos con más de 100 committers: https://projects.apache.org/projects.html?number[18] Escriba gimnasia con Rust: https: //github. com/skyzh/type-exercise-in-rust[19] @fgksgf: https://github.com/fgksgf[20] lidera el lanzamiento de Apache SkyWalking CLI 0.10.0: https://lists.apache.org/thread/lf1nvnw5ks97f8s47m2dgttssb7nq6rz