Lanzamiento de software de código abierto demasiado pronto [cerrado]

¿Cuál es la responsabilidad moral de lanzar software de código abierto demasiado pronto? Por ejemplo, un producto casi completo que no se ha probado completamente.

¿Cuál es la expectativa del programador? ¿Esperar hasta que se pruebe por completo o lanzar a código abierto y luego continuar con el desarrollo, las pruebas y los avances?

El temor es que el software sea de código abierto y pueda generar problemas para los consumidores.

¿Es este un miedo infundado?

Por el contrario, creo que debe lanzar un software de código abierto lo antes posible. No hay "demasiado pronto" para eso (pero debería compilarse).

^{O al menos publique el código fuente de manera muy temprana y continua (p. Ej ., Presionando con frecuencia en github ), sin realizar lanzamientos formales .}

Sin embargo, es muy importante marcarlo como etapa alfa o beta, y si es posible decir (por ejemplo, en un archivo READMEo TODOen un blog, etc.) lo que falta, no se prueba o está en mal estado. También debe usar el número de versión para transmitir dicha información.

Con el software libre , lo mejor que puede suceder es que alguien eche un vistazo al código fuente y le proponga un pequeño parche para mejorarlo. ¡Es por eso que haces tu software gratis!

^{¡Por lo tanto, debe hacer visible su trabajo diario en su software gratuito! Los contribuyentes externos se enojarían si su parche no funcionara o fuera un duplicado de su código fuente de software reciente.}

Lo que debe temer es que nadie se interese por su software (y contribuya a él). Atraer interés externo a un software libre (en particular, atraer contribuyentes externos) es un largo viaje.

TL; DR:

Salir temprano. Liberar a menudo.

Anécdota personal:

Estaba realmente entusiasmado con el proyecto en el que estaba trabajando. Como, muy emocionado. No podía dormir por la noche emocionado. Entonces, empujé a mi co-dev a lanzar v1.0 más rápido de lo que él quería.

Fue terrible. Nada funcionó como se suponía que debía hacerlo. Había errores a cada paso, pero los registramos y los arreglamos. Incluso hicimos que algunos de los primeros usuarios presentaran errores que quizás no hubiéramos encontrado. Una o dos semanas después, lanzamos una nueva versión que abordaba muchos de los problemas y luego volvimos a crear nuevas funciones.

Liberar temprano fue lo mejor que pudimos haber hecho. Pone nuestro producto frente a usuarios reales. Al hacer esto, los errores expuestos pueden o no haber encontrado y mejorado nuestro proyecto. También les hizo saber a los primeros usuarios que nos tomamos en serio este proyecto. Habrá más lanzamientos y desarrollo activo.

Sin embargo, podría haber ido fácilmente al revés. Podríamos haber ignorado esos informes de errores. O podríamos no haber reaccionado rápidamente. Podría haber sido una historia diferente si nos tomó 3 meses lanzar v1.1 en lugar de unas pocas semanas.

Es lo mismo que con el software de código cerrado. La comunicación es importante

Informe a los usuarios cuál es el estado del software y por qué está disponible para descargar.

El software siempre generará problemas con el cliente, sin importar si se ha probado completamente o no. La mayoría de los clientes aceptan ese hecho, y algunos clientes nunca lo hacen. Pero si el software generará más problemas de los que se podría esperar razonablemente, existe la obligación moral de informar al cliente sobre el riesgo que está asumiendo. La información debe ser breve (etiquetas "Alpha / Beta / EarlyAccess") y en detalle: una lista de problemas conocidos, soluciones y consideraciones especiales, por ejemplo, si es probable que los datos puedan estar dañados.

* Tenga en cuenta que algunas grandes compañías de software han capacitado a los usuarios para pensar en "Beta" como un estado en el que el software es bastante sólido, por lo que decirle al usuario que el software es "Beta" a menudo no es suficiente información.

No hay responsabilidad moral alguna. Nadie se ve obligado a usar su software a medias.

