Allerede denne uge finder en IT-festival sted i Sankt Petersborg . En af talerne vil være Richard Stallman. deltager også i festivalen, og selvfølgelig kunne vi ikke undgå at tage emnet FOSS op. Derfor hedder en af vores præsentationer . Den vil være dedikeret til historien om udviklingen af Embox som et open source projekt. I denne artikel vil jeg dele de vigtigste ideer, der efter min mening påvirker udviklingen af open source projekter. Artiklen, ligesom præsentationen, er baseret på mine personlige erfaringer.
Lad os begynde med det enkle, nemlig definitionen af termen open source. Det er tydeligt, at et open source projekt er et projekt der har en af de licenser, der giver adgang til kildekoden for projektet. Desuden indebærer et åbent projekt muligheden for at foretage ændringer af tredjepartsudviklere. Så hvis en virksomhed eller udvikler offentliggør koden for deres produkt, helt eller delvist, gør det ikke nødvendigvis produktet til et open source projekt. Endelig bør enhver projektaktivitet føre til et eller andet resultat, og åbenheden af projektet indebærer, at dette resultat bruges ikke kun af udviklerne selv.
Vi vil ikke beskæftige os med problemerne ved åbne licenser. Det er et for stort og komplekst emne, der kræver dybdegående behandling. Der er skrevet en del gode artikler og materialer om emnet. Men da jeg ikke selv er specialist inden for ophavsret, vil jeg kun sige, at licensen skal svare til projektets mål. For eksempel var valget af BSD-licensen frem for GPL-licensen ikke tilfældigt for Embox.
Faktum er, at et åbent projekt skal give mulighed for at foretage ændringer og påvirke udviklingen af projektet, hvilket indebærer, at projektet er decentraliseret. At styre det, opretholde integriteten og funktionaliteten er meget sværere sammenlignet med et projekt, der har centraliseret kontrol. Der opstår et rimeligt spørgsmål om, hvorfor man overhovedet skulle lave åbne projekter. Svaret ligger inden for den kommercielle rentabilitet; for en bestemt klasse af projekter opvejer fordelene ved denne tilgang omkostningerne. Det vil sige, at den åbne tilgang ikke passer til alle projekter og slet ikke er tilladt. For eksempel er det svært at forestille sig udviklingen af et styringssystem til et kraftværk eller et fly baseret på åbne principper. Nej, naturligvis skal moduler baseret på åbne projekter inkluderes i sådanne systemer, da det giver en række fordele. Men der skal være nogen, der tager ansvar for det endelige produkt. Selv hvis systemet er fuldt ud baseret på koden fra åbne projekter, lukker udvikleren, ved at samle det hele i et enkelt system og lave specifikke builds og indstillinger, det i virkeligheden. Koden kan herved være offentligt tilgængelig.
Der er også adskillige fordele ved at oprette eller deltage i åbne projekter for disse systemer. Som jeg allerede har nævnt, kan koden for det endelige system forblive offentligt tilgængelig. Hvorfor det? Det er jo åbenlyst, at der næppe er nogen, der ejer et sådant fly for at teste systemet. Det er sandt, men der kan meget vel være nogen, der ønsker at kontrollere specifikke dele af koden, eller for eksempel kan nogen opdage, at det anvendte bibliotek ikke helt er korrekt konfigureret.
Endnu større fordele opstår, hvis en virksomhed afsætter en del af systemet til et separat projekt. For eksempel en bibliotek til understøttelse af en bestemt datakommunikationsprotokol. I dette tilfælde kan omkostningerne ved at vedligeholde denne del af systemet deles med andre virksomheder i samme felt, selv hvis protokollen er specifik for dette område. Desuden kræver det betydeligt mindre tid for specialister, der kan studere denne del af systemet i åben adgang, for at bruge det effektivt. Endelig gør det at adskille en del som en selvstændig enhed, der anvendes af tredjepartsudviklere, denne del mere kvalitetsbevidst, da der skal tilbydes effektive API’er, laves dokumentation, og jeg nævner ikke engang forbedring af testdækningen.
Virksomheden kan også opnå kommercielle fordele uden at skabe åbne projekter, så længe dens specialister deltager i tredjepartsprojekter, der anvendes i virksomheden. For alle fordelene forbliver: medarbejderne kender bedre projektet, hvilket indebærer en mere effektiv anvendelse; virksomheden kan påvirke retningen for udviklingen af projektet; og brugen af klar, testet kode reducerer tydeligt virksomhedens omkostninger.
Fordelene ved at skabe open source-projekter stopper ikke her. Lad os tage en så vigtig del af forretningen som marketing. For det er det en fremragende sandkasse, der giver mulighed for effektivt at vurdere markedsbehovene.
Og selvfølgelig skal man ikke glemme, at et open source-projekt er en effektiv måde at proklamere sine specialiseringskompetencer. I nogle tilfælde er det faktisk den eneste måde at trænge ind på markedet. For eksempel startede Embox som et projekt til at skabe et RTOS. Det er næppe nødvendigt at forklare, at der findes masser af konkurrenter. Uden at skabe et fællesskab ville vi simpelthen ikke have haft ressourcerne til at bringe projektet til den endelige bruger, dvs. for at tredjeparter kunne anvende projektet.
Fællesskabet er nøglen i et open source-projekt. Det muliggør betydelige omkostningsreduktioner i projektledelse og bidrager til udvikling og vedligeholdelse af projektet. Man kan sige, at uden et fællesskab eksisterer der overhovedet ikke et open source-projekt.
Der er skrevet mange materialer om, hvordan man opretter og styrer et open source-projektfællesskab. Jeg vil for ikke at gentage allerede kendte fakta fokusere på erfaringerne fra Embox. Et interessant spørgsmål er for eksempel processen med at oprette et fællesskab. Mange fortæller, hvordan man styrer et eksisterende fællesskab, men de aspekter ved dets oprettelse bliver ofte overset, idet man betragter det som en given.
Hovedreglen ved oprettelse af et open source-projektfællesskab er, at der ikke er nogen regler. Jeg mener, at der ikke findes universelle regler, ligesom der ikke findes nogen sølvkugle, især fordi projekterne er meget forskellige. Det er næppe muligt at anvende de samme regler til oprettelse af et fællesskab for et loggingsbibliotek i js og til en snævert specialiseret driver. Desuden ændrer reglerne sig på forskellige faser af projektudviklingen (og dermed også fællesskabet).
Embox begyndte som et studenterprojekt, da der var adgang til studerende fra afdelingen for systemprogrammering. I virkeligheden trådte vi ind i et andet fællesskab. Vi kunne interessere medlemmerne af dette fællesskab, studerende, med gode praktiske erfaringer inden for deres felt, videnskabelige arbejder inden for systemprogrammering, samt kursus- og specialeprojekter. Vi overholdt dermed en af de grundlæggende regler for organisering af et fællesskab; medlemmerne skal få noget ud af det, og prisen skal svare til deltagerens bidrag.
Næste fase for Embox var at finde eksterne brugere. Det er meget vigtigt at forstå, at brugerne er fuldgyldige deltagere i open source-fællesskabet. Der er normalt flere brugere end udviklere. Og for at få lyst til at blive bidragyder til projektet, begynder man først at bruge det på en eller anden måde.
De første brugere af Embox var afdelingen for Teoretisk Cybernetik. De foreslog at skabe en alternativ firmware til Lego Mindstorm. Og selvom de stadig var lokale brugere (vi kunne mødes personligt og diskutere, hvad de ønskede), var det alligevel en meget god oplevelse. For eksempel udviklede vi demos, som vi kunne vise til andre, fordi robotter er sjove og tiltrækker opmærksomhed. I sidste ende fik vi virkelig eksterne brugere, der begyndte at spørge, hvad Embox er, og hvordan man bruger det.
På dette stadium måtte vi begynde at tænke på dokumentation og kommunikationsmidler med brugerne. Selvfølgelig havde vi tænkt på disse vigtige ting før, men det var for tidligt, og det gav ikke et positivt resultat. Effekten var snarere negativ. Jeg vil give et par eksempler. Vi brugte googlecode, hvis wiki understøttede flersprogethed. Vi lavede sider på flere sprog, ikke kun engelsk og russisk, som vi så småt kunne kommunikere på, men også tysk og spansk. Resultatet var, at det så meget tåbeligt ud, når folk spurgte på disse sprog, men vi slet ikke kunne svare. Eller vi indførte regler for, hvordan man skulle skrive dokumentation og kommentere, men da API'et ændrede sig ret ofte og væsentligt, endte vi med, at vores dokumentation blev forældet og førte til mere forvirring end hjælp.
I sidste ende førte alle vores indsats, selv de forkerte, til, at der kom eksterne brugere. Og der dukkede endda en kommerciel kunde op, der ønskede, at der skulle udvikles et skræddersyet OS til ham. Og det udviklede vi, da vi har erfaring og nogle forarbejder. Her skal der fortælles om både de gode og dårlige aspekter. Jeg vil starte med de dårlige. Da mange udviklere blev involveret i dette projekt på kommerciel basis, var samfundet allerede ret ustabilt og blev delt, hvilket selvfølgelig ikke kunne undgå at påvirke projektets udvikling. En yderligere faktor var, at projektets retning blev bestemt af én kommerciel kunde, som ikke havde til hensigt at fremme projektets videre udvikling. I det mindste var dette ikke den primære mål.
På den anden side var der en række positive aspekter. Vi fik virkelig eksterne brugere. Det var ikke kun kunderne, men også dem, som systemet var beregnet til. Motivation til at deltage i projektet voksede. For hvis man kan tjene penge på noget interessant, er det altid rart. Og vigtigst af alt, vi hørte et ønske fra kunderne, som på det tidspunkt syntes absurd, men som nu er hovedideen bag Embox, nemlig at bruge allerede udviklet kode i systemet. I dag er den primære idé bag Embox at bruge Linux-software uden Linux. Således var den vigtigste positive faktor, der fremmede projektets videre udvikling, erkendelsen af, at projektet bruges af eksterne brugere, og at det skal løse nogle af deres problemer.
På det tidspunkt var Embox allerede steget ud over et studenterprojekt. Den primære begrænsende faktor for projektets udvikling som et studenterprojekt er motivationen hos deltagerne. Studerende deltager, så længe de studerer, men når de er dimittender, skal der komme en anden motivation. Hvis motivationen ikke dukker op, stopper studenten med at deltage i projektet. Hvis man tager i betragtning, at studerende først skal trænes, så sker det, at de bliver gode specialister, når de dimitterer, men deres bidrag til projektet er begrænset af deres uerfarenhed.
Generelt bevæger vi os glidende hen til det væsentlige punkt, der gør det muligt at tale om oprettelse af et opensource-projekt — at skabe et produkt, der løser brugernes problemer. Som jeg allerede har forklaret ovenfor, er den grundlæggende egenskab ved et opensource-projekt dets fællesskab. Og deltagerne i fællesskabet er først og fremmest brugerne. Men hvordan skulle de komme til at eksistere, hvis der ikke er noget at bruge? Så det viser sig, at ligesom med et ikke-opensource-projekt, skal man fokusere på at skabe en MVP (minimum viable product), og hvis den fanger brugernes interesse, så vil fællesskabet opstå omkring projektet. Hvis man derimod forsøger at skabe et fællesskab kun gennem PR, skrive wiki på alle verdens sprog, eller have det rigtige git workflow på github, så vil det næppe have betydning i de tidlige faser af projektet. Selvfølgelig er disse ting i rette faser ikke kun vigtige, men også nødvendige.
Afslutningsvis vil jeg gerne nævne , som efter min mening afspejler brugerens forventninger til et opensource-projekt:
Jeg overvejer seriøst at skifte til dette operativsystem (i det mindste at prøve det. Det bliver virkelig aktivt udviklet, og der laves mange fede ting).
P. S. På har vi hele tre oplæg. Et om open source og to om embedded (og en af dem er praktisk). På standen vil vi afholde en workshop i programmering af mikrokontrollere med hjælp fra . Traditionelt vil vi tage noget hardware med og lade folk programmere den. Der vil også være en quest og andre aktiviteter. Kom til festivalen og besøg vores stand, det bliver sjovt.
Kilde: habr.com
