I denne uge afholdes en it-festival i Sankt Petersborg . En af talerne bliver Richard Stallman. deltager også i festivalen, og vi kunne selvfølgelig ikke ignorere emnet gratis software. Derfor hedder en af vores rapporter . Det vil være dedikeret til historien om Embox's udvikling som et open source-projekt. I denne artikel vil jeg tale om de vigtigste ideer, der efter min mening påvirker udviklingen af opensource-projekter. Artiklen er ligesom rapporten baseret på personlige erfaringer.
Lad os starte med noget simpelt, med definitionen af begrebet opensource. Et open source-projekt er naturligvis et projekt, der har en af de licenser, der giver adgang til projektets kildekode. Derudover betyder et åbent projekt, at tredjepartsudviklere kan foretage ændringer. Det vil sige, at hvis en virksomhed eller udvikler udgiver koden til sit produkt, helt eller delvist, gør dette endnu ikke dette produkt til et opensource-projekt. Og endelig skal enhver projektaktivitet føre til en eller anden form for resultat, og projektets åbenhed indebærer, at dette resultat ikke kun bruges af udviklerne selv.
Vi vil ikke berøre problemerne med åbne licenser. Dette er et for stort og komplekst emne, som kræver en dybtgående undersøgelse. Der er skrevet en hel del gode artikler og materialer om dette emne. Men da jeg ikke selv er ekspert inden for ophavsret, vil jeg kun sige, at licensen skal opfylde projektets mål. For eksempel var valget af en BSD i stedet for en GPL-licens for Embox ikke tilfældigt.
At et open source-projekt skal give mulighed for at foretage ændringer og påvirke udviklingen af open source-projektet indebærer, at projektet er distribueret. At administrere det, opretholde integritet og ydeevne er meget vanskeligere sammenlignet med et projekt med centraliseret ledelse. Et rimeligt spørgsmål opstår: hvorfor åbner projekter overhovedet? Svaret ligger i området for kommerciel gennemførlighed; for en bestemt klasse af projekter opvejer fordelene ved denne tilgang omkostningerne. Det vil sige, at det ikke er egnet til alle projekter, og en åben tilgang er generelt acceptabel. For eksempel er det svært at forestille sig at udvikle et styresystem til et kraftværk eller et fly baseret på et åbent princip. Nej, selvfølgelig bør sådanne systemer indeholde moduler baseret på åbne projekter, for det vil give en række fordele. Men nogen skal være ansvarlig for det endelige produkt. Selvom systemet er fuldstændig baseret på koden for åbne projekter, lukker udvikleren, efter at have pakket alt i ét system og lavet specifikke builds og indstillinger, det i det væsentlige. Koden kan være offentligt tilgængelig.
Der er også en masse fordele for disse systemer ved at skabe eller bidrage til open source-projekter. Som jeg allerede har sagt, kan slutsystemkoden forblive offentligt tilgængelig. Hvorfor, fordi det er indlysende, at det er usandsynligt, at nogen vil have det samme fly til at teste systemet. Det er rigtigt, men der kan godt være nogen, der vil tjekke visse dele af koden, eller for eksempel kan nogen opdage, at det bibliotek, der bruges, ikke er konfigureret helt korrekt.
En endnu større fordel viser sig, hvis virksomheden allokerer en grundlæggende del af systemet til et separat projekt. For eksempel et bibliotek, der understøtter en form for dataudvekslingsprotokol. I dette tilfælde, selvom protokollen er specifik for et givet emneområde, kan du dele omkostningerne ved at vedligeholde denne del af systemet med andre virksomheder fra dette område. Derudover kræver specialister, der kan studere denne del af systemet i det offentlige domæne, meget mindre tid til at bruge det effektivt. Og endelig, at adskille et stykke i en uafhængig enhed, som tredjepartsudviklere bruger, giver os mulighed for at gøre denne del bedre, fordi vi skal tilbyde effektive API'er, skabe dokumentation, og jeg taler ikke engang om at forbedre testdækningen.
En virksomhed kan modtage kommercielle fordele uden at skabe open source-projekter; det er nok for dets specialister at deltage i tredjepartsprojekter, der bruges i virksomheden. Når alt kommer til alt, forbliver alle fordelene: Medarbejderne kender projektet bedre, derfor bruger de det mere effektivt, virksomheden kan påvirke retningen for projektets udvikling, og brugen af færdiglavet, debugget kode reducerer naturligvis virksomhedens omkostninger.
Fordelene ved at skabe opensource-projekter slutter ikke der. Lad os tage en så vigtig del af forretningen som markedsføring. For ham er dette en meget god sandkasse, der giver ham mulighed for effektivt at evaluere markedets krav.
Og selvfølgelig må vi ikke glemme, at et opensource-projekt er en effektiv måde at erklære dig selv som bærer af enhver specialisering. I nogle tilfælde er dette den eneste måde at komme ind på markedet på. For eksempel begyndte Embox som et projekt for at skabe en RTOS. Der er nok ingen grund til at forklare, at der er mange konkurrenter. Uden at skabe et fællesskab, ville vi simpelthen ikke have haft nok ressourcer til at bringe projektet til slutbrugeren, det vil sige, at tredjepartsudviklere kunne begynde at bruge projektet.
Fællesskabet er nøglen i et opensource-projekt. Det giver dig mulighed for betydeligt at reducere projektledelsesomkostninger, udvikle og understøtte projektet. Vi kan sige, at uden et fællesskab er der slet ikke noget opensource-projekt.
Der er skrevet meget materiale om, hvordan man opretter og administrerer et open source-projektfællesskab. For ikke at genfortælle allerede kendte fakta, vil jeg forsøge at fokusere på oplevelsen af Embox. For eksempel er processen med at skabe et fællesskab et meget interessant emne. Det vil sige, at mange fortæller, hvordan man administrerer et eksisterende fællesskab, men øjeblikke i dets oprettelse bliver nogle gange overset, når man betragter dette som en selvfølge.
Hovedreglen ved oprettelse af et opensource-projektfællesskab er, at der ikke er nogen regler. Jeg mener, der er ingen universelle regler, ligesom der ikke er nogen sølvkugle, om ikke andet fordi projekterne er meget forskellige. Det er usandsynligt, at du kan bruge de samme regler, når du opretter et fællesskab for et js-logbibliotek og en eller anden højt specialiseret driver. Desuden ændres reglerne på forskellige udviklingsstadier af projektet (og dermed fællesskabet).
Embox startede som et studenterprojekt, fordi det havde adgang til studerende fra systemprogrammeringsafdelingen. Faktisk var vi på vej ind i et andet samfund. Vi kunne interessere deltagerne i dette samfund, studerende, i god industriel praksis i deres speciale, videnskabelige arbejde inden for systemprogrammering, kurser og eksamensbeviser. Det vil sige, at vi fulgte en af de grundlæggende regler for at organisere et fællesskab: Fællesskabsmedlemmer skal modtage noget, og denne pris skal svare til deltagerens bidrag.
Den næste fase for Embox var søgningen efter tredjepartsbrugere. Det er meget vigtigt at forstå, at brugere er fuldgyldige deltagere i opensource-fællesskabet. Der er normalt flere brugere end udviklere. Og for at have lyst til at blive bidragsyder til et projekt, begynder de først at bruge det på den ene eller anden måde.
De første brugere af Embox var Institut for Teoretisk Kybernetik. De foreslog at lave en alternativ firmware til Lego Mindstorm. Og selvom disse stadig var lokale brugere (vi kunne mødes med dem personligt og diskutere, hvad de ønskede). Men det var stadig en meget god oplevelse. For eksempel udviklede vi demoer, som kunne vises til andre, fordi robotter er sjove og tiltrækker opmærksomhed. Som et resultat fik vi virkelig tredjepartsbrugere, der begyndte at spørge, hvad Embox er, og hvordan man bruger det.
På dette stadie skulle vi tænke på dokumentation, på kommunikationsmidler med brugerne. Nej, vi tænkte selvfølgelig på disse vigtige ting før, men det var for tidligt og gav ikke en positiv effekt. Effekten var ret negativ. Lad mig give dig et par eksempler. Vi brugte googlecode, hvis wiki understøttede flersprogethed. Vi lavede sider på flere sprog, ikke kun engelsk og russisk, hvor vi næsten ikke kunne kommunikere, men også tysk og spansk. Som følge heraf ser det meget latterligt ud, når det bliver spurgt på disse sprog, men vi kan slet ikke svare. Eller de indførte regler om at skrive dokumentation og kommentere, men da API'et ændrede sig ret ofte og markant, viste det sig, at vores dokumentation var forældet og var mere vildledende, end den hjalp.
Som et resultat førte alle vores bestræbelser, selv de forkerte, til udseendet af eksterne brugere. Og endda dukkede en kommerciel kunde op, som ønskede, at hans egen RTOS skulle udvikles til ham. Og vi udviklede det, fordi vi har erfaring og noget grundarbejde. Her skal du tale om både de gode øjeblikke og de dårlige. Jeg starter med de dårlige. Da mange udviklere var involveret i dette projekt på kommerciel basis, var samfundet allerede ret ustabilt og splittet, hvilket naturligvis ikke kunne andet end at påvirke udviklingen af projektet. En yderligere faktor var, at retningen for projektet blev sat af én kommerciel kunde, og hans mål var ikke den videre udvikling af projektet. Dette var i hvert fald ikke hovedmålet.
På den anden side var der en række positive aspekter. Vi har virkelig tredjepartsbrugere. Det var ikke kun kunden, men også dem, som dette system var beregnet til. Motivationen for at deltage i projektet er steget. Når alt kommer til alt, hvis du også kan tjene penge på en interessant forretning, er det altid rart. Og vigtigst af alt hørte vi et ønske fra kunder, som på det tidspunkt virkede skørt for os, men som nu er hovedideen med Embox, nemlig at bruge allerede udviklet kode i systemet. Nu er hovedideen med Embox at bruge Linux-software uden Linux. Det vil sige, at det primære positive aspekt, der bidrog til den videre udvikling af projektet, var erkendelsen af, at projektet bruges af tredjepartsbrugere, og det burde løse nogle af deres problemer.
På det tidspunkt var Embox allerede gået ud over rammerne af et studenterprojekt. Den væsentligste begrænsende faktor i udviklingen af projektet efter elevmodellen er deltagernes motivation. Studerende deltager, mens de studerer, og når de er færdige, bør der være en anden motivation. Hvis motivationen ikke viser sig, stopper eleven blot med at deltage i projektet. Tager vi med i betragtning, at eleverne først skal oplæres, viser det sig, at de bliver gode specialister, når de er færdiguddannede, men deres bidrag til projektet er på grund af uerfarenhed ikke særlig stort.
Generelt går vi gnidningsløst videre til hovedpunktet, der giver os mulighed for at tale om at skabe et opensource-projekt - at skabe et produkt, der løser problemerne for dets brugere. Som jeg forklarede ovenfor, er hovedegenskaben ved et opensource-projekt dets fællesskab. Desuden er medlemmer af fællesskabet primært brugere. Men hvor kommer de fra, når der ikke er noget at bruge? Så det viser sig, at du ligesom med et ikke-opensource-projekt skal fokusere på at skabe et MVP (minimum viable product), og hvis det interesserer brugerne, så vil der dukke et fællesskab op omkring projektet. Hvis du kun er engageret i at skabe et fællesskab gennem community-PR, skrive en wiki på alle verdens sprog eller rette git-workflow på github, så er det usandsynligt, at dette betyder noget i de tidlige stadier af projektet. Selvfølgelig er disse på de passende stadier ikke kun vigtige, men også nødvendige ting.
Afslutningsvis vil jeg gerne påpege efter min mening afspejler brugernes forventninger fra et opensource-projekt:
Jeg overvejer seriøst at skifte til dette OS (prøv i det mindste. De forfølger det aktivt og laver seje ting).
PS til Vi vil have så mange som tre rapporter. En om open source og to om embedded (og en er praktisk). På standen vil vi afholde en masterclass om programmering af mikrocontrollere ved hjælp af . Som sædvanlig tager vi hardwaren med og lader dig programmere den. Der vil også være en quest og andre aktiviteter. Kom til festivalen og vores stand, det bliver sjovt.
Kilde: www.habr.com