Modello di sviluppo del software libero: la cattedrale e il bazar

The Cathedral and the Bazaar è un documento di tipo manifesto sviluppato da Eric S. Raymond nel 1.998 per cercare di spiegare dalla sua prospettiva ed esperienza (Fetchmail Development) ciò che ha capito sulla creazione e l'evoluzione di successo di Linux e dei suoi programmi correlati, soprattutto dal punto di vista della differenza tra i modelli di sviluppo software, che ha personalmente chiamato: Cathedral Model e Bazaar Model.

E in questa pubblicazione, forniremo un'analisi e un riassunto di detto manifesto così popolare tra gli sviluppatori del movimento del software libero. Che è liberamente disponibile e accessibile in molte parti del Web, ma può essere scaricato dal seguente collegamento Web per accedervi più rapidamente: La Cattedrale e il Bazar.

INTRODUZIONE

Detto materiale «La cattedrale e il bazar» ci presenta la visione che nel mondo dell'ingegneria del software ci sono «due stili di sviluppo completamente diversi, il modello cattedrale, applicabile alla maggior parte degli sviluppi compiuti nel mondo del software commerciale, rispetto al modello bazaar, più tipico del mondo Linux ”.

Sottolineando che questi 2 modelli derivano da punti di partenza opposti sulla natura del processo di debug del software, e della sua particolare teoria su quella che chiamava Legge di Linus che affermava quanto segue: "Dato un numero sufficiente di occhi, tutti gli errori sono irrilevanti" o in altre parole: "Con un numero sufficiente di occhi, tutti gli errori sono sciocchezze".

Ed enfatizza la parola Hacker, che secondo me l'autore ha espresso come una sorta di Utente di alto livello capace di comprendere e sfruttare efficacemente un programmae per rilevare, suggerire o attuare correzioni o modifiche di forma e sostanza efficienti per l'intera comunità di utenti.

In altre letterature, questa parola o concetto chiamato Hacker si riferisce a:

«un esperto, appassionato di una determinata area disciplinare, in particolare l'area tecnologica, e il cui scopo è sfruttare tale conoscenza per scopi benigni. È quella persona, solitamente un professionista in un'area di conoscenza, che è appassionata di conoscenza, scoprire e imparare cose nuove e capire come funzionano, arrivando al punto di migliorarlo con suggerimenti e proposte efficaci, e sempre con l'intenzione di condividere la conoscenza o evitare un guasto o un malfunzionamento dell'oggetto di studio.

Che è un concetto più universale e reale, poiché ci sono "hacker" in tutte le aree della conoscenza umana.

DESARROLLO

Tra i tanti che hanno letto questo materiale, sicuramente ci sarà un gran numero di persone che concorderanno sul fatto che l'idea che "Linux è sovversivo" sia chiaramente espressa lì. Ma perché?

Perché fino a quel momento c'era un file molteplicità di metodi o modelli di sviluppo software standardizzati basati su un "approccio più centralizzato e pianificato sin dall'inizio" Perché l'atto di creare Software è stato considerato come qualcosa di associato a qualcosa che porta a "una certa complessità critica".

E che nonostante il fatto che il mondo Unix esistesse già, fatto di piccoli strumenti, prototipazione rapida e programmazione evolutiva, L'emergere della filosofia di sviluppo del software libero sotto Linux ha portato la questione a un altro livello di sofisticazione.

Mentre nel mondo dello sviluppo di software privato è stato fatto in un "modo silenzioso e riverente", così come si costruisce una cattedrale, nel mondo dello sviluppo di software libero (Linux) è stato fatto in "modo rumoroso e con molteplici programmi (percorsi) e approcci (proposte)", proprio come fossi in un grande bazar.

Questo grande manifesto ci offre diverse premesse per condensare le idee ivi espresse, in termini di Modello di sviluppo del software libero, che sono:

PREMESSA # 1

TUTTI I BUONI LAVORI NEL SOFTWARE INIZIANO A TENTARE DI SODDISFARE IL PROBLEMA PERSONALE DI UNO SVILUPPATORE.

