Ο προγραμματιστής της Microsoft καλεί τη Διαχείριση σχετικά με τον χειρισμό του ζητήματος .Net Hot Reload

Τα μέλη της κοινότητας ανοιχτού κώδικα εξαγριώθηκαν πρόσφατα με τη Microsoft επειδή προφανώς κατάργησε σκόπιμα μια δυνατότητα από την πλατφόρμα ανάπτυξης λογισμικού ανοιχτού κώδικα .Net 6 (την οποία διαχειρίζεται η Microsoft), έτσι ώστε οι επαγγελματίες προγραμματιστές να χρησιμοποιήσουν το Visual Studio 2022, το αρκετά ακριβό αλλά πολύ πολύ της Microsoft ισχυρό IDE.

Αποδεικνύεται ότι οι προγραμματιστές εντός της Microsoft ήταν εξίσου θυμωμένοι και Η Microsoft ανακάλεσε την απόφασή της δεν τους έχει καθησυχάσει, με πολλούς να φοβούνται την επόμενη περίπτωση όπου η Microsoft τοποθετεί τα βραχυπρόθεσμα οικονομικά της συμφέροντα πάνω από τη δέσμευσή τους με την κοινότητα ανοιχτού κώδικα.

Αυτό είχε ως αποτέλεσμα την απελευθέρωση του μια ανώνυμη επιστολή προς τη διοίκηση της Microsoft στην οποία ο συγγραφέας κατηγορεί ευθέως την εταιρεία ότι λέει ψέματα για να προστατεύσει τη διοίκηση.

Σημειώνουν ότι η Microsoft προσπάθησε σκόπιμα να κρύψει την κατάργηση του Hot Reload βιαζόμενος το PR προτού οι προγραμματιστές του .Net 6 προλάβουν να σχολιάσουν και ότι η δικαιολογία της Microsoft ότι δεν μπορούσαν να επικεντρωθούν στο Hot Reload τόσο για το .Net 6 όσο και για το VS 2022 ήταν κούφια όταν δεν υπήρχε ένδειξη ότι το έργο δεν μπορούσε να ολοκληρωθεί ικανοποιητικά και για τα δύο.

Εξέφρασαν την ανησυχία τους ότι η Microsoft θα καταβάλει περαιτέρω προσπάθειες για να ακρωτηριάσει το .Net 6 σε μια προσπάθεια να προωθήσει το VS 2022, παρά το γεγονός ότι τα εργαλεία ανοιχτού κώδικα είναι αρκετά δημοφιλή μέσα στην ίδια τη Microsoft.

Ο συγγραφέας ζήτησε μια διαφανή έρευνα σχετικά με τον τρόπο με τον οποίο λήφθηκε το Hot Reload και αλλαγές στη διαχείριση της Microsoft, ώστε να μην μπορούν να ληφθούν ξανά τέτοιες βιαστικές αποφάσεις.

Παρά τον κάπως έντονο τόνο που έκανε πολλούς να πιστέψουν ότι η σημείωση δεν είναι αληθινή, αρκετοί MVP της Microsoft εμφανίστηκαν και επιβεβαίωσαν ότι η επιστολή γράφτηκε όντως από έναν υπάλληλο της Microsoft στο τμήμα DivDev.

Διαβάστε αναλυτικά την επιστολή παρακάτω:

Προς την ηγεσία του τμήματος προγραμματιστών της Microsoft,

Όσοι από εμάς εργαζόμαστε στο τμήμα προγραμματιστών της Microsoft (DevDiv) θα θέλαμε να απαντήσουμε στην πρόσφατη διαμάχη σχετικά με την αφαίρεση και την επαναφορά της δυνατότητας "ρολόι με dotnet" του dotnet 6. Ενώ είμαστε ευγνώμονες που επικράτησαν πιο ψυχρές κεφαλές και το "ρολόι dotnet". διατηρήθηκε, δεν αισθανόμαστε σίγουροι ότι αυτό δεν θα συμβεί ξανά; ακριβώς το αντίθετο.

Για να δείξουμε αυτό το σημείο, θα δούμε την πρόσφατη ανάρτηση ιστολογίου του Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Με βάση όλα όσα γνωρίζουμε για την κατάσταση και τον τρόπο λειτουργίας του Developer Division, λίγα από αυτά που έγραψε ο Scott φαίνονται αληθινά και έρχονται σε αντίθεση με αυτό που συνέβη. Για να είμαστε σαφείς, δεν πρόκειται για επίθεση στον Scott Hunter. και αντ 'αυτού, δείχνει πόσο μακριά είναι πρόθυμοι να φτάσουν οι άλλοι για να προστατεύσουν τη διοίκηση.

«Ως ομάδα, δεσμευόμαστε να είναι το .NET μια ανοιχτή πλατφόρμα και να κάνουμε την ανάπτυξή μας ανοιχτά. Το ίδιο το γεγονός ότι αποφασίσαμε να υιοθετήσουμε μια ανοιχτή στάση από προεπιλογή για την ανάπτυξη της λειτουργίας Hot Reload είναι απόδειξη αυτού.»

