Cap. 2. Începutul

Puneți-vă în pantofii cuiva care tocmai a auzit despre proiect, poate chiar în urma căutării unei aplicații care să rezolve o problemă. Primul lucru pe care îl vor observa va fi numele proiectului.

Un nume bun nu va aduce automat succesul proiectului la fel cum un nume rău nu-l va blestema—deși, în realitate, un nume foarte,rău ar putea face asta, vom porni de la presupunerea că niciunul dintre cititori nu vrea să-și facă proiectul să eșueze. Cu toate acestea, un nume rău poate încetini rata de adopție a proiectului, fie pentru că oamenii nu-l consideră serios, fie pentru că pur și simplu nu pot să-l rețină.

Un nume bun:

După ce au găsit site-ul proiectului, următorul lucru pe care oamenii îl vor face este să caute o descriere rapidă, o declarație a misiunii, astfel încât să decidă (în termen de 30 de secunde) dacă sunt sau nu interesați să afle mai multe. Aceasta trebuie amplasată pe prima pagină în mod proeminent, de preferință chiar sub numele proiectului.

Declarația scopului trebuie să fie concretă, limitatoare și, mai presus de orice, scurtă. Acesta este un exemplu bun, de la http://www.openoffice.org/:

În doar câteva cuvinte, au nimerit toate punctele importante, în special prin apelul la cunoștințele anterioare ale cititorului. Spunând: "ca și o comunitate", ei semnalizează faptul că nicio corporație nu va domina dezvoltarea; "internațional " înseamnă că aplicația va permite oamenilor să lucreze în mai multe limbi și cu mai multe setări locale; "toate platformele principale " înseamnă că aceasta va fi portabilă pe Unix, Macintosh și Windows. Restul sugerează faptul că interfețele deschise și formatele de fișiere ușor de înțeles sunt o parte importantă a țelului. Nu spun direct că vor să creeze o alternativă gratuită la Microsoft Office dar majoritatea oamenilor pot să citească printre rânduri. Deși această declarație pare largă la prima vedere, în realitate este destul de restrânsă: cuvintele "suită de produse pentru birou" au un înțeles foarte concret pentru cineva care este familiarizat cu astfel de aplicații. Din nou, se presupune experiența anterioară a cititorului (în acest caz, probabil din MS Office) pentru a face declarația misiunii concisă.

Natura declarației misiunii depinde parțial de cel care o scrie, nu doar de aplicația pe care o descrie. De exemplu, are sens pentru OpenOffice.org să folosească sintagma "ca și o comunitate ", pentru că proiectul a fost inițiat, și încă este sponsorizat în mare, de Sun Microsystems. Incluzând aceste cuvinte, Sun indică faptul că e conștientă de grijile că ar încerca să domine procesul de dezvoltare. În acest fel de probleme, simpla demonstrație de conștientizare a potențialului problemei ajută destul în evitarea problemei în întregimea ei. Pe de altă parte, proiectele care nu sunt sponsorizate de o corporație nu au nevoie de o astfel de sintagmă; dezvoltarea de către comunitate este lucrul normal așa că, în mod normal, nu ar fi niciun motiv pentru care să fie enumerat ca și parte a misiunii.

Cei care rămân interesați după ce au citit declarația scopului vor vrea să vadă mai multe detalii, poate documentația pentru utilizatori sau dezvoltatori, și, în cele din urmă, să downloadeze ceva. Dar înainte să se întâmple oricare dintre lucrurile acestea, vor dori să știe că sursele sunt deschise.

Prima pagină trebuie să explice clar și fără ambiguitate că proiectul este open-source. Poate părea evident acest lucru dar ați fi surprinși să aflați câte proiecte uită să facă asta. Am văzut site-uri de proiecte de software liber unde prima pagină nu numai că nu specifica sub care licență de software liber era distribuită dar nici măcar nu menționa faptul că proiectul e liber. Uneori cea mai importantă informație era retrogradată până la pagina de download, cea pentru dezvoltatori sau alt loc în care era nevoie de mai mult de un click de mouse pentru a ajunge. În cazuri extreme, licența nu apărea nicăieri pe site—singurul mod de a o găsi era de a downloada aplicația și de a căuta înăuntru.