Che è una realtà innegabile perché Molti di coloro che lavorano nello sviluppo di software libero di solito iniziano a causa della necessità di risolvere un problema personale o quello di un collettivo o di un gruppo, ovvero per ottimizzare un processo già eseguito in modo più lento e / o ripetitivo, che spesso diventa faticoso e / o noioso per chi vi partecipa, cercando di massimizzare il tempo e gli sforzi di chi ne è coinvolto.

PREMESSA # 2

I bravi programmatori sanno cosa scrivere. IL PIÙ GRANDE SAPERE COSA RISCRIVERE E RIUTILIZZARE.

Qualsiasi programmatore sa che iniziare da zero non è niente di male o inutile, quando si tratta di sviluppare un programma o un'applicazione. Tuttavia, per molti che stanno iniziando e per altri già esperti in materia, è risaputo che a volte "Inventare la ruota" di nuovo non è molto efficiente, ma è meglio solo ottimizzarlo e adattarlo alle proprie esigenze. In altre parole, è meglio riscrivere e assimilare quanto più codice possibile da altri esperti del settore che ci interessa per risolvere il nostro sviluppo software.

PREMESSA # 3

"PENSA A GETTARNE ALMENO UNO - FINISCI PER FARLO COMUNQUE."

Un buon Software Developer deve saper ascoltare in dettaglio ciò che gli utenti dei loro sviluppi dicono o suggeriscono o propongono, poiché un programma che è già funzionante, può comunque diventare qualcosa di molto grande, pur essendo funzionale, qualcosa che perde il nord, un mostro funzionale che fa tutto per tutti e, a sua volta, qualcosa di non piacevole. Quindi ascoltare per tornare alle origini, riconquistare gli utenti persi, aggiungere nuove funzionalità, rimuovere quelle non necessarie, rendere il programma più piccolo, più specifico e generale, è sempre una buona pratica.

PREMESSA # 4

SE HAI IL GIUSTO ATTEGGIAMENTO, PROBLEMI INTERESSANTI TI TROVERANNO.

Un buon cambiamento di atteggiamento e puntuale può significare un cambiamento radicale per ogni programmatore o sviluppatore di software nei suoi sviluppi attuali o nuovi che a sua volta significa nuovi vantaggi di tempo, denaro o comfort per gli utenti dei loro prodotti. Stai alla ricerca di modi innovativi per risolvere i problemi che si stanno presentando in un buon sintomo nella giusta direzione.

PREMESSA # 5

QUANDO UN PROGRAMMA NON TI INTERESSA PIU ', IL TUO ULTIMO DOVERE È TRASFERLO A UN SUCCESSORE COMPETENTE.

Per molti programmatori o sviluppatori di software, così come altri tecnologi, non è raro voler dedicare nuovo tempo a nuovi progetti. Ma nel mondo del Software Libero la premessa è passare il testimone, ci sono altri che vorrebbero continuare con lo sviluppo dei loro prodotti già abbandonati, per i quali devono permettere a chiunque di hackerare (migliorare) il programma per sé o per vantaggio degli utenti della comunità del programma.

PREMESSA # 6

TRATTARE I TUOI UTENTI COME COLLABORATORI È IL MODO MENO COMPLICATO PER MIGLIORARE RAPIDAMENTE ED EFFETTIVAMENTE DEBUGARE UN PROGRAMMA.

Poiché "libero" è spesso interpretato come "libero" nello sviluppo di Software Libero, molti programmatori tendono a raggrupparsi per evitare l'usura non pagata alleandosi con altri sviluppatori o utenti avanzati dei loro sviluppi, per continuarli o affinché altri continuino loro, in cambio di ricevere "crediti" nello sviluppo di future innovazioni di codice e garantendo che i futuri sviluppi includano formalmente alcune licenze, per evitare un uso improprio.

PREMESSA # 7

RILASCIATELO PRESTO. Lancialo spesso. E ASCOLTA I TUOI UTENTI.

A differenza del mondo dello sviluppo di software proprietario, nel software libero spesso accade che molto e veloce sia meglio. Poiché l'ampia base di utenti e sviluppatori che abitualmente utilizzano e sviluppano un programma nella comunità ea loro volta interagiscono tra loro, per comunicare i loro dubbi, suggerimenti, proposte, reclami e / o reclami, può diventare una preziosa fonte di conoscenza per evolvere un programma verso fasi di sviluppo mature.

