Software-ul open source are următoarele proprietăți obligatorii. Utilizarea software-ului open source pentru a crea produse comerciale de succes

Software-ul open source are admiratorii săi, iar în ultima perioadă când vine vorba de dezvoltarea unui fel de produse „naționale”, deci practic se înțelege open-source. În mod paradoxal, interesul pentru acest tip de software a generat o mulțime de distorsiuni și concepții greșite care în practică împiedică distribuirea acestuia.

Compania noastră participă la proiecte open source din 2005 - și datorită dezvoltării propriilor soluții open source (proiecte OpenVZ, CRIU), participând la alte proiecte open source (QEMU, OpenStack, libvirt, libcontainer etc.). În ultimii 10 ani, am adunat unele dintre cele mai comune mituri despre software-ul open source. Voi trece peste fiecare dintre concepțiile greșite și voi explica de ce este greșită. Cu siguranță, vă veți aminti tot atâtea, dar, după părerea mea, aceste cinci sunt cele mai „infernale”.

Proiectul open source este un proiect open source.

Orice proiect software constă din multe artefacte: cod sursă al proiectului, informații despre defectele necorectate, cod sursă de testare, documentație. Codul sursă al proiectului este doar o parte a acestuia, accesul liber la care nu dă dreptul de a deschide întregul proiect. Pe lângă codul sursă, alte artefacte de dezvoltare ar trebui să fie disponibile gratuit, iar cu cât sunt mai multe artefacte deschise, cu atât proiectul este mai deschis contribuitorilor (persoane care doresc să contribuie la proiect). În plus, sunt necesare procese transparente între toți membrii comunității, comunicări deschise în proiect etc. Toate aceste măsuri vor contribui doar la dezvoltarea proiectului și la cooperarea fructuoasă a membrilor comunității.

Calitatea software-ului open source este mai proastă, deoarece oricine poate scrie cod pentru el.

Principiul principal al software-ului open source - dezvoltarea comună deschisă - în sine este o garanție că codul de calitate scăzută, cârjele și patch-urile pur și simplu nu pot fi ascunse de ceilalți participanți. O persoană, care participă la astfel de proiecte, este pregătită pentru faptul că munca sa va fi supusă atât analizei, cât și criticilor și, prin urmare, nu va înșela. Reputația lui este în joc și nimeni nu vrea să o piardă.

În plus, în unele comunități (de exemplu, comunitatea din jurul dezvoltării nucleului Linux) există un principiu strict - doar codul cel mai bun, testat și ideal este acceptat în nucleul original. O încercare de a adăuga modificări de calitate scăzută va fi respinsă, a doua încercare este plină de pierderea reputației persoanei sau companiei care contribuie.

Adică, un proiect open source face într-adevăr posibil ca orice persoană să participe la scrierea codului, dar în proiecte serioase, din cauza pragului ridicat de intrare, codul nu va fi acceptat de la persoane cu un nivel insuficient de expertiză.
Majoritatea companiilor mari de IT (IBM, Google, Canonical, Parallels etc.) au departamente întregi în care specialiștii sunt plătiți pentru a lucra la proiecte open source și astfel lucrează indirect la produsele companiei.

Separat, este de menționat că companiile care dezvoltă produse bazate pe proiecte open source, în timpul testării, sunt interesate să îmbunătățească codul proiectelor open source pe care le folosesc. Prin urmare, toate problemele descoperite trebuie remediate și asigurate că această remediere a fost adăugată la ramura principală a proiectului pentru a avea cât mai puține diferențe în codul dvs. și codul proiectului deschis. Produsele noastre folosesc codul altor proiecte open source, așa că remediam problemele găsite în codul acestor proiecte și le trimitem în amonte. Acesta a fost cazul vulnerabilităților din nucleul RHEL: Red Hat l-a notat pe Vladimir Davydov pentru că a descoperit vulnerabilități grave CVE-2014-0203 și CVE-2014-4483 într-una dintre actualizările nucleului RHEL6 (a doua problemă, de altfel, a fost găsit utilizând unul dintre testele noastre automate, folosind Linux Test Project). Vasily Averin a primit recunoștință pentru găsirea erorii CVE-2014-5045, Dmitry Monakhov pentru CVE-2012-4508. Faptul de a testa bine kernel-ul Linux a fost remarcat chiar de Andrew Morton (cine este acesta?): „Mă interesează. În ultimele luni, cei de la @ openvz.org au găsit (și au remediat) o grămadă de erori obscure, dar serioase și destul de vechi. Cum ai găsit aceste bug-uri?”

Rezultat

De fapt, toate aceste mituri apar în cea mai mare parte în rândul utilizatorilor care fie abia încep să lucreze cu software-ul OpenSource, fie nu l-au încercat deloc. Cel mai bun mod de a scăpa de prejudecăți este să începeți să lucrați îndeaproape cu astfel de soluții.
Am actualizat recent produsul nostru Virtuozzo 7. Dacă sunteți, de asemenea, interesat să creați cea mai bună tehnologie de virtualizare a containerelor, atunci

Eforturile producătorilor de echipamente informatice de a promova soluții susținute de un sprijin puternic de marketing sunt recunoscute pe scară largă software cu sursă deschisă(software open source). În uzul oficial modern în rusă, acest fenomen este de obicei numit software gratuit(SPO).

Esența conceptului constă în mai multe principii pentru crearea și distribuirea de software open source:

