Companie de dezvoltare. Când e bine să publici codul sursă sub o licență deschisă?

Când vine vorba despre lansarea unui produs, majoritatea companiilor de dezvoltare aleg să nu publice sursele aplicațiilor. Clienții primesc doar produsul final, într-un format care nu permite modificarea sa. Mai mult, unele companii își protejează în mod special produsele pentru a împiedica copierea sau modificarea lor. Există însă și o altă opțiune.

Mă refer, desigur, la publicarea surselor aplicațiilor realizate, sub una din licențele open source. Ca orice decizie de business, și aceasta este însoțită de avantaje și dezavantaje. Iată-le mai jos:

Avantaje:

• Adopția este mai rapidă. Atunci când oricine poate să descarce sursa aplicației (și, de cele mai multe ori, se oferă și varianta gata compilată și pregătită de rulare), mult mai multă lume va încerca produsele. Mai mulți oameni care încearcă = mai mulți posibili clienți plătitori.
• Se poate construi mult mai repede o comunitate în jurul produsului și poți să faci “croudsourcing”. Produsele open source au “darul” de a aduna mult mai repede o comunitate în jurul lor. Fie că este vorba despre utilizatori, administratori sau dezvoltatori, vei avea la dispoziție un număr mai mare de oameni pe care îi poți consulta în legătură cu dezvoltările ulterioare.
• Dezvoltarea este mai rapidă, feedback-ul este imediat. Ciclul de dezvoltare (testare – bug-fixing – release) tinde să fie mult mai scurt în cazul produselor open source, iar numărul de persoane implicate, mai mare (comunitatea de care am scris mai sus). Efortul de dezvoltare nu este mai mic, cum poate s-ar putea crede, dar tot restul procesului de testare și bug-fixing este mai dinamic.
• Suportul tehnic tinde să fie mai bun. Atunci când ai o comunitate stabilă, este suficient să îi pui la dispoziție un wiki și/sau un forum – acesta vor deveni aproape automat locuri în care suportul tehnic se oferă de către utilizatorii “avansați” către “începători”. În timp, baza de date cu probleme și soluții crește în cantitate și calitate.
• Ai un avantaj de imagine și încredere. Produsele open source pot fi analizate și auditate de oricine. Unii utilizatori au nevoie să se asigure că nu ai inclus în produs backdoor-uri, spyware sau probleme de securitate neintenționate. Mai mult, simplul fapt că ai în portofoliu produse open source îți creează o imagine favorabilă.

Dar nu totul este roz! Există un număr de dezavantaje și riscuri atunci când alegi să lansezi produse cu sursă deschisă:

• Nu ai control asupra modului în care este folosit produsul. Felul în care ți-ai închipuit tu că va fi utilizat produsul s-ar putea să nu aibă nici o legătură cu ce aleg utilizatorii să facă de fapt. Mai mult, pentru că produsul poate fi modificat, oricând te poți trezi că există un “fork” care se îndepărtează și mai mult de ideea originală. Dacă ești un “control freak”, mai bine rămâi la modelul de licențiere proprietar.
• Concurența te poate copia imediat. Dacă ai un produs bun tehnic, dar nu reușești să acoperi foarte repede o parte semnificativă din piață, este posibil ca un concurent care are resurse de marketing și vânzări considerabile să poată să vină cu o ofertă foarte bună și să “fure” clienții tăi. Nu uita că în lumea open source produsul poate să fie copiat, diferența o fac serviciile și comunitatea.
• Ai mai puțină flexibilitate în alegerea modului de licențiere și a felului în care poți vinde software-ul. Pentru că nu poți să vinzi (ușor) licențe de utilizare, iar despre vânzarea codului sursă nici nu se poate pune problema, trebuie să monetizezi pe partea de consultanță, suport tehnic, sau să oferi soluții SaaS.

După părerea mea, există foarte puține scenarii în care să fie de preferat să păstrezi produsele software “închise”, sunt în schimb un mare fan al licențelor open source, iar cele scrise mai sus sper să fie de ajutor companiilor de dezvoltare care vor să decidă ce model de licențiere este potrivit.

Dacă lucrezi într-o companiei de dezvoltare software, voi cum vă licențiați produsele? Scrie un comentariu mai jos!

Image credit: Declan Jewell.

No related posts.