Deze week vindt het IT-festival plaats in Sint-Petersburg. . Een van de sprekers is Richard Stallman. neemt ook deel aan het festival en natuurlijk konden we het onderwerp open source niet negeren. Daarom heet een van onze presentaties . Het zal gewijd zijn aan de geschiedenis van de ontwikkeling van Embox als open-source project. In dit artikel wil ik de belangrijkste ideeƫn delen die naar mijn mening van invloed zijn op de ontwikkeling van opensource-projecten. Het artikel, net als de presentatie, is gebaseerd op persoonlijke ervaring.
Laten we beginnen met het eenvoudige, met de definitie van de term opensource. Het is duidelijk dat een open-source project een project is dat een van de licenties heeft die toegang tot de sourcecode van het project biedt. Bovendien impliceert een open project de mogelijkheid voor externe ontwikkelaars om wijzigingen aan te brengen. Dat wil zeggen, als een bedrijf of ontwikkelaar de code van zijn product, gedeeltelijk of volledig, publiceert, maakt dit het product nog niet tot een opensource-project. En ten slotte moet elke projectactiviteit leiden tot een resultaat, waarbij de openheid van het project impliceert dat dit resultaat niet alleen door de ontwikkelaars wordt gebruikt.
We zullen de problemen van open licenties niet behandelen. Dit is een te groot en complex onderwerp dat diepgaand onderzoek vereist. Over dit onderwerp zijn veel goede artikelen en materialen geschreven. Maar aangezien ik zelf geen specialist ben op het gebied van auteursrecht, wil ik alleen zeggen dat de licentie moet voldoen aan de doelstellingen van het project. Bijvoorbeeld, voor Embox was de keuze voor een BSD-licentie in plaats van een GPL-licentie niet toevallig.
Het feit dat een open project de mogelijkheid moet bieden om wijzigingen aan te brengen en invloed uit te oefenen op de ontwikkeling van het project, impliceert dat het project gedistribueerd is. Het beheren ervan, en het waarborgen van de integriteit en functionaliteit is veel complexer in vergelijking met een project met gecentraliseerd beheer. Dit roept de terechte vraag op waarom open projecten Ć¼berhaupt worden opgezet. Het antwoord ligt in de commerciĆ«le haalbaarheid; voor een bepaalde klasse projecten weegt het voordeel van deze benadering zwaarder dan de kosten. Met andere woorden, niet voor alle projecten is de open benadering geschikt of zelfs aanvaardbaar. Het is moeilijk voor te stellen dat de ontwikkeling van een systeem voor het beheer van een elektriciteitscentrale of een vliegtuig gebaseerd kan zijn op het open principe. Ja, bepaalde modules van dergelijke systemen moeten gebaseerd zijn op open projecten, omdat dit verschillende voordelen oplevert. Maar iemand moet verantwoordelijk zijn voor het eindproduct. Zelfs als het systeem volledig is gebaseerd op de code van open projecten, sluit de ontwikkelaar het in feite af door alles in Ć©Ć©n systeem te verpakken en specifieke builds en instellingen te maken. De code kan daarbij publiekelijk toegankelijk blijven.
Voor deze systemen zijn er ook tal van voordelen verbonden aan het creƫren van open projecten of deelname eraan. Zoals ik al zei, kan de code van het eindproduct publiekelijk toegankelijk blijven. Maar waarom? Het is toch duidelijk dat er waarschijnlijk niemand is die hetzelfde vliegtuig heeft om het systeem te testen. Dat klopt, maar er kan zomaar iemand zijn die bepaalde stukjes code wil controleren, of iemand kan ontdekken dat de gebruikte bibliotheek niet helemaal correct is geconfigureerd.
Er ontstaat nog meer voordeel wanneer een bedrijf een deel van het systeem als een apart project aanmerkt. Bijvoorbeeld, een bibliotheek ter ondersteuning van een bepaald gegevensuitwisselingsprotocol. In dit geval, zelfs als het protocol specifiek is voor een bepaald vakgebied, kunnen de kosten voor het onderhouden van dit systeemgedeelte worden gedeeld met andere bedrijven in dat gebied. Bovendien hebben specialisten die deze systeemcomponent openbaar kunnen bestuderen, veel minder tijd nodig voor een effectieve implementatie. Ten slotte maakt het scheiden van een component in een zelfstandige entiteit, die door externe ontwikkelaars wordt gebruikt, deze component kwalitatief beter, omdat er effectieve API's moeten worden aangeboden, documentatie moet worden geschreven en ik zeg zelfs niet dat het testcoverage moet worden verbeterd.
Een bedrijf kan commerciƫle voordelen behalen zonder open projecten te creƫren; het is voldoende dat zijn specialisten deelnemen aan externe projecten die in het bedrijf worden toegepast. Immers, alle voordelen blijven behouden: medewerkers kennen het project beter, wat hun efficiƫntie verhoogt, het bedrijf kan invloed uitoefenen op de ontwikkeling van het project en het gebruik van goed werkende code verkort duidelijk de kosten voor het bedrijf.
De voordelen van het creƫren van opensource-projecten eindigen hier niet. Laten we een zo belangrijke bedrijfscomponent als marketing nemen. Voor marketing is dit een uitstekende sandbox die helpt bij het effectief beoordelen van de marktvereisten.
En uiteraard moet niet worden vergeten dat een opensource-project een effectieve manier is om jezelf te profileren als iemand met een bepaalde specialisatie. In sommige gevallen is dit zelfs de enige weg om de markt te betreden. Bijvoorbeeld, Embox begon als een project voor het creƫren van een OSRV. Vermoedelijk is het niet nodig uit te leggen dat er tal van concurrenten zijn. Zonder de oprichting van een gemeenschap zouden we eenvoudigweg niet de middelen hebben gehad om het project bij de eindgebruiker te brengen, dat wil zeggen, zodat externe ontwikkelaars het project zouden gaan gebruiken.
De gemeenschap is essentieel voor een opensource-project. Het maakt een aanzienlijke verlaging van de projectbeheerkosten mogelijk, ontwikkelt en ondersteunt het project. Men kan stellen dat zonder een gemeenschap er eigenlijk geen opensource-project is.
Er is veel geschreven over hoe je een community voor een open-sourceproject kunt creƫren en beheren. Om al bekende feiten niet te herhalen, zal ik me richten op de ervaringen van Embox. Een interessant aspect is bijvoorbeeld het proces van het creƫren van een community. Veel mensen vertellen hoe je een bestaande community kunt beheren, maar de momenten van creatie worden vaak over het hoofd gezien, alsof het een gegeven is.
De belangrijkste regel bij het creƫren van een community voor een open-source project is: er zijn geen regels. Wat ik bedoel is dat er geen universele regels bestaan, net zoals er geen zilveren kogel is, vooral omdat de projecten heel verschillend zijn. Je kunt moeilijk dezelfde regels gebruiken bij het creƫren van een community voor een logging-bibliotheek in js en een gespecialiseerde driver. Bovendien veranderen de regels naarmate het project (en dus ook de community) zich ontwikkelt.
Embox begon als een studentenproject, omdat we toegang hadden tot studenten van de afdeling systeemprogrammering. In wezen sloten we ons aan bij een andere community. We konden de deelnemers van deze community, de studenten, interesseren met goede industriƫle praktijkervaring in hun vakgebied, wetenschappelijke papers op het gebied van systeemprogrammering, en cursus- en afstudeerprojecten. We voldeden dus aan een van de belangrijkste regels voor het organiseren van een community: communityleden moeten iets kunnen krijgen, en de prijs moet in verhouding staan tot de bijdrage van de deelnemer.
De volgende fase voor Embox was het zoeken naar externe gebruikers. Het is heel belangrijk om te begrijpen dat gebruikers volwaardige leden zijn van een open-source community. Meestal zijn er meer gebruikers dan ontwikkelaars. En om een bijdrage aan het project te willen leveren, moeten ze het eerst op de een of andere manier gaan gebruiken.
De eerste gebruikers van Embox waren de afdeling Theoretische Cybernetica. Zij stelden voor om een alternatieve firmware voor Lego Mindstorm te creƫren. En hoewel het nog steeds lokale gebruikers waren (we konden hen persoonlijk ontmoeten en bespreken wat ze wilden), was het toch een zeer goede ervaring. We ontwikkelden bijvoorbeeld demo's die we aan anderen konden tonen, want robots zijn leuk en trekken de aandacht. Uiteindelijk kregen we echt externe gebruikers die vroegen wat Embox was en hoe ze het konden gebruiken.
In deze fase moesten we nadenken over documentatie en communicatiemiddelen met de gebruikers. Natuurlijk dachten we eerder al over deze belangrijke zaken na, maar het was prematuur en had geen positief effect. Het effect was eerder negatief. Laat me een paar voorbeelden geven. We gebruikten Googlecode, waarvan de wiki meertaligheid ondersteunde. We creĆ«erden pagina's in verschillende talen, niet alleen Engels en Russisch, waarmee we enigszins konden communiceren, maar ook Duits en Spaans. Het was erg gĆŖnant toen iemand in deze talen vroeg, maar we niet konden antwoorden. Of we stelden regels in voor het schrijven van documentatie en commentaar, maar omdat de API vrij vaak en ingrijpend veranderde, verouderde onze documentatie en leidde meer tot verwarring dan dat het hielp.
Uiteindelijk leidden al onze inspanningen, zelfs de onjuiste, ertoe dat we externe gebruikers kregen. Er kwam zelfs een commerciƫle opdrachtgever die wilde dat we een eigen OSR ontwikkelden. We ontwikkelden het omdat we ervaring en enkele ontwikkelingen hadden. Hier moet ik zowel de goede als de slechte momenten vertellen. Ik begin met de slechte. Aangezien veel ontwikkelaars aan dit project op commerciƫle basis waren betrokken, was de gemeenschap, die al vrij instabiel was, verdeeld, wat natuurlijk gevolgen had voor de ontwikkeling van het project. Een bijkomende factor was dat de richting van het project werd bepaald door ƩƩn commerciƫle opdrachtgever, wiens doel niet de verdere ontwikkeling van het project was. Althans, dat doel was niet de prioriteit.
Aan de andere kant waren er een aantal positieve punten. We kregen echt externe gebruikers. Dit waren niet alleen klanten, maar ook degenen voor wie dit systeem bedoeld was. De motivatie om deel te nemen aan het project steeg. Want als je met iets interessants bezig bent en daar ook nog eens geld mee kunt verdienen, is dat altijd leuk. En het belangrijkste is dat we een wens van de klanten hoorden, die op dat moment voor ons absurd leek, maar die nu de kernidee van Embox vormt, namelijk het gebruik van al geschreven code in het systeem. Tegenwoordig is de kernidee van Embox het gebruik van Linux-software zonder Linux. Het belangrijkste positieve aspect dat de verdere ontwikkeling van het project bevorderde, was het besef dat het project door externe gebruikers wordt gebruikt en dat het hun problemen moet oplossen.
Op dat moment was Embox al buiten de grenzen van een studentenproject gegaan. De belangrijkste beperkende factor voor de ontwikkeling van het project volgens het studentenmodel is de motivatie van de deelnemers. Studenten nemen deel terwijl ze studeren, maar wanneer ze afstuderen, moet er een andere motivatie verschijnen. Als die motivatie er niet is, stopt de student eenvoudigweg met het deelnemen aan het project. Houdt men er rekening mee dat studenten eerst moeten worden opgeleid, dan worden ze goede specialisten tegen de tijd van hun afstuderen, maar de bijdrage aan het project is, vanwege gebrek aan ervaring, niet erg groot.
In feite komen we geleidelijk aan het belangrijkste punt dat het mogelijk maakt om over de oprichting van een opensource-project te spreken, namelijk het creƫren van een product dat de problemen van zijn gebruikers oplost. Zoals ik hierboven al uitlegde, is de belangrijkste eigenschap van een opensource-project de gemeenschap ervan. En de deelnemers van de gemeenschap zijn in de eerste plaats gebruikers. Maar waar moeten ze vandaan komen als er nog niets is om te gebruiken? Het blijkt dat, net als bij een niet-opensourceproject, we ons moeten concentreren op het creƫren van een MVP (minimaal levensvatbaar product), en als dat de gebruikers interesseert, zal er een gemeenschap rond het project verschijnen. Als we echter alleen proberen een gemeenschap te creƫren door middel van PR, het schrijven van wiki's in alle talen van de wereld, of een goede git-workflow op GitHub, zal dat waarschijnlijk geen impact hebben in de vroege stadia van het project. Natuurlijk zijn dat op de juiste momenten niet alleen belangrijke, maar ook noodzakelijke zaken.
Tot slot wil ik... , naar mijn mening weerspiegelt het de verwachtingen van de gebruiker van een opensource-project:
Ik overweeg serieus om over te stappen naar dit besturingssysteem (of in ieder geval het te proberen. Het wordt behoorlijk actief ontwikkeld met geweldige functies).
P. S. Op hebben we maar liefst drie lezingen. EĆ©n over open source en twee over embedded (waarvan Ć©Ć©n praktisch). Op de stand zullen we een masterclass geven over het programmeren van microcontrollers met behulp van . Traditioneel brengen we hardware mee en laten we deze programmeren. Er komt ook een quest en andere activiteiten. Kom naar het festival en naar onze stand, het wordt leuk.
Bron: habr.com