Τίποτα σχετικά με το αίτημα έλξης δεν ήταν ανοιχτό. Το αναφέραμε σε μια ανάρτηση ιστολογίου (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) και βιάσαμε αδιαφανώς το PR για να το αποφύγουμε σχόλια. Πώς μπορούμε να πούμε ότι είμαστε διαφανείς όταν αυτό είναι τόσο ξεκάθαρο το αντίθετο; Είναι σαν να ξέραμε όλοι συλλογικά ότι αυτό ήταν λάθος, αλλά έπρεπε να το ακολουθήσουμε ούτως ή άλλως.

"Η συντριπτική πλειοψηφία των προγραμματιστών .NET χρησιμοποιεί το Visual Studio και θέλουμε να βεβαιωθούμε ότι το VS προσφέρει την καλύτερη εμπειρία για το .NET 6."

Ακόμα κι αν αυτό είναι αλήθεια, αυτό σημαίνει ότι δεν νοιαζόμαστε για τους μη χρήστες του Visual Studio; Πώς το να τραβήξετε αυτή τη δυνατότητα τόσο αργά στην ανάπτυξη θα το έκανε τόσο το Visual Studio να έχει την καλύτερη εμπειρία για το Hot Reload; Είναι προσβλητικό για όσους δεν χρησιμοποιούν πάντα το Visual Studio για την ανάπτυξη dotnet και λέει ότι δεν καταλαβαίνουμε τους πελάτες μας ή ακόμα και τους υπαλλήλους μας που χρησιμοποιούν αυτό που κατασκευάζουμε.

Χρησιμοποιούμε CLI και χρησιμοποιούμε VS Code. Σταμάτα να προσποιείσαι το αντίθετο.

«Κάναμε λάθος στην εκτέλεση αυτού του σχεδίου με τον τρόπο που υλοποιήθηκε. Στην προσπάθειά μας να διερευνήσουμε το πεδίο εφαρμογής, καταλήξαμε κατά λάθος να διαγράψουμε τον πηγαίο κώδικα αντί απλώς να μην επικαλεστούμε αυτήν τη διαδρομή κώδικα.

Για να είμαστε σαφείς, το να κατηγορούμε τον μηχανικό για αυτό το «λάθος» είναι δειλό. Το πρόβλημα ήταν η κατάργηση της δυνατότητας, όχι ο τρόπος με τον οποίο την πραγματοποίησαν. Λέμε να το «απενεργοποιούσαμε» αντί να το αφαιρέσουμε, δεν θα είχαμε επαναφέρει την αλλαγή; Αυτός ο κώδικας θα είχε εργαστεί ενεργά ή θα είχε αφεθεί να σαπίσει;

«Καθώς ο διάδρομος είναι σύντομος για την κυκλοφορία .NET 6 και το Visual Studio 2022, επιλέξαμε να επικεντρωθούμε στο να φέρουμε πρώτα το Hot Reload στο VS2022».

Για να δείξουμε ότι ο "Έλεγχος ποιότητας" δεν συνέβη με το "ρολόι dotnet", θα το συγκρίνουμε με ένα άλλο προϊόν που καθυστερήσαμε: το MAUI.

Το MAUI είναι σε τραχύ σχήμα. Ήταν σαφές από την RC1 ότι η ποιότητα δεν επρόκειτο να είναι αρκετά υψηλή μέχρι τη στιγμή που θα αποσταλεί το dotnet 6. υπήρχαν πάρα πολλά για να διορθωθούν και όχι αρκετός χρόνος για να γίνει. Η ομάδα MAUI και οι συνεργάτες της έφεραν αυτά τα ζητήματα στην ηγεσία, γεγονός που ώθησε το προϊόν πίσω στις αρχές του επόμενου έτους.

Δεν υπήρχε και δεν υπάρχει ακόμη καμία ένδειξη ότι το "ρολόι dotnet" ήταν στο ίδιο μέρος. Η διερεύνηση των προβλημάτων του GitHub ούτε των καθυστερήσεων της ομάδας dotnet δείχνουν ανησυχίες ότι η ποιότητα δεν ήταν εκεί. Αντιθέτως, τα πήγαινε μια χαρά. Αυτά θα είχαν αναφερθεί πολύ νωρίτερα στον κύκλο κυκλοφορίας μας, αν υπήρχαν πραγματικές ανησυχίες για την ποιότητα, όχι τρεις εβδομάδες πριν από την αποστολή.

"Όπως συμβαίνει με πολλές εταιρείες, μαθαίνουμε να εξισορροπούμε τις ανάγκες της κοινότητας OSS και να είμαστε εταιρικός χορηγός για το .NET."

Αν διαβάσουμε ανάμεσα στις γραμμές, αυτή η δήλωση είναι αληθινή. Ερχόμαστε σε διένεξη με αυτά που βάζουμε στο dotnet, το Visual Studio και τον κώδικα του Visual Studio. Η διατήρηση του Hot Reload ως "προστιθέμενης αξίας" για το Visual Studio κρατά αυτούς που είναι κλειδωμένοι στο επί πληρωμή προϊόν και λιγότερους λόγους για να μεταβούν στο VS Code. Με ψυχρό και υπολογισμένο τρόπο, αυτό είναι απολύτως λογικό, και είναι επίσης απόλυτη ανοησία.

