Anche il logo del pinguino ne ha risentito.

#3 LINUX FA SCHIFO: uno sviluppo non proprio efficiente?

Ok il terzo capitolo volevo farlo decisamente più comico, inserendo….ahh non posso dirvelo. Ma avrei voluto, sappiatelo.

Alla fine ho optato, utilizzando tutti i miei neuroni rimasti, per un argomento un po’ più serio ed articolato, qualcosa che riguardasse nel profondo il mondo dello sviluppo Linux e, più in generale, quello del mondo Open-Source (si ok, non tutti i software si sviluppano con gli stessi strumenti, ma Git è piuttosto diffuso nell’ambito free).

Prima di iniziare, come sempre, devo introdurre una premessa (per evitare di essere scuoiato vivo, so che avete i denti affilati), ci tengo a ribadire che il seguente contenuto non è da intendere come “ah ma ti stai lamentando di Linux?” ma invece come “mi hai fatto riflettere su un aspetto molto interessante, un aspetto migliorabile, facendomi anche fare 4 risate :D”.

Oggi tratteremo l’eccellente, preciso e privo di errori l’indecente mondo dello sviluppo software su Git e piattaforme simili.

Le basi: chi ci lavora dietro?

Al mondo esistono due tipi di sviluppatori (così come due tipi di persone):

  • quelli che sviluppano software previo pagamento;
  • quelli che sviluppano software in maniera totalmente gratuita.

ora, a prescindere da cosa sia giusto o meno (premetto che sono convinto che sia corretto farsi pagare per svolgere un lavoro, qualunque esso sia| si, ci sono eccezioni eh), chi lavora dietro al mondo Linux (e in generale, dell’Open-Source), tranne qualche rara eccezione (vedi Canonical, OpenSUSE ecc.) non viene pagato. Svolge il proprio lavoro gratuitamente ed in favore della comunità Open-Source.

Un software sviluppato…ma come?

Dovete sapere che, quando uno sviluppatore decide di partorire il proprio obbrobrio creare la propria opera d’arte, rendendola disponibile per tutti, sia essa un intero programma, un tool, una piccola patch o una semplice linea di codice, quest’ultima viene caricata su un software di controllo versione distribuito, come ad esempio:

  • Git (creato direttamente da Torvalds, il kernel e le patch vanno lì infatti);
  • Bazaar;
  • Mercurial;
  • BitKeeper

ciò permette di inserire il proprio lavoro e renderlo visionabile a tutti gli altri sviluppatori, in maniera da costruire quindi un lavoro distribuito e ben organizzato.

Riepilogando, semplicisticamente, io vado ad inserire una linea di codice e tu, che sei uno sviluppatore dall’altro parte del globo terrestre, puoi vederla e, se vuoi, modificarla.

Un sistema dove centinaia di migliaia di sviluppatori, liberamente, senza essere pagati e nel proprio tempo libero possono caricare chissà quante linee di codice come capita prime ed a proprio piacimento. Cosa potrebbe mai andare storto?

La disponibilità di software Open-Source continua ad aumentare a ritmi impressionanti, ormai da diversi anni, e sembra proprio non volersi fermare.

Si, è FANTASTICO avere tutti questi programmi, tutti questi tool, questi aggiornamenti, queste patch, cicciobello e i wurstel affumicati sul legno di faggio in Alto-Adige, ma quanti di questi funzionano bene?

Quanti di questi programmi/tool, funzionano alla stessa maniera per tutti? Quanti di questi hanno un numero di bug talmente basso da potersi definire stabili?

La risposta è difficile, ed è probabilmente uno dei più grandi talloni d’Achille del mondo Open-Source e, a grandi linee, del mondo Linux.

Quindi mi staresti dicendo che Linux è semplicemente un sistema inutile e pieno di bug?

Si No. No dai ragazzi, sul si ero molto ironico, non mi azzarderei mai, io stesso amo Linux.

E’ incredibile, è fantastico che il mondo Open-Source (e Linux) abbia un così enorme numero di partecipanti, di persone che nel tempo libero riescono a creare software eccezionali, che su Windows magari nemmeno esistono e arriveranno tra qualche anno (ogni riferimento alla differenza di funzioni tra Windows 7 e Windows 10 spudoratamente copiate da Linux è puramente casuale).

Tuttavia, è innegabile (oltre che irreversibile) che degli sviluppatori pagati, con un progetto organizzato e seguito da una o più aziende, svolgano un lavoro migliore e con un numero di bug inferiori.

Ma questa, è un po’ la storia di ciò che costa poco e ciò che costa tanto: non sempre ciò che ha un prezzo superiore offre, nel complesso, qualcosa di migliore (ma è anche vero che, all’aumentare del prezzo, dovrebbe conseguirne una maggiore possibilità che il prodotto offra qualcosa in più).

