Τί μπορεί να είναι το ισοδύναμο του Open Source Software σε ένα περιβάλλον όπου αγοράζουμε όλο και λιγότερο λογισμικό και όλο και περισσότερες “υπηρεσίες”;
Το Ανοικτό Λογισμικό διασφάλιζε διάφορα πράγματα, όπως την δυνατότητα να μπορείς να τροποποιήσεις το λογισμικό σύμφωνα με τις ανάγκες σου, την δυνατότητα να δημιουργήσεις ένα νέο προϊόν λογισμικού τροποποιώντας και βελτιώνοντας το αρχικό και κυρίως την ελέυθερη πρόσβαση στην γνώση -την τεχνογνωσία- που περιγράφεται με την μορφή πηγαίου κώδικα.
Πώς θα μπορούσαμε να πετύχουμε κάτι παρόμοιο όταν μιλάμε για υπηρεσίες; Πώς θα μπορούσαμε να διατηρήσουμε τα δικαιώματά μας όταν μετακινήσουμε τα mails μας από ένα Cyrus IMAP server στο GMail; Όταν σταματήσουμε να χρησιμοποιούμε το Open Office και χρησιμοποιούμε το Google Docs; Όταν τον δίσκο μας αντικαταστήσει το Flickr ως χώρος αποθήκευσης φωτογραφιών; Όταν ηχογραφούμε απευθείας το podcast μας στο ODEO;
Κάποιοι μιλάνε για Open APIs. Δεν είμαι σίγουρος ότι αρκεί αυτό. Και βέβαια πρέπει να ορίσουμε πότε ένα API θα αποκαλείται “open”. Το θέμα έχει αρχίσει συζητιέται πάντως όλο και περισσότερο. Χάρηκα που δίαβασα σχετικά στον Jeremy Zawodny που έχει σημαντική θέση στο Yahoo!. Ρίξτε και μία ματιά στο Attention Trust, αν και δείχνει άσχετο με το θέμα, δεν είναι.
Τα Open APIs, φυσικά, δεν είναι Ανοιχτό Λογισμικό. Πλησιάζουν περισσότερο στη λογική των open standards, αφού κάποιος τρίτος θα μπορούσε να φτιάξει δικό του implementation συμβατό με αυτά τα APIs κσι να το διαθέσει σε διαφορετικό δικτυακό τόπο. Η βασική διαφορά, όμως, είναι ότι θα πρέπει να ξανα-ανακαλύψει τον τροχό, αφού δεν μπορεί να βασίσει το προϊόν του στον κώδικα του προηγούμενου.
Τα Open APIs ενδυναμώνουν τις επικρατούσες εταιρείες, καθώς είναι εύκολο για μια ανεξάρτητη εταιρεία να συμβάλλει στο γενικότερο framework και να παρέχει νέα λειτουργικότητα (ανεβάζοντας τη συνολική αξία του framework) αλλά δύσκολο να ανταγωνιστεί άμεσα το framework καθαυτό. Η λέξη κλειδί, πάντως, είναι “εταιρεία”. Τα OpenAPIs δεν βοηθούν ιδιαίτερα τον ανεξάρτητο προγραμματιστή.
Μιχάλη, συμφωνώ. Για αυτό και λέω ότι πρέπει να ορίσουμε τι θα ονομάζουμε “open”. Π.χ. μπορεί ένα API για να ονομαστεί “open κατά FSF” να διασφαλίζει ότι επιτρέπει την εξαγωγή όλων των δεδομένων που ο χρήστης έχει αποθηκεύσει και δημιουργήσει, να μην εξαρτάται από συγκεκριμένο domain, να μην απαιτεί χρήση κλειστών προτύπων επικοινωνίας (π.χ. για authentication ή encryption) κ.λ.
Το θέμα είναι ποιά είναι αυτά τα στοιχεία που θα μας δώσουν τον ίδίο βαθμό ελευθερίας με το OSS…
Ίσως το θέμα να μην είναι το “Open API” αλλά το “Open Service”;
Ίσως api-neutral services;
Δηλαδή; Πώς είναι ένα API-neutral service;
Σαν αρχή το σκέφθηκα, κατά το πρότυπο του network neutrality. Είχα κατά νου το “σκότωμα” του Google SOAP Seaεch API.
Δηλαδή να μην υπάρχει διακριτική μεταχείριση στην πρόσβαση μιας υπηρεσίας με βάση το api.
Γιa παράδειγμα, θεωρητικό, αποφασίζει η Google πως είναι συμφέρον για την ίδια να δίνει καλύτερο QoS όταν η πρόσβαση γίνεται με το AuthSub api (web applications) παρά με το ClientLogin (stand-alone applications). Δεν ακριβώς μια κατάσταση closed source αλλά ότι κοντινότερο μου έρχεται στο μυαλό σε σχεση με τις υπηρεσίες.
Πιστευω η δυναμη του ανοιχτου λογισμικου ειναι οτι ο κωδικας συνεχια αναπτυσσεται. Αρα με το ΟpenAPI το ιδιο να χρειαστει. Αμα μια υπηρεσια προσφερει τα functions 1,2,3,4, Ειναι λογικο οτι καποια μερα, η συνδεση 3+4 να εχουν αποτελεσμα 5. Ισως το θεμα ειναι το πως το 5 θα κριθει ως αξιο για την επομενη εκδοχη.
Οπως υπαρχουν το sourceforge και το googlecode, ισως να χρειαζομαστε σελιδες που βλεπουμε την αναπτυξη και ποιες ιδεες προσφερονται και ποιες πιανουνε. Δηλαδη το 3+4=5 στο ενα κλαδος, το 1+2=6 σε αλλο κλαδος, και που προσφερονται αυτα τα καινουρια functions, ποιος τα προσφερει, και ποιοι αλλοι το εχουν κανει implement.
Μου φαινεται πως ειναι η ιδεα που πιανει εδω οχι ο κωδικας, και οι περισσοτεροι που κανουν implement την ιδεα στο κλαδος, τοσο καλυτερη η ιδεα ειναι, και τοσο πιο σημαντικη να ολοκληροθη στην επομενη εχδοχη.