Οι πρώιμες και ανά μικρά χρονικά διαστήματα εκδόσεις είναι κρίσιμο μέρος του μοντέλου ανάπτυξης του Linux. Οι περισσότεροι προγραμματιστές (συμπεριλαμβανόμενου και εμένα) πίστευαν ότι αυτό είναι μια κακή πολιτική για μεγαλύτερα από τα τετριμμένα projects, επειδή οι πρώιμες εκδόσεις είναι σχεδόν εξ ορισμού γεμάτες bugs και το μόνο που δεν επιθυμείς είναι να εξαντλείς την υπομονή των χρηστών σου.
Αυτή η άποψη ενίσχυε την γενική αποδοχή ενός "καθεδρικού" είδους ανάπτυξης. Αν ο κύριος στόχος είναι να συναντούν οι χρήστες όσο το δυνατόν λιγότερα bugs, τότε γιατί να εκδίδεις μια φορά κάθε έξη μήνες (ή και λιγότερο συχνά) και μετά να δουλεύεις σκληρά (like a dog) για να απαλλαχθείς απ' τα bugs; Ο πυρήνας του Emacs C φτιάχτηκε μ' αυτό τον τρόπο. Ενώ αντίθετα, η βιβλιοθήκη Lisp όχι, αυτό συνέβη επειδή υπήρχαν ενεργά αρχεία Lisp έξω απ' τον έλεγχο του FSF, στα οποία μπορούσε κανείς να ανατρέξει για να βρει νέες εκδόσεις του κώδικα, ανεξάρτητα απ' τους κύκλους εκδόσεων του Emacs.
Η πιο σημαντική απ' αυτές τις αρχειοθήκες, η elisp του Οχάιο, προέβλεπε το πνεύμα και πολλά απ' τα χαρακτηριστικά των σημερινών μεγάλων αρχειοθηκών του Linux. Αλλά λίγοι από μας σκέφτονταν πραγματικά πολύ για το τι κάναμε, ή για το τι σήμαινε η ύπαρξη αυτών των αρχειοθηκών για το πρόβλημα του "καθεδρικού" μοντέλου ανάπτυξης του FSF. Έκανα μια σοβαρή προσπάθεια γύρω στο 1992 να προσαρτήσω μεγάλο μέρος του κώδικα του Οχάιο στην επίσημη βιβλιοθήκη του Emacs Lisp. Μπήκα σε πολιτικούς μπελάδες και η αποτυχία μου ήταν μεγάλη.
Όμως, ένα χρόνο μετά, καθώς το Linux γινόταν ευρύτερα γνωστό, έγινε ξεκάθαρο ότι κάτι διαφορετικό και υγιέστερο συμβαίνει. Το ανοιχτό μοντέλου ανάπτυξης του Linus ήταν το άκρως αντίθετο του "καθεδρικού" μοντέλου. Έκαναν την εμφάνισή τους οι αρχειοθήκες sunsite και tsx-11 καθώς και πολλαπλές διανομές. Κι όλ' αυτά οδηγούμενα από μια αναπάντεχη συχνότητα εκδόσεων του πυρήνα του συστήματος.
Ο Linus αντιμετώπιζε τους χρήστες του σαν συν-προγραμματιστές με τον καλύτερο δυνατό τρόπο:
7.Εκδόσεις νωρίς, εκδόσεις συχνά και άκου τους χρήστες σου.
Η καινοτομία του Linus δεν ήταν τόσο αυτό (κάτι τέτοιο συνέβαινε για πολύ καιρό στον κόσμο του Unix), αλλά η κλιμάκωσή του σε βαθμό που πλησίαζε την περιπλοκότητα της προς ανάπτυξη εφαρμογής. Εκείνη τη χρονιά (περί το 1992) δεν του ήταν άγνωστη η τακτική να εκδίδει νέο πυρήνα κάθε μέρα! Αυτή η προσπάθεια πέτυχε επειδή ανέπτυσσε την βάση των συν-προγραμματιστών του και χρησιμοποιούσε την δύναμη του Internet για συνεργασία πιο καλά από κάθε άλλον.
Αλλά πώς τα κατάφερε; Και ήταν κάτι που μπορούσα να μιμηθώ ή βασιζόταν σε κάποια μοναδική ευφυία του Linus Torvalds;
Ο Linus ήταν ένας πολύ καλός hacker (πόσοι από εμάς θα κατασκεύαζαν έναν παραγωγικά ποιοτικό πυρήνα λειτουργικά συστήματος;). Το Linux δεν ήταν κανένα τρομερό άλμα προς τα εμπρός. Ο Linus δεν είναι (ή όχι ακόμα) καμιά ιδιοφυία στο να σχεδιάζει όπως, ας πούμε, ο Richard Stallman ή ο James Gosling (NeWS και Java). Εμένα μου φαίνεται ότι ο Linus είναι ένας ευφυής προγραμματιστής, με μια έκτη αίσθηση να αποφεύγει τα bugs και προγραμματιστικά αδιέξοδα και εύκολα βρίσκει το πιο σύντομο δρόμο απ' το σημείο Α προς το σημείο Β. Πραγματικά, ολόκληρος ο σχεδιασμός του Linux αποπνέει αυτή την ποιότητα και αντανακλά την ουσιαστικά συντηρητική και απλοποιητική προσέγγιση του Linus.
Αν, λοιπόν, οι γρήγορες εκδόσεις και η πλήρης χρήση του Internet δεν ήσαν τυχαία γεγονότα αλλά ολοκληρωμένα μέρη της διορατικότητας του Linus, ποια ήταν η πρωτοτυπία του;
Για να το πω απλά, η ερώτηση απαντάται μόνη της. Ο Linus κρατούσε του hackers/χρήστες συνεχώς σε υπερένταση και τους αντάμειβε-σε υπερένταση μέσω του project ή διατηρώντας ένα εγωιστικό κομμάτι της όλης δράσης και τους αντάμειβε με την σταθερά (σχεδόν κάθε μέρα) βελτίωση της εργασία τους.
Ο Linus σκόπευε άμεσα στην μεγιστοποίηση του αριθμού ανθρωποωρών στην κατάργηση των bugs και στην ανάπτυξη, ακόμη και με πιθανό κόστος την αστάθεια του κώδικα ή την αχρήστευση της βάσης των χρηστών του, αν ένα σοβαρό bug αποδεικνυόταν ατίθασο. Ο Linus συμπεριφερόταν σαν να πίστευε στο εξής:
8. Δεδομένης μια μεγάλης βάσης δοκιμαστών beta και συν-προγραμματιστών, σχεδόν κάθε πρόβλημα γρήγορα θα εντοπισθεί κι ένα fix θα κάνει την εμφάνισή του.
Ή , λιγότερο τυπικά, "έχοντας αρκετά μάτια, όλα τα bugs είναι ρηχά". Το άλλαξα σε: "Ο Νόμος του Linus".
Η αρχική μου σκέψη ήταν ότι, κάθε πρόβλημα "θα γίνει φανερό σε κάποιον". Ο Linus απάντησε λέγοντας ότι, το πρόσωπο που καταλαβαίνει και διορθώνει το πρόβλημα δεν είναι αναγκαία ή συνήθως το πρόσωπο που πρώτο το χαρακτηρίζει. "Κάποιος βρίσκει ένα πρόβλημα", λέει, "και κάποιος άλλος το καταλαβαίνει. Και η ανακάλυψη του προβλήματος είναι η μεγαλύτερη πρόκληση". Το ζήτημα, όμως, ήταν ότι και τα δύο έτειναν να γίνονται ταχύτατα.
Εδώ, πιστεύω, ότι βρίσκεται η κεντρική διαφορά που υπογραμμίζει τα δύο στυλ προγραμματισμού, το καθεδρικό και το στυλ παζαριού. Από την άποψη του καθεδρικού προγραμματιστή, τα bugs και τα άλλα προβλήματα προγραμματισμού είναι απρόβλεπτα, ύπουλα, βαθιά φαινόμενα. Χρειάζονται μήνες λεπτομερούς εξέτασης από μερικούς αφοσιωμένους ανθρώπους για να κατασκευάσουν έμπιστο κώδικα. Γι' αυτό και τα μεγάλα διαλείμματα μεταξύ των εκδόσεων και η αναπόφευκτη απογοήτευση όταν οι εκδόσεις αυτές, που τόσο καιρό περιμένεις, δεν είναι τέλειες.
Απ' την άποψη του σε "στυλ παζαριού" προγραμματισμού, τα bugs είναι γενικά επιπόλαια φαινόμενα-ή, τουλάχιστον, καταλήγουν να γίνουν επιπόλαια όταν εκτίθενται σε χίλιους ανυπόμονους συν-προγραμματιστές που μελετούν κάθε νέα έκδοση. Έτσι, κάνεις συχνές εκδόσεις για να κερδίσεις περισσότερες διορθώσεις και σαν δευτερεύον κέρδος, έχεις λιγότερα να χάσεις αν παρουσιαστεί κάποια περιστασιακή τσαπατσουλιά
Αν ο "Νόμος του Linus" είναι εσφαλμένος, τότε κάθε σύστημα που είναι τόσο περίπλοκο όσο ο πυρήνας του Linux, που "μαστορεύεται " από τόσα χέρια, θα έπρεπε να καταρρέει κάτω από το βάρος των απρόβλεπτων κακών αλληλεπιδράσεων και καλά κρυμμένων bugs. Αν, από την άλλη είναι σωστός, εξηγεί ικανοποιητικά την σχετική απουσία bugs από το Linux.
Ως προς αυτό, δεν θα έπρεπε να αποτελεί έκπληξη. Οι κοινωνιολόγοι πριν από χρόνια ανακάλυψαν ότι η μέση γνώμη ενός συνόλου ισοδύναμα ειδικών (ή ισοδύναμα ανίδεων) παρατηρητών είναι λίγο περισσότερο αξιόπιστη από εκείνη ενός μοναδικού τυχαία επιλεγμένου παρατηρητή. Αυτό αποκαλείται "Φαινόμενο των Δελφών". Φαίνεται ότι, αυτό που απέδειξε ο Linus είναι ότι το φαινόμενο αυτό βρίσκει εφαρμογή στην απομάκρυνση των bugs από ένα λειτουργικό σύστημα - ότι το Φαινόμενο των Δελφών μπορεί να ελέγξει την προγραμματιστική πολυπλοκότητα, ακόμη και στο επίπεδο πολυπλοκότητας ενός πυρήνα λειτουργικού συστήματος.
Είμαι υποχρεωμένος στον Jeff Dutky (dutky@wam.umd.edu) που υπέδειξε ότι ο Νόμος του Linus μπορεί να παραφρασθεί σε "Η Κατάργηση των Bugs Μπορεί να Παραλληλισθεί". Ο Jeff παρατηρεί ότι, αν και η κατάργηση των bugs απαιτεί από αυτούς που το πραγματοποιούν να επικοινωνούν με κάποιον συνεργαζόμενο προγραμματιστή, δεν απαιτεί σημαντικό συντονισμό μεταξύ των πρώτων. Έτσι, η κατάργηση των bugs δεν πέφτει στην παγίδα της ίδιας δευτεροβάθμιας πολυπλοκότητας και εξόδων management που καθιστούν την αύξηση των προγραμματιστών στην εργασία προβληματική.
Στην πράξη, η θεωρητική απώλεια αποτελεσματικότητας εξαιτίας του διπλασιασμού της εργασίας των προγραμματιστών για την κατάργηση των bugs σχεδόν ποτέ δεν απασχολεί τον κόσμο του Linux. Ένα αποτέλεσμα της "πολιτικής συχνών και πρωίμων εκδόσεων" είναι η ελαχιστοποίηση τέτοιων διπλασιασμών με την γρήγορη αναδραστική [fed-back] διάδοση των διορθώσεων.
Ο Brooks έκανε μια παρατήρηση σχετικά με εκείνη του Jeff: "Το συνολικό κόστος συντήρησης ενός ευρέως χρησιμοποιούμενου προγράμματος είναι, τυπικά, το 40% ή και περισσότερο του κόστους κατασκευής του. Αυτό το κόστος επηρεάζεται πολύ από τον αριθμό των χρηστών. Περισσότεροι χρήστες βρίσκουν περισσότερα bugs".
Περισσότεροι χρήστες βρίσκουν περισσότερα bugs, επειδή η προσθήκη περισσότερων χρηστών προσθέτει περισσότερους διαφορετικούς τρόπους δοκιμών του προγράμματος. Αυτό το φαινόμενο ενισχύεται όταν οι χρήστες είναι συν-προγραμματιστές. Κάθε προγραμματιστής προσεγγίζει την εργασία χαρακτηρισμού του bug με ελαφρά διαφορετικά αντιληπτικά κι αναλυτικά εργαλεία, από διαφορετική γωνιά, σε σύγκριση με άλλους. Το "Φαινόμενο των Δελφών" φαίνεται να έχει ισχύει ακριβώς εξαιτίας αυτής της ποικιλίας. Στο πλαίσιο της κατάργησης των bugs η ποικιλία αυτή τείνει επίσης να μειώσει τον διπλασιασμό της προσπάθειας.
Έτσι, η προσθήκη περισσότερων δοκιμαστών ίσως δεν μειώνει την πολυπλοκότητα του δύσκολου bug, από την σκοπιά του προγραμματιστή, αυξάνει όμως την πιθανότητα ότι τα εργαλεία κάποιου προγραμματιστή θα ταιριάξουν με το πρόβλημα με τέτοιο τρόπο ώστε το bug να καθίσταται επιπόλαιο γι' αυτό το πρόσωπο.
Ο Linus, όμως, φυλάει και τα ρούχα του. Σε περίπτωση που υπάρχουν σοβαρά bugs, η έκδοση του πυρήνα αριθμείται με τέτοιο τρόπο ώστε οι χρήστες να είναι σε θέση να επιλέξουν είτε την εγκατάσταση της τελευταίας "σταθερής" έκδοσης ή να ρισκάρουν με bugs για να απολαύσουν νέα χαρακτηριστικά. Αυτή η τακτική δεν βρίσκει μιμητές ανάμεσα στους hackers του Linux, αλλά ίσως θα έπρεπε. Το γεγονός ότι και οι δύο επιλογές είναι στην διάθεση των χρηστών τις κάνει ελκυστικές._