Γαλλίδα ερευνήτρια σε άρθρο της
(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).
Αστέρης Μασούρας
begin:vcard
fn:Asteris Masouras
n:Masouras;Asteris
adr:;;;Thessaloniki;;;Greece
email;internet:oneiros [ at ] aix [ dot ] meng [ dot ] auth [ dot ] gr
title:Software Developer
x-mozilla-html:FALSE
url:http://avaton.meng.auth.gr/jablog/blog/Oneiros
version:2.1
end:vcard