• disponibilitatea codurilor sursă pentru toată lumea;
• politica de licențiere de distribuție bazată pe una dintre licențele aprobate de comunitate (vezi opensource.org);
• capacitatea de a participa direct la dezvoltarea și corectarea erorilor software pe cont propriu;
• capacitatea de a schimba unele funcții software și de a se adapta la noile condiții (sub rezerva disponibilității modificărilor pentru întreaga comunitate);
• compatibilitate maximă cu standardele deschise;
• capacitatea de a lucra în diverse sisteme de operare și pe mai multe platforme (cross-platform).

Aceste principii sunt folosite pentru a crea majoritatea

SPO. Este demn de remarcat faptul că există o diferență notabilă între gratuitși gratuit PE. În ciuda faptului că majoritatea licențelor de software open source sunt de distribuție gratuită, această proprietate în sine nu este suficientă pentru ca software-ul să fie considerat software liber.

Open Source a câștigat deja o serie de victorii importante asupra unora dintre cei mai puternici furnizori de software proprietar. Mai exact serverul web Apache este cu mult înaintea produselor similare de la alte companii (inclusiv Microsoft)în ceea ce privește cota de piață datorită costului scăzut, independenței furnizorului, mulți utilizatori experimentați în administrarea sa și asistență pentru dezvoltatori. Linux a ocolit toate celelalte tipuri din punct de vedere al aprovizionării Unix pentru platformă Intel, inclusiv conducerea de lungă durată SCO. SGBD-urile cu sursă deschisă au o prezență puternică în sistemul de operare cu sursă deschisă și pe piețele populare de internet low-end. Amenințarea la adresa software-ului proprietar provine din beneficiile software-ului open source similare cu cele ale internetului, de exemplu. deschidere, libertate de adaptare etc.

Software-ul gratuit are deja o prezență puternică în sistemele de operare pentru server, infrastructura de internet, servere de aplicații web, SGBD-uri pentru întreprinderi mici și departamentale bazate pe baze de date web cu generare dinamică de pagini web, sisteme de calcul tehnice și încorporate și software pentru dispozitive server. Vorbind despre infrastructura internetului, trebuie remarcat faptul că majoritatea dispozitivelor rulează sisteme de operare și alte software-uri open source. Aceste dispozitive includ servere de nume de domeniu, routere, comutatoare, firewall-uri, gateway-uri, echilibrare de încărcare, servere de aplicații și baze de date și multe altele.

Având în vedere aceste progrese, software-ul open source pune în pericol firmele a căror principală sursă de venit sunt taxele de acces pentru clienți și taxele de licențiere a software-ului proprietar. Open Source aduce modelul de afaceri moștenit și al mărfurilor de consum de pe piața hardware la software - un model la care este dificil să se adapteze unui furnizor tradițional de software, în special unui lider.

Mulți dintre vânzătorii care folosesc modele de afaceri open source nu s-au dezvoltat ca furnizori de software tradițional încă de la început. Pe măsură ce cota lor de pe piața de software open source crește și poziția sa pe piețele strategice de internet este în creștere, furnizorii tradiționali de software identifică amenințările din sursa deschisă și oportunitățile prezentate de noile modele de afaceri. Desigur, furnizorii de software vechi au capacitatea de a adopta aceste modele de afaceri în întregime sau parțial, în funcție de portofoliul lor de produse. Chiar și așa, open source reprezintă o amenințare tangibilă și foarte reală pentru modelele de afaceri obișnuite ale companiilor de software.

Există patru principale amenințări open source la adresa companiilor închise.

• Presiunea prețurilor. Deoarece licențele open source, de fapt, necesită distribuția gratuită a software-ului și modificările acestuia, prețurile pentru produsele tradiționale similare trebuie reduse pentru a nu ceda software-ului open source și pentru a lupta împotriva pierderii cotei de piață. De exemplu, SCO nu pot lua 2.000 USD pentru Unix pentru platformă Intel, in timp ce Linux disponibil gratuit, a Microsoft monopolizează sectorul desktop-urilor. Furnizorii tradiționali pot, totuși, să-și recupereze parțial pierderile făcând produsele lor software de o calitate mai bună decât JV O și percepând taxe suplimentare pentru aceasta.
• Funcționalitate suficient de bună. Software-ul „destul de bun” (dar nu cel mai bun) poate exclude parțial produsele vânzătorilor tradiționali de software, care vizează prea des piața de masă. O funcționalitate mai complexă (și costisitoare) în primele etape ale dezvoltării sale este întotdeauna vizată către un grup relativ mic de utilizatori profesioniști. Dar chiar și producătorii care operează pe această piață trebuie să înțeleagă clar că piața software-ului foarte dezvoltat se va extinde și se va adânci. Dacă funcționalitatea avansată nu reușește să atragă o bază mai largă de utilizatori, clienții vor cumpăra în mod natural alternative open source, deși mai puțin avansate. Pe piețele de masă foarte mari, furnizorii dominanti de software open source, pe lângă creșterea ofertei, au spațiu amplu de creștere prin strategii complementare de produse și servicii. Dimensiunea pieței de masă în sine asigură prețuri mai mici datorită volumelor mari de livrări, ceea ce permite utilizatorilor finali să primească profituri tangibile chiar și cu o ușoară creștere a costului produselor lor.

În unele cazuri, software-ul open source poate ocoli chiar și produsele tradiționale în ceea ce privește funcționalitatea. De exemplu, Apache a devenit primul server web care a oferit o funcție de Internet populară printre furnizori IP-aliasing, permițând găzduirea mai multor nume de domenii Internet pe un sistem.

