Un festival IT va avea loc la Sankt Petersburg săptămâna aceasta . Unul dintre vorbitori va fi Richard Stallman. participă, de asemenea, la festival și, bineînțeles, nu putem ignora tema software-ului liber. De aceea se numește unul dintre rapoartele noastre . Acesta va fi dedicat istoriei dezvoltării Embox ca proiect open source. În acest articol vreau să vorbesc despre ideile principale care, după părerea mea, influențează dezvoltarea proiectelor opensource. Articolul, ca și raportul, se bazează pe experiența personală.
Să începem cu ceva simplu, cu definiția termenului opensource. Evident, un proiect open source este un proiect care are una dintre licențele care permite accesul la codul sursă al proiectului. În plus, un proiect deschis înseamnă că dezvoltatorii terți pot face modificări. Adică, dacă o companie sau un dezvoltator publică codul produsului său, parțial sau complet, acest lucru nu face încă din acest produs un proiect opensource. Și, în sfârșit, orice activitate de proiect trebuie să ducă la un fel de rezultat, iar deschiderea proiectului implică faptul că acest rezultat este folosit nu numai de dezvoltatori înșiși.
Nu vom atinge problemele licențelor deschise. Acesta este un subiect prea vast și complex care necesită o investigație aprofundată. S-au scris destul de multe articole și materiale bune pe această temă. Dar din moment ce eu însumi nu sunt un expert în domeniul dreptului de autor, voi spune doar că licența trebuie să îndeplinească obiectivele proiectului. De exemplu, pentru Embbox alegerea unei licențe BSD și nu a unei licențe GPL nu a fost întâmplătoare.
Faptul că un proiect open source ar trebui să ofere capacitatea de a face modificări și de a influența dezvoltarea proiectului open source implică faptul că proiectul este distribuit. Gestionarea acestuia, menținerea integrității și performanței este mult mai dificilă în comparație cu un proiect cu management centralizat. Apare o întrebare rezonabilă: de ce se deschid deloc proiecte? Răspunsul se află în zona fezabilității comerciale; pentru o anumită clasă de proiecte, beneficiile acestei abordări depășesc costurile. Adică nu este potrivit pentru toate proiectele și o abordare deschisă este în general acceptabilă. De exemplu, este greu de imaginat dezvoltarea unui sistem de control pentru o centrală electrică sau o aeronavă bazat pe un principiu deschis. Nu, desigur, astfel de sisteme ar trebui să includă module bazate pe proiecte deschise, deoarece acest lucru va oferi o serie de avantaje. Dar cineva trebuie să fie responsabil pentru produsul final. Chiar dacă sistemul se bazează în totalitate pe codul proiectelor deschise, dezvoltatorul, după ce a împachetat totul într-un singur sistem și a făcut build-uri și setări specifice, îl închide în esență. Codul poate fi disponibil publicului.
Există, de asemenea, o mulțime de beneficii pentru aceste sisteme din crearea sau contribuția la proiecte open source. După cum am spus deja, codul sistemului final poate rămâne disponibil public. De ce, pentru că este evident că este puțin probabil ca cineva să aibă aceeași aeronavă pentru a testa sistemul. Acest lucru este adevărat, dar poate exista cineva care dorește să verifice anumite secțiuni ale codului sau, de exemplu, cineva poate descoperi că biblioteca utilizată nu este configurată destul de corect.
Un beneficiu și mai mare apare dacă compania alocă o parte de bază a sistemului într-un proiect separat. De exemplu, o bibliotecă pentru a suporta un fel de protocol de schimb de date. În acest caz, chiar dacă protocolul este specific unui anumit domeniu, puteți împărți costurile de întreținere a acestei piese din sistem cu alte companii din această zonă. În plus, specialiștii care pot studia această piesă a sistemului din domeniul public au nevoie de mult mai puțin timp pentru ao folosi eficient. Și, în sfârșit, separarea unei piese într-o entitate independentă pe care o folosesc dezvoltatorii terți ne permite să îmbunătățim această parte, deoarece trebuie să oferim API-uri eficiente, să creăm documentație și nici măcar nu vorbesc despre îmbunătățirea acoperirii testelor.
O companie poate primi beneficii comerciale fără a crea proiecte open-source; este suficient ca specialiștii săi să participe la proiecte terțe utilizate în companie. La urma urmei, toate beneficiile rămân: angajații cunosc mai bine proiectul, prin urmare îl folosesc mai eficient, compania poate influența direcția de dezvoltare a proiectului, iar utilizarea codului gata făcut, depanat reduce, evident, costurile companiei.
Beneficiile creării de proiecte opensource nu se termină aici. Să luăm o componentă atât de importantă a afacerii precum marketingul. Pentru el, acesta este un sandbox foarte bun care îi permite să evalueze eficient cerințele pieței.
Și bineînțeles, nu trebuie să uităm că un proiect opensource este o modalitate eficientă de a te declara purtător al oricărei specializări. În unele cazuri, aceasta este singura modalitate de a intra pe piață. De exemplu, Embbox a început ca un proiect de creare a unui RTOS. Probabil că nu este nevoie să explicăm că există o mulțime de concurenți. Fără a crea o comunitate, pur și simplu nu am fi avut suficiente resurse pentru a aduce proiectul la utilizatorul final, adică pentru ca dezvoltatorii terți să înceapă să folosească proiectul.
Comunitatea este cheia într-un proiect opensource. Vă permite să reduceți semnificativ costurile de management al proiectelor, să dezvoltați și să susțineți proiectul. Putem spune că fără comunitate nu există deloc un proiect opensource.
S-a scris o mulțime de materiale despre cum să creați și să gestionați o comunitate de proiecte open source. Pentru a nu mai povesti fapte deja cunoscute, voi încerca să mă concentrez pe experiența Embox. De exemplu, procesul de creare a unei comunități este o problemă foarte interesantă. Adică, mulți spun cum să gestionezi o comunitate existentă, dar momentele creării acesteia sunt uneori trecute cu vederea, considerând acest lucru un dat.
Regula principală atunci când se creează o comunitate de proiecte opensource este că nu există reguli. Adică nu există reguli universale, la fel cum nu există nici un glonț de argint, fie și doar pentru că proiectele sunt foarte diferite. Este puțin probabil să puteți folosi aceleași reguli atunci când creați o comunitate pentru o bibliotecă de jurnalizare js și un driver foarte specializat. Mai mult, la diferite stadii de dezvoltare a proiectului (și deci a comunității), regulile se schimbă.
Embox a început ca un proiect studentesc pentru că avea acces la studenții de la departamentul de programare a sistemelor. De fapt, intram într-o altă comunitate. Am putea interesa participanții acestei comunități, studenți, de bune practici industriale în specialitatea lor, lucrări științifice în domeniul programării sistemelor, cursuri și diplome. Adică am respectat una dintre regulile de bază ale organizării unei comunități: membrii comunității trebuie să primească ceva, iar acest preț trebuie să corespundă contribuției participantului.
Următoarea etapă pentru Embox a fost căutarea de utilizatori terți. Este foarte important să înțelegeți că utilizatorii sunt participanți deplini în comunitatea opensource. De obicei, există mai mulți utilizatori decât dezvoltatori. Și pentru a dori să devină colaborator la un proiect, ei încep mai întâi să îl folosească într-un fel sau altul.
Primii utilizatori ai Embox au fost Departamentul de Cibernetică Teoretică. Ei au sugerat crearea unui firmware alternativ pentru Lego Mindstorm. Și, deși aceștia erau încă utilizatori locali (ne-am putea întâlni cu ei în persoană și discutăm despre ce doreau). Dar a fost totuși o experiență foarte bună. De exemplu, am dezvoltat demonstrații care ar putea fi arătate altora, deoarece roboții sunt distrași și atrag atenția. Drept urmare, am primit utilizatori cu adevărat terți care au început să întrebe ce este Embbox și cum să-l folosească.
În această etapă, a trebuit să ne gândim la documentare, la mijloacele de comunicare cu utilizatorii. Nu, desigur, ne-am gândit la aceste lucruri importante înainte, dar a fost prematur și nu a dat un efect pozitiv. Efectul a fost mai degrabă negativ. Permiteți-mi să vă dau câteva exemple. Am folosit googlecode, al cărui wiki suporta multilingvismul. Am creat pagini în mai multe limbi, nu doar engleză și rusă, în care cu greu puteam comunica, ci și germană și spaniolă. În consecință, pare foarte ridicol când este întrebat în aceste limbi, dar nu putem răspunde deloc. Sau au introdus reguli despre scrierea documentației și comentarii, dar din moment ce API-ul s-a schimbat destul de des și semnificativ, s-a dovedit că documentația noastră era depășită și era mai înșelătoare decât a ajutat.
Drept urmare, toate eforturile noastre, chiar și cele greșite, au dus la apariția utilizatorilor externi. Și a apărut chiar și un client comercial care dorea ca propriul său RTOS să fie dezvoltat pentru el. Și l-am dezvoltat pentru că avem experiență și ceva temei. Aici trebuie să vorbiți atât despre momentele bune, cât și despre cele rele. Voi începe cu cele rele. Deoarece mulți dezvoltatori au fost implicați în acest proiect pe bază comercială, comunitatea era deja destul de instabilă și divizată, ceea ce desigur nu putea decât să afecteze dezvoltarea proiectului. Un factor suplimentar a fost că direcția proiectului a fost stabilită de un client comercial, iar scopul său nu a fost dezvoltarea ulterioară a proiectului. Cel puțin acesta nu era scopul principal.
Pe de altă parte, au existat o serie de aspecte pozitive. Avem utilizatori cu adevărat terți. Nu doar clientul, ci și cei cărora le-a fost destinat acest sistem. Motivația de a participa la proiect a crescut. La urma urmei, dacă poți câștiga și bani dintr-o afacere interesantă, este întotdeauna frumos. Și, cel mai important, am auzit o dorință de la clienți, care la acea vreme ni se părea nebunească, dar care este acum ideea principală a Embbox, și anume, de a folosi codul deja dezvoltat în sistem. Acum, ideea principală a Embbox este să folosești software Linux fără Linux. Adică, principalul aspect pozitiv care a contribuit la dezvoltarea ulterioară a proiectului a fost conștientizarea că proiectul este utilizat de utilizatori terți și ar trebui să rezolve unele dintre problemele acestora.
La acea vreme, Embbox depășise deja sfera unui proiect studențesc. Principalul factor limitativ în dezvoltarea proiectului după modelul studentului este motivația participanților. Studenții participă în timp ce învață, iar atunci când absolvă, ar trebui să existe o altă motivație. Dacă motivația nu apare, studentul pur și simplu încetează să mai participe la proiect. Dacă luăm în considerare că studenții trebuie mai întâi pregătiți, se dovedește că devin buni specialiști până la absolvire, dar contribuția lor la proiect, din lipsă de experiență, nu este foarte mare.
În general, trecem fără probleme la punctul principal care ne permite să vorbim despre crearea unui proiect opensource - crearea unui produs care să rezolve problemele utilizatorilor săi. După cum am explicat mai sus, principala proprietate a unui proiect opensource este comunitatea sa. În plus, membrii comunității sunt în primul rând utilizatori. Dar de unde vin atunci când nu există nimic de folosit? Deci, se dovedește că, la fel ca și în cazul unui proiect non-opensource, trebuie să vă concentrați pe crearea unui MVP (produs minim viabil), iar dacă îi interesează pe utilizatori, atunci va apărea o comunitate în jurul proiectului. Dacă sunteți implicat în crearea unei comunități numai prin intermediul comunității PR, scrierea unui wiki în toate limbile lumii sau fluxul de lucru git corect pe github, atunci este puțin probabil ca acest lucru să conteze în primele etape ale proiectului. Desigur, în etapele corespunzătoare, acestea nu sunt doar importante, ci și necesare.
În concluzie aș dori să subliniez , în opinia mea, reflectând așteptările utilizatorilor de la un proiect opensource:
Mă gândesc serios să trec la acest sistem de operare (măcar încearcă. Îl urmăresc activ și fac lucruri interesante).
PS activat Vom avea până la trei rapoarte. Unul despre open source și două despre embedded (și unul este practic). La stand vom desfășura o clasă de master despre programarea utilizării microcontrolerelor . Ca de obicei, vă vom aduce hardware-ul și vă vom lăsa să îl programați. Vor fi, de asemenea, o căutare și alte activități. Vino la festival și la standul nostru, va fi distractiv.
Sursa: www.habr.com