¿Cómo se determinan los requisitos en los proyectos de software de código abierto?

En el desarrollo interno de software corporativo, es común que los requisitos se determinen a través de un proceso formal que resulta en la creación de una serie de documentos de requisitos. En el desarrollo de software de código abierto, esto a menudo parece estar ausente. Por lo tanto, mi pregunta es: ¿cómo se determinan los requisitos en los proyectos de software de código abierto?

Por "determinar los requisitos" me refiero simplemente a "averiguar qué características, etc., deberían desarrollarse como parte de un software específico".

Los proyectos de código abierto a veces tienen un flujo intenso de comentarios de los usuarios, y a veces las corporaciones simplemente pagan para hacer que ciertas características sean planificadas e implementadas (contratando a sus propios desarrolladores o los desarrolladores originales).

Si su proyecto tiene 100 usuarios, probablemente pueda desarrollar lo que sea más divertido de codificar.

Si su proyecto tiene 100k usuarios, lo más probable es que ya tenga una lista de puntos débiles que la mayoría de los usuarios desean solucionar en la próxima versión, y una lista de las principales características de N que los usuarios solicitan en su rastreador de problemas y siguen preguntando en los foros.

Con estos comentarios, puede escribir documentos de requisitos para su equipo central, crear hojas de ruta para ayudar a los colaboradores independientes a comprender su visión y esperar que algunos de los 100k usuarios envíen parches.

He estado siguiendo el código abierto desde que escuché por primera vez sobre Linux en 1995, y no recuerdo haber escuchado la palabra 'requisitos' en ese contexto.

Eric Raymond tiene un buen ensayo, La catedral y el bazar , en el que habla sobre "rascarse la picazón". Si está tratando de resolver un problema que enfrenta personalmente, no tiene que consultar los documentos de requisitos para determinar si lo ha resuelto o no.

Ese mismo ensayo también habla sobre escuchar a sus usuarios, lo cual es un buen consejo para todos, no solo para proyectos de código abierto. Los proyectos de código abierto tienden a ser meritocráticos, por lo que "el que escribe el código, hace las reglas", más o menos.

En el desarrollo interno de software corporativo, es común que los requisitos se determinen a través de un proceso formal que resulta en la creación de una serie de documentos de requisitos.

Según mi experiencia, esto es mucho más común cuando se realiza un desarrollo basado en contratos, especialmente cuando se tiene una empresa externa que realiza el desarrollo para su empresa, y existe la necesidad legal de un contrato. Pero muchas otras compañías controlan su desarrollo interno por su propia gente de una manera diferente:

• comunicación informal

• requisitos priorizados / errores / problemas / listas de tickets (y eso definitivamente no es un invento de la comunidad "ágil")

Esta es la misma forma en que funcionan la mayoría de los proyectos de código abierto, ya que no hay necesidad de un contrato formal, nadie se molesta en elaborar documentos de requisitos formales grandes, detallados, solo pequeñas listas indoloras de características faltantes o tickets recopilados en un problema rastreador a resolver.

Si el problema es común como, por ejemplo, escribir un compilador o un navegador, los requisitos se dan en forma de estándares de idioma, sistemas operativos de destino y hardware de destino, etc.

Para cosas como GNU Emacs, que son muchas cosas para muchos además de cumplir excelentemente su objetivo original de ser un editor de texto, creo que los requisitos tenían sentido debido al inmenso alcance para extenderlo. Los chats, correos electrónicos, grupos de noticias, edición de código, control de versiones vienen a la mente. Hay un científico investigador trabajando en Emacspeak. Creo que se pueden decir cosas similares de los navegadores y otras cosas que permiten extensiones.

Si el software está alcanzando una función que está disponible solo en software que no es de código abierto, el requisito se da más o menos nuevamente.

EDITAR:

Cuando el software de código abierto pasa a mantenimiento y quedan menos requisitos originales que no se cumplen, la mayoría de los requisitos pueden provenir de errores, la necesidad de adaptarse a nuevas plataformas como CPU de múltiples núcleos y otro hardware que ofrecen un mejor rendimiento cuando se explotan, y demás.

En un proyecto totalmente basado en la investigación como el Hurd de GNU, creo que los requisitos provienen de los resultados de la investigación y los documentos.

Para resumir,

• al comenzar, los requisitos para el software que intenta resolver problemas comunes pueden provenir de documentos estándar

• para el software que se está poniendo al día con otro software existente, es probable que los requisitos sean producir todo o la mayoría del conjunto de características del software existente y algunas otras características que los desarrolladores / usuarios consideran interesantes tener

• para proyectos de investigación, documentos y otras publicaciones podrían establecer los requisitos

• cuando en mantenimiento, los errores, la necesidad de adaptarse a los entornos más nuevos puede ser una fuente importante de requisitos

No estoy seguro, pero una vez que la sugerencia es utilizar una metodología similar a Agile, donde los requisitos se plantean como tickets (o "tarjetas"), utilizando algo como JIRA, cada ticket representa una característica o requisito. Cada boleto podría descomponerse en otros boletos que representan unidades de trabajo más pequeñas.

En cuanto a averiguar qué debe hacer una aplicación o pieza de software, la respuesta simple es "hablar con los otros desarrolladores". :) "Hablar" en este caso podría significar una lista de distribución de correo electrónico, un foro o incluso IRC, cualquier cosa que permita a las personas en diferentes zonas horarias y ubicaciones geográficas chatear.