Τι θα γινόταν αν οι ομάδες που εργάζονται στο Hot Reload for Visual Studio ενσωματώσουν το "dotnet watch" στα προϊόντα τους; Τι θα γινόταν αν η ηγεσία τραβούσε αυτά τα χαρακτηριστικά εβδομάδες πριν από τη γενική κυκλοφορία; Πώς θα βελτίωνε αυτό το Visual Studio με οποιονδήποτε τρόπο; Θα συνεχίσουμε να αφαιρούμε εξαρτήματα από το CLI επειδή φοβόμαστε ότι θα χάσουμε έσοδα από το Visual Studio;

Ο τρόπος με τον οποίο χτίζουμε το καλύτερο Visual Studio είναι να έχουμε τον καλύτερο χρόνο εκτέλεσης στον πλανήτη. Όταν η ομάδα του Visual Studio προσθέτει δυνατότητες στη βάση του dotnet, έχουμε μια σταθερή βάση για να εργαστούν και να συνεισφέρουν όλοι. Μπορούμε να δημιουργήσουμε το καλύτερο IDE συνεργαζόμενοι στο χρόνο εκτέλεσης, χωρίς να χειροτερεύσουμε τα αυθαίρετα προϊόντα ανοιχτού κώδικα.

Τι έπεται? Θα κάνουμε το Omnisharp προϊόν κλειστού κώδικα; Για να μπορούμε να βεβαιωθούμε ότι δεν μπορεί να αποκτήσει νέες δυνατότητες που αφαιρούν την «αξία» του Visual Studio; Για να μην χαρίσουμε χαρακτηριστικά στον Rider; Πώς μας βοηθάει καθόλου αυτό; Αυτές οι αποφάσεις της ηγεσίας διασφαλίζουν ότι το Visual Studio θα είναι πάντα δεύτερης κατηγορίας σε σχέση με οτιδήποτε άλλο στην αγορά. Τέτοιες κινήσεις δεν μας βλάπτουν μόνο με τους πελάτες αλλά και τον τρόπο κατασκευής προϊόντων εσωτερικά. Δεν μας βλάπτουν μόνο με την "κοινότητα OSS", αλλά όλους στο τμήμα προγραμματιστών και τη Microsoft.

Εάν θέλουμε να είμαστε πραγματικά διαφανείς σχετικά με αυτό, θα πρέπει να κάνουμε αυτές τις αλλαγές για να το κάνουμε σωστό:

Χρειαζόμαστε ένα πλήρες χρονοδιάγραμμα, δημοσιευμένο, για το πώς συνέβη αυτό και τους άμεσα υπεύθυνους για το πώς οδήγησε σε αυτό.
Δεν πρέπει ποτέ ξανά να βιαστούμε ένα PR. Ήταν ξεκάθαρο από την αρχή ότι η κατάργηση του κώδικα ήταν λανθασμένη ενέργεια, και αν θέλουμε ειλικρινά σχόλια από την κοινότητα, πρέπει να είμαστε πρόθυμοι να ακούσουμε όχι μετά αλλά πριν.
Εάν αυτές οι αποφάσεις λήφθηκαν μονομερώς από τους ηγέτες, πρέπει να αποτρέψουμε να συμβεί ξανά αυτό. Υπήρχε μια προφανής σύγκρουση συμφερόντων μεταξύ των «αναγκών» της VS και εκείνων του dotnet. Χρειάζεται να υπάρχουν έλεγχοι και ισορροπίες για να αποτρέπεται οποιοδήποτε άτομο, ανεξάρτητα από το πόσο ψηλά βρίσκεται, από το να λαμβάνει αποφάσεις όπως αυτή χωρίς γνήσια ανατροφοδότηση από μέσα και έξω από το τμήμα.

Στόχος μας εδώ δεν είναι να προσβάλουμε κάποιο συγκεκριμένο πρόσωπο στην ηγεσία που μπορεί να έχει πάρει αυτή την απόφαση. Αντίθετα, είναι να διορθωθεί το βασικό πρόβλημα: Κανείς δεν πρέπει να έχει τόση δύναμη να επηρεάσει ένα προϊόν όπως το dotnet τόσο κοντά στην άμεση κυκλοφορία. Οποιοσδήποτε ηγείται του τμήματος προγραμματιστών θα μπορούσε να κάνει τις ίδιες ενέργειες, τις οποίες πρέπει να αποτρέψουμε. Το να έχουμε σαφείς κατευθυντήριες γραμμές για την προστασία αυτών των προϊόντων που αποτελούν τη βάση για οτιδήποτε είναι το Visual Studio όχι μόνο θα μας κάνει τους καλύτερους στην κατηγορία ως διαχειριστές λογισμικού ανοιχτού κώδικα αλλά και θα μας βοηθήσει να δημιουργήσουμε το καλύτερο IDE που μπορούμε.

Ευχαριστώ, Graeme για την συμβουλή.