Free Software Development Model: The Cathedral and the Bazaar

De kathedraal en de bazaar is een manifest-achtig document ontwikkeld door Eric S. Raymond in het jaar 1.998 om te proberen uit te leggen vanuit zijn eigen perspectief en ervaring (Fetchmail Development) wat hij begreep over de succesvolle creatie en evolutie van Linux en zijn verwante programma's, vooral vanuit het perspectief van het verschil tussen de Software Development Models, die hij persoonlijk noemde: het Cathedral Model en het Bazaar Model.

En in deze publicatie zullen we een analyse en samenvatting geven van het manifest dat zo populair is onder de ontwikkelaars van de Vrije Software Beweging. Die gratis beschikbaar en toegankelijk is in veel delen van het web, maar die kan worden gedownload via de volgende weblink om er sneller toegang toe te krijgen: De kathedraal en de bazaar.

INLEIDING

Genoemd materiaal «De kathedraal en de bazaar» geeft ons de visie dat er binnen de wereld van Software Engineering “twee totaal verschillende stijlen van ontwikkeling, het kathedraalmodel, toepasbaar op de meeste ontwikkelingen in de wereld van commerciële software, vergeleken met het bazaarmodel, meer typerend voor de Linux-wereld ”.

Benadrukkend dat deze 2 modellen zijn afgeleid van tegengestelde uitgangspunten over de aard van het software debugging proces, en van zijn specifieke theorie over wat hij de wet van Linus noemde, die het volgende stelde: "Gegeven een voldoende aantal ogen, zijn alle fouten irrelevant" of met andere woorden: "Met een voldoende aantal ogen zijn alle fouten kleinigheden".

En het benadrukt het woord Hacker, dat naar mijn mening de auteur uitdrukte als een soort gebruiker op hoog niveau die in staat is een programma te begrijpen en efficiënt te exploiteren, en om correcties of wijzigingen van efficiënte vorm en inhoud voor de hele gebruikersgemeenschap op te sporen, voor te stellen of door te voeren.

In andere literatuur verwijst dit woord of concept genaamd Hacker naar:

«een expert, gepassioneerd over een bepaald vakgebied, vooral het technologische gebied, en wiens doel het is om van deze kennis te profiteren voor goedaardige doeleinden. Het is die persoon, meestal een professional in een kennisgebied, die gepassioneerd is door kennis, nieuwe dingen ontdekt en leert en begrijpt hoe ze werken, het punt bereikt om het te verbeteren met effectieve suggesties en voorstellen, en altijd met de bedoeling kennis te delen of een storing of storing van het studieobject te voorkomen.

Dat is een meer universeel en reëel concept, aangezien er "hackers" zijn op alle gebieden van menselijke kennis.

DESARROLLO

Van de velen die dergelijk materiaal hebben gelezen, zal er zeker een groot aantal zijn die het ermee eens zullen zijn dat het idee dat "Linux subversief is" daar duidelijk tot uiting komt. Maar waarom?

Omdat er tot dat moment een veelvoud aan gestandaardiseerde methoden of modellen voor softwareontwikkeling op basis van een "meer gecentraliseerde en geplande aanpak vanaf het begin" omdat het maken van software werd opgevat als iets dat verband houdt met iets dat leidt tot "een bepaalde kritische complexiteit".

En dat ondanks het feit dat de Unix-wereld al bestond, bestaande uit kleine tools, rapid prototyping en evolutionair programmeren, De opkomst van de ontwikkelingsfilosofie van Vrije Software onder Linux bracht de zaak naar een ander niveau van verfijning.

Terwijl In de wereld van Private Software Development gebeurde het op een "stille en eerbiedige manier", net zoals een kathedraal wordt gebouwd, in de wereld van vrije softwareontwikkeling (Linux) werd het gedaan op een "onstuimige manier en met meerdere agenda's (paden) en benaderingen (voorstellen)", net alsof je in een grote bazaar bent.

Dit geweldige manifest geeft ons verschillende uitgangspunten om de ideeën die daar worden uitgedrukt, samen te vatten in termen van het Free Software Development Model, namelijk:

PREMISE # 1

ALLE GOEDE WERKZAAMHEDEN IN SOFTWARE BEGINNEN MET EEN PERSOONLIJK PROBLEEM VAN EEN ONTWIKKELAAR.

Dat is een onmiskenbare realiteit omdat Veel van degenen die in Vrije Software Ontwikkeling werken, beginnen meestal vanwege de behoefte om een ​​persoonlijk probleem of dat van een collectief of groep op te lossen, of om een ​​proces te optimaliseren dat al op een langzamere en / of repetitieve manier wordt uitgevoerd, dat vaak de neiging heeft om uitputtend en / of saai te worden voor degenen die eraan deelnemen, waarbij wordt geprobeerd de tijd en inspanningen van de betrokkenen te maximaliseren.

