POSS Chap 5 Part 8
De Framalang Wiki.
Marketing / Marketing
Although most Open Source developers would probably hate to admit it, marketing works. A good marketing campaign can create buzz around an Open Source product, even to the point where hardheaded coders find themselves having vaguely positive thoughts about the software for reasons they can't quite put their finger on. It is not my place here to dissect the arms-race dynamics of marketing in general. Any corporation involved in free software will eventually find itself considering how to market themselves, the software, or their relationship to the software. The advice below is about how to avoid common pitfalls in such an effort; see also the section called “Publicity” in Chapter 6, Communications.
Bien que la plupart des développeurs Open Source n'aimeraient pas l'admettre, le marketing fonctionne. Une bonne campagne marketing peut alimenter le bouche à oreille autour d'un produit open-source, au point que même les codeurs les plus bornés se retrouvent à voir d'un bon œil le logiciel pour des raisons qu'ils ne peuvent pas vraiment définir. Ce n'est pas mon rôle ici de disséquer la course à l'armement du marketing en général. Toute entreprise engagée dans un logiciel libre se retrouvera finalement à réfléchir aux moyens de se vendre, de vendre le logiciel ou de vendre ses relations avec le logiciel. Les conseils ci-dessous vous aideront à éviter les pièges classiques de ce type d'effort, voir aussi la section appelée « Publicité » dans le Chapitre 6, Communication.
Remember That You Are Being Watched / Souvenez vous que vous êtes surveillé
For the sake of keeping the volunteer developer community on your side, it is very important not to say anything that isn't demonstrably true. Audit all claims carefully before making them, and give the public the means to check your claims on their own. Independent fact checking is a major part of Open Source, and it applies to more than just the code.
Afin de conserver la communauté de développeurs bénévoles de votre côté il est très important de ne rien dire qui ne soit pas vérifiable. Sondez toutes les affirmations avec attention avant de les faire et donnez au public les moyens de les vérifier de son côté. La vérification indépendante et rapide est une grande part de l'Open Source et cela s'applique au-delà du code.
Naturally no one would advise companies to make unverifiable claims anyway. But with Open Source activities, there is an unusually high quantity of people with the expertise to verify claims—people who are also likely to have high-bandwidth Internet access and the right social contacts to publicize their findings in a damaging way, should they choose to. When Global Megacorp Chemical Industries pollutes a stream, that's verifiable, but only by trained scientists, who can then be refuted by Global Megacorp's scientists, leaving the public scratching their heads and wondering what to think. On the other hand, your behavior in the Open Source world is not only visible and recorded; it is also easy for many people to check it independently, come to their own conclusions, and spread those conclusions by word of mouth. These communications networks are already in place; they are the essence of how Open Source operates, and they can be used to transmit any sort of information. Refutation is usually difficult, if not impossible, especially when what people are saying is true.
Évidemment, personne ne conseillerait aux entreprises de donner des informations non-vérifiables de toute façon. Mais dans les activités Open Source il y a un nombre exceptionnellement élevé de gens qui possèdent les compétences les vérifier les affirmations, des gens qui ont probablement une connexion à Internet à haut-débit et les contacts qu'il faut pour publier leurs découvertes et faire des dégâts s'ils le veulent. Quand une grande industrie chimique pollue une rivière, c'est vérifiable, mais seulement par des scientifiques formés, qui peuvent être réfutés par les scientifiques de cette industrie chimique, le public, perplexe se demandera ce qu'il doit en penser. A l'opposé, votre comportement dans le monde Open Source n'est pas seulement visible et enregistré, il est aussi facile pour beaucoup de personnes de le vérifier indépendamment, d'aboutir à leurs propres conclusions et de propager ces conclusions par le bouche à oreille. Ces voies de communications sont déjà établies, c'est l'essence même du fonctionnement de l'Open Source, et elles peuvent être utilisées pour transmettre toutes sortes d'informations. Vous défendre est en général très dur, voir impossible, en particulier quand ce que les gens disent est vrai.
For example, it's okay to refer to your organization as having "founded project X" if you really did. But don't refer to yourself as the "makers of X" if most of the code was written by outsiders. Conversely, don't claim to have a deeply involved volunteer developer community if anyone can look at your repository and see that there are few or no code changes coming from outside your organization.
Par exemple, vous pouvez dire que votre organisation a « fondé le projet X » si vous l'avez effectivement fait. Mais ne vous proclamez pas « créateurs de X » si la majeur partie du code a été écrite par des développeurs étrangers à votre projet. A l'inverse, n'affirmez pas que vous avez une communauté de développeurs volontaires profondément engagée si n'importe qui en regardant les dépôts peut voir que peu de changements, voir aucun, proviennent de personnes étrangères à votre entreprise.
Not too long ago, I saw an announcement by a very well-known computer company, stating that they were releasing an important software package under an Open Source license. When the initial announcement came out, I took a look at their now-public version control repository and saw that it contained only three revisions. In other words, they had done an initial import of the source code, but hardly anything had happened since then. That in itself was not worrying—they'd just made the announcement, after all. There was no reason to expect a lot of development activity right away.
Some time later, they made another announcement. Here is what it said, with the name and release number replaced by pseudonyms:Il n'y a pas si longtemps j'ai vu une annonce faite par une entreprise informatique très connue affirmant qu'ils allaient publier un paquet logiciel important sous une licence Open Source. Quand la première annonce a été faite, j'ai jeté un œil à leur dépôt de gestion de version désormais public et j'ai vu qu'il ne contenait que trois révisions. En d'autres termes, ils ont réalisé l'importation du code source mais presque rien n'a changé depuis. Ce n'est pas inquiétant en soi, ils venaient juste de faire l'annonce après tout. Il ne fallait pas s'attendre à voir tout de suite beaucoup d'activité.
Un peu plus tard, ils ont fait une nouvelle annonce. Voilà ce qu'elle disait, les noms et les numéros de version ont été remplacés par des pseudonymes :We are pleased to announce that following rigorous testing by the Singer Community, Singer 5 for Linux and Windows are now ready for production use.Curious to know what the community had uncovered in "rigorous testing," I went back to the repository to look at its recent change history. The project was still on revision 3. Apparently, they hadn't found a single bug worth fixing before the release! Thinking that the results of the community testing must have been recorded elsewhere, I next examined the bug tracker. There were exactly six open issues, four of which had been open for several months already.
Nous sommes heureux d'annoncer qu'après avoir subi des tests rigoureux faits par la Singer Community, Singer 5 pour Linux et Windows est maintenant prêt pour une utilisation professionnelle.Curieux de savoir ce qu'ils avaient découvert par leurs « tests rigoureux », je suis repassé par le dépôt pour y voir l'historique des changements récents. Le projet en était toujours à la version 3. Apparemment, ils n'avaient pas trouver un seul bogue qui valait la peine d'être corrigé avant la sortie ! En pensant que les résultats des tests de la communauté avaient dû être enregistrés quelque part j'ai ensuite examiné le système de suivi de bogues. Il y avait exactement six problèmes a traiter, dont quatre l'étaient déjà depuis quelques mois.
This beggars belief, of course. When testers pound on a large and complex piece of software for any length of time, they will find bugs. Even if the fixes for those bugs don't make it into the upcoming release, one would still expect some version control activity as a result of the testing process, or at least some new issues. Yet to all appearances, nothing had happened between the announcement of the Open Source license and the first Open Source release.
Cela défie l'entendement. Quand les testeurs s'attaquent à de gros morceaux compliqués d'un logiciel pendant un certain temps ils trouveront forcément des bogues. Même si les correctifs pour ces bogues ne sont pas inclus dans la version à venir, on s'attend quand même à voir une certaine activité dans le logiciel de gestion de version, activité résultante du processus de test, ou au moins de nouveaux rapports. Pourtant, selon les apparences, rien ne s'est passé entre l'annonce du passage à une licence open-source et la première version open-source.
The point is not that the company was lying about the community testing. I have no idea if they were or not. But they were oblivious to how much it looked like they were lying. Since neither the version control repository nor the issue tracker gave any indication that the alleged rigorous testing had occurred, the company should either not have made the claim in the first place, or provided a clear link to some tangible result of that testing ("We found 278 bugs; click here for details"). The latter would have allowed anyone to get a handle on the level of community activity very quickly. As it was, it only took me a few minutes to determine that whatever this community testing was, it had not left traces in any of the usual places. That's not a lot of effort, and I'm sure I'm not the only one who took the trouble.
Transparency and verifiability are also an important part of accurate crediting, of course. See the section called “Credit” in Chapter 8, Managing Volunteers for more on this.Le problème n'est pas que l'entreprise a menti à propos des tests faits par la communauté. Je ne sais pas du tout s'ils mentaient ou pas. Mais ils ne se rendaient pas compte qu'un observateur pouvait voir ça comme un gros mensonge. Puisque ni le dépôt de gestion de version ni le suivi de problème ne donnaient d'informations indiquant que le prétendu test rigoureux a eu lieu l'entreprise n'auraient pas dû faire l'annonce du tout ou alors en fournissant un lien clair vers des résultats tangibles des tests (« Nous avons trouvé 278 bogues, cliquez ici pour plus de détails »). Ce dernier aurait permis à n'importe qui de mesurer l'activité de la communauté très rapidement. En l'état, cela m'a pris plusieurs minutes pour déterminer que quoi que fut ce test au final, il n'avait pas laissé de trace aux endroits habituels. Ce n'est pas beaucoup demander et je suis sûr que je ne suis pas le seul à avoir pris la peine de faire cette recherche.
La transparence et la vérifiabilité sont aussi une part importante des remerciements efficaces bien sûr. Voir la section appelée « Remerciements » dans le Chapitre 8, Gérer les volontaires pour plus de détails à ce propos.Don't Bash Competing Open Source Products / N'attaquez pas les produits Open Source concurrents
Refrain from giving negative opinions about competing Open Source software. It's perfectly okay to give negative facts—that is, easily confirmable assertions of the sort often seen in good comparison charts. But negative characterizations of a less rigorous nature are best avoided, for two reasons. First, they are liable to start flame wars that detract from productive discussion. Second, and more importantly, some of the volunteer developers in your project may turn out to work on the competing project as well. This is more likely than it at first might seem: the projects are already in the same domain (that's why they're in competition), and developers with expertise in that domain may make contributions wherever their expertise is applicable. Even when there is no direct developer overlap, it is likely that developers on your project are at least acquainted with developers on related projects. Their ability to maintain constructive personal ties could be hampered by overly negative marketing messages.
Abstenez vous de donner un avis négatif à propos des logiciels open-source concurrents. Il est parfaitement correct de donner des faits négatifs, c'est à dire des affirmations facilement vérifiables comme celles souvent visibles dans les bons tableaux comparatifs. Mais il vaut mieux éviter les caractérisations négatives moins rigoureuses pour deux raisons. Premièrement, elles sont susceptibles de commencer une guerre envenimée qui éloigne des discussions productives. Deuxièmement, et plus important encore, il se peut que certains parmi les développeurs volontaires de votre projet travaillent également sur le projet concurrent. C'est plus probable qu'il n'y paraît de prime abord : les projets sont dans le même domaine (c'est pourquoi ils sont en compétition) et les développeurs ayant des compétences dans ce domaine peuvent apporter leur contribution partout où leur expérience s'applique. Même quand il n'y a pas de chevauchement direct il est probable que les développeurs sur votre projet soient au moins en relation avec les développeurs de l'autre projet. Des messages commerciaux trop négatifs pourraient réduire leur habilité à maintenir des liens personnels constructifs.
Bashing competing closed-source products seems to be more widely accepted in the Open Source world, especially when those products are made by Microsoft. Personally, I deplore this tendency (though again, there's nothing wrong with straightforward factual comparisons), not merely because it's rude, but also because it's dangerous for a project to start believing its own hype and thereby ignore the ways in which the competition may actually be superior. In general, watch out for the effect that marketing statements can have on your own development community. People may be so excited at being backed by marketing dollars that they lose objectivity about their software's true strengths and weaknesses. It is normal, and even expected, for a company's developers to exhibit a certain detachment toward marketing statements, even in public forums. Clearly, they should not come out and contradict the marketing message directly (unless it's actually wrong, though one hopes that sort of thing would have been caught earlier). But they may poke fun at it from time to time, as a way of bringing the rest of the development community back down to earth.
S'attaquer aux produits closed-source concurrents semble être plus largement accepté dans le monde open-source, en particulier quand ces produits sont faits par Microsoft. Personnellement, je déplore cette tendance (bien qu'encore une fois, il n'y a rien de mal à faire une comparaison directe basée sur des faits), non seulement parce que c'est grossier, mais aussi parce qu'il peut être dangereux pour un projet de commencer à croire en son propre « hype » et de ce fait ignorer que les rivaux peuvent en fait être meilleurs. De manière générale faites attention aux effets que peuvent avoir les annonces commerciales sur votre propre communauté de développement. Les gens peuvent devenir tellement enthousiastes à cause du soutien des dollars du marketing qu'ils en perdent leur objectivité vis-à-vis des forces et faiblesses de leur logiciel. Il est normal, et même attendu, de la part des développeurs de l'entreprise de montrer un certain détachement par rapport aux annonces commerciales, même dans les forums publics. Évidemment, ils ne devraient pas contredire le message commercial directement (à moins qu'il soit en fait faux, bien qu'on puisse espérer que ce genre de chose soit détecté plus tôt). Mais ils peuvent le tourner en dérision de temps en temps, c'est un moyen de ramener le reste de la communauté sur Terre.
