spyked bricks in the wall

proiectele closed source sug (uneori)

[ studiu de caz. ]

Afirmația de mai sus nu vrea să implice faptul că proiectele open source nu sug (uneori), ci că pur și simplu proiectele closed source sug, adică-s nașpa în diferite feluri și din mai multe puncte de vedere, în funcție de ochiul care privește. De exemplu în opinia lui Richard Stallman [i] „closed source”, sau mai bine zis „non-free/libre software” este sursa răului absolut, pentru căcum să ai tu în casă o unealtă pe care să nu o poți modifica după bunul plac, de parcă oamenii incompetenți tehnic – adică majoritatea utilizatorilor de calculatoare – ar fi interesați de asta. Eu aleg să discut aici un punct de vedere mai relevant și absolut practic, și anume eficiența dezvoltării proiectelor software.

Discutam acum ceva timp despre eficiența proiectării programelor pe calculator. Deși aspectul are o importanță deosebită în ceea ce privește fundamentele ingineriei software, lucrurile se complică foarte mult în viața reală, acolo unde apar probleme de coordonare, deadline-uri, secrete și alți astfel de dragoni mai mult sau mai puțin plăcuți. Cu alte cuvinte gradul de „închidere” al unui proiect și dificultatea de mentenanță a acestuia sunt corelate pozitiv fără doar și poate, demonstrația fiind pe cât de evidentă pe atât de banală. În același timp livrarea pe piață [ii] e unul din factorii care pot face diferența între un proiect de succes și un rateu, dat fiind că clienții au nevoie de produs ieri [iii], nu peste un an. Nucleul Linux e în mod evident cel mai bun exemplu de succes, pentru că organizarea sa e de așa natură încât îmbunătățirile sunt aduse în (sau aproape de) producție în maxim trei luni de la apariția hardware-ului – nu musai pe piață. Dar să lăsăm Linux pe altă dată. (mai mult…)

1. Despre care am putea presupune că contează ca ideolog al lumii software, el fiind unul din cei care au reușit să imprime avântul necesar apariției unor comunități de dezvoltatori care să producă așa-zisul „free software”. Eu am dubiile mele în privința individului, dar în fine, ce-i al lui e al lui – emacs de exemplu. [↩]
2. i.e. „time to market” [↩]
3. Și nu, acesta nu este un sofism. Gândiți-vă în felul următor: eu, client fiind, mă gândesc astăzi că mi-ar folosi chestia X. Eu nu sunt capabil și/sau nu îmi doresc să produc X, însă sunt dispus să plătesc mâine. Ori dacă X nu-i disponibil mâine pe piață iar eu m-am gândit deja că îmi doresc X, atunci se poate spune – cam tras de păr aș zice eu – că potențialii vânzători de X – actualii dezvoltatori – lucrează deja în pierdere. Cu alte cuvinte există întotdeauna un risc asociat „supra-marketării”, care poate genera mai mult „hype” decât este necesar. [↩]