Cómo iniciar un proyecto de código abierto

Mi nombre es Dima y soy desarrollador Ruby. Hoy quiero compartir mi experiencia creando una solución de código abierto. Hablaré sobre los pasos que debe seguir el proyecto, cómo elegir la funcionalidad correcta para la primera versión y los errores que enfrenté personalmente al crear mi proyecto de código abierto.

Hace medio año, tuve la idea de que sería bueno crear un proyecto de código abierto. En lugar de tareas de prueba para la entrevista, me bastaría con enviar un enlace al repositorio. Me inspiró la perspectiva de ayudar a los colegas con la solución de sus problemas cotidianos.

Siempre me han disgustado las gemas para crear paneles de administración. Cualquier movimiento adicional debe redefinir la clase y, para los campos de cambio, debe realizar cambios en los archivos. Después de pensar y conversar con colegas, decidí crear una nueva biblioteca que sería flexible y no requeriría cuadros de mando ni archivos de configuración.

Determina las metas

Cada proyecto de código abierto resuelve un problema específico. Habla con colegas, chats, foros y comparte tu idea. Todo le ayuda en los primeros pasos para comprender cosas importantes, como qué soluciones ya existen, y escuchar críticas. Habla con personas que ya tienen proyectos de código abierto. Pueden darte consejos muy valiosos, así que no temas preguntar y tomar la iniciativa.

Un consejo importante que recibí en esa etapa es prestar atención en primer lugar a la documentación del proyecto. Puedes tener un muy buen proyecto, pero nadie dedicará tiempo a entender cómo funciona.

El aspecto más importante, sin el cual es imposible seguir adelante, es la motivación. La idea del proyecto debería inspirarte principalmente. La mayoría de las personas se acostumbran a las herramientas con las que trabajan y caen en una zona de confort, por lo que las opiniones externas pueden ser ambiguas.

Planificación

La elección de un administrador de tareas determinado es cuestión de gustos. Debe tener una imagen clara de las tareas y etapas de su proyecto.

Divida las tareas en subtareas. Idealmente, si una tarea no toma más de 3 a 4 horas, es importante disfrutar la implementación de pequeñas tareas. Esto ayudará a evitar el agotamiento y la pérdida de motivación.

Yo uso un rastreador pivotal. La principal ventaja es una versión gratuita para proyectos de código abierto donde puede ordenar las tareas por tipo (característica, error, tarea, lanzamiento) y agruparlas en lanzamientos y fechas límite determinadas.

Documentación

Cada proyecto de código abierto debe contener estas cosas:

  • README
  • Licencia de código abierto
  • Contribuir pautas
  • Registro de cambios

El archivo README no solo explica cómo usar su proyecto, sino también el propósito de su proyecto. Si no sabe cómo escribir correctamente un archivo README, puede buscar otros proyectos conocidos de código abierto o usar una plantilla.

La licencia garantiza que otros puedan usar, copiar y modificar el código fuente del proyecto. Debe agregar este archivo a cada repositorio con su proyecto de código abierto. MIT y Apache 2.0 GPLv3 son las licencias más populares para proyectos de código abierto. Si no está seguro de qué elegir, puede utilizar este conveniente servicio.

El archivo CONTRIBUTING ayudará a otros desarrolladores a contribuir al proyecto. En los primeros pasos del proyecto, no es necesario prestar mucha atención a este archivo. Puede utilizar la plantilla ya preparada de otro proyecto.

El registro de cambios contiene una lista ordenada cronológicamente compatible de cambios significativos para cada versión. Al igual que con el archivo CONTRIBUTING, no recomiendo prestar especial atención a esto en una etapa temprana.

Control de versiones

Para realizar un seguimiento de los cambios importantes para los usuarios y colaboradores, existe una versión semántica. El número de versión contiene números y se adhiere al siguiente patrón XYZ

  • X lanzamiento importante
  • Y versión menor
  • Lanzamiento del parche Z

Integración continua / Entrega continua

Para ejecutar pruebas y compilar automáticamente, uso Travis CI. También es una buena idea agregar insignias para mostrar el ensamblaje exitoso de la compilación en el asistente, la cobertura de prueba (Codecov) y la documentación (Inch CI).

Después de cada nueva confirmación o fusión en el maestro, automáticamente tengo una implementación en Heroku (integración muy conveniente con GitHub). Todas las herramientas son absolutamente gratuitas para un proyecto de código abierto.

Mis errores

Para analizar la etapa inicial, tenía una idea, pero no había un plan claro. Decidí que quería hacer esto sin tener una idea clara de cuánto tiempo tomaría o una representación específica de las funciones que estarían en la primera versión de la biblioteca. Tenía muchas ganas y faltaba un plan claro.

Además, después de leer la historia de otros proyectos (no solo de código abierto), noté que en una etapa temprana, algunos planes son demasiado optimistas. Necesitan una reevaluación de sus fortalezas y capacidades. Pero no es fácil encontrar tiempo cada día para escribir una nueva característica en el proyecto. La mayoría de las tareas finalmente tuvieron que eliminarse, dejando el mínimo necesario para MVP.

Por el momento, mi proyecto de administración simple está en la versión alfa. Otros planes incluyen la creación de una versión separada de la biblioteca para Hanami.