Deze week wordt er een IT-festival gehouden in Sint-Petersburg . Eén van de sprekers zal Richard Stallman zijn. neemt ook deel aan het festival, en natuurlijk konden we het onderwerp vrije software niet negeren. Daarom wordt een van onze rapporten gebeld . Het zal gewijd zijn aan de geschiedenis van de ontwikkeling van Embox als open source-project. In dit artikel wil ik het hebben over de belangrijkste ideeën die naar mijn mening de ontwikkeling van opensource-projecten beïnvloeden. Het artikel is, net als het rapport, gebaseerd op persoonlijke ervaringen.
Laten we beginnen met iets simpels, met de definitie van de term opensource. Uiteraard is een open source-project een project dat een van de licenties heeft die toegang geeft tot de broncode van het project. Bovendien betekent een open project dat externe ontwikkelaars wijzigingen kunnen aanbrengen. Dat wil zeggen: als een bedrijf of ontwikkelaar de code van zijn product geheel of gedeeltelijk publiceert, betekent dit nog niet dat dit product een open source-project is. En ten slotte moet elke projectactiviteit tot een bepaald resultaat leiden, en de openheid van het project impliceert dat dit resultaat niet alleen door de ontwikkelaars zelf wordt gebruikt.
We zullen niet ingaan op de problemen van open licenties. Dit is een te groot en complex onderwerp dat diepgaand onderzoek vereist. Er zijn heel wat goede artikelen en materialen over dit onderwerp geschreven. Maar aangezien ik zelf geen expert ben op het gebied van auteursrecht, zal ik alleen zeggen dat de licentie moet voldoen aan de doelstellingen van het project. Voor Embox was de keuze voor een BSD in plaats van een GPL-licentie bijvoorbeeld niet toevallig.
Het feit dat een open source-project de mogelijkheid moet bieden om veranderingen aan te brengen en de ontwikkeling van het open source-project te beïnvloeden, impliceert dat het project wordt gedistribueerd. Het beheren ervan, het behouden van de integriteit en de prestaties is veel moeilijker vergeleken met een project met gecentraliseerd beheer. Er rijst een redelijke vraag: waarom open je überhaupt projecten? Het antwoord ligt op het gebied van de commerciële haalbaarheid; voor een bepaalde categorie projecten wegen de voordelen van deze aanpak zwaarder dan de kosten. Dat wil zeggen dat het niet voor alle projecten geschikt is en dat een open benadering over het algemeen aanvaardbaar is. Het is bijvoorbeeld moeilijk voor te stellen dat je een besturingssysteem voor een elektriciteitscentrale of een vliegtuig zou ontwikkelen op basis van een open principe. Nee, dergelijke systemen moeten natuurlijk modules bevatten die zijn gebaseerd op open projecten, omdat dit een aantal voordelen biedt. Maar iemand moet verantwoordelijk zijn voor het eindproduct. Zelfs als het systeem volledig gebaseerd is op de code van open projecten, sluit de ontwikkelaar, nadat hij alles in één systeem heeft verpakt en specifieke builds en instellingen heeft gemaakt, het in wezen. De code is mogelijk openbaar beschikbaar.
Er zijn ook veel voordelen voor deze systemen verbonden aan het creëren van of bijdragen aan open source-projecten. Zoals ik al zei, kan de eindsysteemcode openbaar beschikbaar blijven. Waarom, omdat het duidelijk is dat het onwaarschijnlijk is dat iemand hetzelfde vliegtuig zal hebben om het systeem te testen. Dat klopt, maar het kan zijn dat er iemand is die bepaalde delen van de code wil controleren, of dat iemand bijvoorbeeld ontdekt dat de gebruikte bibliotheek niet helemaal correct is geconfigureerd.
Een nog groter voordeel ontstaat als het bedrijf een basisonderdeel van het systeem in een afzonderlijk project onderbrengt. Bijvoorbeeld een bibliotheek die een soort gegevensuitwisselingsprotocol ondersteunt. In dit geval kunt u, zelfs als het protocol specifiek is voor een bepaald vakgebied, de kosten voor het onderhoud van dit onderdeel van het systeem delen met andere bedrijven uit dit gebied. Bovendien hebben specialisten die dit deel van het systeem in het publieke domein kunnen bestuderen veel minder tijd nodig om het effectief te gebruiken. En tenslotte stelt het opsplitsen van een onderdeel in een onafhankelijke entiteit die externe ontwikkelaars gebruiken ons in staat dit onderdeel te verbeteren, omdat we effectieve API's moeten aanbieden, documentatie moeten creëren, en dan heb ik het niet eens over het verbeteren van de testdekking.
Een bedrijf kan commerciële voordelen ontvangen zonder open-sourceprojecten te creëren; het is voldoende dat zijn specialisten deelnemen aan projecten van derden die in het bedrijf worden gebruikt. Alle voordelen blijven immers behouden: werknemers kennen het project beter en gebruiken het daarom effectiever, het bedrijf kan de richting van de ontwikkeling van het project beïnvloeden en het gebruik van kant-en-klare, foutopsporingscode verlaagt uiteraard de kosten van het bedrijf.
De voordelen van het creëren van opensource-projecten houden daar niet op. Laten we een zo belangrijk onderdeel van het bedrijfsleven als marketing nemen. Voor hem is dit een zeer goede sandbox waarmee hij de marktvereisten effectief kan evalueren.
En we mogen natuurlijk niet vergeten dat een opensource-project een effectieve manier is om jezelf als drager van welke specialisatie dan ook te bestempelen. In sommige gevallen is dit de enige manier om de markt te betreden. Embox begon bijvoorbeeld als een project om een RTOS te maken. Het is waarschijnlijk niet nodig om uit te leggen dat er veel concurrenten zijn. Zonder het creëren van een community zouden we eenvoudigweg niet genoeg middelen hebben gehad om het project naar de eindgebruiker te brengen, dat wil zeggen om externe ontwikkelaars het project te laten gebruiken.
De gemeenschap is de sleutel in een opensourceproject. Hiermee kunt u de projectmanagementkosten aanzienlijk verlagen, het project ontwikkelen en ondersteunen. We kunnen zeggen dat er zonder gemeenschap helemaal geen open source-project is.
Er is veel materiaal geschreven over het creëren en beheren van een open source projectgemeenschap. Om reeds bekende feiten niet opnieuw te vertellen, zal ik proberen me te concentreren op de ervaring van Embox. Het proces van het creëren van een gemeenschap is bijvoorbeeld een zeer interessante kwestie. Dat wil zeggen dat velen vertellen hoe ze een bestaande gemeenschap moeten beheren, maar de momenten van de oprichting ervan worden soms over het hoofd gezien, omdat ze dit als een gegeven beschouwen.
De hoofdregel bij het creëren van een opensource-projectgemeenschap is dat er geen regels zijn. Ik bedoel dat er geen universele regels zijn, net zoals er geen wondermiddel bestaat, al was het maar omdat de projecten heel verschillend zijn. Het is onwaarschijnlijk dat u dezelfde regels kunt gebruiken bij het maken van een community voor een js-logboekbibliotheek en een zeer gespecialiseerd stuurprogramma. Bovendien veranderen de regels in verschillende stadia van de ontwikkeling van het project (en dus van de gemeenschap).
Embox begon als een studentenproject omdat het toegang had tot studenten van de afdeling systeemprogrammering. In feite betreden we een andere gemeenschap. We zouden de deelnemers van deze gemeenschap, studenten, kunnen interesseren voor goede industriële praktijken in hun specialiteit, wetenschappelijk werk op het gebied van systeemprogrammering, cursussen en diploma's. Dat wil zeggen, we volgden een van de basisregels voor het organiseren van een community: communityleden moeten iets ontvangen, en deze prijs moet overeenkomen met de bijdrage van de deelnemer.
De volgende fase voor Embox was de zoektocht naar externe gebruikers. Het is heel belangrijk om te begrijpen dat gebruikers volwaardige deelnemers zijn aan de opensource-gemeenschap. Er zijn meestal meer gebruikers dan ontwikkelaars. En om een bijdrager aan een project te willen worden, beginnen ze het eerst op de een of andere manier te gebruiken.
De eerste gebruikers van Embox waren de afdeling Theoretische Cybernetica. Ze stelden voor om een alternatieve firmware voor Lego Mindstorm te maken. En hoewel dit nog steeds lokale gebruikers waren (we konden ze persoonlijk ontmoeten en bespreken wat ze wilden). Maar het was nog steeds een heel goede ervaring. Zo ontwikkelden we demo’s die aan anderen getoond konden worden, omdat robots leuk zijn en de aandacht trekken. Als gevolg hiervan kregen we echte externe gebruikers die zich begonnen af te vragen wat Embox is en hoe het te gebruiken.
In dit stadium moesten we nadenken over documentatie, over communicatiemiddelen met gebruikers. Nee, natuurlijk hebben we al eerder over deze belangrijke dingen nagedacht, maar het was voorbarig en had geen positief effect. Het effect was eerder negatief. Ik zal u een paar voorbeelden geven. We gebruikten googlecode, waarvan de wiki meertaligheid ondersteunde. We hebben pagina's gemaakt in verschillende talen, niet alleen Engels en Russisch, waarin we nauwelijks konden communiceren, maar ook Duits en Spaans. Als gevolg hiervan ziet het er erg belachelijk uit als het in deze talen wordt gevraagd, maar we kunnen helemaal niet antwoorden. Of ze introduceerden regels over het schrijven van documentatie en het plaatsen van commentaar, maar omdat de API vrij vaak en aanzienlijk veranderde, bleek dat onze documentatie verouderd was en eerder misleidend was dan dat het hielp.
Als gevolg hiervan hebben al onze inspanningen, zelfs de verkeerde, geleid tot de verschijning van externe gebruikers. En er verscheen zelfs een commerciële klant die wilde dat zijn eigen RTOS voor hem werd ontwikkeld. En we hebben het ontwikkeld omdat we ervaring en wat basiswerk hebben. Hier moet je praten over zowel de goede als de slechte momenten. Ik zal beginnen met de slechte. Omdat veel ontwikkelaars op commerciële basis bij dit project betrokken waren, was de gemeenschap al behoorlijk onstabiel en verdeeld, wat natuurlijk niet anders dan de ontwikkeling van het project kon beïnvloeden. Daarbij speelde mee dat de richting van het project werd bepaald door één commerciële klant, en zijn doel niet de verdere ontwikkeling van het project was. Dit was in ieder geval niet het hoofddoel.
Aan de andere kant waren er ook een aantal positieve aspecten. We hebben echt externe gebruikers. Het was niet alleen de klant, maar ook degene voor wie dit systeem bedoeld was. De motivatie om mee te doen aan het project is toegenomen. Als je dan ook nog eens geld kunt verdienen aan een interessant bedrijf, is dat altijd leuk. En het allerbelangrijkste: we hoorden één wens van klanten, die ons destijds gek leek, maar die nu het hoofdidee van Embox is, namelijk om reeds ontwikkelde code in het systeem te gebruiken. Het belangrijkste idee van Embox is nu om Linux-software te gebruiken zonder Linux. Dat wil zeggen, het belangrijkste positieve aspect dat heeft bijgedragen aan de verdere ontwikkeling van het project was het besef dat het project wordt gebruikt door externe gebruikers en dat het een aantal van hun problemen zou moeten oplossen.
Op dat moment was Embox al verder gegaan dan een studentenproject. De belangrijkste beperkende factor bij de ontwikkeling van het project volgens het studentenmodel is de motivatie van de deelnemers. Studenten doen mee terwijl ze studeren en als ze afstuderen, moet er een andere motivatie zijn. Als de motivatie niet verschijnt, stopt de student eenvoudigweg met deelname aan het project. Als we er rekening mee houden dat studenten eerst moeten worden opgeleid, blijken ze tegen de tijd dat ze afstuderen goede specialisten te zijn, maar hun bijdrage aan het project is door onervarenheid niet erg groot.
Over het algemeen gaan we soepel verder naar het belangrijkste punt dat ons in staat stelt te praten over het creëren van een opensource-project: het creëren van een product dat de problemen van zijn gebruikers zou oplossen. Zoals ik hierboven heb uitgelegd, is de gemeenschap de belangrijkste eigenschap van een opensourceproject. Bovendien zijn communityleden in de eerste plaats gebruikers. Maar waar komen ze vandaan als er niets te gebruiken is? Het blijkt dus dat je, net als bij een niet-opensource-project, je moet concentreren op het creëren van een MVP (minimaal levensvatbaar product), en als het gebruikers interesseert, zal er een community rond het project verschijnen. Als je alleen bezig bent met het creëren van een community via community PR, het schrijven van een wiki in alle talen van de wereld, of het corrigeren van de git-workflow op github, dan is het onwaarschijnlijk dat dit er in de vroege stadia van het project toe doet. Natuurlijk zijn dit in de juiste fasen niet alleen belangrijke, maar ook noodzakelijke dingen.
Tot slot wil ik erop wijzen , naar mijn mening, als weerspiegeling van de verwachtingen van de gebruiker van een opensource-project:
Ik denk er serieus over na om naar dit besturingssysteem over te stappen (probeer het tenminste. Ze streven er actief naar en doen coole dingen).
PS Aan We zullen maar liefst drie rapporten hebben. Eén over open source en twee over embedded (en één is praktisch). Op de stand zullen we een masterclass geven over het programmeren van microcontrollers met behulp van . Zoals gewoonlijk brengen wij de hardware mee en laten wij deze door jou programmeren. Ook zal er een speurtocht en andere activiteiten plaatsvinden. Kom naar het festival en onze stand, het wordt gezellig.
Bron: www.habr.com