Ο Καθεδρικός και το Παζάρι

The Cathedral and the Bazaar
by Eric S. Raymond

Το Linux είναι ανατρεπτικό. Ποιος θα σκεφτόταν, ακόμη και πριν από πέντε χρόνια , ότι ένα λειτουργικό σύστημα παγκόσμιας εμβέλειας θα φτιαχνόταν, ως δια μαγείας, από τμηματικά hacking που έκαναν χιλιάδες προγραμματιστές σκορπισμένοι σ' όλο τον πλανήτη, ενωμένοι μόνο με τα αδύναμα νήματα του Internet;

Κανείς, βέβαια. Την ώρα που μάθαινα για το Linux στις αρχές του 1993, ασχολούμουνα ήδη με το Unix και τον προγραμματισμό ανοιχτού κώδικα [open source] επί δέκα χρόνια. Ήμουν από τους πρώτους διανεμητές της GNU στα μέσα της δεκαετίας του '80. Είχα κατασκευάσει και διαθέσει έναν σεβαστό αριθμό λογισμικού ανοιχτού κώδικα στο δίκτυο, αναπτύσσοντας ή συναναπτύσσοντας πολλά προγράμματα (nethack, Emacs VC και GUD modes, xlife και άλλα) που παραμένουν σε ευρεία χρήση έως σήμερα. Νόμιζα πως ήξερα πώς είχαν γίνει όλ' αυτά.

Το Linux ανέτρεψε πολλά απ' αυτά που νόμισα ότι ήξερα. Υποστήριζα το "Ευαγγέλιο" των μικρών εργαλείων του Unix, την γρήγορη ανάπτυξη πρωτοτύπων και τον εξελικτικό προγραμματισμό [evolutionary programming] για χρόνια. Πίστευα, όμως, ότι υπάρχει μια συγκεκριμένη κρίσιμη πολυπλοκότητα πάνω από την οποία απαιτούνταν μια περισσότερο κεντρική, απριόρι προσέγγιση. Πίστευα ότι το πιο σημαντικό λογισμικό (λειτουργικά συστήματα και πραγματικά μεγάλα εργαλεία όπως το Emacs) έπρεπε να χτιστούν σαν καθεδρικοί ναοί, προσεχτικά φτιαγμένοι από μεμονωμένους ειδικούς [wizards] ή μικρές ομάδες από "μάγους" [magicians] που να δουλεύουν σε απόλυτη απομόνωση και χωρίς να δημοσιεύονται οι beta πριν την ώρα τους.

Το στυλ προγραμματισμού του Linus Torvalds- πρώιμες και ανά μικρά διαστήματα εκδόσεις λογισμικού, μεταβιβάσεις του κάθε τι, ανοχή στο ζήτημα της ετερογενούς μεγάλης ανάμειξης - ήταν μεγάλη έκπληξη. Δεν έμοιαζε με θρησκευτικό καθεδρικό ναό - η κοινότητα του Linux έμοιαζε περισσότερο με ένα μεγάλο φλύαρο παζάρι διαφορετικών πρακτικών και προσεγγίσεων (που συμβολίζονται με αρχειοθήκες λογισμικού για Linux, στα οποία μπορεί να συνεισφέρει ο καθένας) από το οποίο ένα συνεπές και σταθερό σύστημα μπορούσε να φτιαχτεί μόνο μετά από μια ακολουθία θαυμάτων.

Το γεγονός ότι αυτό το παζάρι έδειχνε να δουλεύει και να δουλεύει καλά, ήταν ένα ξεκάθαρο σοκ. Καθώς ο καιρός περνούσε κι εγώ μάθαινα, δούλευα σκληρά όχι μόνο σε συγκεκριμένα projects, αλλά και προσπαθώντας να καταλάβω γιατί ο κόσμος του Linux όχι μόνο δεν έπεφτε σε σύγχυση αλλά έδειχνε να δυναμώνει συνεχώς, με μια ταχύτητα που δεν την φαντάζονταν οι αρχιτέκτονες καθεδρικών ναών.

Eric S. Raymond

1. Κανένα πρόβλημα δεν πρέπει να λύνεται δύο φορές.
Ένα σημαντικό γνώρισμα των σπουδαίων προγραμματιστών είναι η εγγενής τους τεμπελιά. Ξέρουν ότι χρειάζεται ένα πρόγραμμα όχι για να περνάνε οι χρήστες την ώρα τους αλλά για να έχουν κάποια αποτελέσματα και ότι είναι σχεδόν πάντα ευκολότερο να ξεκινάς από μια μερική λύση από το να ξεκινάς από το μηδέν.