Nu faceți această greșeală. O astfel de omisiune poate duce la pierderea unor potențiali dezvoltatori și utilizatori. Publicați pe prima pagină, chiar sub declarația scopului proiectului, că acesta este software liber sau open-source și menționați licența exactă. Un ghid scurt pentru alegerea licenței se găsește în „Choosing a License and Applying It” în continuarea acestui capitol, iar problemele legate de licențiere sunt discutate în detaliu în Cap. 9, Licenses, Copyrights, and Patents.

În acest moment, vizitatorul nostru ipotetic a determinat— probabil într-un minut sau mai puțin—că e interesat să petreacă, de exemplu, încă cinci minute pentru a investiga proiectul. Următoarele secțiuni descriu ce trebuie să descopere în acele cinci minute.

Ar trebui să existe o listă scurtă cu posibilitățile oferite de software (dacă una dintre ele nu e încă terminată, ea poate fi listată dar se pune "planificat" sau "în curs" lângă aceasta), și genul de sistem necesar pentru a rula software-ul. Gândiți-vă la lista de posibilități și cerințe la fel cum ați prezenta cuiva care vă cere un rezumat scurt al proiectului. De multe ori e doar o extindere logică a scopului declarat. De exemplu, declarația misiunii proiectului poate fi:

Lista de posibilități și cerințe ar da detaliile, clarificând prezentarea scopului declarat:

Având la dispoziție aceste informații, cititorii pot să înțeleagă rapid dacă acest proiect are vreo șansă să îi ajute și pot lua în calcul să contribuie și ei ca dezvoltatori.

Oamenii vor întotdeauna să afle în ce stadiu se află proiectul. Pentru proiectele noi, vor să știe care e diferența dintre promisiunile proiectului și realitatea curentă. Pentru proiectele mature, vor să știe cât de activ sunt întreținute, cât de des apar noi versiuni, cât de rapid se răspunde la erorile raportate, etc.

Pentru a răspunde la astfel de întrebări, trebuie să existe o pagină pentru starea dezvoltării în care să se prezinte scopurile pe termen scurt ale proiectului și nevoile (de exemplu, se poate să fie nevoie de dezvoltatori cu o anumită expertiză). Pagina poate da și informații despre versiunile anterioare, cu liste de capabilități, astfel încât vizitatorii să înțeleagă cum definește proiectul ideea de „progres” și cât de rapid progresează în concordanță cu acea definiție.

Să nu vă fie frică să păreți nepregătiți și nu cedați tentației de a minți în legătură cu starea proiectului. Toată lumea știe că aplicațiile evoluează în etape; nu e nicio rușine în a spune „aplicația e în stadiul alpha și are bug-uri cunoscute. Rulează, și funcționează în cea mai mare parte a timpului, dar o folosiți pe propria răspundere”. O astfel de exprimare nu va speria dezvoltatorii de care e nevoie în această etapă. Cât despre utilizatori, unul dintre cele mai proaste lucruri pe care le poate face un proiect este să atragă utilizatori înainte ca aplicația să fie pregătită pentru ei. O reputație de de instabilitate sau probleme (bug-uri) este greu de înlocuit odată „câștigată”. Conservatorismul are meritele lui pe termen lung; întotdeauna e mai bine ca aplicațiaa să fie mai stabilă decât se așteaptă utilizatorul decât mai puțin stabilă și surprizele plăcute produc cea mai bună reputație.

Aplicația trebuie să poată fi descărcată ca și cod sursă într-un format standard. Când proiectul se află la început, pachetele binare (executabile) nu sunt necesare decât dacă aplicația are cerințe sau dependențe atât de complicate pentru a fi transformată în executabil încât ar fi prea greu pentru majoritatea oamenilor să o facă să ruleze. (Dacă aceasta e situația, proiectul va avea probleme serioase în a atrage dezvoltatori orice-ar fi).

Mecanismul de distribuție trebuie să fie cât mai convenabil, standardizat și simplu. Dacă ați încerca să eliminați o boală, nu ați distribui medicamentul într-un așa fel încât ar fi nevoie de o dimensiune non-standard de seringă pentru a-l administra. La fel, aplicația trebuie să fie conformă cu metodele de compilare și instalare standard; cu cât deviază mai mult de la standarde, cu atât vor renunța mai ușor potențialii dezvoltatori și utilizatori și vor pleca.