Inoltre, come giustamente mi ha fatto notare l’utente Luca Viggiani, nella maggior parte dei casi non esiste un team di controllo qualità sul software inserito, che solitamente viene semplicemente mandato agli utenti finali (finendo poi per fare, quindi, i veri tester).

Diciamo, come altro punto in favore, che il mondo Open-Source in genere, a causa di questa progettazione sparsa del software, partorisce idee molto creative e particolari prima di chi ha già organizzato un proprio software. Proprio perché il progetto non è fisso, proprio per la mancanza di rigidità.

Al prossimo capitolo della rubrica LINUX FA SCHIFO 😛 (oh, non scappate eh, ci sono ancora molte cose da raccontare!)

Riguardo a: Salvo Cirmi (Tux1)

Un pinguino intraprendente che dopo diversi anni di "servizio" online (e soprattutto delle guide) ha acquisito conoscenze non di poco conto sui settori Android, Linux e Windows. Le mie specialità sono il modding e le review. Nel tempo libero (che è raro trovare) suono il piano, mi diverto effettuando modding e provando distribuzioni Linux, BSD ed altre.

Guarda anche..

Emmabuntüs Debian Edition 3 – 1.04 fa il suo debutto!

Per il primo Marzo, il team di Emmabuntus ci fa una sorpresina, con un rilascio …

8 commenti

  1. Grazie, certo fai pure, sono lieto di poter contribuire!

  2. Ciao, anch’io sono assolutamente d’accordo col fatto che in generale chi fa un lavoro dovrebbe essere pagato ma penso che il problema della qualità (nel senso di stabilità e coerenza coi requisiti) dei progetti open source non dipenda tanto dal fatto che chi sviluppa lo fa gratis ma più dal fatto che manchi un committente che paga e che quindi pretende la qualità. Anch’io partecipo allo sviluppo di alcuni progetti open source e ti posso garantire che molti programmatori tendono ad essere più rigorosi in quell’ambito piuttosto che in un contesto commerciale e chiuso. È un po’ l’effetto palcoscenico internazionale… Certo, poi ci sono anche i programmatori da cut & paste ma lì di solito ci pensa la comunità a sistemare le cose. E allora dove sta il problema ? Secondo me il vero problema sta nel fatto che manca un vero team che fa controllo qualità e ha l’autorità di intervenire sugli sviluppatori e bloccare una delivery. Invece spesso si butta fuori codice non testato e si trasferice l’onere del QA all’utente finale. Questo è l’errore madornale

  3. In un solo commento hai espresso una parte importante che avrei voluto inserire (e che probabilmente, con tuo permesso e citazione, inserirei). Si, effettivamente manca un vero quality check, un team di controllo qualità, uno step in più che garantirebbe un minor numero di problemi.

  4. Tu centri il problema, cioè la consistenza del team di sviluppo.
    Ma spesso, sviluppare software per alcuni team è come partecipare ad una partitella di calcio; tutti voglio fare l’attaccante e nessuno vuole rimanere in difesa, così accade che certi aspetti vengano tralasciati perché “noiosi”.
    E’ il caso da te evidenziato della verifica dei bug, ma aggiungere della documentazione interna, ed esterna ( mi riferisco sia la documentazione per gli sviluppatori, che quella per gli utenti finali ).
    Storia vecchia, quello dei commenti, in più ci si aggiunge anche la chat ( ho parlato con Paolo di fare quella cosa… l’altro giorno… ma da nessuna parte c’è un report su cosa hanno parlato! ).
    Ma chi come me, sviluppa software da solo, spesso viene proprio da realtà come quelle che ho descritto e non mi va di passare più tempo a discutere che a sviluppare; con questo rispondo anche a @tux1 relativamente al software di Linux, Linux stesso compreso.
    Se segui le vicende attorno a Torvalds, capite già che a qualsiasi livello le discussioni sono la parte più importanti dello sviluppo.
    M.

  5. Fortunatamente appunto ci sono eccezioni come voi, che svolgono un lavoro affinato più e più volte.

  6. Non sempre è così, ci sono delle eccezioni anche in questo, noi testiamo le ISO personalmente per due mesi su 16 postazioni da lavoro (quindi siamo tutti tester dal fondatore del progetto ai blogger come me), poi lo proviamo su oltre 200 sistemi installati presso i clienti e solamente dopo tutti i test ed avere risolto eventuali bug rilasciamo la ISO Infatti ad ogni test della distro , spagnoli, americani o italiani in ogni recensione in cui l’hanno provata installandola poi affermano “priva di bug” e “sarà la il mio primo boot”, vedi masLinux E E.T.C. Network. Ma è un lavoro lungo e pesante che porta ad un prodotto finale ottimo ma che comunque ai più passa inosservato. Non penso sia produttivo farlo per un piccolo team o un team amatoriale, visto che poi nemmeno viene considerato quanto uno sfondo della scrivania ben colorato.

Lascia un commento