Questa settimana si svolgerà un festival IT a San Pietroburgo . Uno dei relatori sarà Richard Stallman. partecipa anche al festival, e ovviamente non potevamo ignorare il tema del software libero. Pertanto, una delle nostre presentazioni si chiama . Essa sarà dedicata alla storia dello sviluppo di Embox come progetto open source. In questo articolo voglio parlare delle idee principali che, a mio avviso, influenzano lo sviluppo dei progetti open source. L'articolo, come la presentazione, è basato sull'esperienza personale.
Iniziamo con il semplice compito di definire il termine open source. È evidente che un progetto open source è un progetto che utilizza una delle licenze che consentono l'accesso al codice sorgente del progetto. Inoltre, un progetto aperto implica la possibilità di apportare modifiche da parte di sviluppatori esterni. Quindi, se una qualche azienda o sviluppatore pubblica il codice del proprio prodotto, in tutto o in parte, ciò non rende automaticamente quel prodotto un progetto open source. Infine, ogni attività di progetto deve portare a un certo risultato, e l'apertura del progetto implica che tale risultato sia utilizzato non solo dagli sviluppatori stessi.
Non toccheremo le problematiche delle licenze aperte. È un argomento troppo ampio e complesso che richiede un'analisi approfondita. Sono stati scritti molti buoni articoli e materiali su questo tema. Tuttavia, poiché non sono un esperto in diritto d'autore, dirò solo che la licenza deve rispondere agli obiettivi del progetto. Ad esempio, per Embox, la scelta della licenza BSD piuttosto che GPL non è stata casuale.
Il fatto che un progetto open source debba consentire modifiche e influenzare lo sviluppo del progetto stesso implica che il progetto sia distribuito. Gestirlo, mantenere la sua integrità e funzionalità è molto più complesso rispetto a un progetto con gestione centralizzata. Nasce quindi la legittima domanda sul perché realizzare progetti open source. La risposta risiede nella fattibilità commerciale: per una certa classe di progetti, i benefici di questo approccio superano i costi. Questo significa che non tutti i progetti possono adottare un approccio aperto. Ad esempio, è difficile immaginare lo sviluppo di un sistema di gestione di una centrale elettrica o di un aeroplano basato su principi aperti. Certamente, è importante integrare moduli basati su progetti open source in tali sistemi, poiché questo porta diversi vantaggi. Tuttavia, qualcuno deve assumere la responsabilità per il prodotto finale. Anche se il sistema si basa completamente su codice open source, il sviluppatore, imballando tutto in un'unica soluzione e creando specifiche build e configurazioni, di fatto lo chiude. Il codice può rimanere accessibile al pubblico.
Questi sistemi offrono anche un sacco di vantaggi dalla creazione di progetti open source o dalla partecipazione a essi. Come ho già detto, il codice del sistema finale può rimanere pubblico. Perché? È chiaro che è difficile trovare qualcuno con lo stesso aereo per testare il sistema. È vero, ma potrebbe anche esserci qualcuno disposto a controllare singole parti del codice, oppure, ad esempio, qualcuno potrebbe scoprire che la libreria utilizzata non è configurata correttamente.
Un ulteriore vantaggio emerge quando un'azienda dedica una parte fondamentale del sistema a un progetto separato. Ad esempio, una libreria per il supporto di un certo protocollo di scambio dati. In questo caso, anche se il protocollo è specifico per un particolare ambito, è possibile suddividere i costi di mantenimento di questa parte del sistema con altre aziende nel settore. Inoltre, agli esperti che possono studiare questa parte del sistema in accesso aperto serve molto meno tempo per utilizzarla in modo efficace. Infine, trasformare una parte in un'entità autonoma, utilizzata da sviluppatori esterni, consente di migliorare la qualità di questa sezione, poiché è necessario offrire API efficaci, redigere documentazione e, non parlo nemmeno dell'importanza di migliorare la copertura dei test.
Un'azienda può ottenere vantaggi commerciali anche senza creare progetti open source; è sufficiente che i propri specialisti partecipino a progetti esterni utilizzati in azienda. Infatti, i benefici rimangono: i dipendenti conoscono meglio il progetto, quindi lo utilizzano in modo più efficace, e l'azienda può influenzare la direzione dello sviluppo del progetto. Inoltre, l'uso di codice già testato ovviamente riduce i costi dell'azienda.
Ma i vantaggi di creare progetti open source non finiscono qui. Prendiamo un aspetto importante del business come il marketing. Per questo, è un'ottima arena per valutare in modo efficace le esigenze del mercato.
E naturalmente, non bisogna dimenticare che un progetto open source è un modo efficace per affermarsi come portatore di una certa specializzazione. In alcuni casi, può essere addirittura l'unico modo per entrare nel mercato. Ad esempio, Embox è iniziato come un progetto per la creazione di un sistema operativo real-time. Probabilmente non è necessario spiegare che esistono molte concorrenti. Senza la creazione di una comunità, non avremmo semplicemente avuto le risorse per portare il progetto all'utente finale, cioè per far sì che il progetto fosse utilizzato da sviluppatori esterni.
La comunità è fondamentale in un progetto open source. Essa consente di ridurre significativamente i costi di gestione del progetto e favorisce lo sviluppo e il supporto del progetto stesso. Si può dire che senza comunità non esisterebbe affatto un progetto open source.
Ci sono numerosi materiali su come creare e gestire una comunità per un progetto open source. Io, per non ripetere fatti già noti, cercherò di mettere l'accento sull'esperienza di Embox. Ad esempio, una questione molto interessante è il processo di creazione della comunità. Molti parlano di come gestire una comunità esistente, ma spesso tralasciano i momenti di creazione, considerando ciò un dato di fatto.
La regola principale nella creazione di una comunità di un progetto open source è che non ci sono regole. Intendo dire che non esistono regole universali, così come non esiste una soluzione miracolosa, soprattutto perché i progetti sono molto diversi tra loro. È difficile applicare le stesse regole per creare una comunità per una libreria di logging in js e un driver altamente specializzato. Inoltre, le regole cambiano in base alle diverse fasi di sviluppo del progetto (e di conseguenza della comunità).
Embox è iniziato come un progetto universitario, poiché avevamo accesso agli studenti del dipartimento di programmazione di sistema. In effetti, ci stavamo inserendo in un altro tipo di comunità. Potevamo interessare i membri di questa comunità, ovvero gli studenti, con opportunità di buone pratiche industriali nella loro specializzazione, lavori scientifici nel campo della programmazione di sistema, tesi e progetti di fine corso. In altre parole, seguivamo una delle regole fondamentali per organizzare una comunità: i membri devono ricevere qualcosa, e questo valore deve corrispondere al contributo del partecipante.
La fase successiva per Embox è stata la ricerca di utenti esterni. È molto importante capire che gli utenti sono partecipanti attivi della comunità open source. Di solito, ci sono più utenti che sviluppatori. E per voler diventare un contributore del progetto, è fondamentale prima utilizzarlo in qualche modo.
I primi utenti di Embox sono stati il dipartimento di Cibernetica Teorica. Hanno proposto di creare un firmware alternativo per Lego Mindstorm. Anche se si trattava ancora di utenti locali (potevamo incontrarli di persona e discutere di cosa volessero), è stata comunque un'ottima esperienza. Ad esempio, abbiamo sviluppato delle demo che potevano essere mostrate ad altri, perché i robot sono divertenti e attirano l'attenzione. Alla fine, abbiamo ottenuto veri utenti esterni che hanno iniziato a chiedere cos'è Embox e come usarlo.
In questa fase, abbiamo dovuto riflettere sulla documentazione e sui mezzi di comunicazione con gli utenti. Certo, avevamo già considerato queste questioni importanti in passato, ma era prematuro e non portava a risultati positivi. L'effetto era piuttosto negativo. Faccio un paio di esempi. Utilizzavamo Google Code, il cui wiki supportava il multilinguismo. Abbiamo creato pagine in diverse lingue, non solo in inglese e russo, in cui riuscivamo a comunicare a fatica, ma anche in tedesco e spagnolo. Risultava molto ridicolo quando venivano fatte domande in queste lingue, ma noi non sapevamo rispondere affatto. Abbiamo anche introdotto regole per la scrittura della documentazione e la commentazione, ma poiché l'API cambiava abbastanza spesso e in modo sostanziale, la nostra documentazione finiva per diventare obsoleta, ingannando più che aiutando.
Alla fine, tutti i nostri sforzi, anche quelli sbagliati, hanno portato all'emergere di utenti esterni. E persino è emerso un cliente commerciale che desiderava sviluppare un proprio sistema operativo personalizzato. E lo abbiamo fatto, poiché abbiamo esperienza e alcune soluzioni già pronte. Qui è necessario parlare sia dei lati positivi che di quelli negativi. Inizierò dai lati negativi. Poiché molti sviluppatori sono stati coinvolti in questo progetto su base commerciale, la comunità è diventata piuttosto instabile e divisa, il che, ovviamente, ha avuto un impatto sullo sviluppo del progetto. Un ulteriore fattore è stato che la direzione del progetto era determinata da un unico cliente commerciale, il cui obiettivo non era la continua evoluzione del progetto. Almeno, questo obiettivo non era prioritario.
D'altra parte, ci sono stati diversi aspetti positivi. Abbiamo coinvolto realmente utenti esterni. Non solo i committenti, ma anche coloro per cui il sistema era destinato. La motivazione a partecipare al progetto è aumentata. Infatti, se puoi guadagnare facendo qualcosa di interessante, è sempre un valore aggiunto. E soprattutto, abbiamo ascoltato un desiderio dei committenti che in quel momento ci sembrava strano, ma che ora è diventato il concetto centrale di Embox: utilizzare codice già sviluppato nel sistema. Attualmente, l'idea principale di Embox è utilizzare software Linux senza l'effettivo Linux. Cioè, il principale aspetto positivo che ha contribuito allo sviluppo futuro del progetto è stato il riconoscimento che il progetto è utilizzato da utenti esterni e deve risolvere alcuni dei loro problemi.
A quel punto, Embox era già andato oltre il progetto studentesco. Il principale fattore limitante dello sviluppo del progetto secondo il modello studentesco è la motivazione dei partecipanti. Gli studenti partecipano finché stanno studiando, e una volta laureati, deve sorgere un'altra motivazione. Se la motivazione non si presenta, lo studente smette semplicemente di partecipare al progetto. Se si considera che prima è necessario formare gli studenti, si comprende che diventano buoni specialisti al momento della laurea, ma il loro contributo al progetto, a causa della mancanza di esperienza, è piuttosto limitato.
In generale, stiamo passando gradualmente al punto principale che consente di parlare della creazione di un progetto open source: la creazione di un prodotto che risolva i problemi degli utenti. Come già spiegato in precedenza, la caratteristica principale di un progetto open source è la sua comunità. E i membri della comunità sono innanzitutto gli utenti. Ma come possono sorgere se non hanno nulla da utilizzare? Così come per un progetto non open source, è necessario concentrarsi sulla creazione di un MVP (prodotto minimo funzionante), e se questo suscita interesse, attorno al progetto si formerà una comunità. Tuttavia, se ci si concentra solo sulla creazione di una comunità attraverso il marketing, la scrittura di wiki in tutte le lingue del mondo, o un corretto git workflow su GitHub, è improbabile che ciò abbia importanza nelle prime fasi del progetto. Certamente, in fasi appropriate, queste non solo sono importanti, ma anche necessarie.
In conclusione, voglio citare , a mio avviso, che riflette le aspettative degli utenti rispetto ai progetti open source:
Sto seriamente considerando di passare a questo sistema operativo (almeno per provarlo. Lo stanno sviluppando davvero attivamente e stanno facendo cose straordinarie).
P. S. Su Avremo ben tre relazioni. Una sul software open source e due sull'embedded (di cui una pratica). Al nostro stand faremo un workshop sulla programmazione di microcontrollori. Tradizionalmente porteremo hardware e daremo l'opportunità di programmare. Ci sarà anche una caccia al tesoro e altre attività. Venite al festival e al nostro stand, sarà divertente.
Fonte: habr.com
