POSS Chap 2 Intro
Un article de Framalang Wiki.
The classic model of how free software projects get started was supplied by Eric Raymond, in a now-famous paper on Open Source processes entitled The Cathedral and the Bazaar. He wrote:
Every good work of software starts by scratching a developer's personal itch.
(from http://www.catb.org/~esr/writings/cathedral-bazaar/ )
Note that Raymond wasn't saying that Open Source projects happen only when some individual gets an itch. Rather, he was saying that good software results when the programmer has a personal interest in seeing the problem solved; the relevance of this to free software was that a personal itch happened to be the most frequent motivation for starting a free software project.
This is still how most free projects are started, but less so now than in 1997, when Raymond wrote those words. Today, we have the phenomenon of organizations-including for-profit corporations-starting large, centrally-managed Open Source projects from scratch. The lone programmer, banging out some code to solve a local problem and then realizing the result has wider applicability, is still the source of much new free software, but is not the only story.
Raymond's point is still insightful, however. The essential condition is that the producers of the software have a direct interest in its success, because they use it themselves. If the software doesn't do what it's supposed to do, the person or organization producing it will feel the dissatisfaction in their daily work. For example, the OpenAdapter project (http://www.openadapter.org/), which was started by investment bank Dresdner Kleinwort Wasserstein as an Open Source framework for integrating disparate financial information systems, can hardly be said to scratch any individual programmer's personal itch. It scratches an institutional itch. But that itch arises directly from the experiences of the institution and its partners, and therefore if the project fails to relieve them, they will know. This arrangement produces good software because the feedback loop flows in the right direction. The program isn't being written to be sold to someone else so they can solve their problem. It's being written to solve one's own problem, and then shared with everyone, much as though the problem were a disease and the software were medicine whose distribution is meant to completely eradicate the epidemic.
This chapter is about how to introduce a new free software project to the world, but many of its recommendations would sound familiar to a health organization distributing medicine. The goals are very similar: you want to make it clear what the medicine does, get it into the hands of the right people, and make sure that those who receive it know how to use it. But with software, you also want to entice some of the recipients into joining the ongoing research effort to improve the medicine.
Free software distribution is a twofold task. The software needs to acquire users, and to acquire developers. These two needs are not necessarily in conflict, but they do add some complexity to a project's initial presentation. Some information is useful for both audiences, some is useful only for one or the other. Both kinds of information should subscribe to the principle of scaled presentation; that is, the degree of detail presented at each stage should correspond directly to the amount of time and effort put in by the reader. More effort should always equal more reward. When the two do not correlate tightly, people may quickly lose faith and stop investing effort.
The corollary to this is that appearances matter. Programmers, in particular, often don't like to believe this. Their love of substance over form is almost a point of professional pride. It's no accident that so many programmers exhibit an antipathy for marketing and public relations work, nor that professional graphic designers are often horrified at what programmers come up with on their own.
This is a pity, because there are situations where form is substance, and project presentation is one of them. For example, the very first thing a visitor learns about a project is what its Web site looks like. This information is absorbed before any of the actual content on the site is comprehended-before any of the text has been read or links clicked on. However unjust it may be, people cannot stop themselves from forming an immediate first impression. The site's appearance signals whether care was taken in organizing the project's presentation. Humans have extremely sensitive antennae for detecting the investment of care. Most of us can tell in one glance whether a Web site was thrown together quickly or was given serious thought. This is the first piece of information your project puts out, and the impression it creates will carry over to the rest of the project by association.
Thus, while much of this chapter talks about the content your project should start out with, remember that its look and feel matter too. Because the project Web site has to work for two different types of visitors-users and developers-special attention must be paid to clarity and directedness. Although this is not the place for a general treatise on Web design, one principle is important enough to deserve mention, particularly when the site serves multiple (if overlapping) audiences: people should have a rough idea where a link goes before clicking on it. For example, it should be obvious from looking at the links to user documentation that they lead to user documentation, and not to, say, developer documentation. Running a project is partly about supplying information, but it's also about supplying comfort. The mere presence of certain standard offerings, in expected places, reassures users and developers who are deciding whether they want to get involved. It says that this project has its act together, has anticipated the questions people will ask, and has made an effort to answer them in a way that requires minimal exertion on the part of the asker. By giving off this aura of preparedness, the project sends out a message: "Your time will not be wasted if you get involved," which is exactly what people need to hear.
But First, Look Around
Before starting an Open Source project, there is one important caveat:
Always look around to see if there's an existing project that does what you want. The chances are pretty good that whatever problem you want solved now, someone else wanted solved before you. If they did solve it, and released their code under a free license, then there's no reason for you to reinvent the wheel today. There are exceptions, of course: if you want to start a project as an educational experience, pre-existing code won't help; or maybe the project you have in mind is so specialized that you know there is zero chance anyone else has done it. But generally, there's no point not looking, and the payoff can be huge. If the usual Internet search engines don't turn up anything, try searching on http://freshmeat.net/ (an Open Source project news site, about which more will be said later), on http://www.sourceforge.net/, and in the Free Software Foundation's directory of free software at http://directory.fsf.org/.
Even if you don't find exactly what you were looking for, you might find something so close that it makes more sense to join that project and add functionality than to start from scratch yourself.
Eric Raymond, dans un article maintenant célèbre sur les processus Open Source intitulé « The Cathedral and the Bazaar » [NdT : La cathédrale et le bazar], décrit les étapes classiques du lancement d'un projet de logiciel libre. Il y écrit :
Tout logiciel bien fait répond à un besoin particulier d'un développeur.
(d'après http://www.catb.org/~esr/writings/cathedral-bazaar/ )
Remarquez que Raymond ne dit pas que les projets Open Source se font seulement quand quelques individus ont un besoin spécifique. Il dit plutôt que tout bon logiciel est d'abord la réponse à un besoin spécifique d'un programmeur. La pertinence de ceci dans le monde du logiciel libre est que les besoins personnels sont les motivations les plus fréquentes pour commencer un projet de logiciel libre. C'est encore la motivation de base de la plupart des projets libres, mais moins qu'en 1997 quand Raymond a écrit ces mots. Aujourd'hui nous voyons des organisations, y compris des entreprises dont le but est de faire des profits, commencer de grands projets dont la direction est centralisée, à partir de rien. Le programmeur isolé écrivant des bouts de code pour résoudre des problèmes précis et qui réalise que les résultats obtenus peuvent profiter à plus de monde est encore à la base de beaucoup de nouveaux logiciels libres mais ce n'est plus la seule version de l'histoire.
L'idée de Raymond est cependant toujours très perspicace. La condition essentielle est que les créateurs du programme aient un réel intérêt à le voir aboutir car ils l'utilisent eux même. Si le logiciel ne fait pas ce qu'il est supposé faire la personne ou l'organisation qui le produit ne sera pas satisfaite par son travail quotidien. Par exemple, pour le projet OpenAdapter (http://www.openadapter.org/), qui a été lancé par la banque d'investissement Dresdner Kleinwort Wasserstein comme un cadre Open Source pour l'intégration de systèmes d'informations financières disparates, on peut difficilement dire qu'il réponde à un besoin particulier d'un quelconque développeur. Il répond au besoin d'une institution. Mais ce besoin émane directement des expériences de l'institution et de ses partenaires et par conséquent si le programme faillit à sa tâche ils le sauront. Cette configuration produit de bons logiciels car la boucle de rétroaction le mène dans la bonne direction. Le programme n'est pas écrit pour être vendu à quelqu'un d'autre, donc ils peuvent résoudre leurs propres problèmes. Il est écrit pour résoudre le problème particulier de quelqu'un et ensuite être partagé avec tout le monde, un peu comme si le problème était une maladie et le logiciel le médicament dont la distribution est censée éradiquer l'épidémie.
Ce chapitre traite de la présentation d'un nouveau projet de logiciel libre au monde, mais de nombreuses recommandations sembleraient familières aux organisations de santé distribuant des médicaments. Les buts sont très similaires : vous voulez expliquer de manière simple ce que le médicament fait, l'apporter aux personnes concernées et vous assurez que ceux qui le reçoivent savent comment l'utiliser. Mais avec les logiciels vous voulez aussi inciter certains destinataires à rejoindre la recherche en cours pour améliorer le médicament.
La distribution de logiciels libres est à double face : le logiciel doit trouver des utilisateurs et des développeurs. Ces deux besoins ne sont pas forcément en conflit, mais ils rendent la présentation initiale du projet plus compliquée. Certaines informations sont utiles aux deux publics, d'autres le sont uniquement pour l'un ou l'autre. Les deux types d'informations devraient répondre au principe de présentation adaptée, ce qui signifie que le degré de détail présenté à chacun devrait correspondre directement à la somme de temps et d'efforts consentis par le lecteur. Un effort plus important devrait toujours être récompensé à sa juste valeur. Quand le retour sur investissement n'est pas satisfaisant les gens peuvent rapidement perdre la foi et arrêter de s'investir.
Le corollaire de ceci est que les apparences comptent. Les programmeurs en particulier sont souvent sceptiques à ce sujet. Leur amour pour le fond plutôt que pour la forme est presque une source de fierté professionnelle. Ce n'est pas un hasard si tant de programmeurs montrent de l'antipathie envers le marketing et les relations publiques, ni si les professionnels du graphisme sont souvent horrifiés par ce que les programmeurs peuvent produire.
C'est très dommage parce que les situations où la forme devient matière sont nombreuses et la présentation d'un projets en est une. Par exemple, l'une des premières choses qu'apprend un visiteur à propos d'un projet est l'aspect de son site Web. Cette information est absorbée avant que le vrai contenu du site soit compris, avant que le texte ne soit lu ou que le visiteur ne clique sur les liens. Même si ça peut être injuste, les gens ne peuvent pas s'empêcher de se forger une première impression. L'apparence du site montre l'application mise dans la présentation du projet. Les humains ont des antennes très sensibles pour détecter le souci du détail. La plupart d'entre nous peuvent dire en un coup d'œil si un site Web a été assemblé à la va vite ou s'il a été mûrement réfléchi. C'est la première information que votre projet montre et l'impression qu'elle crée pèsera sur le reste du projet par association.
Par conséquent, alors que beaucoup de chapitres de ce livre portent sur le contenu sur lequel devrait reposer votre projet, souvenez-vous que son apparence compte également. Parce que le site Web du projet s'adresse à deux types de visiteurs, les utilisateurs et les développeurs, une attention particulière doit être portée à sa clarté et au besoin d'aller à l'essentiel. Bien que ça ne soit pas le meilleur endroit pour traiter de la conception d'une page Web un principe est suffisamment important pour être mentionné, particulièrement quand le site s'adresse à plusieurs publics (qui peuvent se chevaucher) : les gens devraient avoir une vague idée d'où mène un lien avant de cliquer dessus. Par exemple il devrait être évident en regardant les liens vers la documentation utilisateur qu'ils envoient à la documentation utilisateur et pas, par exemple, à la documentation développeur. Diriger un projet consiste à la fois à fournir des informations mais aussi à rassurer. La simple présence de certaines offres standards, à leur place standard, rassure les utilisateurs et les développeurs qui décident s'ils vont ou non s'impliquer. Cela montre que le projet a une ligne de conduite définie, qu'il a anticipé les questions que les visiteurs peuvent se poser et qu'il a fait l'effort d'y répondre de manière simple. En se montrant bien préparé le projet envoie un message: « Vous n'allez pas perdre votre temps si vous vous engagez » , ce qui est exactement ce que les gens veulent entendre.
Mais en premier lieu, regardez autour de vous.
Avant de commencer un projet Open Source, faites attention à ceci :
Regardez toujours autour de vous pour savoir s'il n'existe pas déjà un projet qui réalise ce que vous voulez. Il y a de bonnes chances que, peu importe le problème que vous souhaitez résoudre, quelqu'un ait déjà pris l'initiative avant vous. S'ils ont réussi à résoudre ce problème et qu'ils ont rendu le code public sous une licence libre vous n'avez aucune raison de réinventer la roue. Il y a des exceptions bien sûr : si vous voulez débuter un projet qui servira d'expérience pédagogique un code pré-existant ne vous aidera pas ; ou alors le projet que vous avez en tête est si spécialisé que vous savez qu'il n'y a aucune chance que quelqu'un d'autre l'ait déjà fait. Mais en général il n'y a pas de raison de ne pas faire de recherche, le gain peut être énorme. Si les moteurs de recherche sur Internet ne retournent aucune réponse essayez de chercher sur http://freshmeat.net/ (un site rassemblant les nouvelles à propos de projets Open Source dont je parlerai plus longuement par la suite), sur http://www.sourceforge.net/ et dans le répertoire des logiciels libres de la Free Software Foundation à l'adresse http://directory.fsf.org/.
Mêmes si vous ne trouvez pas exactement ce que vous recherchiez vous pourrez découvrir quelque chose qui s'en approche suffisamment pour qu'il soit plus logique de rejoindre le projet et d'ajouter une fonctionnalité que de tout construire à partir de rien par vous même.