Deși sună evident, majoritatea proiectelor nu se obosesc să standardizeze procedurile de instalare până la o etapă foarte târzie, spunându-și că pot să facă asta oricând: "O să rezolvăm toate problemele astea când codul va fi mai aproape de a fi gata."Ceea ce nu realizează e că, amânând munca plictisitoare de a termina procedurile pentru compilare și instalare, ei de fapt prelungesc durata de care e nevoie pentru a termina—pentru că ei descurajează dezvoltatorii care altfel ar fi putut contribui la cod. Mai grav de-atât, ei nu știu că pierd toți acești dezvoltatori pentru că procesul este o acumulare de non-evenimente: cineva vizitează site-ul, downloadează aplicația, încearcă să o folosească, nu reușește, renunță și merge mai departe. Cine va ști vreodată că s-a întâmplat în afară de acea persoană? Nimeni care lucrează la proiect nu va realiza interesul acelei persoane și un lucru bun va fi irosit în mod tacit.

Munca plictisitoare care poate aduce câștiguri mari ar trebui să fie făcută întotdeauna devreme și reducerea semnificativă a barierelor în calea celor care vor să se alăture proiectului aduce câștiguri mari.

Când creați un pachet binar downloadabil, e vital să dați un număr unic de versiune astfel încât oamenii să poată compara două versiuni diferite și să știe care dintre ele e mai recentă. O discuție detaliată a modului în care se dau numerele de versiune apare în „Release Numbering”, iar detaliile despre standardizarea procedurilor de compilare și instalare sunt prezentate în „Packaging”, amândouă regăsite în Cap. 7, Packaging, Releasing, and Daily Development.

Downloading source packages is fine for those who just want to install and use the software, but it's not enough for those who want to debug or add new features. Nightly source snapshots can help, but they're still not fine-grained enough for a thriving development community. People need real-time access to the latest sources, and the way to give them that is to use a version control system. The presence of anonymously accessible version controlled sources is a sign—to both users and developers—that this project is making an effort to give people what they need to participate. If you can't offer version control right away, then put up a sign saying you intend to set it up soon. Version control infrastructure is discussed in detail in „Version Control” in Cap. 3, Technical Infrastructure.

The same goes for the project's bug tracker. The importance of a bug tracking system lies not only in its usefulness to developers, but in what it signifies for project observers. For many people, an accessible bug database is one of the strongest signs that a project should be taken seriously. Furthermore, the higher the number of bugs in the database, the better the project looks. This might seem counterintuitive, but remember that the number of bugs recorded really depends on three things: the absolute number of bugs present in the software, the number of users using the software, and the convenience with which those users can register new bugs. Of these three factors, the latter two are more significant than the first. Any software of sufficient size and complexity has an essentially arbitrary number of bugs waiting to be discovered. The real question is, how well will the project do at recording and prioritizing those bugs? A project with a large and well-maintained bug database (meaning bugs are responded to promptly, duplicate bugs are unified, etc.) therefore makes a better impression than a project with no bug database, or a nearly empty database.

Of course, if your project is just getting started, then the bug database will contain very few bugs, and there's not much you can do about that. But if the status page emphasizes the project's youth, and if people looking at the bug database can see that most filings have taken place recently, they can extrapolate from that that the project still has a healthy rate of filings, and they will not be unduly alarmed by the low absolute number of bugs recorded.

Note that bug trackers are often used to track not only software bugs, but enhancement requests, documentation changes, pending tasks, and more. The details of running a bug tracker are covered in „Bug Tracker” in Cap. 3, Technical Infrastructure, so I won't go into them here. The important thing from a presentation point of view is just to have a bug tracker, and to make sure that fact is visible from the front page of the project.

Visitors usually want to know how to reach the human beings involved with the project. Provide the addresses of mailing lists, chat rooms, and IRC channels, and any other forums where others involved with the software can be reached. Make it clear that you and the other authors of the project are subscribed to these mailing lists, so people see there's a way to give feedback that will reach the developers. Your presence on the lists does not imply a committment to answer all questions or implement all feature requests. In the long run, most users will probably never join the forums anyway, but they will be comforted to know that they could if they ever needed to.

In the early stages of a project, there's no need to have separate user and developer forums. It's much better to have everyone involved with the software talking together, in one "room." Among early adopters, the distinction between developer and user is often fuzzy; to the extent that the distinction can be made, the ratio of developers to users is usually much higher in the early days of the project than later on. While you can't assume that every early adopter is a programmer who wants to hack on the software, you can assume that they are at least interested in following development discussions and in getting a sense of the project's direction.

