Già questa settimana a San Pietroburgo si svolgerà un festival IT . Uno dei relatori sarà Richard Stallman. partecipano anche al festival e naturalmente non potevamo trascurare il tema del software libero. Perciò uno dei nostri interventi si intitola . Sarà dedicato alla storia dello sviluppo di Embox come progetto open source. In questo articolo desidero raccontare le idee principali che, a mio avviso, influenzano lo sviluppo dei progetti open source. L'articolo, così come l'intervento, si basa su esperienze personali.
Iniziamo con il concetto di open source. È evidente che un progetto open source è un progetto che possiede una delle licenze che permettono l'accesso al codice sorgente del progetto. Inoltre, un progetto aperto implica la possibilità di apportare modifiche da parte di sviluppatori esterni. Quindi, se un'azienda o uno sviluppatore pubblicano il codice del proprio prodotto, in parte o totalmente, ciò non rende automaticamente quel prodotto un progetto open source. Infine, qualsiasi attività di progetto deve portare a un risultato, e l'apertura del progetto implica che quel risultato sia utilizzato non solo dagli stessi sviluppatori.
Non tratteremo delle problematiche delle licenze aperte. È un argomento troppo vasto e complesso che richiede un'approfondita comprensione. Sono stati scritti molti articoli e materiali di buona qualità su questo argomento. Ma, poiché non sono un esperto in diritto d'autore, dirò solo che una licenza deve rispondere agli obiettivi del progetto. Ad esempio, per Embox, la scelta della licenza BSD invece di quella GPL non è stata casuale.
Il fatto che un progetto open source debba consentire modifiche e influenzare lo sviluppo del progetto stesso implica che sia un progetto distribuito. Gestirlo, mantenere l'integrità e la funzionalità è molto più complesso rispetto a un progetto con gestione centralizzata. Nasce quindi la legittima domanda su perché creare progetti open source. La risposta sta nell'area della convenienza commerciale, per una certa classe di progetti i benefici di tale approccio superano i costi. Cioè, non tutti i progetti sono adatti e, in generale, non è sempre possibile l'approccio aperto. Ad esempio, è difficile immaginare lo sviluppo di un sistema di gestione di una centrale elettrica o di un aeroplano basato su principi open source. Certo, in tali sistemi è opportuno includere moduli basati su progetti open source, poiché ciò offre diversi vantaggi. Tuttavia, per il prodotto finale qualcuno deve assumersi la responsabilità. Anche se il sistema è completamente basato su codice di progetti open source, il suo sviluppatore, raggruppando tutto in un unico sistema e creando specifiche build e configurazioni, in effetti lo chiude. Il codice, quindi, può essere accessibile pubblicamente.
Per questi sistemi ci sono anche molti vantaggi nella creazione di progetti open source o nella partecipazione a essi. Come ho già detto, il codice del sistema finale può rimanere accessibile pubblicamente. Perché? È ovvio che difficilmente qualcuno avrà un aereo simile per testare il sistema. È vero, ma potrebbe anche esserci qualcuno interessato a controllare specifiche sezioni di codice, o ad esempio, qualcuno potrebbe scoprire che la libreria utilizzata non è configurata correttamente.
Un vantaggio ancora maggiore si presenta quando un'azienda dedica una parte fondamentale del sistema a un progetto separato. Ad esempio, una libreria per il supporto di un determinato protocollo di scambio dati. In questo caso, anche se il protocollo è specifico per un determinato settore, è possibile condividere i costi per mantenere questa parte del sistema con altre aziende di questo settore. Inoltre, agli specialisti che possono studiare questa parte del sistema in accesso aperto serve molto meno tempo per un utilizzo efficace. Infine, suddividere una parte in un'entità autonoma, utilizzata da sviluppatori esterni, consente di rendere questa parte di qualità superiore, poiché è necessario offrire API efficaci, creare documentazione, senza contare il miglioramento della copertura dei test.
Un'azienda può ottenere vantaggi commerciali anche senza creare progetti open source, basta che i suoi specialisti partecipino a progetti esterni utilizzati nell'azienda. Infatti, tutti i vantaggi rimangono: i dipendenti conoscono meglio il progetto, quindi lo utilizzano in modo più efficace, l'azienda può influenzare la direzione dello sviluppo del progetto e l'uso di codice già collaudato riduce ovviamente i costi dell'azienda.
E non finisce qui, i vantaggi nella creazione di progetti open source. Prendiamo in considerazione un aspetto importante del business come il marketing. Per questo, è una palestra davvero valida che permette di valutare efficacemente le esigenze del mercato.
E ovviamente non bisogna dimenticare che un progetto open source è un modo efficace per affermarsi come portatore di una certa specializzazione. In alcuni casi, questo è l'unico modo per entrare nel mercato. Ad esempio, Embox è iniziato come progetto per la creazione di un RTOS. Probabilmente non è necessario spiegare che ci sono moltissimi concorrenti. Senza creare una comunità, non avremmo semplicemente avuto abbastanza risorse per portare il progetto all'utente finale, ovvero affinché il progetto venisse utilizzato da sviluppatori esterni.
La comunità è fondamentale in un progetto open source. Essa consente di ridurre significativamente i costi di gestione del progetto, sviluppa e supporta il progetto. Si può dire che senza comunità non esiste affatto un progetto open source.
Ci sono molte risorse su come creare e gestire una comunità di un progetto open source. Per non ripetere fatti già noti, cercherò di focalizzarmi sull'esperienza di Embox. Ad esempio, una questione molto interessante è il processo di creazione di una comunità. Cioè, molti raccontano come gestire una comunità esistente, ma a volte trascurano i momenti della sua creazione, considerandoli dati di fatto.
La regola principale nella creazione di una comunità di un progetto open source è che non ci sono regole. Voglio dire che non esistono regole universali, così come non esiste una soluzione miracolosa, perlomeno perché i progetti sono molto diversi tra loro. È improbabile utilizzare le stesse regole nella creazione di una comunità per una libreria di logging in js e un driver specializzato. Inoltre, nelle diverse fasi di sviluppo di un progetto (e quindi di una comunità), le regole cambiano.
Embox è nato come un progetto studentesco, dato che avevamo accesso agli studenti del dipartimento di programmazione dei sistemi. Fondamentalmente, entravamo in un'altra comunità. I partecipanti a questa comunità, gli studenti, potevano essere interessati a una buona esperienza pratica industriale nel loro campo, ricerche nel settore della programmazione di sistemi, progetti di tesi e laurea. Cioè, stavamo seguendo una delle regole fondamentali per l'organizzazione di una comunità: i membri della comunità devono ricevere qualcosa, e il valore deve corrispondere al contributo del membro.
La fase successiva per Embox è stata la ricerca di utenti esterni. È molto importante comprendere che gli utenti sono partecipanti a pieno titolo della comunità open source. Ci sono generalmente più utenti che sviluppatori. E per voler diventare un contributore del progetto, prima o poi lo iniziano a utilizzare.
I primi utenti di Embox sono stati il dipartimento di Cibernetica Teorica. Hanno proposto di creare un firmware alternativo per Lego Mindstorm. E sebbene fossero ancora utenti locali (potevamo incontrarli di persona e discutere di cosa volessero), è stato comunque un'esperienza molto positiva. Ad esempio, abbiamo sviluppato delle demo che potevamo mostrare agli altri, poiché i robot sono divertenti e attirano l'attenzione. Alla fine, sono comparsi veri e propri utenti esterni, che hanno iniziato a chiedere cosa fosse Embox e come usarlo.
A questo punto, abbiamo dovuto riflettere sulla documentazione e sui mezzi di comunicazione con gli utenti. Certo, avevamo già pensato a queste cose importanti prima, ma era prematuro e non portava a risultati positivi. L'effetto era piuttosto negativo. Porterò un paio di esempi. Abbiamo utilizzato googlecode, il cui wiki supportava la multilinguismo. Abbiamo creato pagine in diverse lingue, non solo in inglese e russo, lingue con cui potevamo comunicare a fatica, ma anche in tedesco e spagnolo. Risultato: sembrava molto ridicolo quando venivano fatte domande in quelle lingue e noi non riuscivamo affatto a rispondere. Oppure stabilivamo regole per la scrittura della documentazione e i commenti, ma poiché l'API cambiava piuttosto frequentemente e in modo sostanziale, la nostra documentazione diventava obsoleta e più fuorviante che utile.
Alla fine, tutti i nostri sforzi, anche quelli non corretti, hanno portato alla comparsa di utenti esterni. È persino emerso un cliente commerciale che desiderava che sviluppassimo un proprio OSRV. E l'abbiamo sviluppato, poiché avevamo esperienza e qualche lavoro preliminare. Qui è necessario parlare sia dei momenti positivi che di quelli negativi. Inizierò con i lati negativi. Poiché molti sviluppatori erano stati coinvolti in questo progetto sulla base commerciale, la comunità, già piuttosto instabile, si è divisa, il che ovviamente non poteva non avere un impatto sullo sviluppo del progetto. Un ulteriore fattore è stato che la direzione del progetto era definita da un cliente commerciale, il cui obiettivo non era lo sviluppo ulteriore del progetto. Almeno, questo obiettivo non era primario.
D'altra parte, c'erano diversi aspetti positivi. Abbiamo ottenuto realmente utenti esterni. Non erano solo clienti, ma anche coloro per cui questo sistema era destinato. La motivazione a partecipare al progetto è aumentata. Infatti, se si può guadagnare anche mentre si fa qualcosa di interessante, è sempre piacevole. E soprattutto, abbiamo ascoltato un desiderio dei clienti, che all'epoca ci sembrava bizzarro, ma che ora è diventato l'idea principale di Embox, ossia utilizzare codice già sviluppato nel sistema. Attualmente, l'idea principale di Embox è utilizzare software Linux senza Linux. Vale a dire, il principale aspetto positivo che ha facilitato ulteriori sviluppi del progetto è stata la realizzazione che il progetto è utilizzato da utenti esterni e deve risolvere alcuni dei loro problemi.
A quel tempo, Embox era già oltre il progetto studentesco. Il principale fattore limitante nello sviluppo del progetto secondo il modello studentesco è la motivazione dei partecipanti. Gli studenti partecipano finché studiano, e quando si laureano, deve emergere una nuova motivazione. Se la motivazione non si manifesta, lo studente smette semplicemente di partecipare al progetto. Se si considera che gli studenti devono prima essere formati, si capisce che diventano buoni specialisti al momento della laurea, ma il loro contributo al progetto, a causa della loro inesperienza, non è molto consistente.
In generale, stiamo gradualmente passando al punto principale che ci consente di parlare della creazione di un progetto open-source, ossia di un prodotto che risolva i problemi degli utenti. Come ho già spiegato sopra, la principale caratteristica di un progetto open-source è la sua comunità. Inoltre, i membri della comunità sono prima di tutto utenti. Ma come possono emergere se non hanno nulla da utilizzare? Ecco quindi che, come per un progetto non open-source, bisogna concentrarsi sulla creazione di un MVP (prodotto minimo funzionante) e se questo interessa gli utenti, attorno al progetto sorgerà una comunità. Se invece ci si occupa della creazione della comunità solo attraverso PR, scrivendo wiki in tutte le lingue del mondo o implementando un corretto flusso di lavoro su GitHub, è difficile che ciò abbia rilevanza nelle prime fasi del progetto. Certamente, nelle fasi appropriate, queste cose non sono solo importanti, ma anche necessarie.
In conclusione, voglio citare , a mio avviso, riflette le aspettative dell'utente da un progetto open source:
Sto seriamente considerando di passare a questo sistema operativo (perlomeno per provarlo. È davvero attivamente sviluppato e ci stanno facendo cose fantastiche).
P. S. A noi avremo ben tre relazioni. Una sull'open source e due sull'embedded (di cui una pratica). Faremo un masterclass sulla programmazione di microcontrollori con . Tradizionalmente porteremo hardware e daremo l'opportunità di programmare. Ci sarà anche un quest e altre attività. Venite al festival e al nostro stand, sarà divertente.
Fonte: habr.com
