Questa settimana si terrà 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. Ecco perché uno dei nostri rapporti si chiama . Sarà dedicato alla storia dello sviluppo di Embox come progetto open source. In questo articolo voglio parlare delle idee principali che, secondo me, influenzano lo sviluppo dei progetti opensource. L'articolo, come il rapporto, si basa sull'esperienza personale.
Cominciamo con qualcosa di semplice, con la definizione del termine opensource. Ovviamente, un progetto open source è un progetto che dispone di una delle licenze che consente l'accesso al codice sorgente del progetto. Inoltre, un progetto aperto significa che gli sviluppatori di terze parti possono apportare modifiche. Cioè, se qualche azienda o sviluppatore pubblica il codice del suo prodotto, parzialmente o completamente, ciò non rende ancora questo prodotto un progetto opensource. Infine, qualsiasi attività progettuale deve portare a qualche tipo di risultato, e l'apertura del progetto implica che questo risultato venga utilizzato non solo dagli sviluppatori stessi.
Non toccheremo i problemi delle licenze aperte. Si tratta di un argomento troppo ampio e complesso che richiede un’indagine approfondita. Sono stati scritti molti buoni articoli e materiali su questo argomento. Ma poiché io stesso non sono un esperto nel campo del diritto d'autore, dirò solo che la licenza deve soddisfare gli obiettivi del progetto. Ad esempio, per Embox la scelta di una licenza BSD anziché GPL non è stata casuale.
Il fatto che un progetto open source debba fornire la possibilità di apportare modifiche e influenzare lo sviluppo del progetto open source implica che il progetto sia distribuito. Gestirlo, mantenendone integrità e performance è molto più difficile rispetto ad un progetto a gestione centralizzata. Sorge una domanda ragionevole: perché i progetti aperti? La risposta sta nell’area della fattibilità commerciale; per una certa classe di progetti, i benefici di questo approccio superano i costi. Cioè, non è adatto a tutti i progetti e un approccio aperto è generalmente accettabile. Ad esempio, è difficile immaginare di sviluppare un sistema di controllo per una centrale elettrica o un aereo basato su un principio aperto. No, ovviamente tali sistemi dovrebbero includere moduli basati su progetti aperti, perché ciò fornirà numerosi vantaggi. Ma qualcuno deve essere responsabile del prodotto finale. Anche se il sistema è completamente basato sul codice di progetti aperti, lo sviluppatore, dopo aver impacchettato tutto in un unico sistema e aver realizzato build e impostazioni specifiche, essenzialmente lo chiude. Il codice potrebbe essere disponibile al pubblico.
Ci sono anche molti vantaggi per questi sistemi dalla creazione o dal contributo a progetti open source. Come ho già detto, il codice del sistema finale potrebbe rimanere pubblicamente disponibile. Perché è ovvio che difficilmente qualcuno avrà lo stesso velivolo per testare il sistema. Questo è vero, ma può darsi che qualcuno voglia controllare alcune parti del codice o, ad esempio, qualcuno possa scoprire che la libreria utilizzata non è configurata in modo corretto.
Un vantaggio ancora maggiore si ottiene se l'azienda assegna alcune parti fondamentali del sistema a un progetto separato. Ad esempio, una libreria per supportare un qualche tipo di protocollo di scambio dati. In questo caso, anche se il protocollo è specifico per una determinata area tematica, è possibile condividere i costi di manutenzione di questa parte del sistema con altre aziende di quest'area. Inoltre, gli specialisti che possono studiare questa parte del sistema di dominio pubblico impiegano molto meno tempo per utilizzarlo in modo efficace. Infine, separare un pezzo in un'entità indipendente utilizzata dagli sviluppatori di terze parti ci consente di migliorare questa parte, perché dobbiamo offrire API efficaci, creare documentazione e non sto nemmeno parlando di migliorare la copertura dei test.
Un'azienda può ricevere vantaggi commerciali senza creare progetti open source, è sufficiente che i suoi specialisti partecipino a progetti di terze parti utilizzati nell'azienda. Dopotutto, 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à pronto e sottoposto a debug riduce ovviamente i costi dell’azienda.
I vantaggi della creazione di progetti open source non finiscono qui. Prendiamo una componente così importante del business come il marketing. Per lui si tratta di un ottimo sandbox che gli consente di valutare efficacemente le esigenze del mercato.
E, naturalmente, non dobbiamo dimenticare che un progetto opensource è un modo efficace per dichiararsi portatore di qualsiasi specializzazione. In alcuni casi, questo è l’unico modo per entrare nel mercato. Ad esempio, Embox è iniziato come progetto per creare un RTOS. Probabilmente non è necessario spiegare che ci sono molti concorrenti. Senza creare una comunità, semplicemente non avremmo avuto risorse sufficienti per portare il progetto all'utente finale, cioè per consentire agli sviluppatori di terze parti di iniziare a utilizzare il progetto.
La comunità è fondamentale in un progetto opensource. Ti consente di ridurre significativamente i costi di gestione del progetto, sviluppare e supportare il progetto. Possiamo dire che senza una comunità non esiste alcun progetto opensource.
È stato scritto molto materiale su come creare e gestire una comunità di progetti open source. Per non raccontare fatti già noti, cercherò di concentrarmi sull'esperienza di Embox. Ad esempio, il processo di creazione di una comunità è una questione molto interessante. Molti cioè raccontano come gestire una comunità esistente, ma a volte si trascurano i momenti della sua creazione, considerandoli un dato di fatto.
La regola principale quando si crea una comunità di progetti opensource è che non ci sono regole. Insomma non esistono regole universali, così come non esiste una soluzione miracolosa, se non altro perché i progetti sono molto diversi. È improbabile che tu possa utilizzare le stesse regole quando crei una comunità per una libreria di registrazione js e alcuni driver altamente specializzati. Inoltre, nelle diverse fasi di sviluppo del progetto (e quindi della comunità), le regole cambiano.
Embox è iniziato come progetto studentesco perché aveva accesso agli studenti del dipartimento di programmazione dei sistemi. In effetti, stavamo entrando in qualche altra comunità. Potremmo interessare i partecipanti di questa comunità, gli studenti, alle buone pratiche industriali nella loro specialità, al lavoro scientifico nel campo della programmazione di sistema, ai corsi e ai diplomi. Cioè, abbiamo seguito una delle regole fondamentali per organizzare una comunità: i membri della comunità devono ricevere qualcosa, e questo prezzo deve corrispondere al contributo del partecipante.
La fase successiva per Embox è stata la ricerca di utenti di terze parti. È molto importante capire che gli utenti partecipano a pieno titolo alla comunità opensource. Di solito ci sono più utenti che sviluppatori. E per voler diventare un collaboratore di un progetto, prima iniziano a usarlo in un modo o nell'altro.
I primi utenti di Embox furono il Dipartimento di Cibernetica Teorica. Hanno suggerito di creare un firmware alternativo per Lego Mindstorm. E sebbene si trattasse ancora di utenti locali (abbiamo potuto incontrarli di persona e discutere di ciò che volevano). Ma è stata comunque un'esperienza molto positiva. Ad esempio, abbiamo sviluppato demo che potrebbero essere mostrate ad altri, perché i robot sono divertenti e attirano l'attenzione. Di conseguenza, abbiamo ottenuto utenti veramente di terze parti che hanno iniziato a chiedersi cos'è Embox e come usarlo.
In questa fase bisognava pensare alla documentazione, ai mezzi di comunicazione con gli utenti. No, certo, abbiamo pensato prima a queste cose importanti, ma era prematuro e non ha dato effetti positivi. L'effetto è stato piuttosto negativo. Lascia che ti faccia un paio di esempi. Abbiamo utilizzato googlecode, la cui wiki supportava il multilinguismo. Abbiamo creato pagine in diverse lingue, non solo inglese e russo, nelle quali difficilmente riuscivamo a comunicare, ma anche tedesco e spagnolo. Di conseguenza, sembra molto ridicolo quando viene chiesto in queste lingue, ma non possiamo rispondere affatto. Oppure hanno introdotto regole sulla scrittura della documentazione e sui commenti, ma poiché l'API è cambiata abbastanza spesso e in modo significativo, si è scoperto che la nostra documentazione era obsoleta ed era più fuorviante che utile.
Di conseguenza, tutti i nostri sforzi, anche quelli sbagliati, hanno portato alla comparsa di utenti esterni. Ed è apparso anche un cliente commerciale che voleva che fosse sviluppato il proprio RTOS. E l'abbiamo sviluppato perché abbiamo esperienza e alcune basi. Qui devi parlare sia dei momenti belli che di quelli brutti. Inizierò con quelli cattivi. Poiché molti sviluppatori erano coinvolti a livello commerciale in questo progetto, la comunità era già piuttosto instabile e divisa, il che ovviamente non poteva che influenzare lo sviluppo del progetto. Un ulteriore fattore è stato il fatto che la direzione del progetto è stata stabilita da un cliente commerciale e il suo obiettivo non era l'ulteriore sviluppo del progetto. Almeno questo non era l'obiettivo principale.
D’altro canto vi sono stati numerosi aspetti positivi. Abbiamo utenti veramente di terze parti. Non si trattava solo del cliente, ma anche di coloro a cui era destinato questo sistema. La motivazione a partecipare al progetto è aumentata. Dopotutto, se puoi guadagnare anche con un business interessante, è sempre bello. E, cosa più importante, abbiamo ascoltato un desiderio dei clienti, che a quel tempo ci sembrava folle, ma che ora è l'idea principale di Embox, ovvero utilizzare il codice già sviluppato nel sistema. Ora l'idea principale di Embox è utilizzare il software Linux senza Linux. Cioè, il principale aspetto positivo che ha contribuito all'ulteriore sviluppo del progetto è stata la consapevolezza che il progetto viene utilizzato da utenti di terze parti e dovrebbe risolvere alcuni dei loro problemi.
A quel tempo Embox era già andato oltre lo scopo di un progetto studentesco. Il principale fattore limitante nello sviluppo del progetto secondo il modello studentesco è la motivazione dei partecipanti. Gli studenti partecipano mentre studiano e quando si diplomano dovrebbe esserci una motivazione diversa. Se la motivazione non appare, lo studente semplicemente smette di partecipare al progetto. Se si tiene conto del fatto che gli studenti devono prima essere formati, si scopre che una volta laureati diventano buoni specialisti, ma il loro contributo al progetto, a causa dell'inesperienza, non è molto ampio.
In generale, passiamo senza intoppi al punto principale che ci consente di parlare della creazione di un progetto opensource: creare un prodotto che risolva i problemi dei suoi utenti. Come ho spiegato sopra, la proprietà principale di un progetto opensource è la sua comunità. Inoltre, i membri della comunità sono principalmente utenti. Ma da dove vengono quando non c’è niente da usare? Quindi si scopre che, proprio come con un progetto non opensource, è necessario concentrarsi sulla creazione di un MVP (prodotto minimo vitale) e, se interessa agli utenti, apparirà una comunità attorno al progetto. Se sei impegnato nella creazione di una comunità solo attraverso le pubbliche relazioni della comunità, scrivendo una wiki in tutte le lingue del mondo o correggendo il flusso di lavoro git su github, è improbabile che ciò abbia importanza nelle prime fasi del progetto. Naturalmente, nelle fasi appropriate, queste non sono solo cose importanti, ma anche necessarie.
In conclusione vorrei sottolineare , secondo me, riflette le aspettative degli utenti da un progetto opensource:
Sto seriamente pensando di passare a questo sistema operativo (almeno provarci. Lo stanno perseguendo attivamente e stanno facendo cose interessanti).
PS Avanti Avremo ben tre rapporti. Uno sull'open source e due sull'embedded (e uno è pratico). Allo stand condurremo una master class sull'utilizzo della programmazione dei microcontrollori . Come al solito, porteremo l'hardware e ti permetteremo di programmarlo. Ci saranno anche una missione e altre attività. Vieni al festival e al nostro stand, sarà divertente.
Fonte: habr.com