Gratis programvaruutvecklingsmodell: Katedralen och basaren

Katedralen och basaren är ett manifesttypsdokument som utvecklades av Eric S. Raymond år 1.998 för att försöka förklara ur sitt eget perspektiv och erfarenhet (Fetchmail Development) vad han förstod om det framgångsrika skapandet och utvecklingen av Linux och dess relaterade program, särskilt ur perspektivet på skillnaden mellan Software Development Models, som han personligen kallade: Cathedral Model och Bazaar Model.

Och i denna publikation kommer vi att tillhandahålla en analys och sammanfattning av det manifest som är så populärt bland utvecklarna av Free Software Movement. Vilket är tillgängligt fritt och tillgängligt i många delar av webben, men som kan laddas ner från följande webblänk för att komma åt det snabbare: Katedralen och basaren.

INLEDNING

Nämnda material «Katedralen och basaren» presenterar oss för visionen att inom världen av mjukvaruteknik finns ”två helt olika utvecklingsstilar, katedralmodellen, som är tillämplig på de flesta av de utvecklingar som gjorts i den kommersiella programvaruvärlden, jämfört med basarmodellen, mer typiskt för Linux-världen ”.

Betonar att dessa två modeller härrör från motsatta utgångspunkter om karaktären av programfelsökningsprocessenoch om hans speciella teori om vad han kallade Linus's Law som sade följande: "Med tanke på ett tillräckligt antal ögon är alla fel irrelevanta" eller med andra ord: "Med ett tillräckligt antal ögon, alla fel är de små saker".

Och det betonar ordet Hacker, som enligt min mening författaren uttryckte som ett slags högnivåanvändare som kan förstå och effektivt utnyttja ett program, och att upptäcka, föreslå eller implementera korrigeringar eller modifieringar av effektiv form och substans för hela användargruppen.

I andra litteraturer hänvisar detta ord eller begrepp som heter Hacker till:

«en expert, brinner för ett visst ämnesområde, särskilt det tekniska området, och vars syfte är att dra nytta av den kunskapen för godartade ändamål. Det är den personen, vanligtvis en professionell inom ett kunskapsområde, som brinner för kunskap, upptäcker och lär sig nya saker och förstår hur de fungerar, når den punkten att förbättra den med effektiva förslag och förslag, och alltid med avsikt för att dela kunskap eller undvika ett misslyckande eller funktionsstörning i studieobjektet.

Vilket är ett mer universellt och verkligt koncept, eftersom det finns "hackare" inom alla områden av mänsklig kunskap.

DESARROLLO

Av de många som har läst sådant material kommer det säkert att finnas ett stort antal som håller med om att tanken att "Linux är subversiv" uttrycks tydligt där. Men varför?

För tills det ögonblicket fanns en mångfalden av standardiserade programvaruutvecklingsmetoder eller modeller baserade på ett "mer centraliserat och planerat tillvägagångssätt från början" Eftersom handlingen att skapa programvara togs som något förknippat med något som leder till "en viss kritisk komplexitet."

Och det trots att Unix-världen redan existerade, bestående av små verktyg, snabb prototypning och evolutionär programmering, Framväxten av Free Software-utvecklingsfilosofin under Linux tog saken till en annan nivå av sofistikering.

Medan I en värld av privat programvaruutveckling gjordes det på ett "tyst och vördnadsfullt sätt", precis som en katedral är byggd, i världen av fri programvaruutveckling (Linux) gjordes det på ett "högljutt sätt och med flera dagordningar (vägar) och tillvägagångssätt (förslag)", precis som om du var i en stor basar.

Detta fantastiska manifest ger oss flera förutsättningar att kondensera de idéer som uttrycks där angående Free Software Development Model, som är:

LÖMNING # 1

ALLA GODA ARBETEN I PROGRAMVARAN BÖRJAR FÖR ATT VÄNLA EN UTVECKLARENS PERSONLIGA PROBLEM.

