En IT-festival kommer att hållas i St Petersburg denna vecka . En av talarna blir Richard Stallman. deltar också i festivalen, och naturligtvis kunde vi inte bortse från ämnet fri programvara. Det är därför en av våra rapporter kallas . Det kommer att ägnas åt historien om Embox utveckling som ett projekt med öppen källkod. I den här artikeln vill jag prata om huvudidéerna som, enligt min mening, påverkar utvecklingen av opensource-projekt. Artikeln, liksom rapporten, bygger på personlig erfarenhet.
Låt oss börja med något enkelt, med definitionen av termen öppen källkod. Uppenbarligen är ett projekt med öppen källkod ett projekt som har en av licenserna som tillåter åtkomst till projektets källkod. Dessutom innebär ett öppet projekt att tredjepartsutvecklare kan göra ändringar. Det vill säga, om något företag eller utvecklare publicerar koden för sin produkt, helt eller delvis, gör detta ännu inte denna produkt till ett opensource-projekt. Och slutligen måste varje projektaktivitet leda till något slags resultat, och projektets öppenhet innebär att detta resultat inte bara används av utvecklarna själva.
Vi kommer inte att beröra problemen med öppna licenser. Detta är ett för stort och komplext ämne som kräver djupgående utredning. Det har skrivits en hel del bra artiklar och material om detta ämne. Men eftersom jag själv inte är expert på upphovsrättsområdet kommer jag bara att säga att licensen måste uppfylla projektets mål. Till exempel, för Embox var valet av en BSD snarare än en GPL-licens inte av misstag.
Att ett open source-projekt ska ge möjlighet att göra förändringar och påverka utvecklingen av open source-projektet innebär att projektet är distribuerat. Att hantera det, upprätthålla integritet och prestanda är mycket svårare jämfört med ett projekt med centraliserad förvaltning. En rimlig fråga uppstår: varför öppnar projekt överhuvudtaget? Svaret ligger inom området kommersiell genomförbarhet; för en viss klass av projekt uppväger fördelarna med detta tillvägagångssätt kostnaderna. Det vill säga, det är inte lämpligt för alla projekt och ett öppet förhållningssätt är allmänt acceptabelt. Det är till exempel svårt att tänka sig att utveckla ett styrsystem för ett kraftverk eller ett flygplan baserat på en öppen princip. Nej, självklart bör sådana system innehålla moduler baserade på öppna projekt, eftersom detta kommer att ge ett antal fördelar. Men någon måste vara ansvarig för slutprodukten. Även om systemet helt och hållet är baserat på koden för öppna projekt, stänger utvecklaren, efter att ha paketerat allt i ett system och gjort specifika konstruktioner och inställningar, det i princip. Koden kan vara allmänt tillgänglig.
Det finns också många fördelar för dessa system från att skapa eller bidra till projekt med öppen källkod. Som jag redan har sagt kan slutsystemkoden förbli allmänt tillgänglig. Varför, för det är uppenbart att det är osannolikt att någon kommer att ha samma flygplan för att testa systemet. Det är sant, men det kan mycket väl finnas någon som vill kontrollera vissa delar av koden, eller till exempel kan någon upptäcka att biblioteket som används inte är riktigt konfigurerat.
En ännu större nytta uppstår om företaget allokerar någon grundläggande del av systemet till ett separat projekt. Till exempel ett bibliotek för att stödja någon form av datautbytesprotokoll. I det här fallet, även om protokollet är specifikt för ett visst ämnesområde, kan du dela kostnaderna för att underhålla denna del av systemet med andra företag från detta område. Dessutom kräver specialister som kan studera denna del av systemet i det offentliga området mycket mindre tid för att använda det effektivt. Och slutligen, att separera en del i en oberoende enhet som tredjepartsutvecklare använder gör att vi kan göra den här delen bättre, eftersom vi måste erbjuda effektiva API:er, skapa dokumentation och jag pratar inte ens om att förbättra testtäckningen.
Ett företag kan få kommersiella fördelar utan att skapa projekt med öppen källkod; det räcker för dess specialister att delta i tredjepartsprojekt som används i företaget. När allt kommer omkring finns alla fördelar kvar: anställda känner till projektet bättre, därför använder de det mer effektivt, företaget kan påverka riktningen för projektets utveckling, och användningen av färdig, felsökt kod minskar uppenbarligen företagets kostnader.
Fördelarna med att skapa opensource-projekt slutar inte där. Låt oss ta en så viktig del av verksamheten som marknadsföring. För honom är detta en mycket bra sandlåda som gör att han effektivt kan utvärdera marknadens krav.
Och naturligtvis får vi inte glömma att ett opensource-projekt är ett effektivt sätt att förklara sig själv som bärare av vilken specialisering som helst. I vissa fall är detta det enda sättet att komma in på marknaden. Till exempel började Embox som ett projekt för att skapa en RTOS. Det finns nog ingen anledning att förklara att det finns många konkurrenter. Utan att skapa en community hade vi helt enkelt inte haft tillräckligt med resurser för att föra projektet till slutanvändaren, det vill säga för tredjepartsutvecklare att börja använda projektet.
Gemenskapen är nyckeln i ett opensource-projekt. Det låter dig avsevärt minska projektledningskostnaderna, utveckla och stödja projektet. Vi kan säga att utan en community finns det inget opensource-projekt alls.
Det har skrivits mycket material om hur man skapar och hanterar en projektgemenskap med öppen källkod. För att inte återberätta redan kända fakta kommer jag att försöka fokusera på upplevelsen av Embox. Till exempel är processen att skapa en gemenskap en mycket intressant fråga. Det vill säga, många berättar hur man hanterar en befintlig gemenskap, men ögonblicken då den skapades förbises ibland, med tanke på att detta är givet.
Huvudregeln när man skapar en öppen källkods-projektgemenskap är att det inte finns några regler. Jag menar att det inte finns några universella regler, precis som det inte finns någon silverkula, om så bara för att projekten är väldigt olika. Det är osannolikt att du kan använda samma regler när du skapar en gemenskap för ett js-loggningsbibliotek och någon mycket specialiserad drivrutin. Dessutom, vid olika utvecklingsstadier av projektet (och därmed samhället), ändras reglerna.
Embox startade som ett studentprojekt eftersom det hade tillgång till studenter från systemprogrammeringsavdelningen. Faktum är att vi gick in i någon annan gemenskap. Vi skulle kunna intressera deltagarna i denna gemenskap, studenter, i god industriell praxis i deras specialitet, vetenskapligt arbete inom området systemprogrammering, kurser och diplom. Det vill säga, vi följde en av de grundläggande reglerna för att organisera en gemenskap: gemenskapsmedlemmar måste få något, och detta pris måste motsvara deltagarens bidrag.
Nästa steg för Embox var sökandet efter tredjepartsanvändare. Det är mycket viktigt att förstå att användare är fullvärdiga deltagare i opensource-gemenskapen. Det finns vanligtvis fler användare än utvecklare. Och för att vilja bli en bidragsgivare till ett projekt börjar de först använda det på ett eller annat sätt.
De första användarna av Embox var Institutionen för teoretisk cybernetik. De föreslog att skapa en alternativ firmware för Lego Mindstorm. Och även om dessa fortfarande var lokala användare (vi kunde träffa dem personligen och diskutera vad de ville). Men det var ändå en väldigt bra upplevelse. Vi tog till exempel fram demos som kunde visas för andra, eftersom robotar är roliga och väcker uppmärksamhet. Som ett resultat fick vi verkligt tredjepartsanvändare som började fråga vad Embox är och hur man använder det.
I det här skedet var vi tvungna att tänka på dokumentation, på kommunikationsmedel med användarna. Nej, visst, vi tänkte på dessa viktiga saker innan, men det var för tidigt och gav ingen positiv effekt. Effekten var ganska negativ. Låt mig ge dig ett par exempel. Vi använde googlecode, vars wiki stödde flerspråkighet. Vi skapade sidor på flera språk, inte bara engelska och ryska, där vi knappt kunde kommunicera, utan även tyska och spanska. Som ett resultat av det ser det väldigt löjligt ut när det frågas på dessa språk, men vi kan inte svara alls. Eller så införde de regler om att skriva dokumentation och kommentera, men eftersom API:et ändrades ganska ofta och påtagligt visade det sig att vår dokumentation var föråldrad och var mer missvisande än den hjälpte.
Som ett resultat ledde alla våra ansträngningar, även de felaktiga, till att externa användare dök upp. Och till och med en kommersiell kund dök upp som ville att en egen RTOS skulle utvecklas åt honom. Och vi utvecklade det för att vi har erfarenhet och en del grundarbete. Här behöver du prata om både de goda stunderna och de dåliga. Jag börjar med de dåliga. Eftersom många utvecklare var inblandade i detta projekt på kommersiell basis, var samhället redan ganska instabilt och splittrat, vilket naturligtvis inte kunde annat än påverka utvecklingen av projektet. En ytterligare faktor var att inriktningen för projektet bestämdes av en kommersiell kund, och hans mål var inte att vidareutveckla projektet. Detta var åtminstone inte huvudmålet.
Å andra sidan fanns det en rad positiva aspekter. Vi har verkligen tredjepartsanvändare. Det var inte bara kunden utan även de som detta system var avsett för. Motivationen att delta i projektet har ökat. När allt kommer omkring, om du också kan tjäna pengar på ett intressant företag är det alltid trevligt. Och viktigast av allt, vi hörde en önskan från kunder, som vid den tiden verkade galen för oss, men som nu är huvudidén med Embox, nämligen att använda redan utvecklad kod i systemet. Nu är huvudidén med Embox att använda Linux-programvara utan Linux. Det vill säga, den främsta positiva aspekten som bidrog till den fortsatta utvecklingen av projektet var insikten att projektet används av tredjepartsanvändare, och det borde lösa några av deras problem.
Vid den tiden hade Embox redan gått utanför ramarna för ett studentprojekt. Den främsta begränsande faktorn i utvecklingen av projektet enligt elevmodellen är deltagarnas motivation. Studenter deltar medan de studerar, och när de tar examen bör det finnas en annan motivation. Om motivationen inte dyker upp slutar eleven helt enkelt att delta i projektet. Om vi tar hänsyn till att studenter först behöver utbildas visar det sig att de blir bra specialister när de tar examen, men deras bidrag till projektet är, på grund av oerfarenhet, inte särskilt stort.
I allmänhet går vi smidigt vidare till huvudpunkten som gör att vi kan prata om att skapa ett opensource-projekt - att skapa en produkt som skulle lösa användarnas problem. Som jag förklarade ovan är huvudegenskapen för ett opensource-projekt dess community. Dessutom är communitymedlemmar i första hand användare. Men var kommer de ifrån när det inte finns något att använda? Så det visar sig att, precis som med ett icke-opensource-projekt, måste du fokusera på att skapa en MVP (minimum viable product), och om det intresserar användare, kommer en community att dyka upp runt projektet. Om du är engagerad i att skapa en gemenskap endast genom community-PR, skriva en wiki på alla världens språk eller rätta git-arbetsflödet på github, är det osannolikt att detta spelar någon roll i de tidiga stadierna av projektet. Naturligtvis, i de lämpliga stadierna är dessa inte bara viktiga, utan också nödvändiga saker.
Avslutningsvis vill jag påpeka , enligt min åsikt, återspeglar användarnas förväntningar från ett öppen källkodsprojekt:
Jag funderar allvarligt på att byta till detta OS (försök åtminstone. De driver det aktivt och gör coola saker).
PS På Vi kommer att ha så många som tre rapporter. En om öppen källkod och två om inbäddad (och en är praktisk). I montern kommer vi att genomföra en masterclass om programmering av mikrokontroller med hjälp av . Som vanligt tar vi med hårdvaran och låter dig programmera den. Det blir även ett uppdrag och andra aktiviteter. Kom till festivalen och vår monter, det ska bli kul.
Källa: will.com