• „Efecte de rețea”, datorită cunoștințelor și studiului software-ului și instrumentelor de utilizare în masă. Costul instruirii utilizatorilor noii tehnologii reprezintă o parte semnificativă din costul total de proprietate, mai mult decât prețul produsului software în sine. O companie cu o bază mare de utilizatori familiarizați cu produsul și instrumentele însoțitoare ale acestuia poate valorifica această familiaritate prin lansarea de noi versiuni sau intrarea pe piețele conexe. Acest tip de efect de rețea poate varia în funcție de tipul de utilizator pe care îl folosesc dezvoltatorii de software API, administratori de sistem - instrumente de administrare specifice, utilizatorii lucrează cu interfețe grafice cu utilizatorul, iar managerii stabilesc relații cu furnizorii. Odată formată, această rețea de parteneri și utilizatori ai soluțiilor open source nu mai este distrusă și vă permite să rezolvați probleme de marketing de ordin mai mic, cum ar fi câștigarea de aderenți și loialitatea clienților.
• Presiunea standardizării. Cea mai recentă amenințare din partea mișcării open source sunt instrumentele și cultura acesteia, care își vede inamicul ca fiind dușmanul tuturor barierelor tehnologice ridicate de furnizorii tradiționali de software.

Recent, direcția cu cea mai rapidă dezvoltare în software este așa-numita "comercialsursa deschisa ", acestea. JV O susținută de companii comerciale convenționale. Corporația ar trebui să fie considerată unul dintre liderii în acest domeniu. Soare, care dezvoltă mai multe proiecte mari în acest sector: OpenSolaris OS, SGBD MySQL, suite office OpenOffice.orgși mediul de virtualizare Cutie virtuală. De regulă, există mai multe versiuni ale unui astfel de software, inclusiv una comercială. Atunci când plătește pentru o licență, utilizatorul primește asistență tehnică, precum și, în unele cazuri, instrumente speciale pentru lucru convenabil care nu sunt disponibile sub o licență deschisă. Adică, cu nevoi mici, companiile pot folosi versiuni gratuite sau gratuite de software, iar odată cu creșterea cererilor, pot cumpăra extensii comerciale fără a schimba nimic în infrastructura și aplicațiile lor. Astfel, versiunea comercială a software-ului open source concurează direct cu dezvoltarea companiilor tradiționale, de exemplu Microsoft, care creează în mod activ scheme speciale de licențiere pentru utilizare în mediul Internet (vorbim despre software-ul server).

Drept urmare, software-ul open source de pe Internet joacă un rol de formare a sistemului, susținând și dezvoltând principiile de bază ale construirii Web-ului. În plus, utilizarea software-ului open source este relevantă din punctul de vedere al concentrării pe furnizarea de servicii în loc de vânzarea de bunuri. Prin urmare, atunci când creați sisteme de Internet, merită să vă concentrați pe standardele deschise și pe software-ul care le implementează, deoarece numai astfel va oferi o oportunitate pentru dezvoltarea afacerilor și noi oportunități pentru piețele electronice.

Utilizarea software-ului open source pentru a susține tehnologiile Internet este firească și necesară din punctul de vedere al proprietăților de scalare, globalitate și compatibilitate. De exemplu, creșterea numărului de servere sau alte dispozitive de infrastructură nu necesită investiții suplimentare în software, care oferă mai multă flexibilitate decât software-ul proprietar. Acest lucru devine valabil mai ales atunci când costul software-ului depășește componenta hardware a proiectului. Cerințele de globalitate și interoperabilitate sunt implementate datorită suportului bun pentru software-ul open source multiplatformă și utilizării standardelor deschise, care permite menținerea unui nivel ridicat de interoperabilitate chiar și cu multe produse și platforme concurente de pe piață.

În lumina dezvoltării moderne a aplicațiilor de servicii bazate pe tehnologii web, software-ul open source în combinație cu computere ieftine (nettop-uri și netbook-uri) pot stoarce în mod semnificativ sistemele desktop și mobile tradiționale, care se bazează pe sistemul de operare. Windowsși apartamente de birou tradiționale. Utilizarea unui sistem de operare specializat ușor cu o interfață grafică bazată pe kernel Linux iar browserele web moderne vă permit să efectuați majoritatea sarcinilor de zi cu zi pe platformele de rețea folosind doar software open source.

Software-ul open source are admiratorii săi, iar în ultima perioadă când vine vorba de dezvoltarea unui fel de produse „naționale”, deci practic se înțelege open-source. În mod paradoxal, interesul pentru acest tip de software a generat o mulțime de distorsiuni și concepții greșite care în practică împiedică distribuirea acestuia.

Compania noastră participă la proiecte open source din 2005 - și datorită dezvoltării propriilor soluții open source (proiecte OpenVZ, CRIU), participând la alte proiecte open source (QEMU, OpenStack, libvirt, libcontainer etc.). În ultimii 10 ani, am adunat unele dintre cele mai comune mituri despre software-ul open source. Voi trece peste fiecare dintre concepțiile greșite și voi explica de ce este greșită. Cu siguranță, vă veți aminti tot atâtea, dar, după părerea mea, aceste cinci sunt cele mai „infernale”.

Proiectul open source este un proiect open source.

Orice proiect software constă din multe artefacte: cod sursă al proiectului, informații despre defectele necorectate, cod sursă de testare, documentație. Codul sursă al proiectului este doar o parte a acestuia, accesul liber la care nu dă dreptul de a deschide întregul proiect. Pe lângă codul sursă, alte artefacte de dezvoltare ar trebui să fie disponibile gratuit, iar cu cât sunt mai multe artefacte deschise, cu atât proiectul este mai deschis contribuitorilor (persoane care doresc să contribuie la proiect). În plus, sunt necesare procese transparente între toți membrii comunității, comunicări deschise în proiect etc. Toate aceste măsuri vor contribui doar la dezvoltarea proiectului și la cooperarea fructuoasă a membrilor comunității.

