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.

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.

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.

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:

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.

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.

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.

Transparencia y verificabilidad son tambien importante parte de la acreditación acertada, desde luego. Ver “Credit” en Capítulo 8, Coordinando a los Voluntarios para más del tema.

Abstente de dar opiniones negativas a otros proyectos libres que compitan con el tuyo. Es perfectamente bien mostrar hechos—negativos que son, acerciones faciles de confirmar del tipo visto en muchas tablas comparativas. Sin embargo, la caracterización negativa es menos rigurosa en naturaleza y es mjeor ser evitada, por dos razones. Primera, es que eres responzable de comenzar una guerra de discusión que pueda distraer de una discusión productiva. Segundo, y más importante, algunos de los desarrolladores voluntarios en tu proyecto pueden estar involucrados en estos proyectos que compitan con el tuyo también. Esto puede ser más probable de lo que originalmente aparente: el proyecto esta ya en el mismo dominio (por eso estan compitiendo), y los desarrolladores con esa experiencia en este dominio puede hacer contribuciones en donde la misma sea aplicable. Aún cuando no sean desarrolladores tán involucrados al mismo grado, es probable que por lo menos existan desarrolladores que esten observando tu proyecto. La habilidad de mantener vínculos constructivos personales pueden ser dañados por mensajes de marketing demasiado negativos.

Hablando mal de productos de código cerrado parece ser más ampliamente aceptado en el mundo del software libre, especialmente cuando estos productos son hechos por Microsoft. Personalmente, yo deploro esta tendencia (aunque al miso tiempo, no hay nada malo en comparaciones factuales), no solo por que es mala educación, pero también por que es peligroso por que un proyecto puede empezar a creerse esta fama e ignorar areas donde el otro proyecto sea en realidad superior. En general, estate atento del efecto que las declaraciones de marketing pueden tener en tu propia comunidad de desarrollo. Las personas pueden estar tan emocionadas de ser respaldadas por algunos dolares de marketing que pierdan la objetvidiad sobre las verdaderas fuerzas y debilidades. Es normal, y aun esperados, para una empresa de desarrolladores el exhibir cierto repudio a las declaraciones de marketing, aun en foros públicos. Claramente, ellos no deberán contradecir el mensaje de marketing directamente (a menos que sean erroneos, aunque uno espera que estas cosas sean detectados más temprano). Pero quizas se mofen de esto de vez en cuando, como una forma de traer el resto de la comunidad de desarrollo de vuelta a la realidad.