The words we use to describe what we do can matter a lot in how we in the FOSS community think about what we do. Once upon a time, there was Free Software, as defined by Richard Stallman in the famous Four Freedoms: • The freedom to run the program, for any purpose (freedom 0). • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. • The freedom to redistribute copies so you can help your neighbor (freedom 2). • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Les mots dont nous nous servons pour décrire ce que nous faisons peuvent influer dans une large mesure sur la manière dont nous, les membres de la communauté FOSS, réfléchissons à ce que nous faisons. Il était une fois, les Logiciels libres, tels que définis par Richard Stallman dans ses « Four Freedoms » (Quatre libertés) célèbres : * La liberté d'exécuter le programme, pour quelque usage que ce soit (la liberté 0). * La liberté d'étudier le fonctionnement du programme et de le modifier afin qu'il accomplisse ses tâches comme vous le désirez (la liberté 1). L'accès au code source y est une condition préalable. * La liberté d'en redistribuer des exemplaires afin d'aider votre prochain (la liberté 2). * La liberté de distribuer des exemplaires de vos versions modifiées à d'autres (la liberté 3) Ce faisant, vous offrez à la communauté entière l'occasion de bénéficier de vos modifications. L'accès au code source y est une condition préalable.
Now, I happen to be a big supporter of this. I love the idea of Free Software. And I have noticed that some people I greatly respect, such as Jon ‘maddog’ Hall, are always careful to refer to it as Free Software. Nonetheless, there are problems with this terminology. If you have been around FOSS for very long, you have noticed that the word “free” admits of several meanings, one of which has to with the cost. And that was never the point in FOSS. There is nothing in the definition of FOSS or in the GPL that says you are prohibited from charging for your software. And, because of the ambiguity in “free,” we have to be careful to use “Free As In Freedom” to denote what Stallman meant by the Four Freedoms, as distinct from “Free As In Beer” to denote lack of a monetary price.
Bon, il se trouve que j'en suis un grand défenseur. J'aime l'idée des Logiciels libres. Et j'ai remarqué que certaines personnes que je respecte beaucoup, tel que Jon « maddog » (chien enragé) Hall, s'efforcent toujours d'en parler en termes de Logiciel libre. Il y a, cependant, quelques problèmes avec cette expression. Si vous côtoyez le FOSS depuis un certain temps, vous aurez remarqué que le mot anglais « free » a plusieurs significations, l'une étant à propos du coût. Et cela n'a jamais été l'objectif du FOSS. Il n'y a rien dans la définition de FOSS, ni dans le GPL, qui indique qu'il est interdit de faire payer vos logiciels. Ainsi, à cause de l'ambiguïté de « free », nous devons faire attention d'utiliser « Free as in Freedom » (libre comme la liberté) pour indiquer ce que Stallman voulait dire par les « Four Freedoms », pour le différencier de « Free as in Beer » (gratuit comme la bière), pour signifier la gratuité.
A later term was developed called Open Source, which put the focus on making the source code freely available. Now, it is clear from the Four Freedoms above that this is essential to Free Software, so I am not sure just how big a difference this makes. But if you want to explain to the average user why any of this matters, you have to acknowledge that the average user really doesn’t care if the source code is available since they can never imagine themselves trying to modify the code. In point of fact, I would expect that it is highly likely that I will go to my grave without ever attempting to modify the code of any software I use. I am not a programmer, and I don’t have any desire to be one. I like programmers, some of my best friends are programmers, and the world is undoubtedly a better place because of programmers, but I don’t think that is my role in FOSS. So I don’t have a strong interest in looking at the source code. And to you in the back with your hand up, I agree that it would be silly to buy a car that had the hood welded shut, but I don’t repair my own cars either. Instead I support the economy by helping a mechanic to earn a semi-honest living.
Plus tard, a été développée l'expression Open Source, qui met l'accent sur la disponibilité sans contraintes du code source. Bon, il est clair, étant donné les Four Freedoms ci-dessus, que cela est essentiel aux Logiciels libres et je ne suis donc pas certain que l'expression fasse une grande différence. Toutefois, si vous voulez expliquer à l'utilisateur lambda l'importance de ceci, il faut admettre que l'utilisateur moyen se fiche de savoir si le code source est disponible, puisqu'il ne peut pas se voir en train de le modifier. Pour être honnête, je pense que je serai mort et enterré avant d'avoir essayé de modifier le code de quelque logiciel que ce soit. Je ne suis pas programmeur et je n'ai aucun désir de l'être. J'aime bien les programmeurs, quelques-uns de mes meilleurs amis sont des programmeurs, le monde est sans aucun doute meilleur à cause des programmeurs, mais je ne pense pas que ce soit mon rôle dans le FOSS. Ainsi, regarder le code source ne me paraît pas très intéressant. Et à vous qui êtes impatient d'ajouter votre grain de sel, je suis d'accord que ce serait idiot d'acheter une voiture dont le capot était soudé en position fermée, mais je ne répare pas mes propres voitures non plus. À la place, je soutiens l'économie en aidant un mécanicien à gagner sa vie de façon presque honnête.
The term I have adopted for this purpose is to call what we do “Community-Supported Software,” because I think that puts the emphasis where it more properly belongs, at least for some uses. If we value this software, I think we all have a responsibility to support it in whatever way we can. Some do that as programmers, but the rest of us have a role to play. And I want to explore some of those options (and maybe motivate some people to get involved). Because I think it is true that freedom is never free. It requires all of us to take part in defending and supporting it.
La position que j'ai adoptée dans cette optique est d'appeler ce que nous faisons des « Logiciels soutenus par la Communauté » parce que je crois que cela met l'accent là où il devrait être, au moins pour certaines utilisations. Si ces logiciels nous sont précieux, je pense que nous avons tous la responsabilité de les soutenir dans toute la mesure de nos possibilités. Certains le font comme programmeurs, mais nous autres avons également notre rôle à jouer. Et j'aimerais examiner quelques-unes de ces options (et, peut-être, inciter des gens à s'impliquer). Parce que je pense qu'il est vrai que la liberté n'est jamais gratuite. Nous devons tous prendre part à sa défense et son soutien.
Bug Hunting I’ve already mentioned that Free Software should more properly be considered “Community-Supported” software, and I said I would come back to discuss just what that means. There are lots of ways for someone to support Free Software, but one of the most important is by submitting bugs to the developers. Remember that these fine people are creating wonderful software with minimal budgets, and that means they cannot possibly test their software under all possible conditions. Many of us (myself included) build our own computers out of parts we mix and match, everyone installs their own custom blend of software, etc. Under the circumstances, you have to expect that we will stumble over problems that no one knew about. And the only way they can get fixed and the software improved for everyone is by filing bugs. This is how the developers get informed about the problems, and is step one to fixing them.
La chasse aux bogues
J'ai déjà dit qu'il serait préférable de penser aux Logiciels libres comme des logiciels « Soutenus par la communauté » et j'ai aussi dit que je discuterais de la signification exacte de cette appellation.
On peut soutenir les Logiciels libres de beaucoup de façons, mais l'une des plus importantes est la soumission de bogues au développeurs. N'oubliez pas que ces personnes admirables créent des logiciels géniaux avec des budgets minimes et que cela veut dire qu'ils n'ont pas la possibilité de tester ces logiciels dans toutes les conditions envisageables. Beaucoup d'entre nous (moi-même y compris) construisons nos propres ordinateurs à partir de pièces que nous assemblons tant bien que mal, et que tout le monde installe son mélange de logiciels personnalisés, etc. Dans ces circonstances, il faut s'attendre à rencontrer des problèmes totalement inconnus. Et la seule façon de les faire réparer et, ainsi, d'améliorer le logiciel pour tous, consiste en la soumission de bogues. C'est comme cela que les développeurs sont informés sur les problèmes et c'est le premier pas vers leur résolution.
The first place to look for filing bugs is with your distro. The major distros tend to have online bug-tracking mechanisms of some kind, and they will have specific directions on how to file a bug. They may decide that it should go upstream (i.e. the bug is in a package that they included but don’t directly support), but it is really never wrong to start with the distro. If you want to read more about this, a good place to start is at LinuxCareeer.com. Note how they start off their discussion: Linux distributions, and Open Source software in general, are, before anything, community efforts. Every distribution lists somewhere on its website ways to contribute to and help the effort. And it’s quite an effort too, which programmers provide for free, working in their spare time. One recurrent theme on each of those “how to contribute” documents is “Submit bugs when found,” although the exact wording may differ.
Si vous voulez soumettre des bogues, le premier endroit à regarder est votre distrib. Les distrib. importantes ont souvent des mécanismes de suivi des bogues en ligne et ils auront un mode d'emploi précis pour la soumission des bogues. Il se peut qu'ils décident qu'il devrait aller en amont (par ex., si le bogue se trouve dans un paquet inclus dans la distrib., mais pas pris en charge directement), mais vous n'aurez jamais tort de commencer par la distrib. Si vous voulez en lire davantage, un bon endroit pour commencer est à LinuxCareer.com. Voyez comment ils démarrent leur discussion :
Les distributions Linux et les logiciels Open Source en général sont, avant tout, des œuvres communautaires. Quelque part sur le site web de chaque distribution vous trouverez une liste de façons de contribuer et d'aider à l'œuvre. Qui plus est, l'effort fourni est énorme et les programmeurs donnent le leur gratuitement, en travaillant pendant leurs loisirs. Un thème récurrent de chacun de ces documents sur « Comment contribuer » est « Soumettre des bogues quand vous en trouvez », bien que la terminologie exacte puisse différer.
This site gives more specific instructions for Ubuntu, Mint, Fedora, Debian, and openSUSE. But if you use some other distro, just go to the site of the distro and you will be certain to find how they do it. Or Google for the name of the distro and the phrase “filing bugs” and you will probably get there right away. Now, aside from the specific mechanics of submitting a bug for your distro, there are some general things that are important to any good bug report, and you should learn to look for these: • Did anything just change? Did you just add a new video card, for instance? If you change to a different video card, does that affect the problem? Did you just install new software? Did you just update something? Can you roll back the change and try again? Knowing the answers to these questions can be very important in determining where the problem lies. • What were you doing when the problem occurred? Is it reproducible, i.e. if you do the same things again, do you get the exact same problem? Again, a very important piece of information for tracking down the bug. • Do you have any log data to add to the report? Get to know where this data lives, and how to access it. For instance, dmesg is a great source of information. Just including this file in your bug report can be useful, but even better is finding out how to pull out the relevant details first. • Check to see if this bug has already been submitted. If so, you may be able to add on to the report as an additional case of the same bug. Even better, if you learned how to get good information, you can improve the original bug report to the point where the developers can actually work on it. When you look at how bugs are submitted, a large number of them cannot be worked on because there is no useful information. Learn to make yours useful. Also, you may discover that the bug has already been fixed, and all you need to do is update your software. That is pretty good, right?
Ce site-là donne des instructions assez précises pour Ubuntu, Mint, Fedora, Debian et openSUSE. Mais si vous utilisez une autre distribution, il suffit d'aller sur son site et vous serez certain de trouver leur façon de faire. Ou faites une recherche sur Google avec le nom de la distrib. et la phrase « Soumettre bogues » et vous y serez sans doute tout de suite.
Bon, à part les mécanismes précis de la soumission d'un bogue pour votre distrib. il y a des choses générales qui sont importantes pour tout bon rapport de bogue. Vous devrez les garder en mémoire :
* Est-ce que quelque chose vient de changer ? Par exemple, y a-t-il une nouvelle carte graphique ? Si vous changez votre carte pour une autre, cela affecte-t-il le problème ? Est-ce que vous venez d'installer un nouveau logiciel ? Avez-vous mis quelque chose à jour ? Pouvez-vous annuler le changement et essayez à nouveau ? Connaître les réponses à ces questions peut être très important pour cibler l'origine du problème. * Que faisiez-vous lorsque le problème est survenu ? Pouvez-vous le reproduire, c'est-à-dire que si vous refaites les mêmes choses, le même problème survient-il ? Encore un renseignement qui est très important pour la recherche du bogue. * Avez-vous des données de log à ajouter au rapport ? Apprenez l'emplacement de ces données et comment y accéder. Dmesg, notamment, est une excellente source d'informations. Le simple fait d'inclure ce fichier dans votre rapport de bogue peut être utile, mais le mieux, c'est de trouver d'abord comment en extraire les détails pertinents. * Vérifiez si un rapport sur ce bogue existe déjà. Si c'est le cas, il se peut que vous puissiez ajouter des informations au rapport, comme un autre cas du même bogue. Encore mieux, si vous avez appris comment obtenir de bons renseignements, vous pouvez améliorer tellement le rapport de bogue initial que les développeurs pourront vraiment y travailler. Quand vous regardez la façon dont les bogues sont soumis, un grand nombre d'entre eux ne peuvent pas être réparés car il n'y a pas d'informations utiles. Apprenez à rendre vos informations utiles. Puis vous découvrirez peut-être que le bogue a déjà été réparé et que tout ce qu'il faut faire, c'est mettre votre système à jour. Ce n'est pas mal, non ?
Here is an example of one problem I had. The software package in question was Miro, which downloads and plays videos from the Web, which for me is mostly video podcasts. And I use it every day, so this problem mattered to me. I had just upgraded my distro to the newest version, and suddenly Miro would not play any of my videos. I checked and I could play them in other software, but I wanted Miro to work for me again. I also checked on another computer with the same distro version, and had the exact same problem. So I filed a bug in two places, one with the distro, the other with Miro itself. I got a reply from a developer on the Miro project within hours, and he said that he had tried that exact distro version and had no problems. So there was probably some combination of software that I tended to use that did something unexpected. He asked me to grab a log file from Miro, and send it to him. I did so, and again he wrote back promptly pointing out a couple of lines in the log file, and saying that it looked like I was missing a critical package. I checked, and it looked like this package was on my system, but I removed it, reinstalled it, and then Miro worked properly again. I think this counts as a very good outcome. When you create good bug reports, you help yourself and you help others. And that is a big part of what it means to have Community-Supported Software.
Voici l'exemple d'un des problèmes que j'ai rencontrés. Le paquet en question était Miro, qui télécharge et lit des vidéos du Web, ce qui pour moi veut dire principalement des podcasts vidéo. Et je l'utilise tous les jours - ce problème m'importait vraiment, donc. Je venais de faire une mise à niveau de ma distrib. vers la version la plus récente et, tout d'un coup, Miro ne lisait aucune de mes vidéos.J'ai vérifié, et constaté qu'il était possible de les lire avec d'autres logiciels, mais je voulais que Miro fonctionne à nouveau. J'ai aussi vérifié sur un autre ordinateur avec la même version de distrib. et j'ai rencontré le même problème. J'ai donc soumis deux rapports de bogues, l'un auprès de la distrib. et l'autre à Miro lui-même. J'ai eu une réponse d'un développeur de chez Miro dans les quelques heures disant qu'il avait essayé exactement la même version de la distrib. sans problèmes. Alors, j'utilisais sans doute une combinaison de logiciels qui devait faire quelque chose d'inattendu. Il m'a demandé de récupérer le fichier log de Miro et de le lui envoyer. Je l'ai fait et, à nouveau, il a répondu rapidement en soulignant deux ou trois lignes dans le fichier log et en me disant qu'il avait l'impression qu'un paquet critique manquait. J'ai vérifié et le paquet semblait être installé sur mon système, mais je l'ai enlevé et réinstallé et, ensuite, Miro a fonctionné comme il fallait à nouveau. Je pense que cela peut être considéré comme un très bon résultat.
Lorsque vous créez de bons rapports de bogues, vous vous aidez et vous aidez les autres. Et c'est une grand partie de la signification de logiciels pris en charge par la Communauté.
Documentation In my day job,I am a Project Manager, and one of the things I constantly try to get is good documentation. I hope I have even produced a little of it myself. But there is no topic on which I get more resistance than on creating good documentation. No one ever has time to create it, but somehow they find the resources to pay the price when they don’t have it. If getting good documentation is hard in the corporate world, how about in the Free Software world? It is equally difficult. I can’t tell you how many times I have tried to access the Help system for one of my KDE applications only to get an error that says there is no Help material available. You really feel sometimes like you are being told “We wrote it, now you figure out what to do with it.” And part of the reason is that we don’t always think about it properly (in my opinion). I would start by distinguishing between two kinds of documentation: technical, and end-user. Technical documentation, as the name implies, is the sort of thing that the developers could provide if they chose to do so. This could get to the very deepest level of code documentation, but even if it lives at a somewhat higher level, it is not end-user documentation. And the question of whether it even exists remains. Developers like developing, but they generally don’t like documenting. And in Free Software many of these people are volunteers.
La documentation
Le jour, au travail, je suis gestionnaire de projet et l'une des choses que j'essaie sans cesse d'obtenir est une bonne documentation. J'espère en avoir produit un peu moi-même. Mais il n'y a pas de sujet où je rencontre davantage de résistance que la création d'une bonne documentation. Personne n'a jamais le temps d'en créer, mais d'une façon ou d'une autre, ils arrivent à trouver des ressources pour payer le prix quand ils ne l'ont pas. Si obtenir de la bonne documentation est difficile dans le monde des entreprises, quid du monde des Logiciels libres ? C'est tout aussi difficile. Je ne peux pas compter le nombre de fois où j'ai essayé d'accéder au système d'aide pour l'une de mes applications KDE, pour n'arriver qu'à un message m'informant qu'il n'y a pas d'aide disponible. Parfois, vous avez vraiment l'impression que l'on vous dit : « Nous l'avons écrit, à vous maintenant d'essayer de comprendre ce qu'il faut en faire. » Une partie de la raison de cela est que, à mon avis, nous n'y réfléchissons pas comme il faudrait.
Je commencerais par faire la distinction entre deux sortes de documentations : la documentation technique et celle faite pour l'utilisateur final. Comme son nom l'indique, la documentation technique est le genre de truc que pourraient fournir les développeurs, s'ils voulaient bien le faire. Cela pourrait aller au plus profond de la documentation du code, mais même à des niveaux plus élevés, ce n'est pas de la documentation pour utilisateur final. Reste la question de son existence même. Les développeurs aiment bien développer, mais ils n'aiment pas faire de la documentation. Et dans le monde des Logiciels libres, beaucoup de ces gens sont des bénévoles.
But the topic of end-user documentation takes us in a different direction, and one where people with the right skills can be very helpful. It can also be a little frustrating. I recall one experience I had where I offered to help create end-user documentation for an application. When I asked to see what they had, the response was “We don’t have anything, that is what we want you to do.” Now I like to think I am a good writer, and I know I have been praised at work for the documentation I have written, but any writer needs something to start with. At work, I can make the technical people sit down with me, answer my questions, and so on. And you really need something like that to do good documentation. Good technical documentation can get you started, but to do good end-user documentation you will need to have some kind of access to the developers. And if the folks on the project you want to help don’t understand this, you need to explain it to them. They may want someone to come along and just magically make something happen without anyone else on the project being involved, but that is just not feasible. Good documentation is a group effort, really.
Mais le sujet de la documentation pour utilisateur final nous mène dans une autre direction, celle où des gens ayant les bonnes compétences peuvent vraiment aider. Cela peut aussi être un peu frustrant. Je me rappelle une fois où j'avais proposé d'aider à créer de la documentation pour utilisateur final, pour une application. Quand j'ai voulu voir ce qu'ils avaient déjà, la réponse a été : « On n'a rien, c'est ce qu'on veut que tu fasses. » Bon, j'aime à penser que je suis bon écrivain et je sais qu'on m'a bien félicité au travail pour la documentation que j'ai écrite, mais n'importe quel écrivain a besoin d'un point de départ. Au travail, je peux obliger les gens de la partie technique à s'asseoir avec moi, répondre à mes questions et ainsi de suite. Mais vous avez vraiment besoin de quelque chose dans ce genre pour faire de la bonne documentation. Une bonne documentation technique peut vous aider à commencer, mais pour faire de la bonne documentation pour utilisateur final vous aurez besoin d'avoir accès aux développeurs. Et si les gens travaillant sur le projet que vous voulez aider ne le comprennent pas, il vous faut leur expliquer. Il se peut qu'ils veuillent que quelqu'un se pointe et fasse en sorte que les choses se passent, comme par magie, sans que personne d'autre du projet soit impliqué, mais cela n'est simplement pas possible. En fait, la bonne documentation se fait en groupe.
In writing for the end-user, you need to be able to think a little differently. End-users are, by-and-large, not technical. There can be exceptions to this rule, but this is a good starting place for writing the most useful documentation. And the best way to do this is by thinking of “stories”. The Agile community tends to do a good job of this in terms of software development, but you need to carry this into documentation as well. You could write a book on this topic, and I don’t have that kind of space here so I will be somewhat more brief. Stories in this context means picturing a typical user of some kind, and imagining how they might try to use the software. Who is this person? Be specific – give this person a name, an age, a sex, a background. The better you do this – the better able you will be to get into this person’s skin and see things the way they do. Then look at some questions they might have.
Quand vous écrivez pour l'utilisateur final, il faut pouvoir réfléchir un peu différemment. Les utilisateurs finaux ne sont pas, en général, portés sur les choses techniques. Il peut y avoir des exceptions à cette règle, mais ceci est un bon point de départ pour écrire la documentation la plus utile. Et la meilleure façon de faire est de penser à des « histoires ». La communauté Agile le fait souvent très bien en termes de développement de logiciels, mais il faut porter l'idée vers la documentation aussi. On pourrait écrire un livre entier à ce sujet et je n'en ai pas la place ici ; je serai donc un peu plus bref. Écrire des histoires dans ce contexte suppose de dépeindre un utilisateur moyen en imaginant comment il pourrait vouloir utiliser ce logiciel. Qui est cet individu ? Soyez précis - donnez-lui un nom, un âge, un sexe, des antécédents. Mieux vous faites ceci et mieux vous saurez rentrer dans la peau de cet individu et voir les choses comme il les voit. Ensuite, regardez quelques questions qu'il pourrait avoir.
Why would I want to use this software? What do I hope to accomplish here? Would I use this infrequently, or daily? Would I use this alone, or with other software? And that is just a few of the questions you might want to ask at the beginning. By answering them, you set a direction for what you want to do. And if you can begin here, and you can write out answers that end-users can make sense of, you can make an invaluable contribution to Free Software. One last note is about translating documentation. Free software is international in scope, and often the people who need it most also need it in their own language. If you can translate the documentation, that is also a much-needed contribution. Many projects are looking for help with this aspect of the documentation. Just offer to help.
Qu'est-ce qui m'incite à vouloir utiliser ce logiciel ?
Qu'est-ce que j'espère accomplir avec ?
Est-ce pour une utilisation occasionnelle ou quotidienne ?
Est-ce à utiliser seul ou avec d'autres logiciels ?
Et ce n'est que quelques-unes des questions que vous voudriez sans doute poser au départ. En y répondant, vous fixez une direction pour ce que vous voulez faire. Et si vous savez commencer par cela, si vous pouvez écrire des réponses que les utilisateurs finaux comprendront, votre contribution aux Logiciels libres serait d'une très grande valeur.
Un dernier mot concernant la traduction de la documentation : les Logiciels libres sont de portée internationale et souvent, les personnes qui en ont besoin, en ont besoin aussi dans leur propre langue. Si vous savez traduire la documentation, les projets ont vraiment besoin de vous. Beaucoup cherchent de l'aide avec cet aspect de leur documentation. Il suffit de proposer la vôtre.
The “M” Word And by that I mean Money. As I mentioned previously, when we talk about Free Software, the emphasis ought to be on freedom, not on price. The fact that so much Free Software is also free of purchase is great. It offers people who cannot afford expensive proprietary software a chance to use comparable software that can improve their lives, their businesses, and their societies. But, at the same time, it does require some money to produce the software. While there are cases where the financial support comes from interested companies who may assign their staff as developers or provide server space (and companies like Red Hat and IBM provide a lot of support this way), there are also a lot of smaller projects that need help. And some activities that are important are not supported by corporations at all, but instead must rely on individuals to provide this support. I would never suggest you stop feeding your kids to do this, but the reality is that most users of Free Software in the US and Europe (for example) could easily afford to make some contributions. And I want to suggest some ways you can do this.
« A » comme Argent
Un mot de cinq lettres en quelque sorte.
Comme je l'ai déjà indiqué, quand nous parlons de Logiciels libres, l'accent devrait être mis sur la liberté, pas sur le prix. Le fait que tant de Logiciels libres soient également gratuits est génial. Il donne aux personnes incapables de se payer des logiciels propriétaires chers l'occasion d'utiliser des logiciels similaires, qui peuvent améliorer leur vie, leur entreprise et leur société. Mais, en même temps, il faut de l'argent pour produire les logiciels. Alors que, dans certains cas, le soutien financier vient d'entreprises intéressées qui peuvent prêter ou affecter du personnel au développement ou fournir de l'espace serveur (et des sociétés comme Red Hat et IBM fournissent pas mal de soutien dans ce domaine), il existe aussi des projets plus petits qui ont besoin d'aide. Et certaines activités qui ont leur importance ne sont pas du tout soutenues par des entreprises et, à la place, doivent compter sur des individus pour ce soutien. Je ne suggérerais jamais que vous arrêtiez de nourrir vos gosses pour faire ceci, mais la vérité est que, la plupart des utilisateurs des Logiciels libre aux États-unis et en Europe, notamment, pourraient facilement se permettre de faire des dons. Et j'aimerais suggérer quelques façons de le faire.
To begin with, most of the Free Software projects have a Web page. And if you go to the Web page you will probably see something like a PayPal button to make a donation. My rule of thumb is that if I use the software a lot I ought to support it financially. I have always felt this way, going back to the days of “shareware”. Shareware used to be “try before you buy” software produced generally by independent developers who let you use the software free-of-charge, but asked you to register and pay for it if you liked it. While undoubtedly some number of people simply used the software and ignored the obligation to pay for it, it was clear to me (and many others) that, if the developers could not get paid for their trouble, they would stop making useful software. Now that I am firmly in the Free Software camp, I feel the same way: if we don’t make sure our developers are supported, they will go do other things. They also need to eat, they also have families, they need to pay their bills.
Pour commencer, la plupart des projets de Logiciels libres ont un site web. Et si vous allez sur leur site, vous verrez sans doute quelque chose comme un bouton PayPal pour faire un don. Personnellement, j'ai adopté la règle suivante : si j'utilise beaucoup le logiciel, j'ai une obligation de le soutenir financièrement. J'ai toujours pensé ceci, depuis l'époque du « shareware » (ou partagiciels). Dans le temps, les partagiciels était des logiciels « à essayer avant d'acheter » et ont été produits par des développeurs indépendants qui vous permettaient d'utiliser le logiciel gratuitement, mais demandaient que vous vous inscriviez et le payiez si vous l'aimiez. Alors que, sans aucun doute, un certain nombre de gens utilisent tout simplement le logiciel en ignorant leur devoir de le payer, c'était clair (pour moi et pour beaucoup d'autres) que, si les développeurs n'arrivaient pas a se faire payer pour leurs efforts, ils arrêteraient de produire des logiciels utiles. Maintenant que je me trouve fermement dans le camp des Logiciels libres, j'ai les mêmes sentiments : si nous ne nous assurons pas que nos développeurs sont soutenus, ils iront faire autre chose. Comme nous, ils ont besoin de manger, ils ont des familles, ils doivent payer les factures.
I will give a few examples from my own experience just to illustrate how easy it is to do this if you are sensitive to the issue. I realize this may look like I am trying to make myself look good, but I don’t think I am any better than anyone else, I just don’t have anyone else’s examples handy right now. • The first example is a project called Miro (http://www.getmiro.com/), which produces software to download videos from the Internet and play them. I subscribe to a lot of video podcasts, as well as a few YouTube channels, and this is how I do it. And I use this software every day, so it is a good candidate for support. About a year ago they were looking to sign up people in a fund-raising drive called “Adopt a line of code”, for which you would pay $4 per month through PayPal. It looked good to me, so I signed up. After all, I get far more than $4 per month of benefit from this software and have come to rely on it every day.
Je vais donner quelques exemples tirés de mes propres expériences, afin de démontrer combien c'est facile de le faire, si vous êtes sensible au problème. Je me rends compte que cela peut prêter à penser que j'essaie de me donner bonne contenance, mais je ne crois pas être meilleur que quiconque et je n'ai actuellement pas d'exemples d'autres personnes à portée de main. * Le premier exemple concerne un projet nommé Miro (http://www.getmiro.com/), qui fait des logiciels pour télécharger des vidéos sur le Net, puis de les lire. J'ai un abonnement à beaucoup de podcasts vidéo, ainsi qu'à quelques canaux sur YouTube et c'est comme ça que je le fais. J'utilise ce logiciel quotidiennement, ce qui en fait un bon candidat pour mon soutien. Il y a environ un an, ils cherchaient à faire inscrire des gens à une collecte de fonds appelée « Adopter une ligne de code » pour laquelle vous payeriez 4 $ par mois avec PayPal. Cela m'a semblé très bien, alors je me suis inscrit. Après tout, j'en tire un bénéfice de beaucoup plus de 4 $ par mois et je compte sur ce logiciel tous les jours.
• I also am a KDE user on all of my computers. A few months back, I saw a post from one of the developers, Sebastian Trueg (http://trueg.wordpress.com/), that he needed to raise money to support himself so he could continue his work on KDE. Unlike some of the developers, he had no corporate paycheck supporting his KDE work. Well, I use KDE every day, I rely on it, and I clicked the PayPal button for a donation (My memory is that I gave him $10, not a huge amount, but I hope that among all of the KDE users he raised enough money to keep working.) • My particular distro of choice is Kubuntu, and, again, I use it every day. I don’t think Canonical really needs my donations to keep going, but they base their work on Debian, so when I saw a fundraising drive to write and publish the Debian System Administrator’s Handbook, I pledged a small amount (again, I think it was $10 or so. For me, $10 is the amount I can casually donate without worrying about paying my own bills.)
* J'utilise KDE sur tous mes ordinateurs. Il y a quelques mois, j'ai vu un message de Sebastian Trueg (http://trueg.wordpress.com/), l'un des développeurs, signalant qu'il avait besoin de réunir des fonds pour subvenir à ses propres besoins, et pouvoir continuer son travail sur KDE. Contrairement à certains développeurs, il n'avait pas de salaire soutenant son travail sur KDE. Bon, j'utilise KDE tous les jours, je compte dessus et j'ai cliqué sur le bouton PayPal pour faire un don. (Si mes souvenirs sont bons, je lui ai donné 10 $, ce qui n'est pas beaucoup, mais j'espère que, parmi tous les utilisateurs de KDE il a réuni assez de fonds pour pouvoir continuer à travailler.) * La distrib. que je préfère est Kubuntu et je l'utilise tous les jours. Je ne pense pas que Canonical ait vraiment besoin de mes dons pour continuer son travail, mais celui-ci est basé sur Debian ; ainsi, quand j'ai vu une collecte de fonds pour pouvoir écrire et publier le Debian System Administrator's Handbook, je me suis engagé à contribuer avec un peu d'argent (à nouveau, je pense qu'il s'agissait d'environ 10 $. Pour ce qui me concerne, 10 $ est ce que je peux donner sans trop réfléchir à comment je vais pouvoir payer mes propres factures.)
Another form of support you can give is by joining some of the Non-Profit charitable organizations that support Free Software. There are a number of them, but I will note a few. First is the Free Software Foundation (http://www.fsf.org/). This was set up by Richard Stallman, and is the one organization on my list that is directly focused on defending our software freedoms. This is the group that promotes the GPL license. Because my own freedom is very important to me, I am proud to say that I am a member. This is a little more expensive than my donations above, at $10 per month, but I’m glad to do it. Another group that you can support through a membership is The Linux Foundation (http://www.linuxfoundation.org/). This group pays the salary of Linus Torvalds (and just announced that they are supporting Greg Kroah-Hartman), so if the Linux Kernel is your thing this would be a good thing to join. Individual memberships are $99 per year. Next I want to mention the Linux Fund (http://www.linuxfund.org/). They raise money through what are called “Affinity Cards”, i.e. credit cards with a logo of your favorite group. You many have seen these before to support sports teams or universities, but you can support Free Software. And despite that name “Linux Fund” they also support BSD, which is Free Software by any definition. All you need to do is sign up for a credit card through them and a small part of your purchases goes to support the project you choose.
Une autre forme de soutien possible est de devenir membre de quelques associations à but non lucratif ou caritatives et qui soutiennent les Logiciels libres. Il y en a un certain nombre, mais je ne vais en citer que quelques-unes. Tout d'abord, il y a la Free Software Foundation (http://www.fsf.org/), fondée par Richard Stallman. C'est l'unique association sur ma liste qui se concentre sur la défense des libertés dans le domaine des logiciels. C'est l'organisme qui promeut la licence GPL. C'est parce que ma propre liberté m'est très importante que je suis fier de dire que j'en suis membre. À 10 $ par mois, c'est un peu plus cher que les dons cités ci-dessus, mais je suis heureux de le faire. Un autre groupe que vous pouvez soutenir au moyen d'une adhésion est The Linux Foundation (http://www.linuxfoundation.org/). C'est l'organisme qui paie le salaire de Linus Torvalds (et il vient d'annoncer qu'ils soutiennent Greg Kroah-Hartman), alors si le Noyau Linux est votre truc, ce serait une bonne organisation pour vous. Les adhésions individuelles reviennent à 99 $ par an. Ensuite, je veux parler du Linux Fund (http://www.linuxfund.org/). Ils collectent des fonds avec ce qui s'appelle des « Affinity Cards », autrement dit des cartes de crédit avec le logo de votre groupe préféré. Il se peut que vous ayez déjà vu ces cartes dans le cadre du soutien d'une équipe de sport ou d'une université, mais il est possible aussi de soutenir les Logiciels libres. Et, malgré le nom « Linux Fund », ils soutiennent aussi BSD [Berkeley Software Distribution], les Logiciels libres par excellence. Tout ce qu'il faut faire c'est demander une carte de crédit par leur intermédiaire, et une petite partie de vos achats est utilisée pour soutenir le projet de votre choix.
The last one I would like to mention is the Software Freedom Conservancy (http://sfconservancy.org/). This is a non-profit group headed by Bradley Kuhn that helps a lot of projects. Essentially, they provide the legal structure to enable smaller projects to raise money while the SFC handles the administrative overhead. Bradley was formerly at the Free Software Foundation, and is still the most active person in defending the GPL, so this is a name you may well have heard before. But at SFC he is directly helping all of these projects. Current member projects include Amarok, Git, Samba, and Wine. I’m guessing at least a few of those projects produce software you use, so you can help them out with a donation.
La dernière dont j'aimerais parler est la Software Freedom Conservancy (http://sfconservancy.org/). Il s'agit d'un groupe à but non lucratif dont le directeur est Bradley Kuhn et qui aide de très nombreux projets. En résumé, ils fournissent la structure légale qui permet au petits projets de collecter des fonds pendant que la SFC gère les frais administratifs généraux. Bradley vient de la Free Software Foundation et reste toujours la personne la plus active dans la défense de la GPL; ainsi, vous pourriez très bien avoir entendu son nom avant. Mais à SFC, il aide directement tous ces projets. Les projets membres actuels comprennent Amarok, Git, Samba et Wine. Je présume qu'au moins deux ou trois de ces projets produisent des logiciels que vous utilisez, alors vous pouvez les aider en faisant un don.
Getting Involved We have explored some of the ways everyone can support Free Software, such as by filing bugs, writing documentation, and by providing financial support. I want to wrap it up by exploring what may be the best way of all to get started, and this is to get involved. Join a group. Help out. The first place you might wish to look at is your local Linux User Group (LUG). This is where you can meet people in your community who also are interested in Free Software. You might think that only Linux gets discussed there, but I’d bet you would be surprised. I know my local LUG has speakers covering a wide range of topics in Free Software. Last month we learned about Sourceforge, for instance, which supports a bunch of different Free Software projects. LUGs also provide community outreach, such as by doing install fests and by cooperating with local schools and organizations. I always suggest to people that this is the first place to go both to get help and to get involved.
S'impliquer
Nous venons d'examiner quelques-unes des façons de soutenir les Logiciels libres, notamment avec des rapports de bogues, en écrivant de la documentation et en fournissant un soutien financier. J'aimerais terminer avec ce qui pourrait être la meilleure façon de commencer, à savoir s'impliquer. Devenir membre d'un groupe. Donner un coup de main.
Le premier endroit où vous pourriez commencer est votre Groupe local d'utilisateurs Linux (GUL). C'est ici que vous pouvez rencontrez des gens dans votre communauté qui s'intéressent aussi aux Logiciels libres. Vous pouvez croire qu'il n'y a que Linux comme sujet de discussion, mais je pense que vous serez étonné. Je sais que mon GUL local présente des conférenciers qui parlent de toute une gamme de sujets dans le domaine des Logiciels libres. Par exemple le mois dernier, nous avons appris beaucoup de choses sur Sourceforge, qui soutient une foule de projets différents dans ce même domaine. Les GUL proposent également une approche communautaire, telle que l'organisation de fêtes d'installation ou en coopérant avec des écoles et associations locales. Je n'arrête pas de dire aux gens que c'est le premier endroit où aller à la fois pour obtenir de l'aide et pour s'impliquer.
The next place you might want to look into is with your Linux distro of choice. Mine is Kubuntu, which is a variant on Ubuntu that uses the KDE desktop. So I have joined my Ubuntu Local Community (i.e. LoCo), which in my case is Michigan in the US. This group organizes Bug Jams, where people get together to file and work on bugs. And they organize release parties twice a year when new releases come out. I know that Fedora has what they call the Fedora Ambassadors program, and many other distros have opportunities to get involved. You have only to ask. Finally, I am going to mention the various Linux and Free Software conferences. I am involved with one called Ohio LinuxFest, where I am the Publicity director. I just finished writing a page for our web site (https://ohiolinux.org/node/187) where I listed 8 major positions we are trying to fill, as well as a bunch of day-of-event positions for volunteers. If you have never been involved with an event like this, you might not realize just how much work is involved in making the magic happen each year. But it is hard work, and every one of them is looking for volunteers to help put it on. And this is something you can do even if you don’t feel like you can file bugs or write documentation, or you don’t have the money to provide financial support. You can always provide help at these events. Chances are there is one not too far from you.
Ensuite, le prochain endroit que vous pourriez examiner est auprès de votre distrib. Linux préférée. La mienne est Kubuntu, une variété d'Ubuntu qui utilise le bureau KDE. J'ai donc rejoint ma communauté locale Ubuntu (autrement dit ma LoCo), qui, pour ce qui me concerne, est au Michigan dans les États-Unis. Ce groupe organise des soirées Bogues, où les gens se rassemblent pour faire des rapports de bogues et pour travailler dessus. Et ils organisent des soirées versions deux fois par an quand les nouvelles versions sortent. Je sais que chez Fedora, ils ont ce qu'ils appellent le programme Fedora Ambassadors, et beaucoup d'autres distrib. proposent des occasions où vous pouvez vous impliquer. Il suffit de demander.
Enfin, je vais parler des diverses conférences autour de Linux et des Logiciels libres. Je me suis impliqué dans l'une d'entre elles, l'Ohio Linuxfest où je suis directeur de la publicité. Je viens de terminer une page pour notre site web (https://ohiolinux.org/node/187) où j'ai énuméré 8 postes importants que nous essayons de pourvoir, ainsi qu'un tas de postes pour des bénévoles le jour même d'un événement. Si vous ne vous êtes jamais impliqué dans un événement comme celui-ci, vous pouvez ne pas vous rendre compte de la quantité de travail nécessaire pour recréer la magie chaque année. Mais c'est un travail difficile et chaque événement cherche des bénévoles pour aider à sa réalisation. Et c'est quelque chose que vous pouvez faire même si vous pensez ne pas être capable de faire des rapports de bogues ou d'écrire de la documentation, ou si vous n'avez pas d'argent pour donner un soutien financier. Vous pouvez toujours aider à ces événements. Il y a de grandes chances qu'il y en a un pas très loin de chez vous.
What really matters, though, is that you make a contribution of some kind. As we said when we started this series of posts, Free Software means Community-supported Software. When it stops getting community support, it dies. If you value Free Software, then you have a responsibility to support it in one way or another. My role here is to give you ideas on how you can do that.
En tout cas, l'important, c'est de faire une contribution de quelque sorte que ce soit. Comme nous avions dit, lorsque nous avons démarré cette série de messages, les Logiciels libres veulent dire des Logiciels soutenus par la Communauté. Si le soutien de la Communauté s'arrête, le logiciel meurt. Si les Logiciels libres ont de la valeur pour vous, alors vous avez la responsabilité de les soutenir d'une façon ou d'une autre. Mon objectif ici est de vous donner des idées sur comment le faire.