As this chapter is only about getting a project started, it's enough merely to say that these communications forums need to exist. Later, in „Handling Growth” in Cap. 6, Communications, we'll examine where and how to set up such forums, the ways in which they might need moderation or other management, and how to separate user forums from developer forums, when the time comes, without creating an unbridgeable gulf.

If someone is considering contributing to the project, she'll look for developer guidelines. Developer guidelines are not so much technical as social: they explain how the developers interact with each other and with the users, and ultimately how things get done.

This topic is covered in detail in „Writing It All Down” in Cap. 4, Social and Political Infrastructure, but the basic elements of developer guidelines are:

No pejorative sense is intended by "dictatorship", by the way. It's perfectly okay to run a tyranny where one particular developer has veto power over all changes. Many successful projects work this way. The important thing is that the project come right out and say so. A tyranny pretending to be a democracy will turn people off; a tyranny that says it's a tyranny will do fine as long as the tyrant is competent and trusted.

See http://subversion.apache.org/docs/community-guide/ for an example of particularly thorough developer guidelines, or http://www.openoffice.org/dev_docs/guidelines.html for broader guidelines that focus more on governance and the spirit of participation and less on technical matters.

The separate issue of providing a programmer's introduction to the software is discussed in „Developer documentation” later in this chapter.

Documentation is essential. There needs to be something for people to read, even if it's rudimentary and incomplete. This falls squarely into the "drudgery" category referred to earlier, and is often the first area where a new open source project falls down. Coming up with a mission statement and feature list, choosing a license, summarizing development status—these are all relatively small tasks, which can be definitively completed and usually need not be returned to once done. Documentation, on the other hand, is never really finished, which may be one reason people sometimes delay starting it at all.

The most insidious thing is that documentation's utility to those writing it is the reverse of its utility to those who will read it. The most important documentation for initial users is the basics: how to quickly set up the software, an overview of how it works, perhaps some guides to doing common tasks. Yet these are exactly the things the writers of the documentation know all too well—so well that it can be difficult for them to see things from the reader's point of view, and to laboriously spell out the steps that (to the writers) seem so obvious as to be unworthy of mention.

There's no magic solution to this problem. Someone just needs to sit down and write the stuff, and then run it by typical new users to test its quality. Use a simple, easy-to-edit format such as HTML, plain text, Texinfo, or some variant of XML—something that's convenient for lightweight, quick improvements on the spur of the moment. This is not only to remove any overhead that might impede the original writers from making incremental improvements, but also for those who join the project later and want to work on the documentation.

One way to ensure basic initial documentation gets done is to limit its scope in advance. That way, writing it at least won't feel like an open-ended task. A good rule of thumb is that it should meet the following minimal criteria:

The last point is of wider importance, actually, and can be applied to the entire project, not just the documentation. An accurate accounting of known deficiencies is the norm in the open source world. You don't have to exaggerate the project's shortcomings, just identify them scrupulously and dispassionately when the context calls for it (whether in the documentation, in the bug tracking database, or on a mailing list discussion). No one will treat this as defeatism on the part of the project, nor as a commitment to solve the problems by a certain date, unless the project makes such a commitment explicitly. Since anyone who uses the software will discover the deficiencies for themselves, it's much better for them to be psychologically prepared—then the project will look like it has a solid knowledge of how it's doing.

If the project involves a graphical user interface, or if it produces graphical or otherwise distinctive output, put some samples up on the project web site. In the case of interface, this means screenshots; for output, it might be screenshots or just files. Both cater to people's need for instant gratification: a single screenshot can be more convincing than paragraphs of descriptive text and mailing list chatter, because a screenshot is inarguable proof that the software works. It may be buggy, it may be hard to install, it may be incompletely documented, but that screenshot is still proof that if one puts in enough effort, one can get it to run.

There are a few sites that provide free hosting and infrastructure for open source projects: a web area, version control, a bug tracker, a download area, chat forums, regular backups, etc. The details vary from site to site, but the same basic services are offered at all of them. By using one of these sites, you get a lot for free; what you give up, obviously, is fine-grained control over the user experience. The hosting service decides what software the site runs, and may control or at least influence the look and feel of the project's web pages.

See „Canned Hosting” in Cap. 3, Technical Infrastructure for a more detailed discussion of the advantages and disadvantages of canned hosting, and a list of sites that offer it.