PREMISE # 2

GOEDE PROGRAMMERS WETEN WAT TE SCHRIJVEN. DE BESTE WETEN WAT TE HERSCHRIJVEN EN HERGEBRUIKEN.

Elke programmeur weet dat helemaal opnieuw beginnen niets slechts of onnodig is als het gaat om het ontwikkelen van een programma of applicatie. Echter, voor velen die beginnen en voor anderen die al kennis hebben van de materie, is het algemeen bekend dat "Het wiel uitvinden" soms niet erg efficiënt is, maar het is beter om het gewoon te optimaliseren en aan te passen aan je eigen behoeften. Dat wil zeggen, het is beter om alle mogelijke code van andere experts in het veld die ons aangaan te herschrijven en te assimileren om onze eigen softwareontwikkeling op te lossen.

PREMISE # 3

"DENK ER AAN ER MINSTENS ÉÉN UIT TE WERPEN - JE ZULT HET EINDELIJK DOEN."

Een goede softwareontwikkelaar moet weten hoe hij in detail moet luisteren naar wat de gebruikers van hun ontwikkelingen zeggen, suggereren of voorstellen, aangezien een programma dat al functioneel is, toch iets heel groots kan worden, ondanks dat het functioneel is, iets dat het noorden verliest, een functioneel monster dat alles voor iedereen doet, en op zijn beurt iets niet erg prettig. Dus luisteren om terug te gaan naar de wortels, verloren gebruikers terug te winnen, nieuwe functies toe te voegen, onnodige functies te verwijderen, het programma kleiner, specifieker en algemeener te maken, is altijd een goede gewoonte.

PREMISE # 4

ALS JE DE JUISTE HOUDING HEBT, VINDEN INTERESSANTE PROBLEMEN JE.

Een goede mentaliteitsverandering en op tijd kan voor elke programmeur of softwareontwikkelaar een radicale verandering betekenen in hun huidige of nieuwe ontwikkelingen die op hun beurt weer nieuwe voordelen in tijd, geld of comfort betekenen voor de gebruikers van hun producten. Zoek naar innovatieve manieren om problemen op te lossen die zich voordoen als een goed symptoom in de goede richting.

PREMISE # 5

WANNEER EEN PROGRAMMA U NIET MEER INTERESSANT IS, IS UW LAATSTE PLICHT OM HET OVER TE GEVEN AAN EEN BEVOEGDE OPVOLGER.

Voor veel programmeurs of softwareontwikkelaars, maar ook voor andere technologen, is het niet ongebruikelijk dat ze nieuwe tijd willen besteden aan nieuwe projecten. Maar in de wereld van Vrije Software is het uitgangspunt om het stokje door te geven, er zijn anderen die willen doorgaan met de ontwikkeling van hun reeds verlaten producten, waarvoor ze iedereen moeten toestaan ​​het programma voor zichzelf of voor de ander te hacken (verbeteren). voordeel van de gemeenschapsgebruikers van het programma.

PREMISE # 6

UW GEBRUIKERS ALS MEDEWERKERS BEHANDELEN, IS DE MINDER INGEWIKKELDE MANIER OM EEN PROGRAMMA SNEL TE VERBETEREN EN EFFECTIEF TE DEBUGGEN.

Omdat "gratis" vaak wordt geïnterpreteerd als "gratis" bij de ontwikkeling van Vrije Software, hebben veel programmeurs de neiging om samen te werken om onbetaalde slijtage te voorkomen door samen te werken met andere ontwikkelaars of geavanceerde gebruikers van hun ontwikkelingen, om ze voort te zetten of om anderen door te laten gaan. ze, in ruil voor het ontvangen van "credits" voor de ontwikkeling van toekomstige code-innovaties en ervoor te zorgen dat toekomstige ontwikkelingen formeel enige licenties omvatten, om misbruik ervan te voorkomen.

PREMISE # 7

BINNENKORT RELEASE. LANCEER HET VAAK. EN LUISTER NAAR UW GEBRUIKERS.

Anders dan in de wereld van propriëtaire softwareontwikkeling, is het bij vrije software vaak zo dat veel en snel beter is. Aangezien de brede basis van gebruikers en ontwikkelaars die gewoonlijk een programma in de gemeenschap gebruiken en ontwikkelen en op hun beurt met elkaar communiceren, om hun twijfels, suggesties, voorstellen, klachten en / of beweringen kenbaar te maken, kan dit een waardevolle bron van kennis worden om snel een programma ontwikkelen naar volwassen ontwikkelingsstadia.

