|Riscurile asociate utilizării proiectelor open-source
Întrucât în decursul timpului am avut ocazia să dau peste multe probleme organizatorice ale proiectelor open-source m-am gândit să fac o mică prezentarea a acestora.
Înainte de a trece mai departe aș vrea să precizez că acest articol se referă la doar la riscuri și nu încearcă să denigreze imaginea proiectelor open-source sau să sugereze că cele comerciale ar fi mai bune.
#1 Un singur autor/administrator/contributor
Foarte multe proiecte open-source au un singur autor iar din această cauză pot apărea următoarele probleme:
- abandonarea – autorul dispare, nu mai este interesat să continue sau noul lui loc de muncă nu-i mai permite acest lucru
- neacceptarea diferitelor petice venite de la contributori ocazionali.
Probleme similar pot fi și atunci când sunt puțini contributori mai ales atunci când toți lucrează la aceeași firmă. Ideal ar fi ca proiectul să fie susținut de cel puțin două grupuri care să nu aibă alte legături decât interesul ca proiectul să continue și să nu devină abandonware sau să i se schimba scopul (se întâmplă des ca autorul să închidă proiectul continându-l cu un proiect comercial).
#2 Model decizional închis
Nu garantează nimeni că autorii proiectului sunt deschiși la sugestiile comunității de utilizatori. Se întâmplă și nu foarte rar ca autorii proiectului să refuze diferite sugestii, iar acum nu mă refer la cereri din partea utilizatorilor ci chiar să refuze petice venite de la aceștia fără a da motive întemeiate.
#3 Ramnificarea proiectului (forking-ul)
Se întâmpla ca atunci când apar neînțelegeri mari între administratori și alți membrii permanenți sau actuali unii să decidă să creeze o ramură proprie a proiectului și să continue dezvoltarea pe ea. Problemele generare de ramnificare ar fi:
- neclarități între utilizatori
- împărțirea comunității și chiar și a echipei de contributori
Exemple ar fi Media Player Classic cu cele două ramuri ale sale.
#4 Interesele autorului
Foarte multe proiecte open-source, probabil majoritatea, sunt create tot cu scopul unui profit – lucru care nu este neapărat rău. Totuși atunci când deținătorul proiectului nu clarifică modelul de business pe care îl urmează apar tot felul de probleme precum:
- nu-ți acceptăm contribuția dacă nu ești partener (… mai exact să cotizezi cumva)
- îngreunarea comunicării între utilizatori cu speranța că aceștia vor apela la asistență (contra cost)
- apariția unor mesaje (deranjante uneori) ce te roagă să donezi pentru viitorul proiectului
#5 lipsă unui ‘open-workflow’
Faptul că un proiect este open-source nu însemnă neapărat că aveți acces la următoarele
- bug-tracker public
- source repository public
- posibiltiatea de a descărca oricând ultima versiune
- forum de discuții
- listă de discuții
- politică de primire de petice (patch)
- politică de aprobare sau respingere a anumitor propuneri
Probabil că ar fi interesant de realizat un indicator al sănătății unui proiect open-source – un indicator care să măsoare riscurile de mai sus. Desigur că multe alte riscuri mi-au scăpat așa că aștept părerile voastre.
No comments yet.
English