Vilket är en obestridlig verklighet för Många av dem som arbetar med fri programvaruutveckling börjar vanligtvis på grund av behovet av att lösa ett personligt problem eller ett kollektivt eller grupps problem, eller för att optimera en process som redan utförts på ett långsammare och / eller repetitivt sätt, som ofta tenderar att bli utmattande och / eller tråkigt för dem som deltar i den och försöker maximera de involverade tid och ansträngningar.

LÖMNING # 2

BRA PROGRAMMERARE VET VAD DU SKRIVER. DEN STÖRSTA VETEN VAD DU SKRIVER OCH ÅTERANVÄNDER.

Alla programmerare vet att det inte är dåligt eller onödigt att börja från grunden när det gäller att utveckla ett program eller en applikation. Men för många som börjar och för andra som redan är kunniga i saken är det välkänt att ibland "Att uppfinna hjulet" inte är särskilt effektivt, men det är bättre att bara optimera det och anpassa det till dina egna behov. Med andra ord är det bättre att skriva om och assimilera så mycket kod som möjligt från andra experter inom området som berör oss för att lösa vår egen mjukvaruutveckling.

LÖMNING # 3

"TÄNKA ATT Kasta bort åtminstone en - du kommer att sluta göra det när som helst."

En bra mjukvaruutvecklare måste veta hur man lyssnar i detalj på vad användarna av deras utveckling säger eller föreslår eller föreslår, eftersom ett program som redan är funktionellt fortfarande kan bli något mycket stort trots att det är funktionellt, något som förlorar norr, en funktionellt monster som gör allt för alla, och i sin tur något som inte är trevligt. Så att lyssna för att gå tillbaka till ursprunget, vinna tillbaka förlorade användare, lägga till nya funktioner, ta bort onödiga, göra programmet mindre, mer specifikt och allmänt, är alltid en bra praxis.

LÖMNING # 4

OM DU HAR RÄTT ATTITUDE FUNNER intressanta problem dig.

En bra attitydförändring och i tid kan innebära en radikal förändring för varje programmerare eller mjukvaruutvecklare i sin nuvarande eller nya utveckling som i sin tur innebär nya fördelar med tid, pengar eller komfort för användarna av deras produkter. Se upp för innovativa sätt att lösa problem som presenterar sig i ett bra symptom i rätt riktning.

LÖMNING # 5

NÄR ETT PROGRAM INTE LÄNGRE intresserar dig, ÄR DIN SISTA SKYDD ATT ÖVERFÖRA DET TILL EN KOMPETENT FRÅGARE.

För många programmerare eller mjukvaruutvecklare, liksom för andra tekniker, är det inte ovanligt att man vill ägna ny tid åt nya projekt. Men i världen av fri programvara är förutsättningen att överföra stafettpinnen, det finns andra som vill fortsätta med utvecklingen av sina redan övergivna produkter, för vilka de måste låta någon hacka (förbättra) programmet för sig själva eller för nytta av programmets användare.

LÖMNING # 6

ATT BEHANDLA DINA ANVÄNDARE SOM SAMARBETSÄGARE ÄR DEN MINSTE KOMPLICERADE VÄGEN FÖR ATT RASKT FÖRBÄTTRA OCH EFFEKTIVT FELLA ETT PROGRAM.

Eftersom "gratis" ofta tolkas som "gratis" i utvecklingen av fri programvara, tenderar många programmerare att gruppera sig för att undvika obetalt slitage genom att samarbeta med andra utvecklare eller avancerade användare av deras utveckling, för att fortsätta dem eller för andra att fortsätta dem, i utbyte mot att ta emot "krediter" i utvecklingen av framtida kodinnovationer och se till att framtida utvecklingar formellt inkluderar viss licensiering, för att undvika missbruk av den.

LÖMNING # 7

Släpp snart. LANSERA DET OFTA. OCH lyssna på dina användare.