Calitatea software-ului open source este mai proastă, deoarece oricine poate scrie cod pentru el.

Principiul principal al software-ului open source - dezvoltarea comună deschisă - în sine este o garanție că codul de calitate scăzută, cârjele și patch-urile pur și simplu nu pot fi ascunse de ceilalți participanți. O persoană, care participă la astfel de proiecte, este pregătită pentru faptul că munca sa va fi supusă atât analizei, cât și criticilor și, prin urmare, nu va înșela. Reputația lui este în joc și nimeni nu vrea să o piardă.

În plus, în unele comunități (de exemplu, comunitatea din jurul dezvoltării nucleului Linux) există un principiu strict - doar codul cel mai bun, testat și ideal este acceptat în nucleul original. O încercare de a adăuga modificări de calitate scăzută va fi respinsă, a doua încercare este plină de pierderea reputației persoanei sau companiei care contribuie.

Adică, un proiect open source face într-adevăr posibil ca orice persoană să participe la scrierea codului, dar în proiecte serioase, din cauza pragului ridicat de intrare, codul nu va fi acceptat de la persoane cu un nivel insuficient de expertiză.
Majoritatea companiilor mari de IT (IBM, Google, Canonical, Parallels etc.) au departamente întregi în care specialiștii sunt plătiți pentru a lucra la proiecte open source și astfel lucrează indirect la produsele companiei.

Separat, este de menționat că companiile care dezvoltă produse bazate pe proiecte open source, în timpul testării, sunt interesate să îmbunătățească codul proiectelor open source pe care le folosesc. Prin urmare, toate problemele descoperite trebuie remediate și asigurate că această remediere a fost adăugată la ramura principală a proiectului pentru a avea cât mai puține diferențe în codul dvs. și codul proiectului deschis. Produsele noastre folosesc codul altor proiecte open source, așa că remediam problemele găsite în codul acestor proiecte și le trimitem în amonte. Acesta a fost cazul vulnerabilităților din nucleul RHEL: Red Hat l-a notat pe Vladimir Davydov pentru că a descoperit vulnerabilități grave CVE-2014-0203 și CVE-2014-4483 într-una dintre actualizările nucleului RHEL6 (a doua problemă, de altfel, a fost găsit utilizând unul dintre testele noastre automate, folosind Linux Test Project). Vasily Averin a primit recunoștință pentru găsirea erorii CVE-2014-5045, Dmitry Monakhov pentru CVE-2012-4508. Faptul de a testa bine kernel-ul Linux a fost remarcat chiar de Andrew Morton (cine este acesta?): „Mă interesează. În ultimele luni, cei de la @ openvz.org au găsit (și au remediat) o grămadă de erori obscure, dar serioase și destul de vechi. Cum ai găsit aceste bug-uri?”

Rezultat

De fapt, toate aceste mituri apar în cea mai mare parte în rândul utilizatorilor care fie abia încep să lucreze cu software-ul OpenSource, fie nu l-au încercat deloc. Cel mai bun mod de a scăpa de prejudecăți este să începeți să lucrați îndeaproape cu astfel de soluții.
Am anunțat recent un proces de dezvoltare deschis pentru următoarea versiune a produsului nostru Virtuozzo 7. Dacă sunteți, de asemenea, interesat să creați cea mai bună tehnologie de virtualizare a containerelor, atunci

adnotare

Acest articol se concentrează pe beneficiile, considerentele strategice, obstacolele și oportunitățile asociate cu utilizarea software-ului open source în produsele comerciale. Folosind mediul de dezvoltare integrat (IDE) bazat pe Eclipse ca exemplu, vom discuta despre diferențele dintre licențele de cod sursă software de protecție și neprotectoare. Când se integrează sau se conectează sursa deschisă cu sursa închisă „proprietă”, este adesea necesară îngrijirea și prudența corespunzătoare. Trebuie avute în vedere, de asemenea, diferite aspecte juridice, cum ar fi potențialul de încălcare a brevetului. Vom încerca, de asemenea, să explicăm de ce principiile de bază ale utilizării software-ului open source în mediul tehnologiei informației (IT) nu se aplică produselor comerciale pentru dispozitive încorporate.

QNX Momentics IDE ca studiu de caz pentru utilizarea software-ului cu sursă deschisă

În 2001, când multe firme de software se luptau să facă față colapsului general al pieței de valori IT, în special celor legate de e-business pe Internet, QNX Software Systems a luat decizia strategică de a începe dezvoltarea unui nou mediu de dezvoltare integrat (IDE). ) pentru piata.sisteme embedded. Compania avea deja un istoric solid în dezvoltarea unei serii de instrumente utilizate în dezvoltarea dispozitivelor încorporate, dar compania și-a dat seama că crearea unui IDE ar ajuta să rămână pe vârful valului în fața concurenței acerbe. Decizia de a crea un IDE a fost, de asemenea, condusă de o schimbare a atenției asupra cerințelor clienților. În timpul recesiunii, clienții cu buget limitat au devenit mai interesați de soluții care ar putea maximiza productivitatea și să-i facă mai mobili (flexibili) în munca lor, ceea ce ar îmbunătăți eficiența economică generală.

