Ενδιαφέρον θέμα, αλλά θα ήθελα να θυμίσω ότι η αντιπαράθεση γίνεται
ανάμεσα σε εθελοντική συμμετοχή στην ανάπτυξη ενός προγράμματος και στην
κερδοσκοπικά κινούμενη ανάπτυξη. Τα επιχειρήματα που παρουσιάζονται δεν
έχουν να κάνουν τίποτα με την ανοιχτού και κλειστού κώδικα ανάπτυξη των
προγραμμάτων.
Φαντάζομαι ότι πρόγραμματα όπως το Eclipse και το OpenOffice.org που η
ανάπτυξη τους χρηματοδοτήθηκε από εταιρείες, αλλά ταυτόχρονα ο κώδικας
τους δίνεται ελεύθερα, δεν επηρρεάζονται από τα επιχειρήματα που
αναφέρονται.
Φιλικότατα
Στάθης Αλεξόπουλος
Asteris Masouras wrote:
Γαλλίδα ερευνήτρια σε άρθρο της
(http://firstmonday.org/issues/issue9_4/levesque/index.html) με τίτλο
"Fundamental issues with open source software development"
αναλύει τους 5 λόγους που, κατά τη γνώμη της, δυσχεραίνουν την αποδοχή
του Ανοικτού Λογισμικού από το ευρύ κοινό. Ακολουθεί το σχόλιο μου για
το άρθρο (ανατύπωση από το blog μου, χωρίς τα περισσότερα links -
http://avaton.meng.auth.gr/jablog/blog/Oneiros/post/28):
Οι παρατηρήσεις της Levesque (http://www.cs.toronto.edu/%7Eml/) για
την έλλειψη ευχρηστίας αντανακλούν τον πρόσφατο λίβελο του Eric
Raymond (http://www.catb.org/%7Eesr/writings/cups-horror.html),
πρόεδρου του Open Source Initiative, που ξεσήκωσε θύελλα αντιδράσεων,
χρησιμοποιεί δε και τα ίδια απλουστευμένα επιχειρήματα, ενώ ως δεύτερο
σημαντικό μειονέκτημα του Ανοικτού Λογισμικού θέτει την παρωχημένη και
ελλειπή τεκμηρίωση. Παρ' ότι δέχομαι ως καλόπιστη την κριτική της, θα
διαφωνήσω ριζικά με τα επιχειρήματά της στα δύο αυτά σημεία. Όσον
αφορά τον σχεδιασμό ευχρηστίας, εκτός του ότι απαιτεί συνεργασία
μηχανικών λογισμικού, γραφιστών και ψυχολόγων, απαιτεί εξ' ορισμού και
την συμμετοχή χρηστών σε διαρκείς μετρήσεις και ελέγχους. Στον τομέα
αυτό, οι εταιρείες λογισμικού έχουν φυσικά το πλεονέκτημα, καθώς
μπορούν να προωθούν άμεσα το ατελές λογισμικό τους σε συμβεβλημένους
δοκιμαστές (beta testers -
http://www.microsoft-watch.com/article2/0,1995,1560027,00.asp), αλλά
ακόμα και σε ομάδες κοινού μέσω του δικτύου διανομής τους, και να
ζητούν συνεχές feedback. Εξ' άλλου, κι οι ίδιοι οι χρήστες εγείρουν
περισσότερες απαιτήσεις για λογισμικό που έχουν πληρώσει, ακόμα κι αν
θα μπορούσαν να εξυπηρετηθούν καλύτερα από δωρεάν διατιθέμενο
λογισμικό. Αυτό το παράδοξο οδηγεί στην αδυναμία των developers
Ανοικτού Λογισμικού να συγκεντρώνουν ποιοτικό και εποικοδομητικό
feedback από τους χρήστες, και ειδικά σε θέματα τόσο εξειδικευμένα
όπως είναι η ευχρηστία. Μεγάλο ρόλο στο θέμα αυτό παίζει φυσικά κι η
έλλειψη διάθεσης σε μεγάλο βαθμό από μέρους γραφιστών και ψυχολόγων,
όχι μόνο να συμμετάσχουν εθελοντικά σε projects Ανοικτoύ Λογισμικού
(αποβλέποντας και στην επαγγελματική εμπειρία που θα αποκόμιζαν έτσι),
αλλά ακόμα και να προσεγγίσουν την ανάπτυξη λογισμικού ως μια πιθανή
καριέρα. Για κάποιο λόγο (για να δανειστώ την έκφραση της Levesque), η
ανάπτυξη λογισμικού θεωρείται προνόμιο, πασατέμπο και βίτσιο των
προγραμματιστών και μόνο.
Όσο για το δεύτερο σημείο της, η εποχή μας ανέδειξε το γραφικό
interface σε τέτοιο βαθμό που οποιαδήποτε τεκμηρίωση βαθύτερη της μίας
σελίδας, ειδικά αν δεν συνοδεύεται από εικονογράφηση ή επίδειξη,
θεωρείται δυσπρόσιτη και προσπερνάται από τον χρήστη (εξ' ου και τα
γνωστά αποφθεύγματα RTFM και STFW). Παραδέχομαι ευθέως πως
επανηλλειμένα έχω γίνει κι εγώ ένοχος της παραπάνω συμπεριφοράς, η
οποία όμως σε παρατεταμένο βαθμό οδηγεί στην αμάθεια. Καμιά γενιά στο
παρελθόν δεν απαίτησε τον έλεγχο τόσης γνώσης καταβάλλοντας τόση λίγη
προσπάθεια. Ομολογουμένως, η κλασική μορφή τεκμηρίωσης του Ανοικτού
Λογισμικού (τα γνωστά manpages) δεν αποτελεί υπόδειγμα ευκρίνειας,
όμως συνολικά το Ανοικτό Λογισμικό διακρίνεται περισσότερο για τον
τεράστιο όγκο τεκμηρίωσης που παράγει (κατά το πρότυπο των παλιών
βιβλιοθηκών του UNIX που γεμίζανε δωμάτια), ειδικά για εγκαθιδρυμένα
προγράμματα, παρά για οτιδήποτε άλλο. Το πρόβλημα ίσως έγκειται στο
οτι αυτά τα εγχειρίδια γράφονται για να διαβαστούν από
προγραμματιστές, στους οποίους θα είναι και χρησιμότερα, όμως μερίδιο
ευθύνης έχουν και οι χρήστες που δεν συνεισφέρουν εποικοδομητική
κριτική. Το πρόβλημα λοιπόν κι αυτό ανάγεται σε πρόβλημα αξιολόγησης
ευχρηστίας, και συνεπώς στην πρότερη παρατήρηση. Επίσης, η συγγραφή
τεκμηρίωσης απαιτεί κι αυτή την αξιοποίηση ακόμα μίας σύνθετης και
ξεχωριστής ειδικότητας, αυτή του τεχνικού συγγραφέα (technical
writer), που χρειάζεται κατ'ελάχιστο να έχει γνώσεις προγραμματισμού,
συγγραφής, λογοτεχνικής επιμέλειας και μετάφρασης
(http://www.hci.com.au/hcisite2/journal/So%20you%20want%20to%20be%20a%20technical%20writer.htm).
Τέλος, εκεί που πλατειάζει και γενικολογεί η Levesque είναι πιστεύω
στο τρίτο σημείο της, όπου μιλώντας για την τάση προσήλωσης στην
παροχή πρόσθετης λειτουργικότητας καταλήγει: "Sometimes it’s a lack of
focus on the user interface, documentation, coding standards,
security, project direction, specified target audience, etc". Βάζοντας
παράμερα τον τεκμηριωμένο αντίλογο (πως δηλαδή η προσήλωση στα
features αποτελούσε πάντα ενδεικτική του εταιρικού σκεπτικού, ενώ το
Ανοικτό Λογισμικό βασίζεται στην αντιδιαμετρικά αντίθετη φιλοσοφία της
συναρμογής καλά δομημένων υποδομών λογισμικού), παρατηρώ απλά πως τα
θέματα που αραδιάζει επιγραμματικά σ'αυτή την πρόταση είναι σε μεγάλο
βαθμό κάθετα μεταξύ τους, με την έννοια ότι αντιμάχονται για τους
ίδιους πόρους κατά την διαδικασία ανάπτυξης. Τέλος, ως συνολικό
αντιπαράδειγμα στις γενικολογίες της ερευνήτριας, προτείνω τη μελέτη
των διαδικασιών ανάπτυξης της διανομής Debian
(http://www.debian.org/doc/developers-reference/) αλλά και εκείνων του
οργανισμού Apache (http://www.apache.org/foundation/how-it-works.html)
και ειδικότερα του Jakarta Project
(http://jakarta.apache.org/site/guides.html).
Αστέρης Μασούρας
_______________________________________________
Open-source mailing list
Open-source [ at ] grnet [ dot ] gr