Lo único de lo que preocuparse sería de su credibilidad.

Mi experiencia es que hay que lograr un equilibrio.

En este momento, estoy trabajando (en el sentido de responder preguntas y proporcionar sugerencias de desarrollo, sin ver ningún código) con un desarrollador que está produciendo lo que parece ser un proyecto FOSS muy emocionante que utiliza el código que he escrito. El lanzamiento público se ha retrasado repetidamente debido a la realización de cambios en el diseño que harán que el proyecto sea mucho mejor a largo plazo, pero que requieren reescrituras significativas de código que ya se ha escrito y que ya estaba "funcionando". Mi opinión es que, si se hubiera realizado una versión funcional pero imperfecta tan pronto como hubiera algo que mostrar, las ideas para los cambios (y los parches reales) podrían haber surgido de la comunidad en general que está interesada en este proyecto y acelerarlo en lugar de tener los problemas surgen lentamente, uno a la vez, mientras el desarrollador piensa en ellos y solicita comentarios de diseño de mí y de otros miembros interesados ​​de la comunidad. Desde este punto de vista, soy un gran defensor de "liberar temprano, liberar a menudo".

Por otro lado, los lanzamientos de baja calidad pueden hacer que un nuevo proyecto se vea mal incluso antes de que despegue. Algunas trampas que he visto incluyen:

• Esqueleto de árboles con definiciones de interfaz pero sin código.
• Código que no se compila correctamente para nadie más que el desarrollador.
• No hay instrucciones sobre cómo construir / ejecutar el programa.
• No hay documentación de qué aspectos se espera que funcionen.
• Descripción poco clara de lo que el programa hace o hará.
• Falta de cualquier demostración de utilidad.

Para el último punto, estoy pensando en cosas como:

• Compilador / intérprete que ni siquiera puede compilar / ejecutar un programa tipo hello-world.
• Emulador que al menos no puede ejecutar un programa de muestra de algún tipo o demostrar que está haciendo algo.
• Herramienta de procesamiento de imágenes que no puede hacer nada más que cargar y volver a guardar la imagen sin modificar.
• Juego con nada más que una pantalla de título.

Este tipo de problemas se presta a una imagen de "vaporware" que puede ser difícil de sacudir a menos que sea muy abierto sobre la falta de código de trabajo para empezar.

Finalmente, haga que sus números de versión tengan sentido. No llame a su proyecto "1.0" hasta que haga lo que los usuarios esperan que haga sin fallar. Siempre he tenido suerte con el uso de números de versión alrededor de "0.5" para el lanzamiento público inicial y desde allí, pero también he visto cosas como "0.1" o "0.10" que tienen sentido.

Hay un caso cuando la liberación de software libre puede tener consecuencias negativas. Algunas especificaciones tienen licencia para el público con la condición de que todas las implementaciones distribuidas al público se ajusten a la especificación completamente cuando se publiquen por primera vez. El editor legalmente le prohíbe distribuir una implementación de trabajo en progreso de la especificación. Sin una licencia negociada específica del editor de la especificación, debe compartirla con nadie hasta que pase todas las pruebas. Esto obliga a un "modelo de catedral" (como Eric S. Raymond lo llamó) en implementaciones de la especificación.

Una especificación bajo dicha licencia es la Especificación del lenguaje Java . Esta restricción se aplica a los desarrolladores de máquinas virtuales compatibles con la JVM, pero afortunadamente no a los desarrolladores de aplicaciones que se ejecutan en una JVM.

El artículo " 4 Detalles Shifty sobre el 'Open Source' .NET de Microsoft " de Liu Qihao & Ciaran O'Riordan menciona la posibilidad de interpretar la Promesa de Patente de Microsoft para las Bibliotecas .NET y los Componentes de Tiempo de Ejecución para excluir implementaciones incompletas del CLR de manera similar . Pero, de nuevo, esto no se aplica a las aplicaciones que se ejecutan en el CLR.