Pentru QNX, dezvoltarea unui IDE a fost „un pariu pentru viitor”, deoarece costul și efortul de dezvoltare a unui proiect nu erau la îndemâna celor mai mulți furnizori de instrumente de sistem încorporat la acea vreme. Din fericire, QNX a lucrat îndeaproape cu IBM pe diferite segmente ale pieței dispozitivelor încorporate. Printr-o strânsă colaborare, IBM a împărtășit cu QNX planurile sale de a lansa un IDE cu sursă deschisă care va deveni ulterior fundația platformei Eclipse.

IBM sa oferit să folosească expertiza QNX pentru a adapta tehnologia IDE la nevoile dezvoltatorilor care construiesc aplicații încorporate C/C++. Aproape imediat, QNX a subliniat avantajele convingătoare ale utilizării unui IDE cu sursă deschisă. De exemplu, pentru un astfel de mediu ar fi posibil:

• eliminați dependența de un singur furnizor, care este de obicei asociată cu necesitatea de a licenția platforma ferestrei;
• oferi codul sursă pentru personalizare la nevoile clientului;
• angajați actorii importanți din industrie pentru a sprijini și a construi un ecosistem de tehnologii și plug-in-uri complementare;
• oferi clienților o arhitectură stabilă care poate sprijini diferențierea produselor;
• pentru a permite dezvoltatorilor de dispozitive încorporate să utilizeze stațiile de lucru standard ca platformă de dezvoltare potrivită pentru lucrul cu aplicații de tehnologie a informației (în cea mai largă gamă de aplicații).

În cele din urmă, s-a luat în considerare posibilitatea separată ca IDE-ul să câștige popularitate și să devină standardul de facto, ceea ce ar permite QNX să folosească o astfel de platformă pentru a captura piața ecosistemelor mari de dezvoltatori și instrumente terțe.

Fondarea proiectului open source Eclipse.org

Consorțiul Eclipse a fost fondat de Borland, IBM, Merant, QNX Software Systems, Red Hat și SUSE în noiembrie 2001. La începutul lui 2004, Consiliul de Administratori a reorganizat Consorțiul Eclipse într-o corporație non-profit numită Fundația Eclipse.

De la început, Eclipse a fost un proiect cu adevărat open source. Proiectul a oferit atât tehnologii open source gratuite, cât și acces la o comunitate a celor mai educați și avansați dezvoltatori din domeniul lor. Astfel, această tehnologie s-a dovedit a fi o platformă universală pentru integrarea tuturor tipurilor de instrumente de dezvoltare. Se bazează pe o arhitectură deschisă, extensibilă și este licențiat în mod clar ca un produs redistribuibil, fără drepturi de autor. Contribuțiile comunității la proiectul Eclipse se bazează pe modelul de dezvoltare standard Open Source Software (OSS), dar majoritatea membrilor oferă și dezvoltare comercială bazată pe platforma Eclipse.

Proiect de creare a depozitului de instrumente

În decembrie 2001, QNX a început să construiască QNX® Neutrino® RTOS, bazat pe IDE-ul Eclipse. În viziunea companiei, IDE-ul ar trebui să aibă o funcționalitate excelentă, să se concentreze pe lucrul cu limbaje C/C++, să aibă instrumente profund integrate pentru depanare, profilare, analiză și construirea de aplicații încorporate. De la început, echipa QNX a intenționat să fie un IDE multifuncțional și multilingv care acceptă mai multe platforme de instrumente. Aceasta a inclus:

• mai multe platforme de instrumente: Windows, Solaris, QNX Neutrino RTOS (dezvoltare self-hosted);
• mai multe arhitecturi tinta: ARM, MIPS, PowerPC, SH-4, x86;
• limbaje de programare C, C++, Java.

De atunci, IDE-ul a continuat să crească pentru a include suport pentru platforma Linux și suport pentru arhitecturi de procesoare suplimentare, inclusiv procesoare XScale.

Proiectul a fost lansat în stilul „programare extremă”. O echipă de 12 cei mai buni ingineri a fost selectată în companie. Li s-a oferit o cameră specială, izolată de orice distragere a atenției și puse la dispoziția lor completă.

Grupului i s-a acordat autoritatea necesară în domeniul luării deciziilor, li s-a întocmit un program de lucru dur, în pragul riscului, cu lansarea versiunii beta a produsului în 16 săptămâni, iar versiunea comercială de către 4 iulie 2002. Grupul a respectat toate termenele stabilite și a lansat un nou produs - denumit QNX Momentics® IDE - exact la timp, o dovadă a potențialului software-ului open source de a reduce timpul de lansare pe piață.

De la idee la livrarea produsului - mai puțin de 7 luni

Bazându-se pe platforma Eclipse, echipa QNX a finalizat un IDE foarte puternic și versatil pentru dezvoltarea de software încorporat în șase luni. IDE-ul a susținut dezvoltarea multiplatformă pe mai multe platforme de instrumente și mai multe limbaje de programare și a susținut cele mai populare plăci de procesoare țintă încorporate. Cu platforma Eclipse, QNX a reușit să:

• utilizați compilatoare GNU și instrumente de linie de comandă pentru dezvoltare încrucișată;
• suportă plug-in-uri terță parte, cum ar fi IBM WebSphere pentru Java încorporat și Rational ClearCase pentru dezvoltare bazată pe model;
• creați instrumente suplimentare pentru construirea sistemelor, gestionarea dispozitivelor țintă, analiza memoriei, crearea de sisteme și aplicații etc.

