Con la inversión y la atención de los últimos años, las comunidades nacionales de código abierto han brotado como hongos después de la lluvia. Hoy, las nuevas fuerzas de IA encabezadas por GPT han tomado el relevo de la actualidad. Podemos revisar los logros de las comunidades de código abierto nacionales que han surgido en los últimos años en el ciclo de enfriamiento y qué problemas comunes se pueden mejorar. .
El título de este artículo es que el funcionamiento de las comunidades nacionales de código abierto siempre tiene un estilo de pintura peculiar, que también está en línea con los sentimientos principales de los desarrolladores de software que son los principales participantes en las comunidades teóricas de código abierto en los últimos años. Desde el deslumbrante marketing de código abierto, hasta las innovaciones alternativas de código abierto de una sola vez y código abierto conmutable, hasta la involución y lucha del código abierto homogéneo... Todo esto no solo es muy diferente del movimiento de código abierto impulsado por el espíritu hacker que los desarrolladores están familiarizados con Es difícil decir que la política de código abierto ha logrado el objetivo de la innovación tecnológica digital.
Apoyar el desarrollo de consorcios de innovación, como comunidades de código abierto de tecnología digital, mejorar la propiedad intelectual y los sistemas legales de código abierto, y alentar a las empresas a abrir códigos fuente de software, diseños de hardware y servicios de aplicaciones.
"El Decimocuarto Plan Quinquenal para el Desarrollo Nacional Económico y Social de la República Popular China y Esquema de Metas a Largo Plazo para 2035"
Desde la perspectiva de la construcción y operación de la comunidad de código abierto, creo que las razones principales de esta situación se dividen en tres aspectos: el problema del personal operativo, el problema de los desarrolladores del equipo central y el problema fundamental de la solidez del producto de software.
Los problemas de los operadores provienen principalmente del uso de pensamiento de marketing de novatos orientado al consumidor (2C, al cliente) para hacer operaciones comunitarias de código abierto orientadas al desarrollador (2D, al desarrollador).
Debe decirse que los objetos de operación de 2C a 2D son todos para individuos y pueden considerarse como alguna forma de operación de usuario: los consumidores son usuarios de plataformas o productos finales, y los desarrolladores de código abierto son principalmente usuarios de software de código abierto. En términos de estrategias de operación de usuarios de alto nivel, ambos deben clasificar los retratos de los grupos de usuarios, comprender las necesidades y utilizar los recursos para brindar a los usuarios comentarios oportunos, de modo que los usuarios puedan pasar más tiempo en su comunidad y crear el valor que espera. .
Sin embargo, los productos de consumo que impulsan las operaciones 2C suelen tener un ciclo de ventas corto y un umbral bajo, lo que lleva a que la estrategia óptima para las operaciones 2C sea el marketing para principiantes, es decir, tratar a los usuarios como principiantes, solo en términos de región, edad, Distinguir entre atributos como género y ocupación, utilizan actividades de feedback rápido para estimular los deseos inmediatos de los usuarios, ganar el tráfico que requiere la plataforma o vender productos, es decir, consumo impulsivo.
Un ejemplo típico es el push marketing local en el que se intercambian pequeños obsequios por atención en la calle. Por ejemplo, se construyó un nuevo supermercado de entrega en una zona residencial. Al contratar a un grupo de repartidores sin ningún requisito previo, pueden distribuir folletos en lugares con mucho tráfico, seguir la cuenta oficial del supermercado o descargar una aplicación para recibir unos pocos yuanes en Vales o pequeños centros comerciales.Regalo. Básicamente, no hay necesidad de distinguir el grupo objetivo, las personas que pueden caminar en la calle son usuarios potenciales del supermercado.
¿Te resulta un poco familiar este estilo de pintura?
Cuando el concepto de operación de código abierto estaba de moda, muchas empresas reclutaron operadores para sus propias comunidades de código abierto para operar a los usuarios de la misma manera.
OceanBase da me gusta y da regalos
Programa de control de plagas de TEngine
Ambos ejemplos despertaron una fuerte aversión por parte de los desarrolladores.
¿Cómo evaluar Ali OceanBase GitHub como regalo? [1]
Antipatrón de la experiencia del desarrollador: operaciones impulsadas por el mercado [2]
Las operaciones de código abierto deben discutirse independientemente del historial [3]
Los desarrolladores no están felices de ver tales actividades, no porque no puedan dar pequeños obsequios, ni por el "pecado original" de las operaciones, sino porque estas actividades que utilizan recursos corporativos para llamar la atención de los desarrolladores violan el sentido común del desarrollo de software.
En el caso de los obsequios "me gusta" de OceanBase, algunos desarrolladores utilizan las estrellas en la plataforma GitHub como un indicador auxiliar para seleccionar bibliotecas de software de código abierto, porque el crecimiento natural de las estrellas proviene básicamente de los elogios activos y la difusión secundaria de los usuarios. Star no es un indicador clave para que los desarrolladores adopten un software. El software ha sido verificado por ellos mismos o por otros, y un plan de uso reproducible es la ventaja decisiva. estrella significa que los usuarios lo elogian activamente y es una referencia poco relevante de que el software ha sido verificado. Las actividades de entrega de obsequios "Me gusta" de OceanBase no tendrán un impacto a gran escala, pero solo destruirán el valor original de su propio conteo de estrellas.
En cuanto a interpretar cualquier forma de crecimiento de estrellas como el crecimiento del tamaño de la comunidad, es una tontería. El comportamiento detrás de la estrella es solo una simple acción de clic sin ningún umbral. Una persona que ha recibido un volante de supermercado puede convertirse en consumidor de supermercado sin ningún tipo de formación. Pero una persona que se une a la diversión para dar "me gusta" al almacén de códigos no tiene motivos para seguir participando. De hecho, por razones bien conocidas y las características de nicho inherentes al desarrollo de software, incluso si depende del objetivo de aumentar las estrellas, dichas actividades promocionales no traerán más de 1k nuevas estrellas a OceanBase. Además, con los antecedentes de la gran fábrica, la fuerza técnica y la práctica de producción de OceanBase, es básicamente innecesario y poco probable lograr el objetivo de aumentar la conciencia aumentando deliberadamente las estrellas.
Para el plan de control de plagas de TEngine, este problema es un poco más sutil. Porque parece estar relacionado con la escritura de código, y parece haber creado valor para el desarrollo de software libre ¿No vale la pena promover tal actividad? En ese momento, los operadores de OceanBase sintieron que podía promocionarse, y también se involucraron en una ola de regrabado:
Actividades homogéneas de OceanBase
Con respecto a estas actividades, los comentarios de @Xuanwo en "Las operaciones de código abierto deben discutirse independientemente de la mente" representan las opiniones principales de los desarrolladores de código abierto:
Necesitamos mirar el valor creado por el evento, no la motivación del organizador del evento.
¿Valen la pena las actividades de control de plagas? Sí, pero solo un poco. En comparación con el costo de los mantenedores que dedican tiempo a encontrar errores tipográficos, el valor de esta actividad puede ser negativo.
Los proyectos de GSoC y otras actividades son todas necesidades reales, y los proyectos deben estar equipados con un mentor, y los contribuyentes pueden obtener una guía completa del mentor. Al participar en el proyecto GSoC, los proyectos de código abierto pueden abordar algunas necesidades a largo plazo y los contribuyentes pueden obtener información sobre una comunidad de código abierto y hacer sus propias contribuciones.
Cuando participé en la comunidad de TiDB, también inicié un problema de seguimiento de trabajo de bajo umbral similar para reestructurar las pruebas[4] para migrar las pruebas existentes a un marco compatible con la integración de IDE. Después de haber completado algunas funciones clave de la herramienta y el desarrollo de la interfaz, la mayor parte del trabajo es una traducción relativamente mecánica.
La diferencia entre este problema y las actividades anteriores es que proviene de las necesidades reales y el método de desarrollo se ajusta al sentido común de la ingeniería de software. Cuando descubrí por primera vez que no podía ejecutarse en GoLand, sentí que la selección del marco de prueba debería optimizarse. Después de que @disksing migró con éxito el marco de prueba de PD de la verificación de la bifurcación PingCAP para testificar, y también en la comunidad TiDB, vi a dos o tres recién llegados que tenían la misma idea expresaron sus opiniones sobre la falta de integración IDE. Empecé a promover este trabajo.
La experiencia de rastrear múltiples subtareas en este problema se extendió más tarde a muchos otros proyectos y también inspiró otras contribuciones de código en el proceso de guiar a los participantes para desencantar el código TiDB. Sin embargo, dado que el umbral de desarrollo del código principal de TiDB aún no es bajo, al final recuerdo un ejemplo de no convertirme en un desarrollador principal de TiDB a través de este problema.
TiDB también ha realizado trabajos relacionados con linter, pero el método es usar herramientas automatizadas para escanear módulos uno por uno, en lugar de ver uno manualmente y escribir un problema como TEngine u OceanBase y esperar a que los desarrolladores "externos" lo arreglen. afecta el crecimiento digital.
Haz que algunos linters sean realmente felices [5]
Haga linter facter al permitir que bazel nogo implemente linter incremental rápido [6]
Para problemas de errores tipográficos, la comunidad de Rust tiene una herramienta de errores tipográficos [7] que los escanea, informa y corrige automáticamente. Se ha utilizado mucho en el grupo de proyectos de Databend y básicamente puede erradicar los problemas de errores tipográficos.
Además, existe otra diferencia entre las tareas mencionadas anteriormente y los ejemplos negativos enumerados anteriormente, es decir, los desarrolladores pueden reconocer que estas tareas son tareas domésticas, es decir, tareas domésticas. Además del valor de la discusión sobre la organización de problemas y la selección y el desarrollo del marco de herramientas, los desarrolladores rara vez comercializan tareas específicas y, en ejemplos negativos, el objeto del marketing son las tareas mismas. No es de extrañar que los desarrolladores estén tan poco impresionados por este tipo de marketing de priorización e inversión.
Debido a las limitaciones del texto, existen otros problemas y soluciones a estos problemas, este artículo no los ampliará, pero aquí hay una lista simple.
Para las operaciones orientadas a los desarrolladores, las prácticas de la industria en el extranjero son relativamente ricas, han creado conceptos y conceptos como la relación con el desarrollador (DevRel), la experiencia del desarrollador (DX) y la posición del evangelista de la comunidad.
El texto y los materiales de texto enriquecido a los que vale la pena referirse en este sentido son:
"El arte de la operación comunitaria" [8]
《Personas impulsadas》[9]
Canal de YouTube de Jono Bacon, autor de los dos libros anteriores [10]
"Relaciones con desarrolladores: métodos y prácticas" [11]
Experiencia de desarrollador en Vercel [12]
Entre ellos, "Relaciones con los desarrolladores" es el material de lectura preferido que está más en línea con los antecedentes de los operadores. Discutirá los retratos, los segmentos y los viajes de los grupos de usuarios de desarrolladores, así como también cómo formular e implementar con éxito estrategias de relación con los desarrolladores en empresas
A diferencia de los requisitos de contratación de un solo recipiente de las operaciones nacionales de código abierto, un equipo de comunidad de código abierto bien dividido se compone aproximadamente de los siguientes tipos de funciones:
El gerente del equipo comunitario formula estrategias comunitarias y objetivos de crecimiento.
Los especialistas en operaciones planifican y organizan eventos o juegos y son responsables de la coordinación del lugar y el material.
Los expertos en contenido formulan estrategias de contenido y las implementan sobre la base de las estrategias de la comunidad.
Los expertos de DevRel son responsables de las presentaciones técnicas, registran la evolución de la participación y los comentarios, dan seguimiento a los desarrolladores de alto potencial y aprovechan a los líderes de opinión.
Además, si aún puede encontrar los talentos correspondientes, considerará desarrollar cursos y hacer un seguimiento de los escenarios de los usuarios para transformar posibles oportunidades comerciales.
Vale la pena mencionar que los expertos en contenido formulan estrategias de contenido, y producir y difundir contenido técnico específico es un trabajo muy desafiante. Puede consultar el diseño e implementación del sitio web "Cultivo y desarrollo de ingenieros de documentación técnica en inglés" por el ingeniero de documentación de StreamNative Sherlock .
Finalmente, la experiencia de operar comunidades nacionales de código abierto tiene los siguientes materiales de referencia:
Intercambio de experiencias de operaciones comunitarias de código abierto
"De Tres a Diez Mil", el Camino al Crecimiento Rápido de Usuarios 2B"
Vale la pena señalar que los profesionales que operan comunidades de código abierto entre empresas que venden productos de software o brindan servicios técnicos pueden difuminar fácilmente la diferencia entre 2B (para empresas) y 2D. Vale la pena consultar estos artículos sobre cómo tratar con los desarrolladores de usuarios y cómo producir contenido de alta calidad Para comprender 2B y 2D, se recomienda agregar el Capítulo 8 de "Relaciones con los desarrolladores" para comparar y comprender.
La llamada comunidad de código abierto es una comunidad formada en torno a un software de código abierto específico. El software no es estático, sino iterativo en respuesta a los requisitos. Los miembros que lideran y completan este proceso iterativo son los desarrolladores. Por lo tanto, los desarrolladores son los principales participantes en la comunidad de código abierto y la productividad principal.
Las comunidades nacionales de código abierto iniciadas por las empresas y los problemas de deformación operativa causados por los desarrolladores son causados casi en su totalidad por la falta de una estrategia de código abierto y la respuesta de estrés de verse obligado a abrir el código repentinamente bajo la guía de la teoría.
Muchas empresas deciden abrir un determinado sistema interno, pero en realidad es solo un comportamiento de seguimiento, sin una estrategia o experiencia de código abierto: el código fuente abierto es un fin en sí mismo.
En este momento, como personal de investigación y desarrollo de primera línea o supervisor de investigación y desarrollo de base que trabaja en este sistema, de repente me dijeron que el almacén de códigos con el que trato todos los días y envío cambios será de código abierto. La estrategia de autoprotección subconsciente es abierta. Solo código fuente: el código fuente abierto es ¿El código fuente se publica públicamente bajo una licencia de código abierto? Presiona Publicar... ¡bien hecho! En cuanto a los planes de I+D y los procesos de desarrollo, ¿qué tiene que ver esto con el código abierto? ¿No lo abrí ya? Esto se puede hacer como de costumbre.
Por lo tanto, lo que la empresa de código abierto es una imagen de almacén de código del sistema interno. Esto es realmente comprensible. Después de todo, siempre que el código fuente esté completo, abrirlo para que todos lo lean es una contribución social. No se dice que las empresas deban divulgar completamente el proceso de desarrollo de software y el contenido de las discusiones de diseño.
Sin embargo, el efecto esperado por las empresas e incluso por los tomadores de decisiones en sus corazones no es simplemente código fuente abierto, lo que quieren es "co-construcción". Aunque ya critiqué la ambigüedad y el capricho de esta afirmación en "El mito de la co-construcción", por el momento, tomémoslo literalmente y entendamos los requisitos para realizar la "co-construcción" de una manera colaborativa común en código abierto. comunidades _
Desde el principio, verá que los flujos de trabajo compartidos son imprescindibles. Si no hay un proceso de desarrollo unificado, al menos el proceso principal, incluso los desarrolladores senior no podrán participar más sin la información necesaria y las discusiones suficientes. Mencioné este punto de vista al comienzo de "Cómo las empresas practican la colaboración de código abierto" , y lo discutí en detalle con los cuatro proyectos OceanBase, Apache InLong, TiDB y Taichi como casos.
La mayor ventaja que la comunidad de código abierto puede aportar a la empresa proviene de los desarrolladores con ciertas capacidades y experiencia de desarrollo.Basado en la premisa de acceder al código fuente, los requisitos no realizados, los problemas de compatibilidad y la facilidad de uso que encuentra el software en aplicaciones específicas. Escenarios Realice una personalización en el lugar para los problemas sexuales y luego retroalimente estas personalizaciones al upstream, de modo que no necesite repetir el desarrollo secundario cuando use la nueva versión del software upstream. Si es un problema que no se puede personalizar y resolver en el acto, el desarrollador puede realizar una depuración básica e informar un problema más claro debido al acceso al código fuente. Basados en el mismo código fuente y flujo de trabajo de desarrollo unificado, los desarrolladores de diferentes organizaciones pueden comunicarse en el mismo contexto y promover conjuntamente la resolución de problemas.
Para una comunidad de código abierto iniciada por una empresa, los desarrolladores iniciales deben ser empleados de la empresa. Si los empleados de la empresa no toman la iniciativa en la implementación de este enfoque de flujo de trabajo abierto, es aún menos probable que los desarrolladores externos a la empresa empujen a la comunidad en esta dirección. Al final, la comunidad sigue siendo una plataforma sin vida con solo códigos espejo, sin vitalidad.
Uno de los indicadores más básicos para medir si el upstream de una comunidad de código abierto tiene un flujo de trabajo abierto es observar si tiene una buena experiencia de configuración del entorno de desarrollo [13] . Debido a toda la colaboración de código abierto basada en el código fuente, al menos los desarrolladores deben poder crear su propio entorno de desarrollo, ejecutar casos de uso básicos y ejecutar pruebas unitarias. De lo contrario, cualquier cambio es edición de texto y depuración en el cerebro, lo cual no es imposible, pero el umbral es muy alto. Y es un umbral innecesario Incluso las personas con esta capacidad pueden ver que el flujo de trabajo no es razonable y no están dispuestos a perder este tiempo haciendo esfuerzos innecesarios.
Por último, profundicemos en por qué la estrategia de autoprotección de Open Source Code Only de este desarrollador rara vez aparece en la comunidad de proyectos de código abierto iniciada por individuos.
La razón directa es que los desarrolladores individuales a menudo no tienen la motivación y la energía para construir otro conjunto de flujos de trabajo Estos proyectos a menudo se construyen en el espacio público con una cadena de herramientas común desde el principio. No hay dos conjuntos de flujos de trabajo internos y externos, por lo que es naturalmente "código abierto durante todo el proceso".
La razón profunda es explorar por qué es más probable que los desarrolladores individuales acepten métodos de desarrollo colaborativo de código abierto, ya que los autores de proyectos a menudo atraen a los participantes mediante el desarrollo de software de alta calidad y una fuerte propiedad. Los autores de proyectos suelen estar agradecidos con los desarrolladores que pueden ayudarlos. Para los problemas y parches enviados por otros desarrolladores, dado que el diseño de la función central y la implementación del software se completan por sí mismos, generalmente el autor del proyecto puede hacer juicios precisos y tiene suficiente crédito para tomar decisiones, por lo que no se sentirá limitado por otros. durante el proceso de colaboración.
Por el contrario, la situación de la empresa de código abierto. El software que las empresas pueden seleccionar como código abierto es algo poderoso. Bajo el actual sistema de promoción de la secuencia de I+D, los primeros autores de estos softwares básicamente han sido promovidos, de lo contrario confiarán en este logro para cambiar trabajos con salarios altos: no participarán en la comunidad de código abierto del software. Los empleados que en realidad serán asignados para manejar el trabajo de la comunidad de código abierto a menudo no tienen suficiente crédito para tomar decisiones Al menos cuando la mayoría de los equipos de I + D no se preocupan en absoluto por la comunidad de código abierto, es difícil para ellos explicar por qué un requisito de colaboración de código abierto requiere que otros desarrolladores "internos" también sean conscientes y cooperen con las formas cambiantes de trabajar.
Por lo tanto, estos empleados asignados solo pueden manejar los asuntos más simples en términos de motivación y poder. Esto lleva a que los participantes "externos" de alto nivel experimenten procesos de colaboración ineficientes, lo que básicamente les impide completar cualquier trabajo; mientras que los desarrolladores "internos" no son enviados por el sistema de órdenes de trabajo para los requisitos "externos" que surgen de vez en cuando. para hacer frente al trabajo de la empresa, que es molesto.
Si algún día la empresa vuelve a recordar la historia de la "co-construcción" y comienza a darle al "equipo de código abierto" la demanda de aumentar el número de la comunidad, por un lado, los medios de bajo umbral en un período corto de tiempo son solo las tareas mencionadas en la sección anterior; por otro lado, No solo eso, las personas en el "equipo de código abierto" tienen que pedirles a los desarrolladores "externos" que participen para lograr su propio rendimiento. Este tipo de situación que desprecia el contenido aportado por otros y se ve obligado a arrodillarse y lamer el servicio, lo discutí en un artículo anterior "Dos sombreros de desarrolladores" .
Si el primer autor de un proyecto empresarial de código abierto todavía está en la comunidad, entonces las posibilidades de que aparezcan estos problemas son tan bajas como las de una comunidad de proyecto de código abierto iniciada por un individuo.
Por ejemplo, el proyecto Apache InLong mencionado anteriormente fue donado por Tencent. Zhang Guocheng, uno de los autores originales, todavía está muy involucrado en el desarrollo comunitario y la planificación de la dirección. Espera llevar el software que creó al entorno de producción de más usuarios a través del código fuente abierto y la influencia de ASF. Al mismo tiempo, también necesita mantener las instancias de uso de InLong dentro de Tencent. Basado en esta motivación, y debido a que él es el autor original del software, pudo unificar el proceso de lanzamiento de la versión interna y externa. El presidente de PMC, Charles, quien también apostó su carrera por el proyecto InLong, es el director del proyecto InLong dentro de Tencent. Impulsado por un fuerte sentido de la responsabilidad, puede promover activamente el concepto de diseño y los casos de uso de InLong en el mundo exterior, y desarrollar activamente los desarrolladores de la comunidad. Según mi observación del proyecto InLong, básicamente cada dos o tres meses, varios desarrolladores calificados son nominados para el equipo de Committer.
Por ejemplo, el proyecto OpenDAL que traje recientemente a la incubadora de ASF fue donado por DatafuseLabs. Por supuesto, puede pensar que su fuente es similar al proyecto personal de código abierto de @Xuanwo, pero de hecho es un proyecto establecido por DatafuseLabs. El negocio principal de @Xuanwo también incluye desarrollar y mantener el proyecto OpenDAL. @Xuanwo presentó el pasado y el presente de OpenDAL en BeyondStorage: por qué fallamos [14] . En su blog personal, también hay una serie de introducciones técnicas y uso compartido de operaciones de OpenDAL.
El punto clave aquí es que construir una comunidad de código abierto no es solo desarrollar código. Aunque un buen software es el núcleo, si la comunidad quiere construir y operar de manera autosuficiente, casi necesita el entusiasmo del espíritu empresarial. Para el primer autor, el software es su propio trabajo, y el éxito del software puede impulsar su propio éxito. Al mismo tiempo, también obtuvo la autoridad para indicar la dirección del desarrollo del software a partir del proceso de desarrollo del software original. fuera con la bendición. El surgimiento de TiDB es obviamente un ejemplo, y después de que el fundador desapareció de la comunidad central y fue reemplazado por un gerente profesional que no tenía ninguna relación con el proyecto como director técnico, el olor típico de código abierto de varias grandes empresas comenzó a surgir. aparecer.
Por supuesto, no significa que si no es el autor original, solo puede esperar pasivamente, pero es más difícil para el sucesor obtener una reputación similar a la del autor original a través del trabajo duro, y el sucesor a menudo tiene poca motivación. para hacer tal cosa. Recuerdo que hay casos bastante exitosos en los que se hace esto, se debe considerar que los ingenieros senior de Alibaba Group participaron y heredaron gradualmente el liderazgo de la comunidad Flink.
En cuanto a cómo los desarrolladores deberían participar en la comunidad de código abierto, cómo organizar y construir materiales relacionados en la comunidad de código abierto, el más recomendado es, naturalmente, "La Catedral y el Bazar" [15 ] . Entre ellos, el segundo "Cathedral and Bazaar" y el tercero "Cultivating the Mental Layer" discuten respectivamente las formas y ventajas de la colaboración de código abierto, así como la propiedad y la reputación del software de código abierto.
Además, Making Open Source Software [16] es un valioso material de referencia, la Guía de código abierto de GitHub [17] es un par de folletos concisos sobre el tema y Open Collaboration [18] es un interesante GitHub Un libro completo sobre el código abierto comunidad y sus patrones en la plataforma.
Cabe decir que los problemas de implementación del personal operativo provienen principalmente de la inmadurez de la industria y la experiencia no es ampliamente conocida. Con la exposición de muchos casos buenos y malos, creo que los operadores pueden encontrar rápidamente una nueva posición y establecer capacidades operativas para los desarrolladores. De hecho, hay señales de esto y han surgido algunos talentos pioneros.
Con respecto a la posición y los incentivos de los desarrolladores, una vez que una empresa se da cuenta de que el éxito de la comunidad de código abierto es básicamente el espíritu empresarial interno, entonces, si aún decide tomar la ruta del código abierto, ya no faltarán los recursos relevantes y la asignación de talento. Del lado del desarrollador, con la orientación y el intercambio de experiencias de comunidades exitosas de proyectos de código abierto, creo que con el espíritu pragmático de los desarrolladores, también puedo entender la metodología necesaria para construir una comunidad de código abierto. Por supuesto, desde el conocimiento hasta la implementación real, parece que todavía es un obstáculo difícil de cruzar.
Además, si la comunidad nacional de código abierto quiere desarrollar y obtener un amplio espacio operativo, el problema más difícil al final es cómo mejorar la potencia del producto del software de código abierto o la calidad del software de código abierto.
Wu Sheng, el autor de SkyWalking , mencionó en la entrevista que "el código abierto no tiene magia negra, la burbuja estallará en dos años" [19] :
El núcleo del código abierto es tener un pensamiento de producto. Desde cierto punto de vista, el líder comunitario debe ser una persona muy técnica. Pero desde otra perspectiva, es más importante que un líder comunitario considere un proyecto de código abierto como un producto o una mercancía que se puede vender.
El mayor temor del código abierto es la competencia por la velocidad y el rendimiento. Si persigue ciegamente la velocidad, el resultado es que después de que su función salga, otras pueden ponerse al día rápidamente a través de alguna optimización, lo que hará que pierda su espacio vital. Solo continuando innovando podremos seguir adelante. En este proceso, si confiamos ciegamente en los KPI y los indicadores de datos que trae el marketing para guiar el desarrollo de proyectos de código abierto en lugar de volver a los problemas que los proyectos de código abierto deben resolver, esto se convertirá en un desastre para el desarrollo de proyectos de código abierto. .
Muchos proyectos extremadamente populares en la historia no pueden dejar nada atrás después de la emoción. La razón principal es que la fuerza del producto del software no es lo suficientemente fuerte, es decir, no puede resolver problemas prácticos, e incluso los problemas que dice resolver no lo hacen. no existe.
El contenido involucrado en esta discusión es demasiado complicado, y creo que lanzar esta pregunta ha logrado el propósito de este artículo. Di algunos ejemplos específicos en la primera sección "Los usuarios no lo compran: ¿cómo lo uso?" en "La muerte de Dachang Open Source" , que se puede usar como referencia.
Referencias
[1] ¿Cómo evaluar los Me gusta y los obsequios de Ali OceanBase GitHub? :
https://www.zhihu.com/question/494108102
[2] Antipatrón de la experiencia del desarrollador: operaciones impulsadas por el mercado:
https://dx.phodal.com/docs/anti-patterns/marketing-drive-developement.html
[3] Las operaciones de código abierto deben discutirse independientemente del historial:
https://xuanwo.io/informes/2022-13/
[4] Problema de seguimiento para pruebas de reestructuración:
https://github.com/pingcap/tidb/issues/26022
[5]Haz que algunos linters sean realmente felices:
https://github.com/pingcap/tidb/issues/22979
[6]Haga que linter facter permita que bazel nogo implemente un linter incremental rápido:
https://github.com/pingcap/tidb/issues/35345
[7] errores tipográficos: https://crates.io/crates/typos
[8] "El arte de la operación comunitaria":
https://book.douban.com/subject/26976995/
[9]《Impulsado por personas》:
https://book.douban.com/subject/35531548/
[10]Canal de YouTube:
https://www.youtube.com/jonobacon
[11] "Relaciones con desarrolladores: métodos y prácticas":
https://book.douban.com/subject/36337667/
[12]Experiencia del desarrollador en Vercel:
https://leerob.io/blog/dx
[13] Experiencia en configuración de entornos de desarrollo:
https://t.zsxq.com/0e2fvSfXz
[14]Más allá del almacenamiento: por qué fallamos:
https://xuanwo.io/2023/01-mas-alla-del-almacenamiento-por-que-fallamos/
[15] "La Catedral y el Bazar":
https://book.douban.com/subject/25881855/
[16] Creación de software de código abierto:
https://produciendooss.com/
[17]Guías de código abierto:
https://opensource.guide/
[18] "Colaboración abierta":
https://book.douban.com/subject/36199828/
[19] "El código abierto no tiene magia negra, la burbuja estallará en dos años":
https://www.infoq.cn/article/v0wqth2ubqwayxg08b7t
Desliza para ver todas las referencias
Reimpreso de丨tisonkun El Libro del Cielo Nocturno
Editor: Weng Peipei
Lectura relacionada|Lectura relacionada
¿Cómo unirse a Kaiyuanshe?
Informe anual Kaiyuanshe 2022: Abriendo un nuevo mundo
Introducción a Kaiyuanshe
Fundada en 2014, la Sociedad Kaiyuan está compuesta por miembros individuales que contribuyen voluntariamente a la causa del código abierto. Se forma de acuerdo con el principio de "contribución, consenso y cogobernanza". Siempre ha mantenido las características de neutralidad del proveedor, bienestar público y sin fines de lucro. Integración internacional, desarrollo comunitario, incubación de proyectos "es una federación comunitaria de código abierto con la misión. Kaiyuanshe coopera de forma activa y estrecha con comunidades, empresas y unidades relacionadas con el gobierno que apoyan el código abierto. Con la visión de "Con sede en China y contribuyendo al mundo", su objetivo es crear un ecosistema de código abierto saludable y sostenible y promover la comunidad de código abierto de China. convertirse en una fuerza activa en el sistema global de código abierto Participación y colaboradores.
En 2017, Kaiyuanshe se transformó en una organización compuesta en su totalidad por miembros individuales, que opera con referencia al modelo de gobierno de las principales fundaciones internacionales de código abierto como ASF. En los últimos nueve años, ha conectado a decenas de miles de personas de código abierto, ha reunido a miles de miembros y voluntarios de la comunidad, cientos de disertantes en el país y en el extranjero, y ha cooperado con cientos de patrocinadores, medios y socios de la comunidad.
