Det arrangeres en IT-festival i St. Petersburg denne uken . En av foredragsholderne vil være Richard Stallman. deltar også på festivalen, og vi kunne selvfølgelig ikke se bort fra temaet gratis programvare. Det er derfor en av rapportene våre heter . Det vil være dedikert til historien til Embox sin utvikling som et åpen kildekode-prosjekt. I denne artikkelen vil jeg snakke om hovedideene som etter min mening påvirker utviklingen av åpen kildekode-prosjekter. Artikkelen er, i likhet med rapporten, basert på personlig erfaring.
La oss starte med noe enkelt, med definisjonen av begrepet åpen kildekode. Selvfølgelig er et åpen kildekode-prosjekt et prosjekt som har en av lisensene som gir tilgang til kildekoden til prosjektet. I tillegg betyr et åpent prosjekt at tredjepartsutviklere kan gjøre endringer. Det vil si at hvis et selskap eller en utvikler publiserer koden til produktet sitt, delvis eller fullstendig, gjør dette ennå ikke dette produktet til et åpen kildekode-prosjekt. Og til slutt, enhver prosjektaktivitet må føre til et slags resultat, og åpenheten til prosjektet innebærer at dette resultatet ikke bare brukes av utviklerne selv.
Vi skal ikke berøre problemene med åpne lisenser. Dette er et for stort og komplekst tema som krever inngående undersøkelser. Det er skrevet ganske mange gode artikler og materiell om dette emnet. Men siden jeg selv ikke er ekspert på opphavsrett, vil jeg bare si at lisensen må oppfylle målene for prosjektet. For eksempel, for Embox var valget av en BSD i stedet for en GPL-lisens ikke tilfeldig.
At et åpen kildekodeprosjekt skal gi mulighet til å gjøre endringer og påvirke utviklingen av åpen kildekodeprosjektet innebærer at prosjektet er distribuert. Å administrere det, opprettholde integritet og ytelse er mye vanskeligere sammenlignet med et prosjekt med sentralisert ledelse. Et rimelig spørsmål dukker opp: hvorfor åpner prosjekter i det hele tatt? Svaret ligger i området for kommersiell gjennomførbarhet; for en viss klasse prosjekter oppveier fordelene med denne tilnærmingen kostnadene. Det vil si at det ikke er egnet for alle prosjekter og en åpen tilnærming er generelt akseptabel. For eksempel er det vanskelig å tenke seg å utvikle et kontrollsystem for et kraftverk eller et fly basert på et åpent prinsipp. Nei, selvfølgelig bør slike systemer inneholde moduler basert på åpne prosjekter, fordi dette vil gi en rekke fordeler. Men noen må være ansvarlig for sluttproduktet. Selv om systemet er fullstendig basert på koden til åpne prosjekter, lukker utvikleren det, etter å ha pakket alt inn i ett system og laget spesifikke bygg og innstillinger. Koden kan være offentlig tilgjengelig.
Det er også mange fordeler for disse systemene ved å lage eller bidra til åpen kildekode-prosjekter. Som jeg allerede sa, kan sluttsystemkoden forbli offentlig tilgjengelig. Hvorfor, fordi det er åpenbart at det er usannsynlig at noen vil ha samme fly for å teste systemet. Dette er sant, men det kan godt være noen som ønsker å sjekke visse deler av koden, eller for eksempel kan noen oppdage at biblioteket som brukes ikke er helt riktig konfigurert.
En enda større fordel viser seg dersom bedriften allokerer en grunnleggende del av systemet til et eget prosjekt. For eksempel et bibliotek for å støtte en slags datautvekslingsprotokoll. I dette tilfellet, selv om protokollen er spesifikk for et gitt fagområde, kan du dele kostnadene ved å vedlikeholde denne delen av systemet med andre selskaper fra dette området. I tillegg krever spesialister som kan studere denne delen av systemet i det offentlige rom mye mindre tid for å bruke det effektivt. Og til slutt, å skille et stykke inn i en uavhengig enhet som tredjepartsutviklere bruker, lar oss gjøre denne delen bedre, fordi vi må tilby effektive APIer, lage dokumentasjon, og jeg snakker ikke engang om å forbedre testdekningen.
Et selskap kan motta kommersielle fordeler uten å lage åpen kildekode-prosjekter; det er nok for spesialistene å delta i tredjepartsprosjekter som brukes i selskapet. Tross alt gjenstår alle fordelene: ansatte kjenner prosjektet bedre, derfor bruker de det mer effektivt, selskapet kan påvirke retningen for prosjektets utvikling, og bruk av ferdig, feilsøkt kode reduserer åpenbart selskapets kostnader.
Fordelene ved å lage åpen kildekode-prosjekter slutter ikke der. La oss ta en så viktig del av virksomheten som markedsføring. For ham er dette en veldig god sandkasse som gjør at han effektivt kan evaluere markedets krav.
Og selvfølgelig må vi ikke glemme at et åpen kildekode-prosjekt er en effektiv måte å erklære deg selv som bærer av enhver spesialisering. I noen tilfeller er dette den eneste måten å komme inn på markedet. For eksempel begynte Embox som et prosjekt for å lage en RTOS. Det er nok ikke nødvendig å forklare at det er mange konkurrenter. Uten å opprette et fellesskap ville vi rett og slett ikke hatt nok ressurser til å bringe prosjektet til sluttbrukeren, det vil si at tredjepartsutviklere kan begynne å bruke prosjektet.
Fellesskapet er nøkkelen i et åpen kildekode-prosjekt. Det lar deg redusere prosjektledelseskostnadene betydelig, utvikle og støtte prosjektet. Vi kan si at uten et fellesskap er det ikke noe åpen kildekode-prosjekt i det hele tatt.
Det er skrevet mye materiale om hvordan man oppretter og administrerer et åpen kildekode-prosjektfellesskap. For ikke å gjenfortelle allerede kjente fakta, vil jeg prøve å fokusere på opplevelsen av Embox. For eksempel er prosessen med å skape et fellesskap en veldig interessant problemstilling. Det vil si at mange forteller hvordan man administrerer et eksisterende fellesskap, men øyeblikkene for opprettelsen av det blir noen ganger oversett, med tanke på at dette er gitt.
Hovedregelen når du oppretter et åpen kildekode-prosjektfellesskap er at det ikke er noen regler. Jeg mener det er ingen universelle regler, akkurat som det ikke er noen sølvkule, om ikke annet fordi prosjektene er veldig forskjellige. Det er usannsynlig at du kan bruke de samme reglene når du oppretter et fellesskap for et js-loggingsbibliotek og noen svært spesialiserte drivere. Dessuten, på ulike stadier av utviklingen av prosjektet (og dermed fellesskapet), endres reglene.
Embox startet som et studentprosjekt fordi det hadde tilgang til studenter fra systemprogrammeringsavdelingen. Faktisk gikk vi inn i et annet fellesskap. Vi kan interessere deltakerne i dette fellesskapet, studenter, i god industriell praksis i deres spesialitet, vitenskapelige arbeid innen systemprogrammering, kurs og vitnemål. Det vil si at vi fulgte en av de grunnleggende reglene for å organisere et fellesskap: fellesskapsmedlemmer må motta noe, og denne prisen må samsvare med deltakerens bidrag.
Neste trinn for Embox var søket etter tredjepartsbrukere. Det er veldig viktig å forstå at brukere er fullverdige deltakere i opensource-fellesskapet. Det er vanligvis flere brukere enn utviklere. Og for å ønske å bli bidragsyter til et prosjekt, begynner de først å bruke det på en eller annen måte.
De første brukerne av Embox var Institutt for teoretisk kybernetikk. De foreslo å lage en alternativ firmware for Lego Mindstorm. Og selv om disse fortsatt var lokale brukere (vi kunne møte dem personlig og diskutere hva de ønsket). Men det var likevel en veldig god opplevelse. For eksempel utviklet vi demoer som kunne vises til andre, fordi roboter er morsomme og tiltrekker seg oppmerksomhet. Som et resultat fikk vi virkelige tredjepartsbrukere som begynte å spørre hva Embox er og hvordan man bruker det.
På dette stadiet måtte vi tenke dokumentasjon, kommunikasjonsmidler med brukerne. Nei, vi tenkte selvfølgelig på disse viktige tingene før, men det var prematurt og ga ingen positiv effekt. Effekten var ganske negativ. La meg gi deg et par eksempler. Vi brukte googlecode, hvis wiki støttet flerspråklighet. Vi laget sider på flere språk, ikke bare engelsk og russisk, der vi nesten ikke kunne kommunisere, men også tysk og spansk. Som et resultat ser det veldig latterlig ut når det blir spurt på disse språkene, men vi kan ikke svare i det hele tatt. Eller de innførte regler om å skrive dokumentasjon og kommentere, men siden API endret seg ganske ofte og betydelig, viste det seg at dokumentasjonen vår var utdatert og var mer misvisende enn den hjalp.
Som et resultat førte all vår innsats, selv de gale, til at det dukket opp eksterne brukere. Og til og med en kommersiell kunde dukket opp som ønsket at hans egen RTOS skulle utvikles for ham. Og vi utviklet det fordi vi har erfaring og noe grunnarbeid. Her må du snakke om både de gode øyeblikkene og de dårlige. Jeg begynner med de dårlige. Siden mange utviklere var involvert i dette prosjektet på kommersiell basis, var samfunnet allerede ganske ustabilt og splittet, noe som selvfølgelig ikke kunne annet enn å påvirke utviklingen av prosjektet. En tilleggsfaktor var at retningen for prosjektet ble satt av én kommersiell kunde, og hans mål var ikke videreutvikling av prosjektet. Dette var i hvert fall ikke hovedmålet.
På den annen side var det en rekke positive sider. Vi har virkelig tredjepartsbrukere. Det var ikke bare kunden, men også de som dette systemet var ment for. Motivasjonen for å delta i prosjektet har økt. Tross alt, hvis du også kan tjene penger på en interessant virksomhet, er det alltid hyggelig. Og viktigst av alt, vi hørte ett ønske fra kunder, som på den tiden virket gale for oss, men som nå er hovedideen til Embox, nemlig å bruke allerede utviklet kode i systemet. Nå er hovedideen til Embox å bruke Linux-programvare uten Linux. Det vil si at det viktigste positive aspektet som bidro til den videre utviklingen av prosjektet var erkjennelsen av at prosjektet brukes av tredjepartsbrukere, og det burde løse noen av deres problemer.
På det tidspunktet hadde Embox allerede gått utenfor rammen av et studentprosjekt. Den viktigste begrensende faktoren i utviklingen av prosjektet etter studentmodellen er motivasjonen til deltakerne. Studentene deltar mens de studerer, og når de er ferdige bør det være en annen motivasjon. Hvis motivasjonen ikke vises, slutter eleven rett og slett å delta i prosjektet. Tar vi med i betraktningen at studentene først må utdannes, viser det seg at de blir gode spesialister når de blir ferdige, men deres bidrag til prosjektet er på grunn av uerfarenhet ikke særlig stort.
Generelt går vi jevnt videre til hovedpunktet som lar oss snakke om å lage et åpen kildekode-prosjekt - å lage et produkt som løser problemene til brukerne. Som jeg forklarte ovenfor, er hovedegenskapen til et åpen kildekode-prosjekt fellesskapet. Dessuten er fellesskapsmedlemmer først og fremst brukere. Men hvor kommer de fra når det ikke er noe å bruke? Så det viser seg at, akkurat som med et ikke-opensource-prosjekt, må du fokusere på å lage en MVP (minimum viable product), og hvis det interesserer brukere, vil et fellesskap dukke opp rundt prosjektet. Hvis du er engasjert i å lage et fellesskap bare gjennom fellesskaps-PR, skrive en wiki på alle verdens språk, eller korrigere git-arbeidsflyten på github, er det usannsynlig at dette har noen betydning i de tidlige stadiene av prosjektet. Selvfølgelig, på de riktige stadiene er dette ikke bare viktige, men også nødvendige ting.
Avslutningsvis vil jeg påpeke , etter min mening, gjenspeiler brukernes forventninger fra et åpen kildekode-prosjekt:
Jeg tenker seriøst på å bytte til dette operativsystemet (prøv i det minste. De forfølger det aktivt og gjør kule ting).
PS på Vi vil ha så mange som tre rapporter. En om åpen kildekode og to om innebygd (og en er praktisk). På standen vil vi gjennomføre en mesterklasse om programmering av mikrokontrollere ved hjelp av . Som vanlig tar vi med maskinvaren og lar deg programmere den. Det blir også oppdrag og andre aktiviteter. Kom på festivalen og vår stand, det blir gøy.
Kilde: www.habr.com