Sa dezvolti un proiect opensource din punct de vedere al programarii este relativ usor. Ai o idee, ai un calculator, instalezi sculele de dezvoltare si poti incepe sa dezvolti. Problemele apar mai tirziu in momentul in care proiectul incepe sa prinda contur si devine utilizabil. Orice proiect opensource trebuie sa se bazeze pe feedback. Care sint greselile care se fac de obicei?
- Proiectul nu are un mailing list. Atit dezvoltatorii cit si utilizatorii trebuie informati asupra evolutiei proiectului. Pentru un proiect mediu / mare de obicei se recomanda crearea a 3 liste de discutii.
- developers – lista de discutii despre aspectele de development al proiectului .
- users – lista de discutii intre utilizatorii proiectului. Aici se pot face sugestii despre noi facilitati ce ar trebui adaugate la proiect, se pot pune intrebari si primi raspunsuri referitoare la utilizarea programului.
- announce – lista de trafic mic pe care se anunta noile versiuni disponibile sau updateurile de securitate
Arhiva cu mailing list-urile trebuie sa fir disponibila via web. Acest lucru combinat cu indexarea in google ajuta la atit la autopromovarea indirecta a proiectului cit si la regasirea usoara a discutiilor. Nu este recomandata inlocuirea mailing listurilor cu forums / blogs / etc deoarece regasirea informatiilor este mai dificila.
- Site-ul web al proiectului este incilcit. De obicei site-urile proiectelor sint facute in graba de catre dezvoltator sau de catre un programator. Si arata ca facute de un programator. Este de preferat ca site-ul sa fie simplu si orice informatie sa fie disponibila dupa un numar cit mai mic de “clicks”. Este necesar sa fie vizibila versiunea curenta stable / versiunea de development si schimbarile majore din versiunea curenta. De asemenea este foarte important sa poata fi gasita repede modalitatea de contact. Nimeni nu sta sa caute in site modalitatea de contact. Ca exemplu pozitiv vedeti blogul lui Zoso . Datele de contact sint simplu sus in dreapta. Foarte elegant si eficient.
- Prea multa informatie tehnica pe prima pagina( in cazul proiectelor care se adreseaza utilizatorilor). O alta greseala care se face este ca pe prima pagina se pune foarte multa informatie tehnica. Daca proiectul se adreseaza utilizatorilor partea tehnica e secundara. Pentru un utilizator un screenshot face cit 5 pagini de text.
- Relatia intre dezvoltator – utilizator este de tip “me god, u lame” . Greseala frecventa la proiectele opensource. Este foarte adevarat ca dezvoltatorul a investit timp, nervi si in final bani in proiectul lui. Dar daca trateaza utilizatorii proiectului “de sus” si nu tine seama de necesitatile lor, va ramine fara utilizatori iar fara utilizatori proiectul ramine fara feedback.
La un moment dat probabil ca dezoltatorul va incerca sa “scoata bani” din proiectul lui. Nimic rusinos sau gresit in asta. Pina la urma trebuie sa si traiasca. Alegerea momentului de trecere la “comercial” este foarte dificil de luat in primul rind din cauza perceptiei utilizatorilor. Celebra si trista replica: “Io-te ba si asta. Dupa ce l-am ajutat cu feedback, acuma vrea sa se imbogateasca pe munca noastra” este la ordinea zilei. Va recomand sa cititi postului lui Dragos despre “OpenSource & Bussiness”
Ma opresc aici deocamdata.