POSS Chap 5 Part 1
Un article de Framalang Wiki.
[modifier] Types of Involvement / Les différentes participations
There are many different reasons Open Source projects get funded. The items in this list aren't mutually exclusive; often a project's financial backing will result from several, or even all, of these motivations:
Sharing the burden
Separate organizations with related software needs often find themselves duplicating effort, either by redundantly writing similar code in-house, or by purchasing similar products from proprietary vendors. When they realize what's going on, the organizations may pool their resources and create (or join) an Open Source project tailored to their needs. The advantages are obvious: the costs of development are divided, but the benefits accrue to all. Although this scenario seems most intuitive for nonprofits, it can make strategic sense even for for-profit competitors.Il y a beaucoup de raisons différentes pour lesquelles les projets Open Source sont supportés. Les points de cette liste ne s'excluent pas mutuellement, souvent le support financier d'un projet résultera de plusieurs, voir de toutes, ces motivations :
Partager la charge
Des organismes distincts ayant des besoins logiciels liés se retrouvent souvent à dupliquer les efforts, soit en écrivant du code redondant en interne, soit en achetant des produits similaires à des vendeurs propriétaires. Quand ils réalisent ce qui arrive, les organismes peuvent fusionner leurs ressources et créer (ou rejoindre) un projet Open Source sur-mesure qui correspond à leurs besoins. Les avantages sont évidents : les coûts de développement sont divisés mais les gains sont accrus pour tout le monde. Bien que ce scénario paraisse plus logique pour des organisations à but non lucratif cela peut être une stratégie payante pour les entreprises commerciales.Augmenting services
When a company sells services which depend on, or are made more attractive by, particular Open Source programs, it is naturally in that company's interests to ensure those programs are actively maintained. Example: CollabNet's support of http://subversion.tigris.org/ (disclaimer: that's my day job, but it's also a perfect example of this model). Examples : http://www.openadapter.org/, http://www.koha.org/
Accroître les services
Lorsqu'une compagnie vend des services qui dépendent de programmes Open Source particuliers, ou qui sont rendus attirants par ceux-ci, il est naturellement dans l'intérêt de cette compagnie de s'assurer que ces programmes soient activement maintenus.
Exemple : Le support de CollabNet au site http://subversion.tigris.org/ (note : c'est mon travail, mais c'est aussi un parfait exemple de ce modèle).Exemples: http://www.openadapter.org/, http://www.koha.org/
Supporting hardware sales
The value of computers and computer components is directly related to the amount of software available for them. Hardware vendors—not just whole-machine vendors, but also makers of peripheral devices and microchips—have found that having high-quality free software to run on their hardware is important to customers. Undermining a competitor
Sometimes companies support a particular Open Source project as a means of undermining a competitor's product, which may or may not be Open Source itself. Eating away at a competitor's market share is usually not the sole reason for getting involved with an Open Source project, but it can be a factor.
Example: http://www.openoffice.org/ (no, this isn't the only reason OpenOffice exists, but the software is at least partly a response to Microsoft Office).
Renforcer l'offre matériel
La valeur des ordinateurs et des composants pour ordinateurs est directement liée au nombre de logiciels disponibles. Les vendeurs de matériel, pas uniquement les vendeurs de machines complètes, mais aussi les fabricants de périphériques et de micropuces, se sont aperçus qu'avoir des logiciels libres de haute qualité pour leur matériel est important pour les clients.
Parfois les entreprises apportent leur soutien à un projet Open Source particulier de manière à affaiblir le produit d'un concurrent, qui peut être lui même Open Source ou non. Grignoter des parts de marché d'un concurrent n'est en général pas la seule raison pour s'investir dans un projet Open Source, mais cela peut compter.
Exemple : http://www.openoffice.org/ (non, ce n'est pas la seule raison d'exister d'OpenOffice, mais le logiciel est au moins en parti une réponse à Microsoft Office).Marketing
Having your company associated with a popular Open Source application can be simply good brand management.
Dual-licensing
Dual-licensing is the practice of offering software under a traditional proprietary license for customers who want to resell it as part of a proprietary application of their own, and simultaneously under a free license for those willing to use it under Open Source terms (see the section called “Dual Licensing Schemes” in Chapter 9, Licenses, Copyrights, and Patents). If the Open Source developer community is active, the software gets the benefits of wide-area debugging and development, yet the company still gets a royalty stream to support some full-time programmers.
Two well-known examples are MySQL, makers of the database software of the same name, and Sleepycat, which offers distributions and support for the Berkeley Database. It's no coincidence that they're both database companies. Database software tends to be integrated into applications rather than marketed directly to users, so it's very well-suited to the dual-licensing model.
Commercialisation
Avoir une compagnie associée à une application Open Source populaire peut simplement être bon pour l'image de l'entreprise.
Double licence
La double-licence est la pratique qui consiste à proposer des logiciels sous une licence propriétaire classique aux clients qui veulent le revendre au sein d'une de leur application propriétaire et en même temps sous une licence libre pour ceux qui veulent l'utiliser en tant que logiciel Open Source (voir la section appelée « La double licence » dans le Chapitre 9, Licences, droits d'auteurs et brevets). Si la communauté de développeurs Open Source est active, le logiciel bénéficie du développement et de la correction de bogues à grande échelle, mais la compagnie perçoit toujours les redevances qui lui permettent de supporter quelques programmeurs à temps plein.
Deux exemples bien connus sont MySQL, les fabricants du logiciel de base de donnée du même nom et Sleepycat qui s'occupe des distributions et du support de la Berkeley Database. Ce n'est pas une coïncidence si ce sont deux compagnies spécialisées dans les bases de données. Les logiciels de base de données sont souvent intégrés à d'autres applications plutôt que vendus directement aux utilisateurs, le modèle à licence double leur correspond très bien.Donations
A widely-used project can sometimes get significant contributions, from both individuals and organizations, just by having an online donation button, or sometimes by selling branded merchandise such as coffee mugs, T-shirts, mousepads, etc. A word of caution: if your project accepts donations, plan out how the money will be used before it comes in, and state the plans on the project's Web site. Discussions about how to allocate money tend to go a lot more smoothly when held before there's actual money to spend; and anyway, if there are significant disagreements, it's better to find that out while it's still academic.
A funder's business model is not the only factor in how it relates to an Open Source community. The historical relationship between the two also matters: did the company start the project, or is it joining an existing development effort? In both cases, the funder will have to earn credibility, but, not surprisingly, there's a bit more earning to be done in the latter case. The organization needs to have clear goals with respect to the project. Is the company trying to keep a position of leadership, or simply trying to be one voice in the community, to guide but not necessarily govern the project's direction? Or does it just want to have a couple of committers around, able to fix customers' bugs and get the changes into the public distribution without any fuss?
Keep these questions in mind as you read the guidelines that follow. They are meant to apply to any sort of organizational involvement in a free software project, but every project is a human environment, and therefore no two are exactly alike. To some degree, you will always have to play by ear, but following these principles will increase the likelihood of things turning out the way you want.
Les dons
Un programme très utilisé peut parfois recevoir des dons importants, à la fois de particuliers et d'entreprises, simplement en affichant un bouton pour faire des dons en ligne ou parfois en vendant des objets portant leur marque comme des tasses de café, des T-shirts, des tapis de souris, etc. Une chose à laquelle il faut faire attention : si votre projet accepte les dons, décidez de comment l'argent sera utilisé avant de recevoir les dons et afficher les prévisions sur le site Web du projet. Les discussions à propos de l'utilisation de l'argent sont plus calmes quand elles se font avant qu'il n'y ait effectivement de l'argent à dépenser et, de toute façon, s'il y a des désaccords importants il vaut mieux s'en rendre compte quand tout n'est encore que théorique.
Le modèle économique d'un donateur n'est pas le seul facteur entrant en ligne de compte dans ses relations avec la communauté Open Source. Les antécédents entre les deux sont importants aussi : est-ce que la compagnie a initié le projet ou est-ce qu'elle se joint à l'effort de développement déjà existant ? Dans les deux cas, le donateur devra gagner sa crédibilité, mais, sans surprise, il aura un peu plus à faire dans le deuxième cas. L'organisme se doit d'avoir des buts précis en ce qui concerne le projet. Est-ce que la compagnie essaie de conserver une position dominante ou essaie-t-elle d'être une voix au sein de la communauté, de guider mais sans forcément gouverner les décisions du projet ? Ou veut-elle simplement avoir deux committers présents, capables de réparer les bogues que rencontrent leurs clients et d'apporter les modifications dans la distribution publique sans faire de bruit ?
Gardez ces questions à l'esprit en lisant les conseils qui suivent. Ils sont faits pour s'appliquer à toutes sortes d'implications par une organisation dans un projet de logiciel libre, mais chaque projet est un environnement humain et deux situations ne seront jamais pareilles. A un certain point vous aurez toujours à vous fier à votre instinct, mais suivre ces conseils devrait augmenter les chances que les choses fonctionnent comme vous le voulez.
