Lorsque je parlais de co-promotion, je ne parlais pas de co-développement (je suppose que c'est à cela que tu faisais allusion quand tu parlais de partir sur un développement commun, je n'ai jamais encore vu). La co-promotion, c'est en quelque sorte de la publicité où les deux marques sont évoquées.
Par exemple, l'entreprise B utilise le logiciel libre A. B fait une campagne de promotion, où il explique qu'il utilise A. Et A explique sur son site communautaire qu'il est utilisé par B. D'où :
-> A gagne en crédibilité du fait de son usage professionnel (à condition que l'entreprise soit crédible évidemment et "librement correct" :).
-> B gagne en crédibilité du fait de son usage d'une solution libre reconnue.
Cette façon de procéder implique évidemment que les grosses communautés contrôlent leurs principales marques : par exemple, la marque Debian est déposée et ne peut donc pas être utilisée par n'importe qui.
Quand à l'aspect co-développement / développement commun entre une communauté et une entreprise, il y a de nombreux exemples qui fonctionnent bien : Roxen, Zope, Linux Kernel, etc. Deux points clefs me semblent une bonne communication entre les différents protagonistes (fixer dès le départ les objectifs, les moyens d'y arriver, etc) et la fixation des interfaces (pour perturber au minimum les autres développements).
Ca se rapproche en fait assez fort de la gestion de projet dans l'automobile, où la voiture est progressivement décomposée en modules (plate-formes, embrayages, moteurs, etc) en vue de permettre le co-développement et le partage entre différents projets (la Megane II et la future Almera partageant la même plate-forme, la Micra et la Clio II partageant les mêmes diesels, etc).
Cela pose néanmoins une question : comment ne pas tuer l'innovation architecturale, dès lors que l'on fige les interfaces ?
[^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?
Posté par Robert VISEUR . En réponse à la dépêche L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?. Évalué à 3.
Par exemple, l'entreprise B utilise le logiciel libre A. B fait une campagne de promotion, où il explique qu'il utilise A. Et A explique sur son site communautaire qu'il est utilisé par B. D'où :
-> A gagne en crédibilité du fait de son usage professionnel (à condition que l'entreprise soit crédible évidemment et "librement correct" :).
-> B gagne en crédibilité du fait de son usage d'une solution libre reconnue.
Cette façon de procéder implique évidemment que les grosses communautés contrôlent leurs principales marques : par exemple, la marque Debian est déposée et ne peut donc pas être utilisée par n'importe qui.
Quand à l'aspect co-développement / développement commun entre une communauté et une entreprise, il y a de nombreux exemples qui fonctionnent bien : Roxen, Zope, Linux Kernel, etc. Deux points clefs me semblent une bonne communication entre les différents protagonistes (fixer dès le départ les objectifs, les moyens d'y arriver, etc) et la fixation des interfaces (pour perturber au minimum les autres développements).
Ca se rapproche en fait assez fort de la gestion de projet dans l'automobile, où la voiture est progressivement décomposée en modules (plate-formes, embrayages, moteurs, etc) en vue de permettre le co-développement et le partage entre différents projets (la Megane II et la future Almera partageant la même plate-forme, la Micra et la Clio II partageant les mêmes diesels, etc).
Cela pose néanmoins une question : comment ne pas tuer l'innovation architecturale, dès lors que l'on fige les interfaces ?