PREMESSA # 8

DATA UNA BASE SUFFICIENTE DI TESTER E COLLABORATORI, QUASI TUTTI I PROBLEMI SARANNO IDENTIFICATI RAPIDAMENTE E LA LORO SOLUZIONE SARÀ EVIDENTE PER QUALCUNO.

Il materiale termina facendo concludere al lettore, molte volte, che il metodo di sviluppo software basato sul modello Bazaar, è molto efficace. Perché maggiore è il potere, la libertà o la conoscenza che uno sviluppatore di software fornisce agli utenti sul proprio programma, più possono contribuire con idee ingegnose o modifiche utili, solo a scopo di vantaggio collettivo.

E questo è piacevolmente espresso nel seguente estratto dal materiale:

"Questa è, credo, la differenza fondamentale tra lo stile della cattedrale e quello del bazar. Secondo il modo in cui una cattedrale guarda alla programmazione, errori e problemi di sviluppo sono fenomeni insidiosi, profondi e contorti. Ci vogliono mesi di controllo da parte di un piccolo numero di persone dedicate per essere sicuri di essere stati rimossi. Da qui i lunghi periodi necessari per il rilascio delle nuove versioni, e l'inevitabile delusione vissuta quando quelle attese da tanto tempo non sono perfette.

Alla luce del modello del bazar, tuttavia, si presume che gli errori siano normalmente questioni minori o, almeno, che diventeranno tali piuttosto rapidamente una volta che saranno esposti agli occhi ansiosi di poche migliaia di collaboratori dediti a rimediare e altro modo per aggirare ogni nuova versione. Quindi continui a rilasciare versioni frequentemente per ottenere ancora più correzioni e, come effetto collaterale benefico, hai meno da perdere se sbagli di tanto in tanto ".

CONCLUSIONE

Personalmente, la mia piccola esperienza nel campo dello sviluppo di software libero con il modello di tipo Bazaar mi lascia le seguenti conclusioni:

• Gli utenti dovrebbero essere trattati come una risorsa inestimabile e, nel migliore dei casi, come alleati inestimabili per la loro collaborazione nello sviluppo del prodotto.
• Ogni idea è buona o vale la pena esplorare, poiché a volte il meno sospettato può essere un'ottima soluzione o miglioramento per lo sviluppo.
• È positivo o probabile che l'idea originale si divida, si espanda o si allontani dal concetto originale, ma ciò che è importante è quanto si deve essere concentrati in termini di tipo di mercato utente che si desidera servire, servire o aiutare.
• Per essere efficienti ed evitare perdite di fatica dovute alla dispersione.
• Il meglio è un codice piccolo, diretto, semplice, ma efficiente che riesce ad essere apprezzato dalla comunità come corretto.
• Un programma è già maturo per la Community degli utenti, quando non c'è più nulla da eliminare, poiché l'aggiunta è sempre una buona possibilità da tenere in considerazione.
• Qualsiasi programma può essere utilizzato (in parte o in toto) per essere riutilizzato in funzioni non concepite in origine.
• Tutto il Software deve portare le rispettive licenze e misure di sicurezza per la riservatezza dell'uso dei Dati dell'utente.
• Non è necessario partire da zero, qualcuno ha sempre sviluppato qualcosa di simile alla nostra idea concepita.
• Bisogna lavorare su qualcosa che ci piace, bisogna provare passione per lo sviluppo a cui si dedicherà nel Software Libero in modo da generare internamente un senso di unione con quanto elaborato, senza arrivare all'estremo di sviluppare un senso di appartenenza esso.
• Devono esserci mezzi di comunicazione eccellenti e frequenti tra sviluppatori e utenti (collaboratori), in modo che il lavoro scorra rapidamente e cambi in modo efficace.

Spero che questa informazione vi sia piaciuta e che vi sia stata utile, poiché la lettura di "La cattedrale e il bazar" è un riferimento obbligatorio per tutti coloro che programmano qualsiasi sviluppo in software libero, non importa quanto grande o piccolo.