Aquesta setmana se celebrarà un festival informàtic a Sant Petersburg . Un dels ponents serà Richard Stallman. també participa en el festival, i per descomptat no podem obviar el tema del programari lliure. Per això es diu un dels nostres informes . Estarà dedicat a la història del desenvolupament d'Embox com a projecte de codi obert. En aquest article vull parlar de les idees principals que, al meu entendre, influeixen en el desenvolupament de projectes de codi obert. L'article, com l'informe, es basa en l'experiència personal.
Comencem per una cosa senzilla, amb la definició del terme opensource. Evidentment, un projecte de codi obert és un projecte que té una de les llicències que permet accedir al codi font del projecte. A més, un projecte obert significa que els desenvolupadors de tercers poden fer canvis. És a dir, si alguna empresa o desenvolupador publica el codi del seu producte, parcial o totalment, això encara no converteix aquest producte en un projecte de codi obert. I, finalment, qualsevol activitat del projecte ha de donar lloc a algun tipus de resultat, i l'obertura del projecte implica que aquest resultat no només és utilitzat pels mateixos desenvolupadors.
No tocarem els problemes de les llicències obertes. Aquest és un tema massa gran i complex que requereix una investigació a fons. S'han escrit molts bons articles i materials sobre aquest tema. Però com que jo mateix no sóc un expert en l'àmbit dels drets d'autor, només diré que la llicència ha de complir els objectius del projecte. Per exemple, per a Embox l'elecció d'una llicència BSD en lloc d'una llicència GPL no va ser casual.
El fet que un projecte de codi obert hagi de proporcionar la capacitat de fer canvis i influir en el desenvolupament del projecte de codi obert implica que el projecte estigui distribuït. Gestionar-lo, mantenir la integritat i el rendiment és molt més difícil en comparació amb un projecte amb gestió centralitzada. Sorgeix una pregunta raonable: per què s'obren els projectes? La resposta es troba en l'àrea de la viabilitat comercial; per a una determinada classe de projectes, els beneficis d'aquest enfocament superen els costos. És a dir, no és adequat per a tots els projectes i un enfocament obert és generalment acceptable. Per exemple, és difícil imaginar-se desenvolupar un sistema de control per a una central elèctrica o un avió basat en un principi obert. No, és clar, aquests sistemes haurien d'incloure mòduls basats en projectes oberts, perquè això aportarà una sèrie d'avantatges. Però algú ha de ser responsable del producte final. Fins i tot si el sistema es basa completament en el codi de projectes oberts, el desenvolupador, després d'haver-ho empaquetat tot en un sol sistema i fet construccions i configuracions específiques, essencialment el tanca. El codi pot estar disponible públicament.
També hi ha molts avantatges per a aquests sistemes de crear o contribuir a projectes de codi obert. Com ja he dit, el codi del sistema final pot romandre disponible públicament. Per què, perquè és obvi que és poc probable que algú tingui el mateix avió per provar el sistema. Això és cert, però potser hi ha algú que vulgui comprovar determinades seccions del codi o, per exemple, algú pot descobrir que la biblioteca que s'utilitza no està configurada del tot correctament.
Un benefici encara més gran apareix si l'empresa assigna una part bàsica del sistema en un projecte independent. Per exemple, una biblioteca per donar suport a algun tipus de protocol d'intercanvi de dades. En aquest cas, encara que el protocol sigui específic d'una determinada àrea temàtica, podeu compartir els costos de manteniment d'aquesta peça del sistema amb altres empreses d'aquesta àrea. A més, els especialistes que poden estudiar aquesta peça del sistema en el domini públic requereixen molt menys temps per utilitzar-lo de manera eficaç. I, finalment, separar una peça en una entitat independent que utilitzen desenvolupadors de tercers ens permet millorar aquesta part, perquè hem d'oferir API efectives, crear documentació i ni tan sols parlo de millorar la cobertura de proves.
Una empresa pot rebre beneficis comercials sense crear projectes de codi obert; n'hi ha prou amb que els seus especialistes participin en projectes de tercers utilitzats a l'empresa. Al cap i a la fi, es mantenen tots els beneficis: els empleats coneixen millor el projecte, per tant l'utilitzen de manera més eficaç, l'empresa pot influir en la direcció del desenvolupament del projecte i l'ús de codi ja fet i depurat redueix òbviament els costos de l'empresa.
Els avantatges de crear projectes de codi obert no acaben aquí. Prenem un component tan important del negoci com el màrqueting. Per a ell, aquesta és una molt bona caixa de sorra que li permet avaluar eficaçment els requisits del mercat.
I, per descomptat, no hem d'oblidar que un projecte de codi obert és una manera eficaç de declarar-se portador de qualsevol especialització. En alguns casos, aquesta és l'única manera d'entrar al mercat. Per exemple, Embox va començar com un projecte per crear un RTOS. Probablement no cal explicar que hi ha molts competidors. Sense crear una comunitat, simplement no hauríem tingut prou recursos per portar el projecte a l'usuari final, és a dir, perquè els desenvolupadors de tercers comencin a utilitzar el projecte.
La comunitat és clau en un projecte de codi obert. Permet reduir significativament els costos de gestió del projecte, desenvolupar i donar suport al projecte. Podem dir que sense comunitat no hi ha cap projecte de codi obert.
S'ha escrit molt material sobre com crear i gestionar una comunitat de projectes de codi obert. Per no tornar a explicar fets ja coneguts, intentaré centrar-me en l'experiència d'Embox. Per exemple, el procés de creació d'una comunitat és un tema molt interessant. És a dir, molts expliquen com gestionar una comunitat existent, però de vegades es passen per alt els moments de la seva creació, considerant-ho un fet.
La regla principal quan es crea una comunitat de projectes de codi obert és que no hi ha regles. Vull dir que no hi ha regles universals, igual que no hi ha una bala de plata, encara que només sigui perquè els projectes són molt diferents. És poc probable que pugueu utilitzar les mateixes regles quan creeu una comunitat per a una biblioteca de registre js i algun controlador altament especialitzat. A més, en les diferents etapes de desenvolupament del projecte (i per tant de la comunitat), les regles canvien.
Embox va començar com un projecte d'estudiant perquè tenia accés als estudiants del departament de programació de sistemes. De fet, estàvem entrant a una altra comunitat. Podríem interessar als participants d'aquesta comunitat, estudiants, en les bones pràctiques industrials de la seva especialitat, treballs científics en l'àmbit de la programació de sistemes, cursos i diplomes. És a dir, hem seguit una de les normes bàsiques per organitzar una comunitat: els membres de la comunitat han de rebre alguna cosa, i aquest preu ha de correspondre a l'aportació del participant.
La següent etapa d'Embox va ser la recerca d'usuaris de tercers. És molt important entendre que els usuaris són participants plens de la comunitat de codi obert. Normalment hi ha més usuaris que desenvolupadors. I per voler ser col·laborador d'un projecte, primer comencen a utilitzar-lo d'una manera o altra.
Els primers usuaris d'Embox van ser el Departament de Cibernètica Teòrica. Van suggerir crear un firmware alternatiu per a Lego Mindstorm. I encara que aquests encara eren usuaris locals (podríem reunir-nos personalment amb ells i discutir què volien). Però tot i així va ser una molt bona experiència. Per exemple, hem desenvolupat demostracions que es podrien mostrar als altres, perquè els robots són divertits i criden l'atenció. Com a resultat, vam aconseguir usuaris realment de tercers que van començar a preguntar-se què és Embox i com utilitzar-lo.
En aquesta etapa, calia pensar en la documentació, en els mitjans de comunicació amb els usuaris. No, és clar, abans hem pensat en aquestes coses importants, però va ser prematur i no va donar cap efecte positiu. L'efecte va ser més aviat negatiu. Permeteu-me que us posi un parell d'exemples. Hem utilitzat googlecode, la wiki del qual admet el multilingüisme. Vam crear pàgines en diversos idiomes, no només anglès i rus, en les quals difícilment ens podíem comunicar, sinó també alemany i espanyol. Com a resultat, sembla molt ridícul quan es pregunta en aquests idiomes, però no podem respondre gens. O van introduir regles per escriure documentació i comentar, però com que l'API canviava força sovint i de manera significativa, va resultar que la nostra documentació estava obsoleta i era més enganyosa del que ajudava.
Com a resultat, tots els nostres esforços, fins i tot els equivocats, van provocar l'aparició d'usuaris externs. I fins i tot va aparèixer un client comercial que volia que es desenvolupés el seu propi RTOS. I l'hem desenvolupat perquè tenim experiència i una mica de base. Aquí cal parlar tant dels bons com dels dolents. Començaré pels dolents. Com que molts desenvolupadors estaven implicats en aquest projecte a nivell comercial, la comunitat ja era força inestable i dividida, cosa que, per descomptat, no podia menys que afectar el desenvolupament del projecte. Un factor addicional va ser que la direcció del projecte la va establir un client comercial, i el seu objectiu no era el desenvolupament posterior del projecte. Almenys aquest no era l'objectiu principal.
D'altra banda, hi havia una sèrie d'aspectes positius. Tenim usuaris realment de tercers. No només era el client, sinó també aquells als quals estava destinat aquest sistema. La motivació per participar en el projecte ha augmentat. Després de tot, si també pots guanyar diners amb un negoci interessant, sempre és agradable. I el més important, vam sentir un desig dels clients, que en aquell moment ens semblava una bogeria, però que ara és la idea principal d'Embox, és a dir, utilitzar codi ja desenvolupat al sistema. Ara la idea principal d'Embox és utilitzar programari Linux sense Linux. És a dir, el principal aspecte positiu que va contribuir al desenvolupament posterior del projecte va ser la constatació que el projecte és utilitzat per usuaris de tercers, i hauria de resoldre alguns dels seus problemes.
En aquell moment, Embox ja havia anat més enllà de l'àmbit d'un projecte d'estudiant. El principal factor limitant en el desenvolupament del projecte segons el model d'estudiant és la motivació dels participants. Els estudiants participen mentre estan estudiant, i quan es graduen, hi hauria d'haver una motivació diferent. Si la motivació no apareix, l'alumne simplement deixa de participar en el projecte. Si tenim en compte que primer s'ha de formar l'alumnat, resulta que en el moment de graduar-se esdevenen bons especialistes, però la seva aportació al projecte, per inexperiència, no és molt gran.
En general, passem sense problemes al punt principal que ens permet parlar de la creació d'un projecte de codi obert: crear un producte que resolgui els problemes dels seus usuaris. Com he explicat anteriorment, la propietat principal d'un projecte de codi obert és la seva comunitat. A més, els membres de la comunitat són principalment usuaris. Però d'on provenen quan no hi ha res a utilitzar? Així doncs, resulta que, igual que amb un projecte que no és de codi obert, cal centrar-se a crear un MVP (producte mínim viable) i, si interessa als usuaris, apareixerà una comunitat al voltant del projecte. Si us dediqueu a crear una comunitat només a través de les relacions públiques de la comunitat, escrivint una wiki en tots els idiomes del món o corregeix el flux de treball de git a github, és poc probable que això tingui importància en les primeres etapes del projecte. Per descomptat, en les etapes adequades, aquestes no només són coses importants, sinó també necessàries.
En conclusió m'agradaria destacar , al meu entendre, reflectint les expectatives dels usuaris d'un projecte de codi obert:
Estic pensant seriosament a canviar a aquest sistema operatiu (almenys prova-ho. Ho estan perseguint activament i fent coses interessants).
PS activat Tindrem fins a tres informes. Un sobre codi obert i dos sobre integrat (i un és pràctic). A l'estand realitzarem una classe magistral sobre programació de microcontroladors utilitzant . Com és habitual, portarem el maquinari i us deixarem programar. També hi haurà una missió i altres activitats. Vine al festival i al nostre estand, serà divertit.
Font: www.habr.com