Cómo construir un proyecto de código abierto verdaderamente excepcionalEn los últimos años, cada vez más desarrolladores han optado por lanzar sus productos como código fuente abierto y, a veces, el resultado es que lo abres con sinceridad. código, pero a nadie le importa. Aunque su producto está bastante bien hecho, simplemente publicar el código fuente del producto no es código abierto porque es posible que otros usuarios no puedan comenzar. Sin usuarios, su entusiasmo se extinguirá con el tiempo. Entonces, ¿cómo podemos hacer que más personas conozcan los proyectos de código abierto y convertirnos en un proyecto de código abierto verdaderamente excelente? Además de la excelencia del proyecto en sí, también es necesario prestar atención a los siguientes puntos. Primero, tenga un archivo README realmente útil Incluso si crea un excelente sitio web para un proyecto de código abierto, algunos usuarios potenciales pueden aprender primero sobre el proyecto leyendo el archivo README. Por lo tanto, debe asegurarse de proporcionar la información más completa posible en el archivo README: 1. Dependencias e información de instalación Escriba las dependencias y la información de instalación lo más claramente posible. Es mejor permitir que los usuarios agreguen dependencias copiando y pegando el código relevante. . Por ejemplo, así. 2. Estado de madurez del proyecto No permita que los usuarios sepan después de usarlo en producción durante unos meses que su proyecto solo se encuentra en la etapa Alfa. 3. Descripción detallada de los idiomas, entornos operativos y versiones de herramientas compatibles. No permita que los usuarios dediquen mucho tiempo a comprender la compatibilidad del proyecto. 4. La licencia especificada debe ser popular y conocida por los usuarios. Si la crea usted mismo o utiliza una licencia desconocida (como WTFPL), los usuarios no se atreverán a utilizar su código abierto en sus proyectos. Puede elegir la Licencia pública Apache 2.0 o la Licencia pública Eclipse, más amigable, etc. Tenga en cuenta que algunas licencias, como la del MIT, también son populares pero no ofrecen ninguna protección de patente. También puede utilizar licencias duales APL2/GPLv2 para permitir a los usuarios elegir la licencia que más les convenga. En segundo lugar, escribir documentos para su proyecto no es fácil y requiere mucho tiempo, pero para los usuarios, la documentación es la forma más conveniente y que ahorra tiempo de comprender un proyecto, y también les permite creer que no se rendirán fácilmente. proyecto. Poner lo que el proyecto puede ayudar a los usuarios a lograr al principio del documento es la clave para que los usuarios decidan si utilizar el proyecto. Además, desea que los usuarios crean que un ser humano está trabajando en el proyecto, no un robot que genera el código. En tercer lugar, el proyecto se puede actualizar fácilmente cuando se corrigen errores en el proyecto y se mejoran ciertas características, es necesario lanzar otra versión. Cosas a tener en cuenta 1. Compatibilidad con versiones anteriores No permita que los usuarios reescriban una gran cantidad de código solo porque no es compatible con versiones anteriores. Esto hará que los usuarios se enojen y abandonen su proyecto. Por supuesto, no es necesario que sea compatible con productos de hace 15 años (como OpenJDK). 2. Registro de cambios: debe haber un registro de cambios claro y claro, que incluya los cambios que se han realizado en esta versión. ¿Romperá el código del proyecto existente del usuario? etc. Por ejemplo, el enfoque de Twitter es: para cada error solucionado, escriba una breve entrada en el registro de cambios; para cada característica agregada, describa brevemente e incluya algún código de muestra para cada cambio en la API; se requiere una breve entrada en el registro; Está claramente indicado en negrita; si hay varias ramas, debe escribir un registro de actualización para cada rama. 3. Etiquetas de versión: agregar etiquetas a cada versión del proyecto, como v1.0.0-alpha1, v1.0.0, v1.1.2, permite a los usuarios distinguir claramente las versiones del proyecto. 4. Hacer un anuncio Después de que se publique el proyecto, el siguiente paso es escribir una publicación en el blog del evento o publicar un anuncio directamente en la lista de correo del proyecto. En el anuncio, debe explicar el propósito del proyecto, si es compatible con versiones anteriores y proporcionar un enlace al registro de cambios. 5. Etiqueta de estado del proyecto Algunos proyectos utilizan el mismo número de versión durante mucho tiempo, como 1.1.0, y el proyecto se mejora constantemente. Si se trata de una versión de desarrollo, también debe marcarse para indicar la etapa de desarrollo del proyecto. Por ejemplo: 1.1.0.pre11.1.0-alpha11.1.0-SNAPSHOT En resumen, debe asegurarse de que su proyecto tenga un plan de nomenclatura de versión estricto.
Cuarto, use GitHub En GitHub, puede completar fácilmente las siguientes tareas: Publicar proyectos Explorar y buscar código Seguir problemas del proyecto Participar en contribuciones Fusionar contribuciones de usuarios Quinto, asegúrese de que haya un lugar para brindar soporte a los usuarios Si su proyecto alcanza un cierto nivel. Popularidad, recibirás constantemente preguntas de los usuarios. Necesita tener un lugar para recopilar y responder las preguntas de los usuarios, como un foro, una lista de correo, etc. Con un lugar para la comunicación, los usuarios también pueden ayudarse unos a otros. Con el tiempo, se formará una buena comunidad. En sexto lugar, la finalización del proyecto no descarta esta situación: puede perder interés en el mantenimiento del proyecto o puede mudarse a un nuevo trabajo y dejar de utilizar el proyecto actual. Puedes anunciarlo en la lista de correo y dejar que otros desarrolladores se hagan cargo de tu proyecto. Es más fácil transferir la propiedad del proyecto en Github, especialmente cuando otros introducen nuevas funciones en su proyecto. Pase lo que pase, no dejes que el proyecto muera. 7. Resumen En resumen, cuando planee lanzar un producto de código abierto, asegúrese de que tenga las siguientes características: Dependencias/instrucciones de instalación claras Al menos una breve biblioteca de documentación/guías con registros de cambios y etiquetas relevantes Alguna información sobre los idiomas y tiempos de ejecución compatibles Lista de correo para obtener información sobre el entorno, las versiones de las herramientas y la madurez del proyecto para que los usuarios hagan preguntas y se ayuden entre sí. VIII En conclusión, si desea que su proyecto de código abierto "prospere", primero debe hacerlo más fácil de usar. Aparte de la documentación del proyecto, nada más requiere mucho tiempo. Además, es fácil abrir un proyecto, pero es difícil mantenerlo durante mucho tiempo. Por lo tanto, también es necesario tener espíritu de perseverancia y estar preparado para librar una guerra prolongada.