Αυτή την εβδομάδα θα πραγματοποιηθεί φεστιβάλ πληροφορικής στην Αγία Πετρούπολη . Ένας από τους ομιλητές θα είναι ο Richard Stallman. συμμετέχει επίσης στο φεστιβάλ, και φυσικά δεν θα μπορούσαμε να αγνοήσουμε το θέμα του ελεύθερου λογισμικού. Γι' αυτό ονομάζεται μία από τις αναφορές μας . Θα είναι αφιερωμένο στην ιστορία της ανάπτυξης του Embox ως έργο ανοιχτού κώδικα. Σε αυτό το άρθρο θέλω να μιλήσω για τις κύριες ιδέες που, κατά τη γνώμη μου, επηρεάζουν την ανάπτυξη έργων ανοιχτού κώδικα. Το άρθρο, όπως και η έκθεση, βασίζεται σε προσωπική εμπειρία.
Ας ξεκινήσουμε με κάτι απλό, με τον ορισμό του όρου opensource. Προφανώς, ένα έργο ανοιχτού κώδικα είναι ένα έργο που έχει μία από τις άδειες χρήσης που επιτρέπει την πρόσβαση στον πηγαίο κώδικα του έργου. Επιπλέον, ένα ανοιχτό έργο σημαίνει ότι οι προγραμματιστές τρίτων μπορούν να κάνουν αλλαγές. Δηλαδή, εάν κάποια εταιρεία ή προγραμματιστής δημοσιεύει τον κώδικα του προϊόντος της, εν μέρει ή πλήρως, αυτό δεν καθιστά ακόμη αυτό το προϊόν έργο ανοιχτού κώδικα. Και τέλος, οποιαδήποτε δραστηριότητα έργου πρέπει να οδηγεί σε κάποιου είδους αποτέλεσμα, και το άνοιγμα του έργου συνεπάγεται ότι αυτό το αποτέλεσμα χρησιμοποιείται όχι μόνο από τους ίδιους τους προγραμματιστές.
Δεν θα θίξουμε τα προβλήματα των ανοιχτών αδειών. Αυτό είναι πολύ μεγάλο και περίπλοκο ένα θέμα που απαιτεί εις βάθος διερεύνηση. Έχουν γραφτεί αρκετά καλά άρθρα και υλικά για αυτό το θέμα. Επειδή όμως ο ίδιος δεν είμαι ειδικός στον τομέα των πνευματικών δικαιωμάτων, θα πω μόνο ότι η άδεια πρέπει να πληροί τους στόχους του έργου. Για παράδειγμα, για το Embox η επιλογή μιας άδειας BSD αντί μιας άδειας GPL δεν ήταν τυχαία.
Το γεγονός ότι ένα έργο ανοιχτού κώδικα πρέπει να παρέχει τη δυνατότητα να κάνει αλλαγές και να επηρεάζει την ανάπτυξη του έργου ανοιχτού κώδικα υποδηλώνει ότι το έργο διανέμεται. Η διαχείρισή του, η διατήρηση της ακεραιότητας και της απόδοσης είναι πολύ πιο δύσκολη σε σύγκριση με ένα έργο με κεντρική διαχείριση. Τίθεται ένα εύλογο ερώτημα: γιατί ανοίγουν καθόλου έργα; Η απάντηση βρίσκεται στον τομέα της εμπορικής σκοπιμότητας· για μια συγκεκριμένη κατηγορία έργων, τα οφέλη αυτής της προσέγγισης υπερτερούν του κόστους. Δηλαδή, δεν είναι κατάλληλο για όλα τα έργα και μια ανοιχτή προσέγγιση είναι γενικά αποδεκτή. Για παράδειγμα, είναι δύσκολο να φανταστεί κανείς την ανάπτυξη ενός συστήματος ελέγχου για ένα εργοστάσιο παραγωγής ενέργειας ή ένα αεροσκάφος με βάση μια ανοιχτή αρχή. Όχι, φυσικά, τέτοια συστήματα θα πρέπει να περιλαμβάνουν ενότητες που βασίζονται σε ανοιχτά έργα, γιατί αυτό θα προσφέρει μια σειρά από πλεονεκτήματα. Κάποιος όμως πρέπει να είναι υπεύθυνος για το τελικό προϊόν. Ακόμα κι αν το σύστημα βασίζεται πλήρως στον κώδικα των ανοιχτών έργων, ο προγραμματιστής, έχοντας συσκευάσει τα πάντα σε ένα σύστημα και έχει κάνει συγκεκριμένες κατασκευές και ρυθμίσεις, ουσιαστικά το κλείνει. Ο κωδικός μπορεί να είναι διαθέσιμος στο κοινό.
Υπάρχουν επίσης πολλά οφέλη για αυτά τα συστήματα από τη δημιουργία ή τη συμβολή σε έργα ανοιχτού κώδικα. Όπως είπα ήδη, ο τελικός κωδικός συστήματος μπορεί να παραμείνει διαθέσιμος στο κοινό. Γιατί, γιατί είναι προφανές ότι είναι απίθανο κάποιος να έχει το ίδιο αεροσκάφος για να δοκιμάσει το σύστημα. Αυτό είναι αλήθεια, αλλά μπορεί να υπάρχει κάποιος που θέλει να ελέγξει ορισμένες ενότητες του κώδικα ή, για παράδειγμα, κάποιος μπορεί να ανακαλύψει ότι η βιβλιοθήκη που χρησιμοποιείται δεν έχει ρυθμιστεί σωστά.
Ένα ακόμη μεγαλύτερο όφελος εμφανίζεται εάν η εταιρεία διαθέσει κάποιο βασικό μέρος του συστήματος σε ένα ξεχωριστό έργο. Για παράδειγμα, μια βιβλιοθήκη που υποστηρίζει κάποιο είδος πρωτοκόλλου ανταλλαγής δεδομένων. Σε αυτήν την περίπτωση, ακόμα κι αν το πρωτόκολλο είναι συγκεκριμένο για μια δεδομένη θεματική περιοχή, μπορείτε να μοιραστείτε το κόστος συντήρησης αυτού του τμήματος του συστήματος με άλλες εταιρείες από αυτήν την περιοχή. Επιπλέον, οι ειδικοί που μπορούν να μελετήσουν αυτό το κομμάτι του συστήματος στο δημόσιο τομέα απαιτούν πολύ λιγότερο χρόνο για να το χρησιμοποιήσουν αποτελεσματικά. Και τέλος, ο διαχωρισμός ενός κομματιού σε μια ανεξάρτητη οντότητα που χρησιμοποιούν τρίτοι προγραμματιστές μας επιτρέπει να κάνουμε αυτό το μέρος καλύτερο, επειδή πρέπει να προσφέρουμε αποτελεσματικά API, να δημιουργήσουμε τεκμηρίωση και δεν μιλάω καν για βελτίωση της κάλυψης δοκιμών.
Μια εταιρεία μπορεί να λάβει εμπορικά οφέλη χωρίς να δημιουργεί έργα ανοιχτού κώδικα· αρκεί οι ειδικοί της να συμμετέχουν σε έργα τρίτων που χρησιμοποιούνται στην εταιρεία. Εξάλλου, όλα τα οφέλη παραμένουν: οι εργαζόμενοι γνωρίζουν καλύτερα το έργο, επομένως το χρησιμοποιούν πιο αποτελεσματικά, η εταιρεία μπορεί να επηρεάσει την κατεύθυνση της ανάπτυξης του έργου και η χρήση έτοιμου, διορθωμένου κώδικα μειώνει προφανώς το κόστος της εταιρείας.
Τα οφέλη από τη δημιουργία έργων ανοιχτού κώδικα δεν σταματούν εκεί. Ας πάρουμε ένα τόσο σημαντικό στοιχείο της επιχείρησης όπως το μάρκετινγκ. Για αυτόν, αυτό είναι ένα πολύ καλό sandbox που του επιτρέπει να αξιολογεί αποτελεσματικά τις απαιτήσεις της αγοράς.
Και φυσικά, δεν πρέπει να ξεχνάμε ότι ένα έργο ανοιχτού κώδικα είναι ένας αποτελεσματικός τρόπος για να δηλώσετε τον εαυτό σας ως φορέα οποιασδήποτε εξειδίκευσης. Σε ορισμένες περιπτώσεις, αυτός είναι ο μόνος τρόπος για να βγείτε στην αγορά. Για παράδειγμα, το Embox ξεκίνησε ως ένα έργο για τη δημιουργία ενός RTOS. Μάλλον δεν χρειάζεται να εξηγήσουμε ότι υπάρχουν πολλοί ανταγωνιστές. Χωρίς τη δημιουργία μιας κοινότητας, απλώς δεν θα είχαμε αρκετούς πόρους για να μεταφέρουμε το έργο στον τελικό χρήστη, δηλαδή για προγραμματιστές τρίτου μέρους να αρχίσουν να χρησιμοποιούν το έργο.
Η κοινότητα είναι το κλειδί σε ένα έργο ανοιχτού κώδικα. Σας επιτρέπει να μειώσετε σημαντικά το κόστος διαχείρισης έργου, να αναπτύξετε και να υποστηρίξετε το έργο. Μπορούμε να πούμε ότι χωρίς κοινότητα δεν υπάρχει κανένα έργο ανοιχτού κώδικα.
Έχει γραφτεί πολύ υλικό σχετικά με τον τρόπο δημιουργίας και διαχείρισης μιας κοινότητας έργου ανοιχτού κώδικα. Για να μην επαναλάβω ήδη γνωστά γεγονότα, θα προσπαθήσω να εστιάσω στην εμπειρία του Embox. Για παράδειγμα, η διαδικασία δημιουργίας μιας κοινότητας είναι ένα πολύ ενδιαφέρον θέμα. Δηλαδή, πολλοί λένε πώς να διαχειριστείτε μια υπάρχουσα κοινότητα, αλλά οι στιγμές της δημιουργίας της μερικές φορές παραβλέπονται, θεωρώντας αυτό δεδομένο.
Ο κύριος κανόνας κατά τη δημιουργία μιας κοινότητας έργου ανοιχτού κώδικα είναι ότι δεν υπάρχουν κανόνες. Εννοώ ότι δεν υπάρχουν καθολικοί κανόνες, όπως δεν υπάρχει ασημένια σφαίρα, έστω και μόνο επειδή τα έργα είναι πολύ διαφορετικά. Είναι απίθανο να μπορείτε να χρησιμοποιήσετε τους ίδιους κανόνες όταν δημιουργείτε μια κοινότητα για μια βιβλιοθήκη καταγραφής js και κάποιο εξαιρετικά εξειδικευμένο πρόγραμμα οδήγησης. Επιπλέον, σε διαφορετικά στάδια ανάπτυξης του έργου (και επομένως της κοινότητας), οι κανόνες αλλάζουν.
Το Embox ξεκίνησε ως φοιτητικό έργο επειδή είχε πρόσβαση σε φοιτητές από το τμήμα προγραμματισμού συστημάτων. Στην πραγματικότητα, μπαίναμε σε κάποια άλλη κοινότητα. Θα μπορούσαμε να ενδιαφέρουμε τους συμμετέχοντες αυτής της κοινότητας, φοιτητές, για την καλή βιομηχανική πρακτική στην ειδικότητά τους, την επιστημονική εργασία στον τομέα του προγραμματισμού συστημάτων, των μαθημάτων και των διπλωμάτων. Δηλαδή, ακολουθήσαμε έναν από τους βασικούς κανόνες οργάνωσης μιας κοινότητας: τα μέλη της κοινότητας πρέπει να λάβουν κάτι και αυτή η τιμή πρέπει να αντιστοιχεί στη συνεισφορά του συμμετέχοντος.
Το επόμενο στάδιο για το Embox ήταν η αναζήτηση τρίτων χρηστών. Είναι πολύ σημαντικό να κατανοήσουμε ότι οι χρήστες είναι πλήρως συμμετέχοντες στην κοινότητα ανοιχτού κώδικα. Συνήθως υπάρχουν περισσότεροι χρήστες παρά προγραμματιστές. Και για να θέλουν να γίνουν συνεισφέροντες σε ένα έργο, αρχίζουν πρώτα να το χρησιμοποιούν με τον ένα ή τον άλλο τρόπο.
Οι πρώτοι χρήστες του Embox ήταν το Τμήμα Θεωρητικής Κυβερνητικής. Πρότειναν τη δημιουργία ενός εναλλακτικού υλικολογισμικού για το Lego Mindstorm. Και παρόλο που αυτοί ήταν ακόμα ντόπιοι χρήστες (θα μπορούσαμε να συναντηθούμε προσωπικά μαζί τους και να συζητήσουμε αυτό που ήθελαν). Αλλά και πάλι ήταν μια πολύ καλή εμπειρία. Για παράδειγμα, αναπτύξαμε επιδείξεις που θα μπορούσαν να προβληθούν σε άλλους, επειδή τα ρομπότ είναι διασκεδαστικά και τραβούν την προσοχή. Ως αποτέλεσμα, έχουμε πραγματικά τρίτους χρήστες που άρχισαν να ρωτούν τι είναι το Embox και πώς να το χρησιμοποιούν.
Σε αυτό το στάδιο, έπρεπε να σκεφτούμε την τεκμηρίωση, τα μέσα επικοινωνίας με τους χρήστες. Όχι, βέβαια, σκεφτήκαμε αυτά τα σημαντικά πράγματα πριν, αλλά ήταν πρόωρο και δεν έδωσε θετικό αποτέλεσμα. Το αποτέλεσμα ήταν μάλλον αρνητικό. Επιτρέψτε μου να σας δώσω μερικά παραδείγματα. Χρησιμοποιήσαμε το googlecode, του οποίου το wiki υποστήριζε την πολυγλωσσία. Δημιουργήσαμε σελίδες σε πολλές γλώσσες, όχι μόνο αγγλικά και ρωσικά, στις οποίες δύσκολα μπορούσαμε να επικοινωνήσουμε, αλλά και γερμανικά και ισπανικά. Ως αποτέλεσμα, φαίνεται πολύ γελοίο όταν ερωτάται σε αυτές τις γλώσσες, αλλά δεν μπορούμε να απαντήσουμε καθόλου. Ή εισήγαγαν κανόνες σχετικά με τη σύνταξη τεκμηρίωσης και τον σχολιασμό, αλλά επειδή το API άλλαζε αρκετά συχνά και σημαντικά, αποδείχθηκε ότι η τεκμηρίωσή μας ήταν ξεπερασμένη και ήταν περισσότερο παραπλανητική παρά βοήθησε.
Ως αποτέλεσμα, όλες οι προσπάθειές μας, ακόμη και οι λάθος, οδήγησαν στην εμφάνιση εξωτερικών χρηστών. Και ακόμη και ένας εμπορικός πελάτης εμφανίστηκε που ήθελε να αναπτυχθεί το δικό του RTOS για αυτόν. Και το αναπτύξαμε γιατί έχουμε εμπειρία και κάποια βάση. Εδώ πρέπει να μιλήσετε τόσο για τις καλές όσο και για τις κακές στιγμές. Θα ξεκινήσω με τα κακά. Δεδομένου ότι πολλοί προγραμματιστές συμμετείχαν σε αυτό το έργο σε εμπορική βάση, η κοινότητα ήταν ήδη αρκετά ασταθής και διχασμένη, κάτι που φυσικά δεν μπορούσε παρά να επηρεάσει την ανάπτυξη του έργου. Ένας επιπλέον παράγοντας ήταν ότι η κατεύθυνση του έργου καθοριζόταν από έναν εμπορικό πελάτη και στόχος του δεν ήταν η περαιτέρω ανάπτυξη του έργου. Τουλάχιστον αυτός δεν ήταν ο βασικός στόχος.
Από την άλλη πλευρά, υπήρχαν μια σειρά από θετικές πτυχές. Έχουμε πραγματικά τρίτους χρήστες. Δεν ήταν μόνο ο πελάτης, αλλά και εκείνοι για τους οποίους προοριζόταν αυτό το σύστημα. Το κίνητρο για συμμετοχή στο έργο έχει αυξηθεί. Εξάλλου, αν μπορείτε επίσης να κερδίσετε χρήματα από μια ενδιαφέρουσα επιχείρηση, είναι πάντα ωραίο. Και το πιο σημαντικό, ακούσαμε μια επιθυμία από τους πελάτες, η οποία εκείνη την εποχή μας φαινόταν τρελή, αλλά που είναι τώρα η κύρια ιδέα του Embox, δηλαδή, να χρησιμοποιήσουμε ήδη ανεπτυγμένο κώδικα στο σύστημα. Τώρα η κύρια ιδέα του Embox είναι η χρήση λογισμικού Linux χωρίς Linux. Δηλαδή, η κύρια θετική πτυχή που συνέβαλε στην περαιτέρω ανάπτυξη του έργου ήταν η συνειδητοποίηση ότι το έργο χρησιμοποιείται από τρίτους χρήστες και θα πρέπει να λύσει ορισμένα από τα προβλήματά τους.
Εκείνη την εποχή, το Embox είχε ήδη ξεπεράσει τα όρια ενός φοιτητικού έργου. Ο κύριος περιοριστικός παράγοντας στην ανάπτυξη του έργου σύμφωνα με το μοντέλο του μαθητή είναι τα κίνητρα των συμμετεχόντων. Οι μαθητές συμμετέχουν ενώ σπουδάζουν και όταν αποφοιτούν, θα πρέπει να υπάρχει διαφορετικό κίνητρο. Εάν δεν εμφανιστεί κίνητρο, ο μαθητής απλώς σταματά να συμμετέχει στο έργο. Αν λάβουμε υπόψη ότι οι μαθητές πρέπει πρώτα να εκπαιδευτούν, αποδεικνύεται ότι γίνονται καλοί ειδικοί μέχρι να αποφοιτήσουν, αλλά η συνεισφορά τους στο έργο, λόγω απειρίας, δεν είναι πολύ μεγάλη.
Γενικά, προχωράμε ομαλά στο κύριο σημείο που μας επιτρέπει να μιλήσουμε για τη δημιουργία ενός έργου ανοιχτού κώδικα - τη δημιουργία ενός προϊόντος που θα έλυνε τα προβλήματα των χρηστών του. Όπως εξήγησα παραπάνω, η κύρια ιδιότητα ενός έργου ανοιχτού κώδικα είναι η κοινότητά του. Επιπλέον, τα μέλη της κοινότητας είναι κυρίως χρήστες. Αλλά από πού προέρχονται όταν δεν υπάρχει τίποτα για χρήση; Αποδεικνύεται λοιπόν ότι, όπως και με ένα έργο που δεν είναι ανοιχτού κώδικα, πρέπει να εστιάσετε στη δημιουργία ενός MVP (ελάχιστο βιώσιμο προϊόν) και εάν ενδιαφέρει τους χρήστες, τότε μια κοινότητα θα εμφανιστεί γύρω από το έργο. Εάν ασχολείστε με τη δημιουργία μιας κοινότητας μόνο μέσω κοινοτικών δημοσίων σχέσεων, γράφοντας ένα wiki σε όλες τις γλώσσες του κόσμου ή σωστή ροή εργασίας git στο github, τότε αυτό είναι απίθανο να έχει σημασία στα αρχικά στάδια του έργου. Φυσικά, στα κατάλληλα στάδια αυτά δεν είναι μόνο σημαντικά, αλλά και απαραίτητα.
Εν κατακλείδι θα ήθελα να επισημάνω , κατά τη γνώμη μου, που αντικατοπτρίζει τις προσδοκίες των χρηστών από ένα έργο ανοιχτού κώδικα:
Σκέφτομαι σοβαρά να αλλάξω σε αυτό το λειτουργικό σύστημα (τουλάχιστον προσπαθήστε. Το επιδιώκουν ενεργά και κάνουν ωραία πράγματα).
Υ.Γ Θα έχουμε έως και τρεις αναφορές. Ένα για ανοιχτό κώδικα και δύο για ενσωματωμένο (και ένα είναι πρακτικό). Στο περίπτερο θα πραγματοποιήσουμε ένα master class προγραμματισμού μικροελεγκτών με χρήση . Ως συνήθως, θα φέρουμε το υλικό και θα σας αφήσουμε να το προγραμματίσετε. Θα υπάρχει επίσης quest και άλλες δραστηριότητες. Ελάτε στο φεστιβάλ και στο περίπτερό μας, θα έχει πλάκα.
Πηγή: www.habr.com