POSS Chap 5 Intro
Un article de Framalang Wiki.
This chapter examines how to bring funding into a free software environment. It is aimed not only at developers who are paid to work on free software projects, but also at their managers, who need to understand the social dynamics of the development environment. In the sections that follow, the addressee ("you") is presumed to be either a paid developer, or one who manages such developers. The advice will often be the same for both; when it's not, the intended audience will be made clear from context.
Ce chapitre examine les moyens d'apporter un financement à un projet de logiciel libre. Il ne concerne pas uniquement les développeurs payés pour travailler sur des projets de logiciel libre mais aussi leurs managers qui doivent comprendre les règles sociales qui régissent le cadre du développement. Dans les parties qui suivent, nous ferons l'hypothèse que le destinataire ("vous") est soit un développeur payé soit un manager. Les conseils seront souvent valables pour les deux, si ce n'est pas le cas, le contexte précisera de manière claire le type de personne visée.
Corporate funding of free software development is not a new phenomenon. A lot of development has always been informally subsidized. When a system administrator writes a network analysis tool to help her do her job, then posts it online and gets bug fixes and feature contributions from other system administrators, what's happened is that an unofficial consortium has been formed. The consortium's funding comes from the sysadmins' salaries, and its office space and network bandwidth are donated, albeit unknowingly, by the organizations they work for. Those organizations benefit from the investment, of course, although they may not be institutionally aware of it at first.
Le financement du développement d'un logiciel libre par une entreprise n'a rien de nouveau. De nombreux développements ont toujours été subventionnés de manière officieuse. Lorsqu'un administrateur système écrit un outil d'analyse système pour l'aider dans son travail et ensuite le publie en ligne et reçoit une aide pour corriger les bogues ainsi qu'une contribution d'autres administrateurs systèmes on peut dire qu'un consortium officieux s'est formé. Le financement de ce consortium provient du salaire des administrateurs systèmes et leur bureau et la bande passante sont pourvus, même si c'est sans le savoir, par les entreprises pour lesquels ils travaillent. Ces entreprises profitent de cet investissement, bien sûr, bien qu'elles n'en soient pas officiellement au courant au départ.
The difference today is that many of these efforts are being formalized. Corporations have become conscious of the benefits of Open Source software, and started involving themselves more directly in its development. Developers too have come to expect that really important projects will attract at least donations, and possibly even long-term sponsors. While the presence of money has not changed the basic dynamics of free software development, it has greatly changed the scale at which things happen, both in terms of the number of developers and time-per-developer. It has also had effects on how projects are organized, and on how the parties involved in them interact. The issues are not merely about how the money is spent, or how return on investment is measured. They are also about management and process: how can the hierarchical command structures of corporations and the semi-decentralized volunteer communities of free software projects work productively with each other? Will they even agree on what "productively" means?
Ce qui change aujourd'hui est que ces efforts sont en cours de formalisation. Les entreprises ont pris conscience des avantages des logiciels Open Source et ont commencé à plus s'impliquer dans leur développement. Les développeurs également en sont venus à s'attendre à ce que les projets vraiment importants captent au minimum des dons et pourquoi pas même des sponsors sur le long terme. Alors que la présence d'argent n'a rien changé au principe de base du développement de logiciels libres cela a beaucoup modifié l'échelle à laquelle se font les choses, à la fois en terme du nombre de développeurs et en temps par développeur. Cela a également eu une incidence sur la manière dont sont organisés les projets et sur les interactions entre les groupes impliqués. Les questions ne portent pas simplement sur la manière de dépenser l'argent ou sur les moyens de mesurer le retour sur investissement. Elles touchent aussi à l'organisation et aux procédures : comment peut-on faire cohabiter les organisations hiérarchisées des entreprises avec les communautés semi-décentralisées du logiciel libre pour en tirer le meilleur ? Auront-ils d'ailleurs la même conception de ce qu'est «
le meilleur » ?
Financial backing is, in general, welcomed by Open Source development communities. It can reduce a project's vulnerability to the Forces of Chaos, which sweep away so many projects before they really get off the ground, and therefore it can make people more willing to give the software a chance—they feel they're investing their time into something that will still be around six months from now. After all, credibility is contagious, to a point. When, say, IBM backs an Open Source project, people pretty much assume the project won't be allowed to fail, and their resultant willingness to devote effort to it can make that a self-fulfilling prophecy.
Un soutien financier est, en général, accueillit les bras ouverts par les communautés de développement Open Source. Il peut réduire la vulnérabilité du projet face aux Forces du Chaos qui emportent tant de projets avant qu'ils ne décollent vraiment et donc il peut aider les gens à donner une chance au logiciel plus facilement, ils se disent alors qu'ils vont investir de leur temps dans quelque chose qui fonctionnera encore dans six mois. Après tout, la crédibilité est contagieuse d'un certain point de vue. Quand, par exemple, IBM soutient un projet Open Source, les gens se disent que le projet n'aura pas le droit d'échouer et leur motivation résultante à y consacrer leurs efforts pourra faire que la prophétie s'auto-réalisera.
However, funding also brings a perception of control. If not handled carefully, money can divide a project into in-group and out-group developers. If the unpaid volunteers get the feeling that design decisions or feature additions are simply available to the highest bidder, they'll head off to a project that seems more like a meritocracy and less like unpaid labor for someone else's benefit. They may never complain overtly on the mailing lists. Instead, there will simply be less and less noise from external sources, as the volunteers gradually stop trying to be taken seriously. The buzz of small-scale activity will continue, in the form of bug reports and occasional small fixes. But there won't be any large code contributions or outside participation in design discussions. People sense what's expected of them, and live up (or down) to those expectations.
Cependant, le financement implique une idée de contrôle également. En cas de mauvaise gestion, l'argent peut diviser le projet en deux castes : les développeurs qui font parti du groupe et les autres. Si les développeurs bénévoles ont la sensation que les décisions sur la construction et les nouvelles fonctionnalités reviennent à celui qui fera l'enchère la plus haute ils s'enfuiront vers un projet qui paraît plus basé sur le mérite et qui apparaît moins comme un travail non rémunéré profitant à quelqu'un d'autre. Ils ne s'en plaindront pas forcément ouvertement dans les listes de diffusion. A la place, vous remarquerez de moins en moins de contributions externes à mesure que les volontaires arrêtent d'essayer de se voir accorder une certaine crédibilité. Le bourdonnement de l'activité à petite échelle continuera, sous forme de rapports de bogues ou de petits correctifs occasionnels. Mais vous ne verrez plus de grande contribution au code ou de participation extérieure dans les discussions portant sur la construction. Les gens ressentent ce que l'on attend d'eux et répondent (ou pas) à ces attentes.
Although money needs to be used carefully, that doesn't mean it can't buy influence. It most certainly can. The trick is that it can't buy influence directly. In a straightforward commercial transaction, you trade money for what you want. If you need a feature added, you sign a contract, pay for it, and it gets done. In an Open Source project, it's not so simple. You may sign a contract with some developers, but they'd be fooling themselves—and you—if they guaranteed that the work you paid for would be accepted by the development community simply because you paid for it. The work can only be accepted on its own merits and on how it fits into the community's vision for the software. You may have some say in that vision, but you won't be the only voice.
Bien que vous devez faire attention à comment vous dépenser l'argent ça ne veut pas dire qu'il ne peut pas acheter de l'influence. L'argent peut très bien faire ça. Le truc est qu'il ne peut pas le faire directement. Dans un échange commercial simple, vous donnez de l'argent pour ce que vous désirez. Si vous avez besoin d'une fonctionnalité supplémentaire, vous signez un contrat, payez votre part et elle sera réalisée. Dans un projet Open Source ce n'est pas si simple. Vous pouvez signer un contrat avec quelques développeurs, mais ils se duperaient, et vous aussi, s'ils vous garantissaient que le travail pour lequel vous avez payé sera accepté par la communauté de développement simplement parce que vous avez payé. Le travail ne peut être accepté que pour son propre mérite et s'il correspond aux projets qu'a la communauté pour le logiciel. Vous pouvez avoir votre mot à dire dans ces projets, mais vous n'êtes pas le seul.
So money can't purchase influence, but it can purchase things that lead to influence. The most obvious example is programmers. If good programmers are hired, and they stick around long enough to get experience with the software and credibility in the community, then they can influence the project by the same means as any other member. They will have a vote, or if there are many of them, they will have a voting bloc. If they are respected in the project, they will have influence beyond just their votes. There is no need for paid developers to disguise their motives, either. After all, everyone who wants a change made to the software wants it for a reason. Your company's reasons are no less legitimate than anyone else's. It's just that the weight given to your company's goals will be determined by its representatives' status in the project, not by the company's size, budget, or business plan.
Donc l'argent ne peut pas vous acheter de l'influence mais il peut vous payer des choses qui vous apporteront de l'influence. L'exemple le plus évident est les programmeurs. Si de bon programmeurs sont engagés, et qu'ils restent suffisamment longtemps pour acquérir de l'expérience dans ce logiciel et de la crédibilité dans la communauté, alors ils peuvent influencer le projet comme n'importe quel autre membre. Ils auront une voix dans les votes, ou s'ils sont nombreux, ils auront un ensemble de votes. S'ils sont respectés dans le projet leur influence portera plus loin que leur simple vote. Les développeurs rémunérés n'ont pas de raison de cacher leurs motivations non plus. Après tout, n'importe qui désirant qu'une modification soit apportée au logiciel le fait pour des raisons. Les raisons de votre entreprise ne sont pas moins valables que celles de quelqu'un d'autre. Il faut juste savoir que le poids accordé aux objectifs de votre entreprise sera déterminé par le statut de ses représentants dans le projet, pas par la taille de l'entreprise ou par son modèle économique.
