Kilka miesięcy temu Marc Bevand - starszy inżynier oprogramowania w firmie Adconion - rozpoczął na forum Hacker News dyskusję dotyczącą powolnej jego zdaniem ewolucji jądra systemowego Windows. Wszystkie zamieszczone w założonym przez niego temacie odpowiedzi były raczej standardowe. Wszystkie prócz jednej. W dyskusji wziął także udział anonimowy pracownik firmy Microsoft, który potwierdził przypuszczenia Bevanda. Po krótkim namyśle szybko jednak usunął swój post. Zgodził się natomiast na opublikowanie go przez Bevanda na jego własnym blogu, pod warunkiem wycięcia z treści wszelkich danych, potwierdzających zajmowane przez anonimowego programistę stanowisko. Tak zachowała się dość popularna opinia pracownika Microsoft na temat rozwijanego przez niego jądra systemowego Windows NT, które zdaniem autora nie tylko jest coraz wolniejsze od jądra linuksowego, ale w niektórych aspektach istnieje pomiędzy nimi stale powiększająca się przepaść.
Autor wyraźnie podkreślił, że rozwój jądra systemu Windows jest mało dynamiczny i powolny – znacznie wolniejszy niż rozwój konkurencyjnego Linuksa, którego twórcy takie cechy przypisywali do tej pory właśnie jemu. Jego zdaniem jądro NT jest również znacznie słabiej testowane, co podczas dużych obciążeń roboczych często odbija się na wydajności. Deweloperzy kodu jądra NT są karani za to, za co deweloperzy Linuksa są nagradzani. W momencie, gdy deweloper zechce zaakceptować zewnętrzny patch musi dwa razy się zastanowić, czy go dodać. Jeśli się na to zdecyduje, to w najlepszym wypadku jego poczynania spotkają się z neutralną reakcją zwierzchników. Również testerzy będą źli, że mają dodatkową pracę, która miejmy nadzieję nie wykryje żadnych nowych usterek, zaś menedżerzy projektu - wiadomo, oni będą chcieli trzymać się ustalonych wcześniej terminów.
Ogólnie mówiąc deweloperzy w ogóle nie są zachęcani do wprowadzania zmian. W przypadku jądra Linux, po zwiększeniu wydajności przeglądania katalogu o konsekwentne 5%, jest się nagradzanym i chwalonym. W Microsoft tylko te największe osiągnięcia są dostrzegane przez najwyższych rangą. Wszystkie pomniejsze spotykają się z chłodną lub neutralną reakcją. Jeśli programista znajdzie sposób na niewielkie zwiększenie wydajności, a nie znajduje się w odpowiednim zespole, wówczas musi działać na własną rękę. Pozostaje mu tylko potajemne przemycenie ulepszenia, zaś jego największym sukcesem będzie to, że jego szef się o tym nie dowie, gdyż mogłoby to nawet zaszkodzić jego karierze.
Microsoft ma również problem z utrzymaniem swoich starych pracowników, którzy przenoszą się do innych firm. Ich miejsca zajmowane są przez młodych i kreatywnych ludzi tuż po studiach. Nie są oni jednak doświadczeni i nie rozumieją decyzji, które podejmowano w odniesieniu do określonych komponentów. Nie mają również szczegółowej wiedzy o tym w jaki sposób działają ich systemy, a dodatkowo nie chcą zmieniać czegoś, co już działa. Dlatego w wielu przypadkach bardziej opłaca się im zbudować coś od podstaw, niż poprawiać już istniejącą rzecz. Przykładem może być choćby wiersz poleceń CMD i stworzona od zera powłoka PowerShell - pomimo, że wielu programistów wolałoby rozbudować CMD. Coraz częściej Microsoft wprowadza nowe rozwiązania, zamiast usprawniać stare. 2-gigabajtowy limit archiwów ZIP, technologia XNA, archaiczny i niezbyt zoptymalizowany kod systemu plików NTFS, implementacja standardu C11 w Visual C++ - wielu tamtejszych programistów chciałoby te rzeczy usprawnić, ale nie mogą.
Zdaniem anonimowego autora, w niektórych aspektach jądro NT wciąż jest lepsze od Linuksa. Niebawem może to jednak ulec zmianie, jeśli opisany powyżej stan się utrzyma. Należy mieć świadomość, że pracownik opisuje sytuację panującą w korporacji jeszcze przed rozpoczęciem restrukturyzacji i ogłoszeniem zmian na stanowisku CEO. Choć kilka dni później autor poprosił o publikację odpowiedniego sprostowania, w którym docenia swoją firmę i wkład wszystkich jej pracowników, to tak czy inaczej przedstawiony przez niego obraz jest dość ponury. Czas pokaże, czy nowy prezes korporacji Microsoft będzie w stanie odpowiednio pokierować firmą, by wpisy takie jak ten już nigdy więcej się nie pojawiały, a sami pracownicy odczuwali dumę z tworzonego przez siebie kodu i wprowadzanych przez poprawek.
