2009-09-25 12 views
7

estoy a punto de publicar un proyecto de código abierto, y realmente me gustaría alguna información sobre un par de cosas:¿Qué pensar al hacer un proyecto de código abierto?

  1. El código es bastante limpio, pero la historia no es el control de versiones. Errores, código de depuración, tal vez código inapropiado, etc. ¿Debería borrar el historial antes de la publicación, o importarlo de todos modos al repositorio público?

  2. ¿Debo priorizar la realización de un tutorial, explicación de funciones o documentación api?

  3. Otros pensamientos que hacen que un nuevo proyecto sea fácil para la gente.

+0

Una pregunta muy relevante para mí, me alegra que haya preguntado. – mmr

Respuesta

9

En mi muy humilde opinión:

1) Si le fijan en ir de código abierto, estar orgullosos de su código. Todos sabemos que hay errores y errores en el camino. También van a haber más, así que no sientas que no puedes mostrarlos públicamente. ¡Usted puede!

2) Definitivamente. Probablemente en eso, también ordene, porque ese es el orden que las personas que usan su producto van a leer. Tendrán que usar su software antes de que decidan trabajar en él.

3) El mejor consejo que puedo dar es tener instrucciones de compilación claras, con suerte con scripts para ayudar a las personas a configurar el entorno. Una plaga común con el software de código abierto es que requiere que los nuevos desarrolladores descarguen toneladas de bibliotecas y configuren su cuadro para que funcione , justo a la derecha para poder construir el software. Eso, para mí, es muy frustrante y puede desanimarme muy rápido.

¡Buena suerte!

1
  1. totalmente su elección, a menos que se utiliza código de derechos de autor para el que no tiene los derechos de distribución o si hay algún problema relacionado con la redistribución, el crédito, lo que sea.

  2. Es difícil de decir sin saber de qué se trata. ¿Qué necesitarías para usarlo? ¿Qué te gustaría ver primero? (Probablemente el tutorial ...)

  3. Quizás un ejemplo de principio a fin que incluya la instalación. Tal vez deba tomarse la molestia de ejecutarlo en un entorno virtual o en una nueva instalación del sistema operativo, por lo que está seguro de que sus instrucciones de instalación se ocupan de todo.

1
  1. Debe ser bastante fácil de aplastar algunos comete juntos, y el esfuerzo valdrá la pena. Los desarrolladores a menudo miran a través de la historia para obtener una idea de cómo el proyecto fue diseñado desde cero.
  2. Definitivamente. Lo mínimo que puede hacer es obtener un motor de documentación como Doxygen para generar la documentación. El tutorial probablemente sea innecesario en este punto; la comunidad escribirá tutoriales para usted, siempre que el código esté bien documentado.
  3. El buen empaque siempre ayuda. Genere binarios precompilados para más de una arquitectura y, si es posible, cree RPM y DEB. Esto reduce la barrera de entrada en gran medida. Nadie contribuye al software que no usan. También podría utilizar un buen rastreador de errores como Bugzilla, o utilizar una solución integrada como Launchpad o Trac. También configure una lista de correo y un canal de IRC. Esto ayudará a construir una comunidad.
+0

No estoy de acuerdo con "la comunidad escribirá tutoriales para usted". Creo que al menos deberías escribir un tutorial dirigido a desarrolladores, lo que significa omitir muchas cosas muy comunes: cosas como "Usamos el sistema de compilación GNU (./configure && make && make install)" en lugar de tener que explicar el Sistema de compilación GNU para alguien que no esté familiarizado con él. Creo que es importante tener un tutorial básico listo para ayudar a los desarrolladores a sumergirse, en lugar de simplemente escribir código bien documentado y limpio y dejándolo a otra persona para que escriba los documentos. –

+1

Oh, me refería a los tutoriales de uso. Para los desarrolladores, las instrucciones de compilación son definitivamente necesarias. – artagnon

Cuestiones relacionadas