proiectele closed source sug (uneori)
sâmbătă, 1 sept. 2012, 13:58
[ 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…)
- 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. [↩]
- i.e. „time to market” [↩]
- Ș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. [↩]
proprietatea intelectuală, implicații tehnice
vineri, 9 mart. 2012, 19:11
Dat fiind faptul că sunt filosof în aceeași măsură în care Ilie Moromete e filosof și dat fiind de asemenea faptul că nu sunt specialist în probleme de economie și cu atât mai puțin în probleme de drept, eu unul nu pot nici măcar să încep a concepe o etică a pirateriei. Eu doar am observat ceea ce mi se pare a fi o problemă gravă, iar mai departe cine are ochi să și-i belească.
Ceea ce pot face însă e să mă uit la problemă dintr-un unghi familiar mie, anume cel tehnic, unghi din care tot privesc lucrurile în ultimii șase ani sau mai mult. Scurta descriere a anatomiei modelului proprietar tratează deja o parte din aspectele care contribuie la toată această babilonie însă nu intră prea tare în detalii, astfel că rămâne ca dânsele să fie penetrate în cele ce urmează. Propun astfel să mergem în continuare pe linia produselor de tip software, în ideea că se pot face în principiu analogii cu restul lucrărilor mai mult sau mai puțin artistice care-s în același timp și proprietate intelectuală, dar mai ales deoarece software-ul pune cele mai mari probleme din acest punct de vedere.
Și voi începe direct cu motivul care stă la baza tuturor problemelor: software-ul în esența sa (și poate doar acolo) este fără dubiu o formă de exprimare aparținând domeniului public, în aceeași măsură în care pictura spre exemplu aparține domeniului public, în virtutea faptului că exprimarea denotă prin definiție comunicare. Diferența principală constă în faptul că expresia software-ului e îngrădită de rigoarea matematicii, orice algoritm convențional reducându-se la idiomuri/formalisme standard. (mai mult…)
anatomia modelului proprietar
sâmbătă, 18 feb. 2012, 20:00
Cuvântul „proprietar” are în limba română un înțeles înrudit cu, însă diferit de cel folosit în cele ce urmează. Proprietarul este astfel cel care deține, posesorul, stăpânul. Ideea de software proprietar sau de model proprietar al software-ului este împrumutată din englezescul „proprietary software”, pentru care nu știu să existe o altă traducere în română.
O analiză a modelului proprietar, cu avantajele și dezavantajele sale, nu ar putea exista în lipsa unei plasări în contextele spațial și temporal a acestuia. Spațiul este pur și simplu economia de piață, cu agenții dânsei (i)raționali și în număr foarte mare [i]. Contextul temporal merge în ambele sensuri, cel trecut fiind exact, iar viitorul fiind alcătuit dintr-o mulțime de perechi eveniment-probabilitate.
Se întâmplă astfel că software-ul s-a încadrat destul de bine în clasa proprietății intelectuale, el fiind mai aproape de ceva abstract precum poezia decât de ceva concret; vorba aia, dintr-un punct de vedere pur teoretic vorbind softurile nu se uzează în timp. Deși pe vremea primelor calculatoare programabile nu se gândea mai nimeni să scoată bani din software, programarea fiind o chestie destinată exclusiv specialiștilor în arhitecturi de calculatoare (adică acelora care și proiectau mașinile de calcul), odată cu evoluția lingvisticii computaționale și a puterii de calcul o serie de indivizi s-au gândit că soluțiile software pot fi vândute pentru cele câteva sute sau mii de calculatoare existente în anii ’70. Astfel s-au scos bani buni din sisteme de operare precum variante Unix sau din programe pentru inginerie sau calcul de înaltă performanță, deci cam din singurele lucruri la care erau folosite calculatoarele pe vremea aia. (mai mult…)
- Cu excepția cazurilor când sunt foarte puțini, de exemplu unul singur. [↩]