Terminar el código no equivale a entregar el trabajo🔥😵 Mucha gente ve el lanzamiento del repositorio del proyecto Grant y empieza a celebrar, pensando: “Listo”.
Pero cuando leí los requisitos del programa @Dusk Grants, mi atención quedó clavada en el último milestone: el solicitante debe incluir un plan de mantenimiento de un año.
Un año. No es “si hay problemas, abre un issue”, es un requisito obligatorio escrito en blanco y negro dentro de la lista de entregables.
Dusk también exige documentación complementaria, pruebas y pasos de instalación y ejecución reproducibles. En lenguaje humano: necesitas un equipo de soporte; no basta con encender la funcionalidad el día de la demo. Tienes que asegurarte de que las personas que vengan después puedan continuarlo y repararlo.
demo es fácil; el mantenimiento es lo caro
Para quienes solicitan, hacer una demo que funcione en el corto plazo no es tan difícil. Escribir el código para que encienda, y que el día de la demostración pase, ya está.
Pero lo realmente caro viene después de un año: se actualizan dependencias, alguien abre un issue y los comandos de la documentación ya no corren. En ese momento, ¿el equipo seguirá dispuesto a volver para arreglar? Si lo hace, ¿quién lo hará? ¿Hay horas de trabajo contempladas para eso en el presupuesto?
Muchos proyectos, cuando terminan la primera versión, los miembros clave se van a ocuparse de otras cosas. El repositorio sigue ahí, pero llegan los usuarios y no pueden instalarlo; preguntan y no hay respuesta. El costo no desaparece: simplemente se transfiere al siguiente desarrollador del ecosistema—esa persona quizá seas tú o quizás sea yo.
Este requisito es un filtro
No creo que, con esta condición, Dusk pueda garantizar que cada proyecto vaya a estar activo a largo plazo. Seamos honestos: con solo una solicitud no se puede garantizar nada.
Pero al menos hizo bien una cosa: poner el costo de “mantenimiento” de forma anticipada en la solicitud.
Un equipo dispuesto a incluir un año de mantenimiento en el presupuesto se parece más a quien quiere entregar infraestructura base, no a quien solo quiere completar una tarea puntual. Esa diferencia no se ve al solicitar; un año después, al mirar el estado del repositorio, queda clarísima.
Lo que vale la pena mirar después de $DUSK es si @Dusk publicará el progreso de mantenimiento y el estado de esos proyectos—datos visibles son más honestos que cualquier promesa. Para que el crecimiento del ecosistema de #dusk tenga un rastro, y no se quede solo con un montón de repositorios que se activan y luego se apagan😖.
Pero cuando leí los requisitos del programa @Dusk Grants, mi atención quedó clavada en el último milestone: el solicitante debe incluir un plan de mantenimiento de un año.
Un año. No es “si hay problemas, abre un issue”, es un requisito obligatorio escrito en blanco y negro dentro de la lista de entregables.
Dusk también exige documentación complementaria, pruebas y pasos de instalación y ejecución reproducibles. En lenguaje humano: necesitas un equipo de soporte; no basta con encender la funcionalidad el día de la demo. Tienes que asegurarte de que las personas que vengan después puedan continuarlo y repararlo.
demo es fácil; el mantenimiento es lo caro
Para quienes solicitan, hacer una demo que funcione en el corto plazo no es tan difícil. Escribir el código para que encienda, y que el día de la demostración pase, ya está.
Pero lo realmente caro viene después de un año: se actualizan dependencias, alguien abre un issue y los comandos de la documentación ya no corren. En ese momento, ¿el equipo seguirá dispuesto a volver para arreglar? Si lo hace, ¿quién lo hará? ¿Hay horas de trabajo contempladas para eso en el presupuesto?
Muchos proyectos, cuando terminan la primera versión, los miembros clave se van a ocuparse de otras cosas. El repositorio sigue ahí, pero llegan los usuarios y no pueden instalarlo; preguntan y no hay respuesta. El costo no desaparece: simplemente se transfiere al siguiente desarrollador del ecosistema—esa persona quizá seas tú o quizás sea yo.
Este requisito es un filtro
No creo que, con esta condición, Dusk pueda garantizar que cada proyecto vaya a estar activo a largo plazo. Seamos honestos: con solo una solicitud no se puede garantizar nada.
Pero al menos hizo bien una cosa: poner el costo de “mantenimiento” de forma anticipada en la solicitud.
Un equipo dispuesto a incluir un año de mantenimiento en el presupuesto se parece más a quien quiere entregar infraestructura base, no a quien solo quiere completar una tarea puntual. Esa diferencia no se ve al solicitar; un año después, al mirar el estado del repositorio, queda clarísima.
Lo que vale la pena mirar después de $DUSK es si @Dusk publicará el progreso de mantenimiento y el estado de esos proyectos—datos visibles son más honestos que cualquier promesa. Para que el crecimiento del ecosistema de #dusk tenga un rastro, y no se quede solo con un montón de repositorios que se activan y luego se apagan😖.