În fig. Figura 1 oferă un exemplu al modului în care platforma Eclipse reduce costul creării unui IDE, permițând companiilor să se concentreze asupra nivelurilor superioare de dezvoltare, unde este de fapt creată inovație reală. De exemplu, folosind platforma Eclipse, QNX a reușit să creeze cu ușurință mai multe instrumente inovatoare de vizualizare care vă permit să pătrundeți adânc în sistemul încorporat și să afișați comportamentul acestuia.

Contribuind înapoi la comunitate

Puterea unui proiect open source de succes constă în colaborarea comunității de dezvoltatori și în îmbunătățirea continuă a bazei de cod. Dacă o companie adoptă și folosește sursa deschisă, atunci pur și simplu are responsabilitatea de a contribui la comunitate. În acest scop, QNX a preluat proiectul Eclipse CDT în iunie 2002.

Scopul proiectului Eclipse CDT (C/C++ Development Tools) este de a crea un set comun de instrumente de dezvoltare C/C++ interoperabile pentru platforma Eclipse. Eclipse CDT a fost comercializat ca un proiect open source, cu drepturi de management de la Eclipse Corporation. Pentru a lansa proiectul CDT, QNX și-a donat resursele de dezvoltare și codul sursă proiectului QNX Momentics IDE. Rational și Red Hat, ca membri ai comunității, au oferit, de asemenea, un sprijin semnificativ proiectului.

Orez. 1. Folosind platforma Eclipse, furnizorii de instrumente se pot concentra pe nivelul superior al stivei de lucru, unde se creează de fapt inovații reale.

QNX continuă să mențină proiectul CDT, care a crescut de la 80.000 de linii de cod inițial modeste la peste 700.000 de linii de cod în prezent. La începutul lui 2006, Eclipse CDT Progress Log a reprezentat aproximativ 52% din contribuția QNX. Urmează IBM cu o contribuție de 36%. Proiectul CDT este al doilea cel mai popular proiect Eclipse după platforma Eclipse în sine.

Îmi pot permite să „dau” codul?

Poate părea că „donarea” codului tău înseamnă a face ceva contrar bunului simț. Cu toate acestea, dacă funcționalitatea produsului dvs. se dovedește a fi utilă de aplicat, atunci de ce să nu contribuiți ca contribuție la comunitatea open source. Făcând acest pas, puteți beneficia de această ofertă de implementare „standard” împreună cu expertiza pentru a susține produsul. Veți putea beneficia de munca întregii comunități pentru a îmbunătăți baza de cod. O astfel de strategie vă poate elibera propriile resurse pentru a efectua cercetări suplimentare, concentrate pe inovație, pe adăugarea de funcționalități suplimentare produselor dumneavoastră.

Mai mult, ai putea obține un anumit control asupra direcției platformei „standard” - câștigat, desigur, datorită contribuțiilor tale la comunitate! Dacă susțineți un proiect, comportați-vă ca un bun cetățean al comunității, respectați opiniile altora, apreciați contribuția și sfaturile altor membri. Să nu credeți că cineva va încerca să vă „curățeze buzunarele” ca urmare a utilizării codului și să vă intercepteze conducerea asupra direcției de dezvoltare a platformei.

De exemplu, strategia QNX Software Systems este de a valorifica beneficiile de a face parte din Eclipse în timp ce dezvoltă noi funcționalități care se conectează prin punctele de extensie standardizate care sunt deja disponibile în platformele Eclipse și CDT. În acest scop, QNX intenționează să rămână un membru activ al comunității Eclipse, valorificând baza de cod existentă și expertiza terțelor părți (plug-in-uri), contribuind la satisfacerea nevoilor reale ale clienților prin crearea de extensii proprietare. Strategia descrisă este ilustrată în Fig. 2.

Orez. 2. Puteți contribui la munca comunității cu propria experiență.

Rezumatul beneficiilor

Platforma de instrumente bazată pe Eclipse este reciproc avantajoasă atât pentru dezvoltatorii de aplicații, cum ar fi QNX, cât și pentru clienții care achiziționează instrumentele platformei.

Dezvoltatorii beneficiază de mai puțin timp de lansare pe piață și de capacitatea de a beneficia de cercetările altor persoane (la un cost redus). Aceste rezultate pot include cod „IP curat” de înaltă calitate furnizat de furnizori de renume precum IBM și QNX. Un alt avantaj pentru dezvoltator este că primește o schemă de licențiere simplă și clară, inclusiv drepturi comerciale și o anumită protecție prin brevet. Mai mult, dezvoltatorul are capacitatea de a lucra pe mai multe platforme de sistem de operare suportate de Eclipse, precum și punctele de extensibilitate bine definite în proiectul Eclipse.

Clienții care cumpără un IDE bazat pe Eclipse beneficiază de o platformă de instrumente dedicată dezvoltării încorporate, suport puternic de compilare încrucișată, depanare ușoară și extensii pentru gestionarea sistemelor țintă. Echipa de dezvoltare a clientului va aprecia numeroasele caracteristici care ușurează munca, timpul redus necesar pentru instruirea suplimentară, performanța bună a produsului și o platformă de încredere pentru a gestiona proiecte mari. Clientul poate, de asemenea, să folosească în mod util cadrul Eclipse în propriile aplicații (de exemplu, RCP, eRCP etc.).

Viitorul Eclipse Corporation

Eclipse Corporation este o comunitate activă și energică. Introduce continuu noi proiecte, oferă noi arhitecturi companiilor inovatoare consacrate și chiar și companiile mici pot comercializa platforma Eclipse prin crearea de noi plug-in-uri la costuri minime care extind funcționalitățile existente (vezi Figura 3).

Orez. 3. Eclipse Corporation este o comunitate vibrantă și în creștere rapidă de dezvoltatori de plug-in-uri.

