POSS Chap 5 Part 7
Un article de Framalang Wiki.
Sommaire |
[modifier] Funding Non-Programming Activities / Financer ce qui ne touche pas à la programmation
Programming is only part of the work that goes on in an Open Source project. From the point of view of the project's volunteers, it's the most visible and glamorous part. This unfortunately means that other activities, such as documentation, formal testing, etc., can sometimes be neglected, at least compared to the amount of attention they often receive in proprietary software. Corporate organizations are sometimes able to make up for this, by devoting some of their internal software development infrastructure to Open Source projects.
La programmation n'est qu'une partie du travail qui se fait au sein d'un projet Open Source. Du point de vue des volontaires du projet c'est la partie la plus visible et la plus glamour. Ce qui veut malheureusement dire que les autres activités, comme la documentation, les tests formels, etc. , peuvent parfois être négligés, au moins par rapport à l'attention qu'ils reçoivent dans les logiciels propriétaires. Les entreprises arrivent parfois à compenser ce vide en assignant une partie de leur infrastructure de développement de logiciel interne à des projets Open Source.
The key to doing this successfully is to translate between the company's internal processes and those of the public development community. Such translation is not effortless: often the two are not a close match, and the differences can only be bridged via human intervention. For example, the company may use a different bug tracker than the public project. Even if they use the same tracking software, the data stored in it will be very different, because the bug-tracking needs of a company are very different from those of a free software community. A piece of information that starts in one tracker may need to be reflected in the other, with confidential portions removed or, in the other direction, added.
La clé du succès de cette opération est de réussir à faire la transition entre les processus internes de l'entreprise et ceux de la communauté de développement publique. Une telle transition ne se fait pas toute seule : souvent les deux groupes ne se ressemblent en rien et les différences peuvent être gommées uniquement par une intervention humaine. Par exemple, l'entreprise peut utiliser un système de suivi de bogues différent de celui du projet publique. Même s'ils utilisent le même logiciel de suivi, les données qui y sont stockées seront très différentes puisque les besoins de suivi de bogue d'une entreprise sont très différents de ceux d'une communauté de logiciel libre. Une information inscrite dans un suivi devrait peut-être apparaître dans l'autre, en enlevant les parties confidentielles ou, à l'inverse, en en ajoutant.
The sections that follow are about how to build and maintain such bridges. The end result should be that the Open Source project runs more smoothly, the community recognizes the company's investment of resources, and yet does not feel that the company is inappropriately steering things toward its own goals.
Les parties qui suivent traitent de la création et du maintien de ces connexions. Au final le projet Open Source devrait tourner plus souplement, la communauté reconnaissant le fait que l'entreprise investit une partie de ses ressources sans pour autant avoir l'impression que l'entreprise tente de diriger de manière inappropriée les choses pour atteindre ses propres buts.
[modifier] Quality Assurance (i.e., Professional Testing) / Assurance Qualité (ou : Les tests professionnels)
In proprietary software development, it is normal to have teams of people dedicated solely to quality assurance: bug hunting, performance and scalability testing, interface and documentation checking, etc. As a rule, these activities are not pursued as vigorously by the volunteer community on a free software project. This is partly because it's hard to get volunteer labor for unglamorous work like testing, partly because people tend to assume that having a large user community gives the project good testing coverage, and, in the case of performance and scalability testing, partly because volunteers often don't have access to the necessary hardware resources anyway.
Pour le développement d'un logiciel propriétaire il est normal d'avoir des équipes dédiées entièrement à l'assurance qualité : chasse aux bogues, tests de performances et d'extensibilité, vérification de l'interface et de la documentation, etc. Par expérience, ces activités ne sont pas traitées avec autant d'ardeur par la communauté de volontaires dans un projet de logiciel libre. C'est en partie dû au fait qu'il est difficile d'avoir des volontaires pour ces travaux peu valorisants comme les tests, en partie également parce que les gens se disent qu'ils disposent d'une grande communauté d'utilisateurs qui fournit un travail de test important au projet et, en ce qui concerne les performances et l'extensibilité, en partie parce que les volontaires ont rarement accès aux ressources matérielles suffisantes de toute façon.
The assumption that having many users is equivalent to having many testers is not entirely baseless. Certainly there's little point assigning testers for basic functionality in common environments: bugs there will quickly be found by users in the natural course of things. But because users are just trying to get work done, they do not consciously set out to explore uncharted edge cases in the program's functionality, and are likely to leave certain classes of bugs unfound. Furthermore, when they discover a bug with an easy workaround, they often silently implement the workaround without bothering to report the bug. Most insidiously, the usage patterns of your customers (the people who drive your interest in the software) may differ in statistically significant ways from the usage patterns of the Average User In The Street.
L'hypothèse selon laquelle avoir beaucoup d'utilisateurs revient au même que d'avoir beaucoup de testeurs n'est pas totalement infondée. Ce n'est certainement pas très utile d'assigner des testeurs aux fonctions basiques en utilisation normale : ces bogues la seront rapidement détectés par les utilisateurs au cours de leur utilisation normale. Mais parce que les utilisateurs essayent simplement d'obtenir un résultat, ils ne vont pas d'eux même se mettre à explorer les confins inexplorés des fonctionnalités du programme et laisseront certainement passer certaines catégories de bogues. De plus, quand ils trouvent un bogue que l'on peut contourner facilement, ils utilisent souvent l'astuce sans prendre la peine de remonter le bogue. Plus insidieusement, l'utilisation que font vos clients (les personnes qui motivent votre intérêt pour le logiciel) du programme peut être complètement différente de l'usage qu'en fait l'utilisateur lambda.
A professional testing team can uncover these sorts of bugs, and can do so as easily with free software as with proprietary software. The challenge is to convey the testing team's results back to the public in a useful form. In-house testing departments usually have their own way of reporting test results, involving company-specific jargon, or specialized knowledge about particular customers and their data sets. Such reports would be inappropriate for the public bug tracker, both because of their form and because of confidentiality concerns. Even if your company's internal bug tracking software were the same as that used by the public project, management might need to make company-specific comments and metadata changes to the issues (for example, to raise an issue's internal priority, or schedule its resolution for a particular customer). Usually such notes are confidential—sometimes they're not even shown to the customer. But even when they're not confidential, they're of no concern to the public project, and therefore the public should not be distracted with them.
Une équipe de test professionnelle peut mettre à jour ce genre de bogues et peut le faire aussi facilement avec un logiciel libre qu'avec un logiciel propriétaire. Le défi est d'apporter les résultats de l'équipe de test au public de manière utile. Les services de tests internes ont en général leur propre manière de rapporter les résultats des tests, en employant un jargon spécifique à l'entreprise ou une connaissance spécialisée de clients particuliers et de leurs ensembles de données. Ce genre de rapports ne seraient pas adaptés dans un système de suivi de bogues public, à la fois à cause de leur forme et pour des problèmes de confidentialité. Même si le logiciel de suivi interne de bogues de votre entreprise est le même que celui utilisé par le projet public les dirigeants pourraient avoir besoin de faire des commentaires spécifiques aux entreprises et d'apporter des changements aux metadonnées concernant les incidents (par exemple, pour élever la priorité interne du problème ou prévoir sa résolution pour un client en particulier). En général ce type de note est confidentielle, parfois elles ne sont même pas montrées au client. Mais quand bien même elles ne seraient pas confidentielles, elles ne concernent en rien le projet public et par conséquent elles ne devraient pas distraire le public.
Yet the core bug report itself is important to the public. In fact, a bug report from your testing department is in some ways more valuable than one received from users at large, since the testing department probes for things that other users won't. Given that you're unlikely to get that particular bug report from any other source, you definitely want to preserve it and make it available to the public project.
C'est le cœur du rapport de bogue lui-même qui est important pour le public. En fait, un rapport de bogue émanant de votre service de test a en quelque sorte plus de valeur qu'un autre envoyé par un utilisateur quelconque puisque le service de test pousse plus loin ses investigations que les autres utilisateurs. Comme il est peu probable que vous receviez ce rapport de bogue précis de la part d'une autre source vous avez vraiment intérêt à le préserver et le rendre disponible au projet public.
To do this, either the QA department can file issues directly in the public issue tracker, if they're comfortable with that, or an intermediary (usually one of the developers) can "translate" the testing department's internal reports into new issues in the public tracker. Translation simply means describing the bug in a way that makes no reference to customer-specific information (the reproduction recipe may use customer data, assuming the customer approves it, of course).
Le service qualité peut remplir un rapport directement dans le suivi public de problèmes s'ils sont suffisamment à l'aise avec ou alors un intermédiaire (en général l'un des développeurs) peut « traduire » le rapport interne du service de test en un nouveau problème dans le suivi public. Traduire signifie simplement décrire le bogue de manière à ne pas faire référence à des informations confidentielles du client (la manière de le faire survenir peut utiliser des données du client, si le client est d'accord évidemment).
It is somewhat preferable to have the QA department filing issues in the public tracker directly. That gives the public a more direct appreciation of your company's involvement with the project: useful bug reports add to your organization's credibility just as any technical contribution would. It also gives developers a direct line of communication to the testing team. For example, if the internal QA team is monitoring the public issue tracker, a developer can commit a fix for a scalability bug (which the developer may not have the resources to test herself), and then add a note to the issue asking the QA team to see if the fix had the desired effect. Expect a bit of resistance from some of the developers; programmers have a tendency to regard QA as, at best, a necessary evil. The QA team can easily overcome this by finding significant bugs and filing comprehensible reports; on the other hand, if their reports are not at least as good as those coming from the regular user community, then there's no point having them interact directly with the development team.
Il est préférable, d'une certaine manière, que le service qualité remplisse les rapports dans le système de suivi public directement. Cela rend plus visible l'implication de votre entreprise dans le projet : des rapports de bogue utiles consolideront la crédibilité de votre entreprise autant que le ferai n'importe quelle contribution technique. Cela créé également un lien direct entre les développeurs et l'équipe de test. Par exemple, si l'équipe qualité interne surveille le système de suivi public, un développeur peut valider un correctif pour un bogue d'extensibilité (pour lequel le développeur peut ne pas avoir les ressources nécessaires au test) en ajoutant une note au rapport demandant à l'équipe qualité de vérifier si le correctif a l'effet désiré. Attendez vous à voir une certaine résistance de la part de certains développeurs, les programmeurs ont tendance à voir le service qualité comme un mal nécessaire au mieux. L'équipe qualité peut facilement surmonter ceci en trouvant des bogues importants et en remplissant des rapports compréhensibles. D'un autre côté, si les rapports ne sont pas au moins aussi bons que ceux provenant de la communauté d'utilisateurs réguliers alors il n'y a aucun intérêt à la faire interagir directement avec l'équipe de développement.
Either way, once a public issue exists, the original internal issue should simply reference the public issue for technical content. Management and paid developers may continue to annotate the internal issue with company-specific comments as necessary, but use the public issue for information that should be available to everyone.
Quoi qu'il en soit, une fois qu'un rapport public existe, le rapport interne original devrait simplement faire référence au rapport public pour ce qui est du contenu technique. La direction et les développeurs payés peuvent continuer à annoter le rapport interne avec des commentaires particuliers à l'entreprise comme ils le jugent nécessaire, mais en continuant à utiliser le rapport public pour les informations qui devraient être disponibles à tous.
You should go into this process expecting extra overhead. Maintaining two issues for one bug is, naturally, more work than maintaining one issue. The benefit is that many more coders will see the report and be able to contribute to a solution.
En vous engageant dans cette voie vous devez vous attendre à plus de contraintes de gestion. Maintenir deux rapports pour un bogue représente, naturellement, plus de travail que de maintenir un seul rapport. L'avantage est que beaucoup plus de codeurs verront ce rapport et pourront apporter leur contribution à la solution.
[modifier] Legal Advice and Protection / Conseils légaux et protection
Corporations, for-profit or nonprofit, are almost the only entities that ever pay attention to complex legal issues in free software. Individual developers often understand the nuances of various Open Source licenses, but they generally do not have the time or resources to follow copyright, trademark, and patent law in detail. If your company has a legal department, it can help a project by vetting the copyright status of the code, and helping developers understand possible patent and trademark issues. The exact forms this help could take are discussed in Chapter 9, Licenses, Copyrights, and Patents. The main thing is to make sure that communications between the legal department and the development community, if they happen at all, happen with a mutual appreciation of the very different universes the parties are coming from. On occasion, these two groups talk past each other, each side assuming domain-specific knowledge that the other does not have. A good strategy is to have a liaison (usually a developer, or else a lawyer with technical expertise) stand in the middle and translate for as long as needed.
Les organisations, qu'elles soient à but lucratif ou à but non-lucratif, sont presque les seules entités à prêter attention aux problèmes légaux dans les logiciels libres. Les développeurs individuels comprennent souvent les nuances entre les différentes licences Open Source, mais ils n'ont en général ni le temps ni les ressources pour suivre les lois sur le droit d'auteur, les marques déposées et les brevets en détail. Si votre entreprise a un service légal, il peut aider un projet en contrôlant les droits d'auteur du code et en aidant les développeurs à comprendre les possibles problèmes liés aux brevets et marques déposées. Dans le Chapitre 9, Licences, droits d'auteurs et brevets nous aborderons plus en détail la forme exacte que peut prendre cette aide. Le plus important est de vous assurer que la communication entre le service légal et la communauté de développement, si elle existe, se fasse en tenant comptes des différences entre les deux parties. Il arrive que ces deux groupes s'ignorent, chacun pensant que l'autre groupe n'a pas la connaissance spécifique requise. Une bonne stratégie est d'avoir un lien (en général un développeur ou alors un avocat ayant des connaissances techniques) entre les deux pour assurer le lien aussi longtemps que nécessaire.
[modifier] Documentation and Usability / Documentation et convivialité
Documentation and usability are both famous weak spots in Open Source projects, although I think, at least in the case of documentation, that the difference between free and proprietary software is frequently exaggerated. Nevertheless, it is empirically true that much Open Source software lacks first-class documentation and usability research.
La documentation et la convivialité sont deux points faibles connus des projets Open Source, bien que, à mon avis, au moins en ce qui concerne la documentation, la différence entre les logiciels libres et propriétaires est souvent exagérée. Néanmoins, par expérience on constate que beaucoup de projets Open Source n'ont pas de documentation de 1ère classe ni ne recherchent la convivialité.
If your organization wants to help fill these gaps for a project, probably the best thing it can do is hire people who are not regular developers on the project, but who will be able to interact productively with the developers. Not hiring regular developers is good for two reasons: one, that way you don't take development time away from the project; two, those closest to the software are usually the wrong people to write documentation or investigate usability anyway, because they have trouble seeing the software from an outsider's point of view.
Si votre entreprise veut aider à remplir ces vides dans un projet, la meilleure chose qu'elle pourra faire sera certainement d'engager des gens qui ne sont pas des développeurs réguliers du projet mais qui seront capables d'interagir productivement avec les développeurs. Ne pas engager des développeurs déjà présents est une bonne chose pour deux raisons : d'une, vous ne rognerez pas sur le temps de développement et de deux, ceux qui sont au plus près du logiciel ne sont en général pas les mieux placés pour écrire la documentation ou pour en étudier la convivialité de toute façon parce qu'ils ont du mal à voir le logiciel du point de vue d'une personne extérieure au développement.
However, it will still be necessary for whoever works on these problems to communicate with the developers. Find people who are technical enough to talk to the coding team, but not so expert in the software that they can't empathize with regular users anymore.
De toute façon, il sera nécessaire pour les personnes qui travaillent sur ces problèmes de communiquer avec les développeurs. Trouvez des gens qui ont un niveau technique suffisant pour parler à l'équipe de programmation, mais qui ne sont pas autant impliqués dans le logiciel afin qu'ils puissent s'identifier aux utilisateurs normaux.
A medium-level user is probably the right person to write good documentation. In fact, after the first edition of this book was published, I received the following e-mail from an Open Source developer named Dirk Reiners:
Un utilisateur de niveau moyen est certainement la personne la plus à même d'écrire une bonne documentation. En fait, après la publication de la première édition de ce livre j'ai reçu ce mail d'un développeur Open Source qui s'appelle Dirk Reiners :
One comment on Money::Documentation and Usability: when we had some money to spend and decided that a beginner's tutorial was the most critical piece that we needed we hired a medium-level user to write it. He had gone through the induction to the system recently enough to remember the problems, but he had gotten past them so he knew how to describe them. That allowed him to write something that needed only minor fixes by the core developers for the things that he hadn't gotten
right, but still covering the 'obvious' stuff devs would have missed.His case was even better, as it had been his job to introduce a bunch of other people (students) to the system, so he combined the experience of many people, which is something that was just a lucky occurrence and is
probably hard to get in most cases.Un commentaire sur L'argent; « Documentation et convivialité » : quand nous avons eu de l'argent à dépenser et que nous avons décidé qu'un tutoriel pour débutant était ce dont nous avions besoin en priorité nous avons engagé un utilisateur de niveau moyen pour l'écrire. Il était passé par la phase d'apprentissage suffisamment récemment pour se souvenir des problèmes, mais il les avait surmontés, il savait donc comment les décrire. Cela lui a permis d'écrire quelque chose qui ne nécessitait plus que des petites corrections par les développeurs pour ce qu'il n'avait pas écrit correctement, mais il couvrait quand même ces choses « évidentes » que les développeurs auraient omises.
Sa situation était idéale puisque ça avait été son boulot de présenter le logiciel à d'autres personnes (des étudiants), il rassemblait donc l'expérience de beaucoup d'utilisateurs, ce qui était une coïncidence heureuse et qui est certainement difficile à obtenir dans la plupart des cas[modifier] Providing Hosting/Bandwidth / Fournir hébergement/bande passante
For a project that's not using one of the free canned hosting sites (see the section called “Canned Hosting” in Chapter 3, Technical Infrastructure), providing a server and network connection—and most importantly, system administration help—can be of significant assistance. Even if this is all your organization does for the project, it can be a moderately effective way to obtain good public relations karma, though it will not bring any influence over the direction of the project.
Pour un projet qui n'utilise pas un service d'hébergement tout compris gratuit (voir la section appelée « Forges » dans la Chapitre 3, Infrastructure technique), fournir un serveur et une connexion réseau et, plus important encore, une aide à l'administration système, peut être d'une importance primordiale. Même si c'est tout ce que votre organisation fera pour le projet cela peut être une manière relativement efficace d'entretenir une bonne image mais cela ne vous apportera aucune influence sur les décisions prises par le projet.
You can probably expect a banner ad or an acknowledgment on the project's home page, thanking your company for providing hosting. If you set up the hosting so that the project's Web address is under your company's domain name, then you will get some additional association just through the URL. This will cause most users to think of the software as having something to do with your company, even if you don't contribute to development at all. The problem is, the developers are aware of this associative tendency too, and may not be very comfortable with having the project in your domain unless you're contributing more resources than just bandwidth. After all, there are a lot of places to host these days. The community may eventually feel that the implied misallocation of credit is not worth the convenience brought by hosting, and take the project elsewhere. So if you want to provide hosting, do so—but either plan to get even more involved soon, or be circumspect about how much involvement you claim.
Vous pouvez sûrement espérer une bannière de publicité ou un signe de reconnaissance sur la page principale du projet, remerciant votre entreprise pour la mise à disposition de l'hébergement. Si vous faites en sorte que l'adresse Web du projet soit sous le nom de votre entreprise alors vous obtiendrez une association un peu plus marquée simplement au travers de l'URL. La plupart des utilisateurs penseront que le logiciel a un rapport avec votre entreprise, même si vous n'apportez rien du tout au développement. Le problème est que les développeurs ne sont pas dupes et ne seront pas forcément satisfaits que vous hébergiez le projet sauf si vous apportez plus de ressources que simplement de la bande passante. Après tout, il y a de nombreuses possibilités d'hébergement maintenant. La communauté pourra au final décider que ce mérite indu ne vaut pas la commodité apportée par l'hébergement offert et décidera de déménager le projet ailleurs. Donc si vous voulez offrir un hébergement, faites le, mais prévoyez de vous impliquer encore plus rapidement ou soyez circonspect à propos du niveau d'engagement que vous prétendez fournir.
