În această săptămână, la Sankt Petersburg va avea loc un festival IT . Printre vorbitori se va număra Richard Stallman. de asemenea participă la festival, și, desigur, nu am putut să ignorăm tema software-ului liber. Prin urmare, unul dintre noi se numește . Aceasta va fi dedicată istoricului dezvoltării Embox ca proiect cu cod deschis. În acest articol, vreau să împărtășesc ideile principale care, în opinia mea, influențează dezvoltarea proiectelor open source. Articolul, la fel ca și prezentarea, se bazează pe experiența personală.
Să începem cu simplul, cu definiția termenului open source. Este evident că un proiect cu cod deschis este un proiect care are una dintre licențele care permit accesul la codul sursă al proiectului. În plus, un proiect deschis presupune posibilitatea de a face modificări de către dezvoltatori externi. Așa că, dacă o companie sau un dezvoltator publică codul produsului său, parțial sau complet, asta nu îl face automat un proiect open source. Și, în sfârșit, orice activitate de proiect trebuie să conducă la apariția unui rezultat, iar deschiderea proiectului presupune că acest rezultat este folosit nu doar de dezvoltatori.
Nu vom aborda problemele licențelor deschise. Aceasta este o temă prea complexă și vastă, care necesită o aprofundare. Pe această temă au fost scrise foarte multe articole și materiale de calitate. Dar, deoarece eu nu sunt specialist în drepturi de autor, voi spune doar că licența ar trebui să corespundă obiectivelor proiectului. De exemplu, pentru Embox, alegerea licenței BSD și nu a licenței GPL nu a fost întâmplătoare.
Faptul că un proiect deschis trebuie să ofere posibilitatea de a face modificări și de a influența dezvoltarea proiectului deschis implică faptul că proiectul este distribuit. Gestionarea acestuia, păstrarea integrității și funcționalității este mult mai complicată comparativ cu un proiect care are o conducere centralizată. Se naște întrebarea legitimă de ce ar trebui să facem proiecte deschise. Răspunsul se află în domeniul viabilității comerciale; pentru o anumită clasă de proiecte, beneficiile acestui abordări depășesc costurile. Cu alte cuvinte, nu toate proiectele se potrivesc și, în general, abordarea deschisă nu este acceptabilă. De exemplu, este greu de imaginat dezvoltarea unui sistem de gestionare pentru o centrală electrică sau un avion bazat pe principiul deschis. Nu, desigur, în structura unor astfel de sisteme ar trebui incluse module bazate pe proiecte deschise, deoarece acest lucru va oferi o serie de avantaje. Dar pentru produsul final trebuie să răspundă cineva. Chiar dacă sistemul este complet bazat pe coduri de proiecte deschise, dezvoltatorul, înglobând totul într-un sistem și făcând anumite construcții și configurații, de fapt, îl închide. Codul poate fi totuși accesibil publicului.
Pentru aceste sisteme există, de asemenea, o mulțime de avantaje în crearea de proiecte deschise sau în participarea la ele. Așa cum am spus anterior, codul sistemului final poate rămâne accesibil publicului. De ce? Pentru că este evident că în mod improbabil cineva va avea un avion similar pentru a testa sistemul. Acesta este adevărat, dar există posibilitatea ca cineva să dorească să verifice anumite porțiuni de cod sau, de exemplu, cineva poate descoperi că biblioteca folosită nu este configurată tocmai corect.
O valoare și mai mare apare atunci când o companie își rezervă o parte de bază a sistemului pentru un proiect separat. De exemplu, o bibliotecă pentru suportul unui protocol de schimb de date. În acest caz, chiar dacă protocolul este specific pentru acest domeniu de activitate, costurile pentru întreținerea acelei părți a sistemului pot fi împărțite cu alte companii din acest domeniu. În plus, specialiștii care pot studia acea parte a sistemului în mod deschis necesită mult mai puțin timp pentru a o folosi eficient. Și, în final, rezervarea unei părți ca entitate de sine stătătoare, folosită de dezvoltatori externi, permite îmbunătățirea acestei părți, deoarece trebuie să se propună API-uri eficiente, să se elaboreze documentația; nu mai vorbesc despre îmbunătățirea acoperirii testelor.
Compania poate obține beneficii comerciale și fără a crea proiecte open-source, fiind suficient ca specialiștii să participe la proiecte externe aplicate în companie. Deoarece toate beneficiile rămân: angajații cunosc mai bine proiectul, deci îl utilizează mai eficient, compania poate influența direcția de dezvoltare a proiectului, iar utilizarea codului gata testat reduce evident costurile companiei.
Avantajele creării de proiecte open-source nu se opresc aici. Să considerăm un element esențial al afacerii, cum ar fi marketingul. Pentru acesta, este o foarte bună platformă care permite evaluarea eficientă a cerințelor pieței.
Și, desigur, nu trebuie uitat că un proiect open-source este o modalitate eficientă de a te prezenta ca un specialist în anumite domenii. În anumite cazuri, acesta este singurul mod de a pătrunde pe piață. De exemplu, Embox a început ca un proiect de dezvoltare a unui OSRV. Probabil că nu trebuie explicat că există o mulțime de concurenți. Fără crearea unei comunități, nu am avea resursele necesare pentru a duce proiectul la utilizatorul final, adică pentru ca proiectul să fie folosit de dezvoltatori externi.
Comunitatea este esențială în cadrul unui proiect open-source. Aceasta permite reducerea semnificativă a costurilor de gestionare a proiectului și contribuie la dezvoltarea și întreținerea acestuia. Se poate spune că fără comunitate, nu există un proiect open-source.
Despre cum să creezi și să gestionezi o comunitate pentru un proiect cu cod deschis s-au scris multe materiale. Eu, pentru a nu repeta faptele deja cunoscute, voi încerca să pun accent pe experiența Embox. De exemplu, o întrebare foarte interesantă este procesul de creare a comunității. Adică, mulți povestesc cum să gestionezi o comunitate existentă, dar aspectele legate de crearea acesteia sunt, uneori, omise, fiind considerate ca fiind evidente.
Regula principală la crearea unei comunități pentru un proiect opensource este că nu există reguli. Vreau să spun că nu există reguli universale, la fel cum nu există o soluție miraculoasă, în parte pentru că proiectele sunt foarte diferite. Nu poți folosi aceleași reguli pentru a crea o comunitate pentru o bibliotecă de logare pe js și un driver specializat. Mai mult, în diferite etape de dezvoltare a proiectului (prin urmare și a comunității), regulile se schimbă.
Embox a început ca un proiect studențesc, deoarece aveam acces la studenții de la catedra de programare sistemică. Practic, intram într-o altă comunitate. Participanții acestei comunități, studenții, puteau fi interesați de o practică industrială bună pentru specialitatea lor, lucrări științifice în domeniul programării sistemice, lucrări de curs și diplome. Așadar, respectam una dintre regulile fundamentale în organizarea comunității: participanții trebuie să obțină ceva, iar acest cost trebuie să corespundă contribuției participanților.
Următoarea etapă pentru Embox a fost căutarea utilizatorilor externi. Este foarte important să înțelegem că utilizatorii sunt participanți activi în comunitatea open source. De obicei, utilizatorii sunt mai mulți decât dezvoltatorii. Și pentru a dori să devină contribuitori ai proiectului, mai întâi, încep să-l folosească într-un fel sau altul.
Primii utilizatori pentru Embox au fost de la catedra de Cibernetică Teoretică. Aceștia au propus crearea unui firmware alternativ pentru Lego Mindstorm. Și deși erau încă utilizatori locali (ne puteam întâlni personal și discuta despre ceea ce vor), totuși a fost o experiență foarte bună. De exemplu, am dezvoltat demo-uri pe care le puteam arăta altora, deoarece roboții sunt distractivi și atrag atenția. În cele din urmă, am avut cu adevărat utilizatori externi care au început să întrebe ce este Embox și cum se folosește.
În acest stadiu, a trebuit să ne gândim la documentație și la modalitățile de comunicare cu utilizatorii. Desigur, ne-am gândit la aceste lucruri importante și mai devreme, dar era prematur și nu aveau un efect pozitiv. Efectul a fost mai degrabă negativ. Voi da câteva exemple. Foloseam googlecode, al cărui wiki suporta multilingvism. Am creat pagini în mai multe limbi, nu doar în engleză și rusă, în care cu greu și cu rușine puteam comunica, ci și în germană și spaniolă. Ca rezultat, era foarte jenat atunci când întrebările veneau în aceste limbi, dar noi nu puteam răspunde deloc. Sau am introdus reguli pentru redactarea documentației și comentarea ei, dar cum API-ul se schimba destul de frecvent și semnificativ, documentația noastră devenea învechită și confuza mai mult decât ajuta.
În cele din urmă, toate eforturile noastre, chiar și cele greșite, au dus la apariția utilizatorilor externi. Și chiar a apărut un client comercial, care dorea să îi dezvoltăm un sistem de operare personalizat. Și am dezvoltat, având în vedere experiența și anumite realizări. Aici trebuie să vorbesc și despre momentele bune, dar și despre cele rele. Voi începe cu cele rele. Deoarece mulți dezvoltatori au fost implicați în acest proiect pe o bază comercială, comunitatea, oricum destul de instabilă, s-a împărțit, ceea ce nu putea să nu afecteze evoluția proiectului. Un alt factor a fost că direcția proiectului era dictată de un client comercial, iar scopul său nu era dezvoltarea ulterioară a proiectului. Cel puțin, acest scop nu a fost unul principal.
Pe de altă parte, au fost câteva aspecte pozitive. Am avut cu adevărat utilizatori externi. A fost nu doar un client, ci și cei pentru care acest sistem a fost destinat. Motivația de a participa la proiect a crescut. Într-adevăr, dacă poți câștiga și dintr-o activitate interesantă, este întotdeauna plăcut. Și cel mai important, am auzit o dorință din partea clienților, care la vremea respectivă ne părea absurdă, dar care acum este ideea de bază a Embox, și anume, utilizarea codului deja dezvoltat în sistem. Acum, ideea principală a Embox este utilizarea software-ului Linux fără Linux. Așadar, principalul aspect pozitiv care a contribuit la dezvoltarea ulterioară a proiectului a fost conștientizarea faptului că proiectul este folosit de utilizatori externi și că trebuie să rezolve unele dintre problemele lor.
La acel moment, Embox depășise deja limitele unui proiect studențesc. Principalul factor de restricție pentru dezvoltarea proiectului într-un model studențesc este motivația participanților. Studenții participă atât timp cât învață, iar când absolvă, ar trebui să apară 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 să fie instruiți, rezultă că devin specialiști buni în momentul absolvirii, dar contribuția lor la proiect, din cauza lipsirii de experiență, nu este foarte mare.
În general, trecem cu ușurință la momentul principal care permite discuția despre crearea unui proiect open-source — crearea unui produs care să rezolve problemele utilizatorilor săi. Așa cum am explicat mai sus, principala caracteristică a unui proiect open-source este comunitatea sa. Și, ceea ce este esențial, participanții la comunitate sunt în primul rând utilizatori. Dar de unde să apară aceștia timp ce nu au cu ce să folosească? Aici ajungem la concluzia că, la fel ca și în cazul unui proiect non-open-source, este necesar să ne concentrăm pe creare de MVP (produs minim viabil), iar dacă acesta va interesa utilizatorii, atunci în jurul proiectului va apărea o comunitate. Dacă ne ocupăm de formarea comunității doar prin PR, scriind wiki în toate limbile lumii sau stabilind un flux de lucru corect pe github, este puțin probabil ca acest lucru să aibă vreo importanță în etapele incipiente ale proiectului. Bineînțeles, în etapele corespunzătoare, acestea sunt lucruri nu doar importante, ci și necesare.
În concluzie, vreau să menționez , care reflectă, în opinia mea, așteptările utilizatorului de la un proiect opensource:
Mă gândesc serios să trec la acest sistem de operare (cel puțin să-l încerc. Este dezvoltat activ și se fac lucruri interesante).
P. S. La avem nu mai puțin de trei prelegeri. Una despre open source și două despre embedded (din care una practică). La stand vom organiza un masterclass despre programarea microcontrolerelor cu ajutorul . Vom aduce echipamente și vom permite programarea acestora. Vor fi și jocuri și alte activități. Veniți la festival și la standul nostru, va fi distractiv.
Sursa: habr.com