Comparația licențelor open source

Nu toate licențele open source sunt create egale. QNX a luat o mișcare bine gândită cu Eclipse Public License. Această alegere a fost dictată în parte de nevoile clienților săi încorporați și în parte de dorința de a prelua controlul asupra (și de a beneficia de) tehnologiile care diferențiază produsele.

Inițiativa nonprofit Open Source () a venit cu o definiție utilă în 10 puncte a sursei deschise. În prezent, pe site sunt listate peste 50 de licențe aprobate OSI, inclusiv Licența Publică Eclipse. Aceste licențe pot conține diferențe semnificative care trebuie înțelese clar. Aceste diferențe pot avea un impact semnificativ asupra proprietății intelectuale (IP) a dezvoltatorilor și asupra capacității acestora de a o proteja. Acest lucru este valabil mai ales atunci când utilizați cod sursă deschis (sau lucrări derivate bazate pe cod sursă deschis) în dispozitive încorporate.

Licență de protecție și neprotecție

În conformitate cu termenii unei licențe defensive, cum ar fi GPL v2, lucrările derivate pot fi redistribuite numai cu codul sursă asociat. În condițiile licenței defensive, este garantat că atunci când codul sursă este lansat în categoria deschisă, acesta va rămâne în acea categorie în toate generațiile ulterioare și lucrările derivate. După cum vom explica mai târziu, această cerință duce la anumite probleme în cazul sistemelor încorporate.

Exemple de licențe nesecurizate sunt licențele originale MIT și BSD. Licențele neprotectoare păstrează dreptul de autor al proprietarului, dar acordă drepturi largi utilizatorului, inclusiv dreptul de a modifica și distribuirea gratuită (sau utilizarea personală) fără restricții a software-ului.

Ce se înțelege prin „licență de virus”

Unii oameni numesc GPL o „licență virală”. Această denumire a apărut din cauza ambiguității definiției legale a conceptului de „dezvoltare derivată”. Cu o interpretare strictă a definiției, se dovedește că chiar și o mică bucată de cod acoperită de GPL este încorporată într-o aplicație proprietară, atunci întreaga aplicație trebuie să fie licențiată sub GPL. Imediat îmi vine în minte o analogie cu un virus.

Întrebări despre primirea despăgubirilor

Recent, IP Indemnification a devenit principalul subiect de discuție pentru dezvoltatori. Ca răspuns, unii furnizori de surse deschise au anunțat că vor proteja clienții de procese pentru încălcarea brevetelor sau a drepturilor de autor. Iar cele mai noi licențe open source clarifică penalitățile pentru utilizatorii care încearcă să-și afirme drepturile de brevet împotriva altor utilizatori ai bazei de cod.

Principalele provocări pentru comercializarea software-ului cu sursă deschisă

Comparație între aplicațiile încorporate și IT

Succesul industriei open source a fost alimentat de adoptarea Linux de către organizațiile IT. Beneficiile utilizării Linux au fost asociate cu rularea pe hardware relativ uniform și stabil (de obicei familia x86) și cu utilizarea unei platforme de calcul flexibile, bogate în resurse.

Acesta nu este cazul software-ului încorporat. Software-ul rulează pe o mare varietate de dispozitive cu caracteristici fixe într-o gamă largă de arhitecturi hardware. Designerii de dispozitive încorporate își bazează adesea avantajul competitiv pe un anumit set de caracteristici, dimensiune, performanță, cost, durata de viață a bateriei, fiabilitate, interoperabilitate și extindere. Aceste caracteristici distinctive sunt de obicei implementate în software-ul de nivel scăzut, care în cazul Linux necesită conectarea directă la kernel-ul sistemului de operare. Personalizarea software-ului de nivel scăzut pentru a satisface nevoile clienților este norma, nu excepția, astfel încât dezvoltatorii obțin adesea funcționalitatea de care au nevoie prin schimbarea nucleului sistemului de operare. Metoda legării directe este folosită și prin încorporarea în fragmente de cod pentru a reduce costul creării bibliotecilor. Această practică, luată împreună, face foarte dificilă protejarea codului proprietar sub licențe GPL (disponibile public).

De obicei, aceste probleme de licențiere nu se aplică aplicațiilor IT, deoarece software-ul proprietar, specific întreprinderii, nu se extinde dincolo de întreprindere și este utilizat numai pentru nevoi interne. Pe de altă parte, dispozitivele încorporate distribuie întotdeauna software derivat care se califică pentru licențe open source „forțate deschise”, ceea ce ar putea pune în pericol aspectele cheie ale ofertelor open source valoroase.

În plus, produsele încorporate au adesea durate de viață lungi, atât în ​​timpul producției, cât și în timpul utilizării. Un produs încorporat care este supus Termenilor de utilizare Open Source prezintă un risc mai mare, inclusiv lipsa suportului tehnic pe termen lung, potențiale probleme de securitate și încălcarea IP.

Probleme de licențiere

Incertitudinea statutului juridic

În ciuda cuvintelor reconfortante ale susținătorilor unor licențe open source, multe dintre problemele cheie care preocupă dezvoltatorii de sisteme încorporate nu au fost încă verificate pe larg de practica criminalistică. După cum sa menționat, definiția lucrării derivate este esențială în aplicarea anumitor clauze ale licenței, deși multe persoane și organizații care acceptă termenii de utilizare open source au puțin sau deloc înțelegerea conceptului.

