Author Archive

Μία από τις σημαντικότερες διαφορές μεταξύ “ανοικτού” και “κλειστού” λογισμικού είναι ο τρόπος οργάνωσης των ομάδων εργασίας. Ο Eric S. Raymond στο “The Cathedral and the Bazaar” (1996) περιγράφει πώς αν στο “κλειστό” λογισμικό επικρατεί μία οργάνωση που θυμίζει καθεδρικό ναό τότε η κατάσταση στο στο “ανοικτό” λογισμικό θα μπορούσε να παρομοιαστεί με παζάρι.

Γράφει ο E.S.R (τα bold δικά μου):

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

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

Σίγουρα όχι εγώ. Μέχρι το Linux να μπει στο ραντάρ μου, στις αρχές του 1993, ήμουν ήδη αναμεμιγμένος στην ανάπτυξη προγραμμάτων στο Unix και το ανοικτό λογισμικό για δέκα χρόνια. Ήμουν ένας από τους πρώτους που έκαναν συνεισφορές στο GNU, στα μέσα της δεκαετείας του ‘80. Είχα δημοσιεύσει στο Internet μία σεβαστή ποσότητα ανοικτού λογισμικού, που είχα αναπτύξει είτε μόνος μου είτε μαζί με άλλους (nethack, τα VC και GUD modes για το Emacs, xlife και άλλα) και που χρησιμοποιείται ευρέως σήμερα. Νόμιζα ότι ήξερα πώς γίνεται.

Το Linux ανέτρεψε πολλά από αυτά που νόμιζα ότι ήξερα. Κήρυσσα επί χρόνια το Ευαγγέλιο του Unix υμνώντας τα μικρά εργαλεία, την γρήγορη ανάπτυξη πρωτοτύπων, τον εξελικτικό προγραμματισμό. Όμως, πίστευα επίσης ότι υπάρχει ένα κρίσιμο σημείο στην πολυπλοκότητα, μετά το οποίο θα απαιτούνταν μία πιο κεντρική, επιβεβλημένη από πριν, προσέγγιση. Πίστευα ότι τα πιο σημαντικά κομμάτια λογισμικού (λειτουργικά συστήματα και πραγματικά μεγάλα εργαλεία όπως ο editor Emacs για προγραμματιστές) χρειάζονταν να χτιστούν όπως οι καθεδρικοί, με την τέχνη ξεχωριστών μάγων ή μικρών ομάδων μάγων, που θα δούλευαν σε απόλυτη απομόνωση, χωρίς την δημοσίευση δοκιμαστικού κώδικα (beta code) πριν την ώρα του.

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

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

Περί τα μέσα του 1996 νόμιζα ότι είχα αρχίσει να καταλαβαίνω. Η τύχη μου έδωσε τον τέλειο τρόπο να δοκιμάσω την θεωρία μου, με την μορφή ενός project ανοικτού λογισμικού που θα μπορούσα συνειδητά να δοκιμάσω να τρέξω με το στυλ του παζαριού. Έτσι και έκανα –και αποδείχθηκε σημαντική επιτυχία.”

Ο σκοπός αυτού του blog είναι να ασχοληθεί με το αντίστροφο, πώς δηλαδή η πολιτική χρησιμοποιεί συνήθειες του Ανοικτού Λογισμικού (π.χ. “release early, release often” αντί για “σχεδίασε επί μήνες/χρόνια πίσω από κλειστές πόρτες και παρουσίασε το τελικό αποτέλεσμα”) και όχι τόσο να παρακολουθήσει την χρήση ανοικτού λογισμικού στο Δημόσιο.

Αλλά τα δύο αυτά θέματα σίγουρα συνδέονται, οπότε νομίζω ότι έστω και ως bookmark, αξίζει να το κρατήσω: Obama Invites Open Source into the White House.

Το Law.Gov είναι μία προσπάθεια να δημιουργηθεί μία αναφορά που θα καταγράφει με ακρίβεια τί πρέπει να γίνει ώστε να δημιουργηθεί ένα distributed registry/repository όλων των κύριων νομικών έργων στις ΗΠΑ.

Σχετική είναι και η ομιλία του Carl Malamud με τίτλο “By the People…”, στο Gov 2.0 summit που έγινε τον Σεπτέμβριο που μας πέρασε.

Ενδιαφέρον έχει και το άρθρο του, Law.Gov: America’s Operating System, Open Source στο O’Reilly Radar.

Το The Cathedral and the Bazaar του Eric S. Reymond είναι ένα από τα σημαντικότερα κείμενα-μανιφέστα του Ανοικτού Λογισμικού.  Μεταξύ άλλων, σε αυτό αναφέρονται 19 “μαθήματα” που έμαθε ο συγγραφέας του καθώς ανακάλυπτε τον κόσμο του Ανοικτού Λογισμικού. Αν και μερικά δείχνουν να αναφέρονται αποκλειστικά και μόνο σε θέματα προγραμματισμού, άλλα μπορούν εύκολα να ερμηνευθούν με πιο ευρύ τρόπο -και στο πλαίσιο της πολιτικής.

Τα απαριθμώ, όπως αναφέρονται στο original κείμενο:

  1. Every good work of software starts by scratching a developer’s personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. “Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)
    Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at leastat least once [JB].
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.”
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and nevernever throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Νομίζω ότι πέρα από το about αυτού του blog, μία πρώτη εισαγωγή στο θέμα θα μπορούσαν να είναι το άρθρο μου το Ανοικτό Λογισμικό ως πολιτική διαδικασία (;) και τα σχόλια που το συνοδεύουν.