Ο Linus Torvalds, για παράδειγμα, δεν έγραψε το Linux απ' την αρχή. Αντίθετα, ξεκίνησε να ξαναχρησιμοποιεί κώδικα και ιδέες απ' το Minix, ένα μικρό Unix-οϊδές λειτουργικό για μηχανές 386. Τελικά, ο κώδικας Minix απομακρύνθηκε ή ξαναγράφτηκε εντελώς--όσο, όμως, ήταν εκεί λειτουργούσε σαν η σκάλα για το βρέφος που, τελικά, έγινε το Linux.

Η παράδοση ελεύθερου κώδικα του Unix ήταν πάντα φιλική προς την επαναχρησιμοποίηση κώδικα (γι' αυτό τον λόγο το GNU project επέλεξε το Unix σαν βασικό λειτουργικό, παρά τις σοβαρές επιφυλάξεις για το ίδιο το λειτουργικό). Η κοινότητα του Linux ώθησε αυτή την παράδοση σχεδόν στα τεχνολογικά της όρια. Προσφέρει σε όλους terabytes ελεύθερου κώδικα. Έτσι, το να αφιερώνεις λίγο χρόνο για να βρεις την κατάλληλη εφαρμογή κάποιου άλλου είναι περισσότερο πιθανό να δώσει θετικά αποτελέσματα στον κόσμο του Linux, παρά οπουδήποτε αλλού.

2. Η Σπουδαιότητα του να Έχεις Χρήστες.
Μια άλλη δύναμη της παράδοσης του Unix, που το Linux ωθεί στα όριά της, είναι ότι πολλοί χρήστες είναι επίσης και hackers. Επειδή ο πηγαίος κώδικας είναι ελεύθερος, μπορούν να γίνουν αποτελεσματικοί hackers. Κάτι τέτοιο μπορεί να αποδειχθεί εξαιρετικά χρήσιμο για την μείωση του χρόνου αποσφαλμάτωσης [debugging]. Με λίγη ενθάρρυνση, οι χρήστες θα διαγνώσουν προβλήματα, θα προτείνουν διορθώσεις και θα βοηθήσουν στην βελτίωση του κώδικα, πολύ πιο γρήγορα από το να το κάνατε μόνοι σας χωρίς βοήθεια.

Η αντιμετώπιση των χρηστών σαν συνεργάτες προγραμματιστές είναι ο λιγότερο επικίνδυνος δρόμος προς την γρήγορη βελτίωση του κώδικα και την αποτελεσματική αποσφαλμάτωση.

Νομίζω ότι το πιο έξυπνο και αποτελεσματικό κατόρθωμα [hack] του Linus, δεν ήταν η κατασκευή του ίδιου του πυρήνα του Linux αλλά, μάλλον, η εφεύρεση του μοντέλου ανάπτυξης Linux. Όταν, παρουσία του, εξέφρασα αυτή την άποψη εκείνος χαμογέλασε και σιγανά επανέλαβε κάτι που συχνά έλεγε: "Βασικά, είμαι πολύ τεμπέλης άνθρωπος που του αρέσει να του αναγνωρίζουν πράγματα που άλλοι άνθρωποι έκαναν". Τεμπέλης σαν γάτος. Ή, όπως θα έλεγε ο Robert Heinlein, πολύ τεμπέλης για να αποτύχει.

3. Εκδόσεις Νωρίς, Εκδόσεις Συχνά.
Οι πρώιμες και ανά μικρά χρονικά διαστήματα εκδόσεις είναι κρίσιμο μέρος του μοντέλου ανάπτυξης του Linux. Οι περισσότεροι προγραμματιστές (συμπεριλαμβανόμενου και εμένα) πίστευαν ότι αυτό είναι μια κακή πολιτική για μεγαλύτερα από τα τετριμμένα projects, επειδή οι πρώιμες εκδόσεις είναι σχεδόν εξ ορισμού γεμάτες bugs και το μόνο που δεν επιθυμείς είναι να εξαντλείς την υπομονή των χρηστών.

Αυτή η άποψη ενίσχυε την γενική αποδοχή ενός "καθεδρικού" είδους ανάπτυξης. Αν ο κύριος στόχος είναι να συναντούν οι χρήστες όσο το δυνατόν λιγότερα bugs, τότε γιατί να εκδίδεις μια φορά κάθε έξι μήνες (ή και λιγότερο συχνά) και μετά να δουλεύεις σκληρά για να απαλλαχθείς απ' τα bugs; Ο πυρήνας του Emacs C φτιάχτηκε μ' αυτό τον τρόπο. Ενώ αντίθετα, η βιβλιοθήκη Lisp, όχι. Αυτό συνέβη επειδή υπήρχαν ενεργά αρχεία Lisp έξω απ' τον έλεγχο του FSF, στα οποία μπορούσε κανείς να ανατρέξει για να βρει νέες εκδόσεις του κώδικα, ανεξάρτητα απ' τους κύκλους εκδόσεων του Emacs.

Linus Torvalds

4. Ο Νόμος του Linus.

Ο Linus αντιμετώπιζε τους χρήστες του σαν συν-προγραμματιστές με τον καλύτερο δυνατό τρόπο: Εκδόσεις νωρίς, εκδόσεις συχνά και άκου τους χρήστες σου.

Η καινοτομία του Linus δεν ήταν τόσο αυτό (κάτι τέτοιο συνέβαινε για πολύ καιρό στον κόσμο του Unix), αλλά η κλιμάκωσή του σε βαθμό που πλησίαζε την περιπλοκότητα της προς ανάπτυξη εφαρμογής. Εκείνη τη χρονιά (περί το 1992) δεν του ήταν άγνωστη η τακτική να εκδίδει νέο πυρήνα κάθε μέρα! Αυτή η προσπάθεια πέτυχε επειδή ανέπτυσσε την βάση των συν-προγραμματιστών του και χρησιμοποιούσε την δύναμη του Internet για συνεργασία πιο καλά από κάθε άλλον.

Ο Linus ήταν ένας πολύ καλός hacker (πόσοι από εμάς θα κατασκεύαζαν έναν παραγωγικά ποιοτικό πυρήνα λειτουργικού συστήματος;). Όμως το Linux δεν ήταν κανένα τρομερό άλμα προς τα εμπρός. Ο Linus δεν είναι (ή όχι ακόμα) καμιά ιδιοφυΐα στο να σχεδιάζει όπως, ας πούμε, ο Richard Stallman ή ο James Gosling (NeWS και Java). Εμένα μου φαίνεται ότι ο Linus είναι ένας ευφυής προγραμματιστής, με μια έκτη αίσθηση να αποφεύγει τα bugs και προγραμματιστικά αδιέξοδα και εύκολα βρίσκει το πιο σύντομο δρόμο απ' το σημείο Α προς το σημείο Β. Πραγματικά, ολόκληρος ο σχεδιασμός του Linux αποπνέει αυτή την ποιότητα και αντανακλά την ουσιαστικά συντηρητική και απλοϊκή προσέγγιση του Linus.

Αν, λοιπόν, οι γρήγορες εκδόσεις και η πλήρης χρήση του Internet δεν ήταν τυχαία γεγονότα αλλά ολοκληρωμένα μέρη της διορατικότητας του Linus, ποια ήταν η πρωτοτυπία του;
Για να το πω απλά, η ερώτηση απαντάται μόνη της. Επειδή ο Linus κρατούσε τους hackers/χρήστες συνεχώς σε υπερένταση, ήθελε να τους ανταμείψει μέσω των συχνών ανανεώσεων (σχεδόν κάθε μέρα) του project.

Δεδομένης μια μεγάλης βάσης δοκιμαστών beta και συν-προγραμματιστών, σχεδόν κάθε πρόβλημα γρήγορα θα εντοπισθεί κι ένα fix θα κάνει την εμφάνισή του. Ή , λιγότερο τυπικά, "έχοντας αρκετά μάτια, όλα τα bugs είναι ρηχά". Το άλλαξα σε: "Ο Νόμος του Linus".

Η αρχική μου σκέψη ήταν ότι, κάθε πρόβλημα "θα γίνει φανερό σε κάποιον". Ο Linus απάντησε λέγοντας ότι, το πρόσωπο που καταλαβαίνει και διορθώνει το πρόβλημα δεν είναι αναγκαία ή συνήθως το πρόσωπο που πρώτο το ανακαλύπτει. "Κάποιος βρίσκει ένα πρόβλημα", λέει, "και κάποιος άλλος το λύνει. Και η ανακάλυψη του προβλήματος είναι η μεγαλύτερη πρόκληση". Το ζήτημα, όμως, ήταν ότι και τα δύο έτειναν να γίνονται ταχύτατα.

Εδώ, πιστεύω, ότι βρίσκεται η κεντρική διαφορά που υπογραμμίζει τα δύο στυλ προγραμματισμού, το καθεδρικό και το στυλ παζαριού. Από την άποψη του καθεδρικού προγραμματιστή, τα bugs και τα άλλα προβλήματα προγραμματισμού είναι απρόβλεπτα, ύπουλα και βαθιά φαινόμενα. Χρειάζονται μήνες λεπτομερούς εξέτασης από μερικούς αφοσιωμένους ανθρώπους για να κατασκευάσουν έμπιστο κώδικα. Γι' αυτό και τα μεγάλα διαλείμματα μεταξύ των εκδόσεων και η αναπόφευκτη απογοήτευση όταν οι εκδόσεις αυτές, που τόσο καιρό περιμένεις, δεν είναι τέλειες.

Απ' την άποψη του σε "στυλ παζαριού" προγραμματισμού, τα bugs είναι γενικά επιπόλαια φαινόμενα ή, τουλάχιστον, καταλήγουν να γίνουν επιπόλαια όταν εκτίθενται σε χίλιους ανυπόμονους συν-προγραμματιστές που μελετούν κάθε νέα έκδοση. Έτσι, κάνεις συχνές εκδόσεις για να κερδίσεις περισσότερες διορθώσεις και σαν δευτερεύον κέρδος, έχεις λιγότερα να χάσεις αν παρουσιαστεί κάποια περιστασιακή τσαπατσουλιά.

Αν ο "Νόμος του Linus" είναι εσφαλμένος, τότε κάθε σύστημα που είναι τόσο περίπλοκο όσο ο πυρήνας του Linux, που "μαστορεύεται " από τόσα χέρια, θα έπρεπε να καταρρέει κάτω από το βάρος των απρόβλεπτων κακών αλληλεπιδράσεων και καλά κρυμμένων bugs. Αν, από την άλλη είναι σωστός, εξηγεί ικανοποιητικά την σχετική απουσία bugs από το Linux.

Οι κοινωνιολόγοι πριν από χρόνια ανακάλυψαν ότι η μέση γνώμη ενός συνόλου ισοδύναμα ειδικών (ή ισοδύναμα ανίδεων) παρατηρητών είναι περισσότερο αξιόπιστη από εκείνη ενός μοναδικού τυχαία επιλεγμένου παρατηρητή. Αυτό αποκαλείται "Φαινόμενο των Δελφών".

Φαίνεται ότι, αυτό που απέδειξε ο Linus είναι ότι το φαινόμενο αυτό βρίσκει εφαρμογή στην απομάκρυνση των bugs από ένα λειτουργικό σύστημα - ότι το Φαινόμενο των Δελφών μπορεί να ελέγξει την προγραμματιστική πολυπλοκότητα, ακόμη και στο επίπεδο πολυπλοκότητας ενός πυρήνα λειτουργικού συστήματος.

Ο Brooks έκανε μια παρατήρηση σχετικά με εκείνη του Jeff: "Το συνολικό κόστος συντήρησης ενός ευρέως χρησιμοποιούμενου προγράμματος είναι, τυπικά, το 40% ή και περισσότερο του κόστους κατασκευής του. Αυτό το κόστος επηρεάζεται πολύ από τον αριθμό των χρηστών. Περισσότεροι χρήστες βρίσκουν περισσότερα bugs".

Περισσότεροι χρήστες βρίσκουν περισσότερα bugs, επειδή η προσθήκη περισσότερων χρηστών προσθέτει περισσότερους διαφορετικούς τρόπους δοκιμών του προγράμματος. Αυτό το φαινόμενο ενισχύεται όταν οι χρήστες είναι συν-προγραμματιστές. Κάθε προγραμματιστής προσεγγίζει το πρόβλημα με ελαφρά διαφορετικά αντιληπτικά κι αναλυτικά εργαλεία, από διαφορετική γωνιά, σε σύγκριση με άλλους. Το "Φαινόμενο των Δελφών" φαίνεται να έχει ισχύ ακριβώς εξαιτίας αυτής της ποικιλίας. Στο πλαίσιο της κατάργησης των bugs η ποικιλία αυτή τείνει επίσης να μειώσει τον διπλασιασμό της προσπάθειας.

5. Το Κοινωνικό Πλαίσιο του Λογισμικού Ανοιχτού Κώδικα

Στο βιβλίο του "The Mythical Man-Month" ο Fred Brooks παρατηρεί ότι, ο χρόνος του προγραμματιστή δεν είναι ανταλλάξιμος. Η προσθήκη προγραμματιστών σ' ένα καθυστερημένο project λογισμικού το καθυστερεί περισσότερο. Ισχυρίζεται ότι, το κόστος της πολυπλοκότητας και της επικοινωνίας ενός project αυξάνονται γεωμετρικά, ενώ η εργασία που ολοκληρώνεται αυξάνεται αριθμητικά. Αυτή η άποψη έγινε γνωστή σαν "ο Νόμος του Brooks" και αναγνωρίζεται από πολλούς σαν κάτι τελείως πασιφανές. Αλλά αν ο Νόμος του Brooks απέδιδε την όλη εικόνα το Linux θα ήταν αδύνατο να υπάρξει.

Το κλασικό κείμενο "Η Ψυχολογία του Προγραμματισμού με Ηλεκτρονικό Υπολογιστή", του Gerald Weinberg, μας δίνει μια ζωτική διόρθωση της άποψης του Brooks. Στην συζήτησή του για τον "χωρίς εγωισμό" προγραμματισμό ο Weinberg παρατηρεί ότι, σε εργασίες που προγραμματιστές δεν απαιτούν "εδαφικά δικαιώματα" για τον κώδικα τους και ενθαρρύνουν άλλους ανθρώπους να αναζητήσουν bugs και πιθανές βελτιώσεις, η βελτίωση συμβαίνει δραματικά γρηγορότερα από οπουδήποτε αλλού.

Οι επιλογές ορολογίας που έκανε ο Weinberg ίσως εμποδίζουν την ανάλυσή του να κερδίσει την αποδοχή που της αξίζει. Κάποιος θα χαμογελούσε στον χαρακτηρισμό των hackers του Internet σαν "χωρίς εγωισμό". Αλλά πιστεύω ότι οι ισχυρισμοί του μοιάζουν σήμερα περισσότερο επιβλητικοί από ποτέ.

Η ιστορία του Unix θα έπρεπε να μας έχει προετοιμάσει για ό,τι μαθαίνουμε απ' το Linux (και για ότι έχω εγώ διαπιστώσει, πειραματικά και σε μικρότερη κλίμακα όταν σκόπιμα αντέγραψα τις μεθόδους του Linus). Ότι, δηλαδή, ενώ η σύνταξη κώδικα παραμένει μια ουσιωδώς μοναχική δραστηριότητα, οι πραγματικά καλές προγραμματιστικές εργασίες προέρχονται όταν χρησιμοποιείται η προσοχή και η διανοητική δύναμη της ομάδας. Ο προγραμματιστής που χρησιμοποιεί το μυαλό του μόνος ή μόνη σ' ένα κλειστό project θα μείνει πίσω απ' τον προγραμματιστή που ξέρει πώς να δημιουργήσει ένα ανοιχτό, εξελικτικό πλαίσιο στο οποίο ο εντοπισμός των bugs και η επίτευξη βελτιώσεων καταφέρονται από εκατοντάδες ανθρώπων.

Όμως, ο παραδοσιακός κόσμος του Unix εμποδίστηκε στην προσπάθειά του να ωθήσει αυτή την προσέγγιση στην τελική της φάση από πολλούς παράγοντες. Τέτοιοι ήταν οι νομικοί περιορισμοί διαφόρων αδειών χρήσης πνευματικών δικαιωμάτων, επαγγελματικά μυστικά και τα εμπορικά συμφέροντα. Ένας άλλος ήταν ότι το Internet δεν ήταν ακόμη αρκετά καλό.

Το Linux ήταν το πρώτο project που έκανε συνειδητές και επιτυχείς τις προσπάθειες να αξιοποιηθεί ολόκληρος ο κόσμος σαν η δική του δεξαμενή ταλέντων. Δεν νομίζω ότι είναι σύμπτωση ότι η γόνιμη περίοδος του Linux εμφανίζεται την ίδια περίοδο με εκείνη της γέννησης του Παγκόσμιου Ιστού (World Wide Web-WWW) και ότι το Linux εγκατέλειψε την παιδική του ηλικία κατά την περίοδο 1993-1994 κατά την οποία απογειώθηκε η βιομηχανία Παροχέων Υπηρεσιών Internet (ISP) και της έκρηξης του μεγάλου ρεύματος ενδιαφέροντος για το Internet. Ο Linus ήταν ο πρώτος άνθρωπος που έμαθε πώς να παίζει με τους νέους κανόνες που δημιουργούσε το Internet.

Οι σχέσεις μεταξύ των μελών της κοινότητας δε μπορούν να βασίζονται σε σχέσεις εξουσίας-ακόμη κι αν μπορούσαν, η εξαναγκαστική εξουσία δεν μπορεί να επιφέρει τα επιθυμιτά αποτελέσματα.  Ο Weinberg παραθέτει την αυτοβιογραφία του Πιοτρ Αλεξέιεβιτς Κροπότκιν, Ρώσου αναρχικού του 19ου αιώνα, "Οι αναμνήσεις ενός Επαναστάτη".

"Έχοντας ανατραφεί από μια οικογένεια που είχε στην ιδιοκτησία της δουλοπάροικους ξεκίνησα την ζωή μου, όπως όλοι οι νέοι της εποχής μου, με πίστη μεγάλη στην αναγκαιότητα του να διατάζεις, να μαλώνεις, και να τιμωρείς. Αλλά όταν, αρκετά νωρίς, έπρεπε να διοικήσω μεγάλες επιχειρήσεις, να συσχετιστώ με [ελεύθερους] ανθρώπους, και όταν το παραμικρό λάθος μπορούσε να οδηγήσει σε οδυνηρές επιπτώσεις, άρχισα να εκτιμώ την διαφορά μεταξύ της δράσης βάσει των αρχών της εντολής και της πειθαρχίας και της δράσης βάσει της αρχής της κοινής κατανόησης. Οι πρώτες εφαρμόζονται θαυμάσια σε μια στρατιωτική παρέλαση, αλλά δεν αξίζουν τίποτα στην πραγματική ζωή όπου ο στόχος μπορεί να επιτευχθεί μόνο με τη σκληρή προσπάθεια πολλών συγκλινουσών θελήσεων"

Η "σκληρή προσπάθεια πολλών συγκλινουσών θελήσεων" είναι ακριβώς αυτό που απαιτεί το project του Linux-και η "αρχή της διαταγής" είναι αδύνατον να εφαρμοστεί μεταξύ εθελοντών, μέσα στον αναρχικό παράδεισο που λέγεται Internet. Για να λειτουργήσουν και να συναγωνιστούν αποτελεσματικά, οι προγραμματιστές που θέλουν να ηγηθούν ενός συνεργατικού project πρέπει να μάθουν να στρατολογούν και να ενεργοποιούν αποτελεσματικές ομάδες προγραμματιστών με τον τρόπο που προτείνει η "αρχή της κατανόησης" του Κροπότκιν. Πρέπει να μάθουν να χρησιμοποιούν τον Νόμο του Linus.

Κανένας προγραμματιστής κλειστού κώδικα δε μπορεί να συγκεντρώσει όλα αυτά τα ταλέντα που η κοινότητα του Linux μπορεί να απασχολήσει για την επίλυση κάποιου προβλήματος.

Ίσως, στο τέλος, η κουλτούρα του ανοιχτού κώδικα θριαμβεύσει όχι επειδή η συνεργασία είναι ηθικώς ορθή ή η "φραγή" του λογισμικού είναι ηθικώς λανθασμένη (υποθέτω ότι θα συμφωνείτε με το τελευταίο), αλλά απλά επειδή ο κόσμος του κλειστού κώδικα δεν μπορεί να κερδίσει έναν εξελικτικό αγώνα με τις κοινότητες ανοιχτού κώδικα, πολύ περισσότερο στον απαιτούμενο χρόνο για την επίλυση ενός προβλήματος.

Eric S. Raymond

Ο Καθεδρικός και το Παζάρι είναι ένα δοκίμιο του Eric S. Raymond σχετικά με τις μεθόδους μηχανικής λογισμικού. Δημοσιεύτηκε για πρώτη φορά το 1999 και παρουσιάζει τα πλεονεκτήματα του ανοιχτού και ελεύθερου κώδικα σ' αντίθεση με τον κλειστό-ιδιόκτητο, αλλά και τα οφέλη της από κοινού συνεργασίας των μελών μιας παγκόσμιας κοινότητας.