Unele soluții care permit vânzătorilor comerciali să implementeze drivere „proprietate” în Linux (de exemplu, Loadable Kernel Modules) se bazează pe argumente „a spus el, a spus ea” mai degrabă decât pe link-uri directe către textul acordului de licență. De fapt, astfel de șoferi care folosesc module LKM sunt plini de ocolirea periculoasă a cerințelor licenței GPL. Mergând la o extremă, se poate interpreta ca însemnând că baza de cod Linux poate fi prezentată ca inutilă pentru majoritatea utilizărilor practice, dacă nu include unele dintre aceste drivere „proprietate”. Această situație poate devaloriza în mod eficient ideea unei licențe GPL.

Lipsa compensației pentru încălcarea PI

În majoritatea cazurilor de utilizare cu sursă deschisă, există o posibilitate reală ca să încălcați din neatenție drepturile de brevet ale altcuiva. Doar o mică parte din licențele open source se referă în mod explicit la brevete și nu se poate face nicio determinare cu privire la licențele implicite. Trebuie să licenți separat orice brevete legate, de exemplu, de codecuri open source care implementează algoritmi MP3 sau alte soluții proprietare. Între timp, băieții răi (inclusiv Microsoft) sunt preocupați să construiască un portofoliu de brevete care, potrivit multor experți, pot fi „împușcați” asupra susținătorilor open source.

Unele licențe se referă în mod explicit la brevete. De exemplu, Eclipse Public License menționează în mod explicit drepturile de brevet și conține o clauză de penalizare dacă cineva încearcă să-și afirme drepturile de brevet în mod diferit. De asemenea, Eclipse face eforturi mari pentru a revizui codul și pentru a afla de unde provine în ceea ce privește licențele, brevetele sau legea drepturilor de autor.

Eforturi suplimentare pentru păstrarea IP

Pentru a utiliza open source, o companie trebuie să depună un efort considerabil în următoarele domenii:

• managementul distribuției produselor;
• managementul licentei;
• rezolvarea conflictelor juridice in ceea ce priveste obligatiile clientilor;
• acordând atenția cuvenită aspectelor legale: menținerea purității drepturilor IP, verificarea drepturilor IP pentru open source, stabilirea sursei codului, urmărirea modificărilor versiunilor de licență, de exemplu, GPL v3 etc.

Acceptarea cerințelor clienților

Unii clienți mari, confruntați cu complexitatea și incertitudinea software-ului open source, au refuzat să se ocupe de produse open source. Dacă doriți să lucrați cu astfel de clienți, trebuie să obțineți sau să le oferiți să includă termeni pentru codul dvs. corespunzător licenței comerciale.

Probleme de IP

Termenii licenței dumneavoastră open source afectează proprietatea intelectuală care distinge produsul dvs.? Dacă da, IP-ul tău este în pericol.

Dacă sistemele dumneavoastră încorporate utilizează un amestec de software propriu și software open source, atunci trebuie să înțelegeți natura, originea și relația tuturor componentelor software-ului încorporat. Fără o astfel de perspectivă profundă, ați putea încălca din neatenție drepturile de proprietate intelectuală ale cuiva sau chiar să vă pierdeți drepturile asupra propriului software.

Fără licențe de brevet sau compensații plătite, software-ul încorporat cu durată lungă de viață, prețul de vânzare relativ ridicat și volumul dispozitivelor încorporate cu caracteristici fixe fac ca astfel de sisteme să fie o țintă evidentă pentru pretențiile de încălcare a brevetelor din partea băieților răi și a concurenților majori.

După cum ilustrează studiul de caz QNX Momentics IDE, software-ul open source are multe beneficii imediate, inclusiv timp mai rapid de lansare pe piață, costuri mai mici de dezvoltare și mai multă libertate de a adăuga caracteristici și inovații produsului dumneavoastră. Dacă oferiți software-ul dvs. ca un serviciu care rezolvă o problemă pentru un client, atunci clientului nu îi pasă dacă ați folosit software open source sau nu, el plătește doar pentru funcția de care are nevoie.

Cu toate acestea, ar trebui să înțelegeți diferența dintre diferitele licențe open source și să alegeți pe cea care se potrivește aplicației dvs. și nevoilor clienților. Mai mult, fiți pregătit să răspundeți pentru obligațiile de licențiere ale software-ului pe care l-ați ales. Ar trebui să fiți conștient de alte cerințe IP (cum ar fi drepturile de brevet) legate de codul software. Fiți atenți la o bază de cod care nu afișează un mesaj de încălcare a IP. Căutați proiecte care oferă despăgubiri pentru eventualele daune și afișați pe ecran un mesaj despre donațiile în numerar pentru dezvoltarea codului pentru a compensa costurile asociate cu încălcarea drepturilor de autor sau a brevetului și așa mai departe. De asemenea, asigurați-vă că software-ul open source pe care îl utilizați este în concordanță cu politica dvs. de proprietate intelectuală și evitați licențele defensive care v-ar putea obliga să dezvăluiți bucăți distinctive din codul dvs. Dacă produsul dvs. este încorporat în sistem, luați în considerare și oferirea de termeni comerciali de licență pentru IP-ul dvs.

Utilizarea codului open source în dispozitivele încorporate duce la probleme mai complexe decât în ​​cazul utilizării unui astfel de software în aplicațiile IT, deoarece prima opțiune este plină de mai multe pericole. Înainte de a decide să utilizați orice software open source, estimați costul real de proprietate (TTCO) și potrivirea acestuia pentru proiectul dvs.

În cele din urmă, alăturați-vă comunității open source de utilizatori și dezvoltatori pentru a vă maximiza valoarea și beneficiile!