POSS Chap 2 Part 4
Un article de Framalang Wiki.
[modifier] Announcing
Once the project is presentable-not perfect, just presentable-you're ready to announce it to the world. This is actually a very simple process: go to http://freshmeat.net/, click on Submit in the top navigation bar, and fill out a form announcing your new project. Freshmeat is the place everyone watches for new project announcements. You only have to catch a few eyes there for news of your project to spread by word of mouth.
If you know of mailing lists or newsgroups where an announcement of your project would be on-topic and of interest, then post there, but be careful to make exactly one post per forum, and to direct people to your project's own forums for follow-up discussion (by setting the Reply-to header). The posts should be short and get right to the point:
To: discuss@lists.example.org Subject: [ANN] Scanley full-text indexer project Reply-to: dev@scanley.org
This is a one-time post to announce the creation of the Scanley project, an Open Source full-text indexer and search engine with a rich API, for use by programmers in providing search services for large collections of text files. Scanley is now running code, is under active development, and is looking for both developers and testers.
Home page: http://www.scanley.org/
Features:
- Searches plain text, HTML, and XML - Word or phrase searching - (planned) Fuzzy matching - (planned) Incremental updating of indexes - (planned) Indexing of remote Web sites
Requirements:
- Python 2.2 or higher
- Enough disk space to hold the indexes (approximately 2x
original data size)
For more information, please come to scanley.org.
Thank you, -J. Random
(See the section called "Publicity" in Chapter 6, Communications for advice on announcing further releases and other project events.)
There is an ongoing debate in the free software world about whether it is necessary to begin with running code, or whether a project can benefit from being opened even during the design/discussion stage. I used to think starting with running code was the most important factor, that it was what separated successful projects from toys, and that serious developers would only be attracted to software that did something concrete already.
This turned out not to be the case. In the Subversion project, we started with a design document, a core of interested and well-connected developers, a lot of fanfare, and no running code at all. To my complete surprise, the project acquired active participants right from the beginning, and by the time we did have something running, there were quite a few volunteer developers already deeply involved. Subversion is not the only example; the Mozilla project was also launched without running code, and is now a successful and popular Web browser.
In the face of such evidence, I have to back away from the assertion that running code is absolutely necessary for launching a project. Running code is still the best foundation for success, and a good rule of thumb would be to wait until you have it before announcing your project. However, there may be circumstances where announcing earlier makes sense. I do think that at least a well-developed design document, or else some sort of code framework, is necessary-of course it may be revised based on public feedback, but there has to be something concrete, something more tangible than just good intentions, for people to sink their teeth into.
Whenever you announce, don't expect a horde of volunteers to join the project immediately afterward. Usually, the result of announcing is that you get a few casual inquiries, a few more people join your mailing lists, and aside from that, everything continues pretty much as before. But over time, you will notice a gradual increase in participation from both new code contributors and users. Announcement is merely the planting of a seed. It can take a long time for the news to spread. If the project consistently rewards those who get involved, the news will spread, though, because people want to share when they've found something good. If all goes well, the dynamics of exponential communications networks will slowly transform the project into a complex community, where you don't necessarily know everyone's name and can no longer follow every single conversation. The next chapters are about working in that environment.
[modifier] Annoncer
Une fois que le projet est présentable, pas parfait, juste présentable, vous êtes prêt à l'annoncer au monde entier. C'est en fait un processus très simple : allez sur http://freshmeat.net/, cliquez sur « Submit » (Soumettre) en haut de la barre de navigation et remplissez un formulaire pour annoncer l'existence de votre nouveau projet. C'est sur Freshmeat que tout le monde se rend pour surveiller les annonces concernant les nouveaux projets. Vous devrez attirer l'attention de quelques paires d'yeux ici pour que le bouche à oreille à propos de votre projet commence.
Si vous connaissez des listes de discussion ou des newsgroups où l'annonce de votre projet cadrerait avec le sujet et apporterait quelque chose alors écrivez-y. Mais prenez garde de faire exactement un sujet par forum et de rediriger les gens vers le forum de votre projet pour poursuivre la discussion (en modifiant « Répondre à » dans l'en-tête). Le message se doit d'être court et d'aller directement au but :
A : discuss@lists.example.org Sujet : [ANN] Projet Scanley d'indexation de textes complets Répondre à : dev@scanley.org
Ceci est un message ponctuel pour annoncer la création du projet Scanley,
un outil d'indexation de texte complet, Open Source, ainsi qu'un moteur
de recherche avec une API riche, à l'usage des programmeurs afin de
permettre un service de recherche pour de grandes quantités de documents
écrits. Scanley est fonctionnel, en cours de développement intense et
recherche des développeurs et des testeurs.
Site internet : http://www.scanley.org
Fonctionnalités :
- Recherche de texte brut, HTML et XML - Recherche de mot ou de phrase - (prévu) Correspondance approximative - (prévu) Mise à jour incrémentale des indexes - (prévu) Indexation de sites Web distants
Pré-requis:
- Python 2.2 ou supérieur - Suffisamment d'espace disque pour contenir les indexes (approximativement 2x la taille d'origine des données)
Pour de plus amples informations, visitez scanley.org.
Merci, -A.Nonyme (Voir la section appelée « Publicité » dans le Chapitre 6, Communication pour des conseils concernant l'annonce des futures versions et autres évènements liés au projet.)
Il y a un débat actuellement dans le monde du logiciel libre, doit-on commencer avec un code fonctionnel ou est-il plus profitable pour le projet d'être rendu public même pendant la période de conception/discussion ? Avant je pensais que commencer un projet avec un code qui marche était le facteur le plus important, que c'était ce qui séparait les projets réussis des gadgets et que les développeurs sérieux ne seraient attirés que par des logiciels qui réalisent déjà quelque chose de concret.
Finalement ce n'est pas toujours le cas. Pour le projet Subversion nous avons commencé avec un modèle, un cœur de développeurs intéressés et proches, beaucoup de paillettes et absolument pas de code. A ma grande surprise, le projet a rassemblé des participants actifs dès le début et au moment où nous avions quelque chose de fonctionnel il y avait déjà quelques volontaires très impliqués dans le projet. Subversion n'est pas le seul exemple, le projet Mozilla a également commencé sans code fonctionnel et maintenant c'est un navigateur Internet populaire et qui rencontre beaucoup de succès.
Face à de telles preuves, j'ai dû revoir ma position sur le fait qu'un code qui marche est absolument nécessaire pour lancer un projet. Un code fonctionnel reste la meilleure base du succès et l'expérience voudrait qu'on attende qu'on l'ait avant d'annoncer la création du projet. Quoiqu'il en soit, certaines circonstances font qu'une annonce anticipée a du sens. Je pense en effet qu'un modèle bien fait ou une sorte de trame pour le code est nécessaire, évidemment il peut être retouché selon les critiques publiques, mais il faut proposer quelque chose de concret, quelque chose de plus tangible que des bonnes intentions, auquel les gens pourront se raccrocher.
Chaque fois que vous annoncez, ne vous attendez pas à voir débarquer une horde de volontaires désirant joindre le projet ensuite. En général, le résultat de votre annonce sera la réception de quelques questions désinvoltes, quelques personnes de plus joindront les listes de diffusion et à part ça les choses continueront comme avant. Mais avec le temps vous remarquerez une augmentation progressive de la participation à la fois des développeurs et des utilisateurs. Annoncer, c'est comme planter une graine. La nouvelle peut mettre du temps à se répandre. Si le projet récompense systématiquement ceux qui s'investissent la nouvelle se répandra malgré tout, parce que les gens parlent quand ils ont bien aimé quelque chose. Si tout se passe bien, les lois exponentielles des réseaux de communications transformeront doucement votre projet en une communauté complexe, où vous ne connaîtrez pas forcément chacun par son nom et où vous ne pourrez plus suivre toutes les discussions. Les prochains chapitres traiteront du travail dans cet environnement.
[10] We haven't gotten to the section on crediting yet, but just to practice what I'll later preach: the observer's name was Brian Behlendorf, and it was he who pointed out the general importance of keeping all discussions public unless there was a specific need for privacy.
[11] This is how code review is usually done in Open Source projects, at any rate. In more centralized projects, " code review " can also mean multiple people sitting down together and going over printouts of source code, looking for specific problems and patterns.[10] Nous n'en sommes pas encore aux remerciements, mais je vais déjà mettre en pratique ce que je prêcherai plus tard : l'observateur était Brian Behlendorf et c'est lui qui a signalé l'importance de maintenir toutes les discussions publiques à moins que vous n'ayez un besoin particulier de confidentialité.
[11] C'est en général comme ça que se passe l'inspection du code dans les projets Open Source dans tous les cas. Dans des projets plus centralisés, « inspection du projet » peut aussi désigner une assemblée de gens s'asseyant autour d'une table pour relire des copies du code source, à la recherche de problèmes et de formules particulières.
