En primer lugar, me disculpo si esta es la sección incorrecta de la red para publicar esta pregunta. Si es así, no dude en moverlo a una ubicación más apropiada ...
Pregunta: Me gustaría escuchar sus ideas sobre las formas en que se inician y ejecutan los proyectos de código abierto. Tengo un proyecto de sistema de gestión de contenido de código abierto y aquí surgen algunas preguntas: ¿Cómo debo actuar? ¿Debo proponer una edición pre-alfa viable con front-and-back de trabajo primero y luego anunciar el proyecto públicamente? ¿O debo anunciarlo de inmediato? Como desarrollador, sé que uno debe usar un sistema de versiones como Git o SVN, lo cual hago, no hay problemas allí. Y el mérito de las pruebas unitarias también es algo para recordar, que, para ser sincero, no me gusta en absoluto ... Gestión de proyectos: soy un principiante en eso, en el mejor de los casos. Las técnicas y experiencias de codificación como el desarrollo ágil es algo que quiero explorar ...
En resumen, cualquier idea para un desarrollador que es nuevo en el mundo del código abierto es bienvenida.
fuente
Respuestas:
Empezaría a parar para escribir cosas como esta:
Este tipo de actitud arrogante en realidad mata más proyectos de código abierto que cualquier otra cosa. El código abierto tiene menos que ver con el código fuente y más con la colaboración. Dé la bienvenida a todos los que quieran ayudar, incluso cuando no tengan la experiencia práctica para hacerlo; ayudar a los proyectos de código abierto a adquirir experiencia es una práctica común, como probablemente ya saben.
El segundo punto es no molestarse en promocionar si no tiene un código de trabajo. Eche un vistazo a sourceforge o Google Code o donde sea y vea el mar de proyectos muertos con nada más que unas pocas líneas de código y muchas buenas intenciones. Codifique primero, hable después.
La mejor promoción es tener un "cliente": que alguien use su producto para que la gente pueda ver que realmente está en producción. Si es un CMS: utilícelo para el sitio del proyecto, por ejemplo.
Si tiene todo esto, su mejor apuesta en promoción es el boca a boca. Pida amigos para usar su proyecto en sus sitios web, por ejemplo. Escribe un blog al respecto y envía el artículo para sitios de agregación como Digg o Slashdot pero, por favor, no hagas esto si el proyecto no está listo para el horario estelar. Nadie quiere leer sobre vapourware.
Buena suerte con tu proyecto.
fuente
Tu pregunta es vaga, pero intentaré una respuesta lo mejor que pueda. ¿Asumo que desea atraer desarrolladores al proyecto para que no sea la única persona que trabaja en el proyecto?
En ese caso, es probable que desee obtener una cuenta en Github o Source forge para que cualquiera pueda tener acceso a ella y realizar cambios. Para empezar, será el único desarrollador que trabaje en él, por lo que no debe preocuparse por la gestión de proyectos, pero tan pronto como haya varias personas involucradas, querrá instigar revisiones de código, establecer objetivos, etc.
Los objetivos se pueden agrupar en un sistema de seguimiento de problemas como bugzilla, agregarlos como errores que deben corregirse y permitir que las personas se asignen a ellos, o hacer que envíen un correo electrónico a una persona central que asigna personas a los problemas.
Querrá atraer a una multitud de desarrolladores, por lo que necesitará un sitio web que describa el proyecto, y dónde lo ve a corto y mediano plazo, así como capturas de pantalla, etc.
Un proyecto de blog / twitter que permite a los usuarios realizar un seguimiento de dónde se encuentra si también es útil.
fuente
Si no lo ha leído, le sugiero La catedral y el bazar de Raymond , y preste especial atención a su experiencia con Fetchmail.
Basado en eso, y en mi propia experiencia, sugiero liberar el código tan pronto como resuelva un problema que otras personas puedan tener . Sí, debe usar un control de fuente de flujo principal y publicarlo en un servidor en alguna parte. Debe elegir una licencia, y eso puede ser un gran problema dependiendo de sus objetivos. Pero en términos de qué publicar y cuándo, "publicar temprano, publicar a menudo".
fuente