Le système de développement cathédrale est très long avec une vision du code une fois seulement les changements terminés et de grandes difficultés pour inclure des contributions externes. Tous les logiciels propriétaires fonctionnent sur ce principe et quelques logiciels libres procédant de la même manière comme GCC ou généralement les logiciels opensource portés par une société : Firefox, openoffice.org, MySQL etc.
J'ai l'impression que tu confonds le modèle marketing avec le modèle de développement. Tous les développement propriétaires ne se font pas en "Cathédrale" - Dans ce cas-ci tu parles en fait du modèle de développement "Waterfall" qui est en effet le modèle de développement classique des logiciels propriétaires et des Cathédrales.
Il existe d'autres méthodologies de développement (je pense à extreme programming et aux autres techniques de développement agile) qui n'ont pas ces restrictions (impossibilité de visualiser le projet avant la fin de gros changements, impossibilité de recevoir des patches) - parce que le but même des ces méthodologies est d'avoir en permanence quelque chose de fonctionnel. Ce qui ne leur empêche évidement pas d'avoir une vue à long terme, même si l'analyse complète de la solution ne se fait qu'au fur et à mesure.
# modèle de développement
Posté par Aris Adamantiadis (site web personnel) . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 4.
J'ai l'impression que tu confonds le modèle marketing avec le modèle de développement. Tous les développement propriétaires ne se font pas en "Cathédrale" - Dans ce cas-ci tu parles en fait du modèle de développement "Waterfall" qui est en effet le modèle de développement classique des logiciels propriétaires et des Cathédrales.
Il existe d'autres méthodologies de développement (je pense à extreme programming et aux autres techniques de développement agile) qui n'ont pas ces restrictions (impossibilité de visualiser le projet avant la fin de gros changements, impossibilité de recevoir des patches) - parce que le but même des ces méthodologies est d'avoir en permanence quelque chose de fonctionnel. Ce qui ne leur empêche évidement pas d'avoir une vue à long terme, même si l'analyse complète de la solution ne se fait qu'au fur et à mesure.