-
Επιτυχημένα έργα ΕΛΛΑΚ: Bootstrapping
-
Ο φίλος μου Αλέξανδρος μου ζήτησε μερικές συμβουλές σχετικά με το “άνοιγμα” μιας εφαρμογής σε ελεύθερο λογισμικό. Ξέθαψα το παρακάτω κείμενο με μερικές σκέψεις επ’ αυτού του θέματος.
Είναι γεγονός ότι δεν είναι απλή υπόθεση να χτίσει κανείς ένα επιτυχημένο έργο ελεύθερου λογισμικού. Οι προκλήσεις που αντιμετωπίζει σαν maintainer είναι πολλών μορφών και εμφανίζονται σε διαφορετικές στιγμές, ενώ αρκετές από αυτές σε εκπλήσσουν. Δεν είναι τυχαίο λοιπόν που ίσως 9 στα 10 έργα ελεύθερου λογισμικού αποτυγχάνουν — είτε αυτό είναι από εγκατάλειψη των developers, αδιαφορία από τους χρήστες, έλευση ενός καλύτερου ανταγωνιστή, ή κάτι άλλο. Το ερώτημα είναι, φυσικά, δεδομένων αυτών, ποια είναι τα σημαντικότερα βήματα που πρέπει να ακολουθήσει ένας developer για να κάνει το έργο του να πετύχει;
Μια βασική αρχή που πρέπει να ακολουθεί ένας open source maintainer σε όλη τη διάρκεια του έργου του, και ειδικά στα πρώτα βήματα, είναι το KISS: Keep it simple, stupid. Με προεκτάσεις μέχρι τη φιλοσοφική αρχής του “Ξυραφιού του Όκαμ”, η κλασική αυτή σχεδιαστική αρχή του UNIX είναι βέβαιο ότι θα βοηθήσει ένα έργο να αναπτυχθεί σταθερά. Αν υπάρχει κάποιο υπάρχον έργο που μπορεί να βελτιωθεί με νέα χαρακτηριστικά, πιθανώς να αξίζει περισσότερο μια τέτοια προσέγγιση παρά μια επανεφεύρεση του τροχού.
Ίσως το καλύτερο σημείο να ξεκινήσει κανείς είναι να καταλάβει τη φύση της ανάπτυξης κώδικα ελεύθερου λογισμικού. Η πεμπτουσία του συστήματος αυτού είναι να αρέσει σε άλλους developers να συχνάζουν στο έργο. Ίσως το σημαντικότερο έργο που έχει να κάνει ο maintainer είναι να καταλαβαίνει τα κίνητρα τους, τι τους παρακινεί και γιατί βρίσκουν το δικό του έργο σούπερ. Να φροντίζει να συνεχίσουν να υπάρχουν ενδιαφέροντα προβλήματα να λυθούν, ή a la Eric Raymond, να υπάρχουν πάντα “itches to be scratched”. Όπως μου είχε πει μια φορά ο Max Spevack, πρώην Fedora Project Leader, όταν τον ρώτησα ποιος νιώθει ότι είναι ο στόχος της δουλειάς του, “ο ρόλος του leader είναι να μετακινεί εμπόδια ούτως ώστε εσύ, ο developer, να μπορείς να δημιουργείς ελεύθερα”.
Ένα σημαντικό πρώτο βήμα είναι το αρχείο README. Ένα καλό τέτοιο αρχείο δηλώνει τον σκοπό του έργου (mission statement), τους στόχους και τα use cases. Αρκετές φορές καλό είναι να αναφέρεται και το τι δεν είναι το έργο (ξανά το KISS). Δεδομένου του ότι ίσως η μεγαλύτερη πρόκληση του έργου είναι αυξήσει τον αριθμό των developers, η σημασία του αρχείου αυτού είναι μάλλον μεγάλη. Σε έναν ιδανικό κόσμο θα υπάρχουν σχέδια υλοποίησης και roadmap, αλλά η αλήθεια να λέγεται, το αρχείο δε χρειάζεται να είναι απόλυτα πλήρες από την αρχή.
Η επιλογή άδειας χρήσης (αρχείο LICENCE ή COPYING) είναι επίσης κάτι σημαντικό, αφού μπορεί να επηρεάσει τη συνδεσιμότητα του έργου με άλλα έργα και βιβλιοθήκες, ενώ δεν είναι εύκολο να αλλάξει στην πορεία. Ευτυχώς έχουμε στη διάθεση μας τις 5-6 σημαντικότερες άδειες που λογικά καλύπτουν το 99% των νέων έργων.
Με αυτά τα δύο — και προαιρετικά ίσως κάποιο βασικό, μίνιμαλ κώδικα — το freshmeat ή το sourceforge είναι ό,τι καλύτερο για ένα πρώτο “σπίτι” για το έργο και τις λύσεις που προτείνει. Μια mailing list (παρέχεται είτε από το sf, είτε πάμε σε Google groups, κλπ) και ένα URL για περισσότερες πληροφορίες, είναι ό,τι χρειαζόμαστε για την δημοσιοποίηση. Συνεχίζοντας την υιοθέτηση ιστορικά νευραλγικής σημασίας αρχών του UNIX, έτσι κι εμείς θα ακολουθήσουμε το “release early, release often”: όσο πιο νωρίς το ανακοινώσουμε τόσο πιο ποιοτικός θα είναι ο κώδικας μας, αλλά και τόσο πιο γρήγορα θα έρθουν τα άτομα στην παρέα (the more, the merrier), τα σχόλια, το testing, και (ας ελπίσουμε όχι στη δική μας περίπτωση) σύνδεσμοι σε άλλα έργα που κάνουν ακριβώς το ίδιο που θέλουμε. Με αυτά υπόψιν, στέλνουμε ένα μικρό email σε σχετικές ομάδες συζητήσεων που θα έχουν lurkers που μπορεί να ενδιαφέρονται στο έργο: στόχος μας, ξανά, είναι οι developers (κι όχι οι χρήστες).
Αυτό ήταν. Φυτεύουμε το σπόρο αυτό και ρόλος μας είναι να βοηθήσουμε το έργο να εξελιχτεί σε ένα ζωντανό οργανισμό. Από αυτό το σημείο και μετά, στους ρόλους του maintainer είναι κι αυτός του στοργικού κηπουρού, του ποιμένα και πατέρα.
(Το κείμενο δημοσιεύτηκε αρχικά στην τακτική στήλη του συγγραφέα στο ελληνικό Linux Format, τεύχος Σεπτεμβρίου-Οκτωβρίου 2008.)