Till skillnad från i världen med egenutvecklad mjukvaruutveckling, i fri programvara är det ofta så att mycket och snabbt är bättre. Eftersom den breda basen av användare och utvecklare som vanligtvis använder och utvecklar ett program i samhället och i sin tur interagerar med varandra, för att kommunicera sina tvivel, förslag, förslag, klagomål och / eller påståenden, kan det bli en värdefull kunskapskälla för att snabbt utveckla ett program mot mogna utvecklingsstadier.

LÖMNING # 8

GIVER EN BRED TILLGÄNGLIG BAS AV TESTARE OCH BIDRAGARE, NÄST ALLA PROBLEM KAN IDENTIFIERAS SNABBT OCH DERES LÖSNING KOMMER ÖVERSIKT FÖR NÅGON.

Materialet avslutas med att få läsaren att dra slutsatsen att mjukvaruutvecklingsmetoden baserad på basarmodellen är mycket effektiv. Eftersom ju mer kraft, frihet eller kunskap en programutvecklare tillhandahåller användare om deras program, desto mer kan de bidra med geniala idéer eller användbara förändringar, bara för kollektiva fördelar.

Och detta uttrycks behagligt i följande utdrag ur materialet:

"Detta är, tror jag, den grundläggande skillnaden mellan katedralen och basaren. Enligt hur en katedral ser på programmering är misstag och utvecklingsproblem smygande, djupa och vridna fenomen. Det tar månader av granskning av ett litet antal dedikerade personer för att vara säkra på att de har tagits bort. Därför är de långa perioder som krävs för att släppa nya versioner och den oundvikliga besvikelsen som upplevs när de som har väntats så länge inte är perfekta.

Mot bakgrund av basarmodellen antas dock att fel vanligtvis är mindre saker eller åtminstone att de kommer att bli så ganska snabbt när de utsätts för de ivriga ögonen på några tusen dedikerade medarbetare för att sätta rätt och rätt tvärtom varje ny version. Så du fortsätter att släppa versioner ofta för att få ännu fler korrigeringar, och som en fördelaktig biverkning har du mindre att förlora om du förstör då och då. "

SLUTSATS

Personligen lämnar min lilla erfarenhet inom området fri programvaruutveckling under basmodellen följande slutsatser:

• Användare bör behandlas som en ovärderlig resurs och i bästa fall som ovärderliga allierade för deras samarbete i utvecklingen av produkten.
• Varje idé är bra eller värt att utforska, eftersom de minst misstänkta ibland kan vara en bra lösning eller förbättring för utveckling.
• Det är bra eller troligt att den ursprungliga idén delar sig, expanderar eller flyttar sig bort från det ursprungliga konceptet, men det som är viktigt är hur fokuserad man ska vara när det gäller vilken typ av användarmarknad du vill betjäna, tjäna eller hjälpa till.
• För att vara effektiv och undvika förlust av ansträngning på grund av spridning.
• Det bästa är en liten, direkt, enkel men effektiv kod som lyckas uppskattas av samhället som korrekt.
• Ett program är redan moget för användargemenskapen när det inte finns något mer att eliminera, eftersom tillägg alltid är en bra möjlighet att ta hänsyn till.
• Vilket program som helst kan användas (helt eller delvis) för att återanvändas i funktioner som inte ursprungligen var tänkta.
• All programvara måste bära sina respektive licens- och säkerhetsåtgärder för konfidentialitet för användningen av användarens data.
• Det är inte nödvändigt att börja från grunden, någon har alltid utvecklat något som liknar vår tänkta idé.
• Man måste arbeta med något som man gillar, man måste känna passion för den utveckling som han kommer att ägna sig åt i fri programvara för att internt skapa en känsla av förening med det som utvecklas, utan att nå det yttersta att utveckla en känsla av ägande över det.
• Det måste finnas utmärkta och frekventa kommunikationsmedel mellan utvecklare och användare (kollaboratörer), så att arbetet flyter snabbt och ändras effektivt.

Jag hoppas att du gillade och tyckte att den här informationen var användbar, eftersom läsningen av "Katedralen och basaren" är en obligatorisk referens för alla som programmerar fri programvaruutveckling, oavsett hur stor eller liten.