PREMISE # 8

AANGEZIEN EEN BREED GENOEG BASIS VAN TESTERS EN MEDEWERKERS, ZULLEN BIJNA ALLE PROBLEMEN SNEL WORDEN GEÏDENTIFICEERD EN ZAL HUN OPLOSSING VOOR IEMAND DUIDELIJK ZIJN.

Het materiaal doet de lezer vaak tot de conclusie komen dat de Software Development Method op basis van het Bazaar-model zeer effectief is. Want hoe meer macht, vrijheid of kennis een softwareontwikkelaar gebruikers geeft over hun programma, hoe meer ze ingenieuze ideeën of nuttige veranderingen kunnen inbrengen, alleen met als doel collectief voordeel.

En dit komt aangenaam tot uiting in het volgende fragment uit het materiaal:

"Dit is, denk ik, het fundamentele verschil tussen de stijlen van de kathedraal en de bazaar. Volgens de manier waarop een kathedraal naar programmeren kijkt, zijn fouten en ontwikkelingsproblemen verraderlijke, diepe en verwrongen verschijnselen. Het duurt maanden van onderzoek door een klein aantal toegewijde mensen om er zeker van te zijn dat ze zijn verwijderd. Vandaar de lange perioden die nodig zijn voor het uitbrengen van nieuwe versies, en de onvermijdelijke teleurstelling die wordt ervaren wanneer degenen waarop zo lang is gewacht niet perfect zijn.

In het licht van het bazaar-model wordt echter aangenomen dat fouten normaal gesproken ondergeschikt zijn, of in ieder geval dat ze zo snel zullen worden als ze worden blootgesteld aan de gretige ogen van een paar duizend toegewijde medewerkers om het goede en het goede andersom elke nieuwe versie. Dus je blijft regelmatig versies uitbrengen om nog meer fixes te krijgen, en als gunstige bijwerking heb je minder te verliezen als je af en toe een fout maakt. "

GEVOLGTREKKING

Persoonlijk laat mijn kleine ervaring op het gebied van Vrije Software Ontwikkeling onder het Bazaar-type Model mij de volgende conclusies trekken:

• Gebruikers moeten worden behandeld als een hulpmiddel van onschatbare waarde, en in het beste geval als bondgenoten van onschatbare waarde voor hun samenwerking bij de ontwikkeling van het product.
• Elk idee is goed of het ontdekken waard, aangezien soms het minst verdachte een geweldige oplossing of verbetering voor ontwikkeling kan zijn.
• Het is goed of waarschijnlijk dat het oorspronkelijke idee zich verdeelt, uitbreidt of afwijkt van het oorspronkelijke concept, maar wat belangrijk is, is hoe gefocust men moet zijn in termen van het type gebruikersmarkt dat u wilt bedienen, bedienen of helpen.
• Om efficiënt te zijn en verlies van inspanning door verspreiding te vermijden.
• Het beste is een kleine, directe, eenvoudige, maar efficiënte code die door de gemeenschap als correct wordt gewaardeerd.
• Een programma is al volwassen voor de gemeenschap van gebruikers, terwijl er niets meer te schrappen valt, aangezien toevoegen altijd een goede mogelijkheid is om rekening mee te houden.
• Elk programma kan (gedeeltelijk of geheel) worden gebruikt om te worden hergebruikt in functies die oorspronkelijk niet waren bedacht.
• Alle software moet zijn respectieve licentie- en beveiligingsmaatregelen dragen voor de vertrouwelijkheid van het gebruik van de gegevens van de gebruiker.
• Het is niet nodig om helemaal opnieuw te beginnen, iemand heeft altijd iets ontwikkeld dat lijkt op ons bedachte idee.
• Je moet aan iets werken dat je leuk vindt, je moet passie voelen voor de ontwikkeling waaraan je je in Vrije Software zult wijden om intern een gevoel van eenheid te creëren met wat er is uitgewerkt, zonder het uiterste te bereiken van het ontwikkelen van een gevoel van eigendom over het.
• Er moeten uitstekende en frequente communicatiemiddelen zijn tussen ontwikkelaars en gebruikers (medewerkers), zodat het werk snel stroomt en effectief verandert.

Ik hoop dat je deze informatie leuk vond en nuttig vond, aangezien de lezing van "The Cathedral and the Bazaar" een verplichte referentie is voor iedereen die Vrije Software Ontwikkeling programmeert, hoe groot of klein ook.