Il vaut mieux que l'architecture soit bien etablie, alors si le developpeur d'origine a ete bien rigoureux il suffit aux autres de suivre ses methodes de travail.
C'est tellement rarement le cas, que l'architecture soit bien etablie et que le developpeur d'origine soit bien rigoureux que tu peux oublier.
Des que les methodes de travail sont imposees, oublie aussi, car sauf exception, rares sont ceux qui vont rester longtemps.
On n'est pas dans une entreprise ou le projet est concu, defini, delimite avant d'etre demarre, et ou les methodes de travail sont celles de la boite, imposees a tous les employes !
Commencer a plusieurs, avec des developpeurs open source qui sont generalement tous persuades que seule leur facon de voir les choses est la bonne, il y a un risque trop grand de se battre sur la facon de faire.
Il est rare de commencer a plusieurs. En general, il y a deja un proto qui marche plus ou moins.
Ensuite, le projet etant naissant, et comme il n'y a pas encore beaucoup d'heures de travail derriere, les eventuels contributeurs ne vont pas chercher a se battre. Il est bien plus simple de repartir a zero, justement car le projet est naissant !
Les bagarres dont tu parles sont celles de projets deja plus avances, ou il n'est plus envisageable de repartir a zero. C'est la que des forks arrivent.
L'autre risque c'est que le developpeur principal aie fait un petit proto qui marchotte, et qu'il se desinteresse tres rapidement de son propre projet.
Non, ca, au contraire, c'est une force des logiciels libres. Si le developpeur principal a fait un petit proto et l'abandonne et qu'un autre s'interesse au projet, le projet continuera !
Sur ce point, je parle en connaissance de cause pour avoir repris un tel projet.
[^] # Re: Un cri de désespoir du développeur d'un projet Open Source.
Posté par a_jr . En réponse à la dépêche Un cri de désespoir du développeur d'un projet Open Source.. Évalué à 1.
C'est tellement rarement le cas, que l'architecture soit bien etablie et que le developpeur d'origine soit bien rigoureux que tu peux oublier.
Des que les methodes de travail sont imposees, oublie aussi, car sauf exception, rares sont ceux qui vont rester longtemps.
On n'est pas dans une entreprise ou le projet est concu, defini, delimite avant d'etre demarre, et ou les methodes de travail sont celles de la boite, imposees a tous les employes !
Commencer a plusieurs, avec des developpeurs open source qui sont generalement tous persuades que seule leur facon de voir les choses est la bonne, il y a un risque trop grand de se battre sur la facon de faire.
Il est rare de commencer a plusieurs. En general, il y a deja un proto qui marche plus ou moins.
Ensuite, le projet etant naissant, et comme il n'y a pas encore beaucoup d'heures de travail derriere, les eventuels contributeurs ne vont pas chercher a se battre. Il est bien plus simple de repartir a zero, justement car le projet est naissant !
Les bagarres dont tu parles sont celles de projets deja plus avances, ou il n'est plus envisageable de repartir a zero. C'est la que des forks arrivent.
L'autre risque c'est que le developpeur principal aie fait un petit proto qui marchotte, et qu'il se desinteresse tres rapidement de son propre projet.
Non, ca, au contraire, c'est une force des logiciels libres. Si le developpeur principal a fait un petit proto et l'abandonne et qu'un autre s'interesse au projet, le projet continuera !
Sur ce point, je parle en connaissance de cause pour avoir repris un tel projet.
Le bonjour chez vous,
Yves