Od: Bill Gates
Data: 5 grudnia 1998
Temat: Wyświetlanie [dokumentów] Office

Jedna rzecz jaką musimy zmienić w naszej strategii to zgoda na poprawne wyświetlanie dokumentów MS Office w obcych programach - jest to najbardziej destrukcyjna z rzeczy jakie możemy uczynić naszej firmie.

Mamy zaprzestać wkładania jakiegokolwiek wysiłku [w poprawne wyświetlanie w obcych programach], ponadto mamy zapewnić by wyświetlanie dokumentów Office w znacznym stopniu wymagało obecności WŁASNOŚCIOWYCH FUNKCJI INTERNET EXPLORERA.

Jakakolwiek inna postawa to samobójstwo dla naszej platformy. To jest sprawa, gdzie Office musi zapobiec zniszczeniu platformy Windows.

Z chęcią wyjaśnię to szerzej.

Podobnie całe to zamiłowanie do [otwartego protokołu dostępu do plików] DAV dla Office/Exchange jest jednym wielkim problemem. Chciałbym się upewnić, że inni też to rozumieją.

Warto wspomnieć, że materiał którego przykładem jest powyższy dokument to wynik lat badań i doświadczeń rynkowych koncernu. Mimo swej niewątpliwej wartości, został udostępniony społeczności IT bez opłat licencyjnych. Był to wówczas precedens -- dziś tylko nieliczni posuwają się do tak daleko idącej filantropii, a jeśli już to robią, to na skutek daleko idących zachęt np. ze strony Komisji Europejskiej.

Jakość omawianej koncepcji mającej na celu zwiększenie wygody użytkowników została precyzyjnie osiągnięta przez ścisłe przyklejanie formatów dokumentów i protokołów wymiany danych do wiodących na runku systemów operacyjnych. Udaje się tym osiągać niespotykaną nigdzie indziej wydajność a jednocześnie dbać o prawomyślność wśród użytkowników i w ten sposób redukować wpływ niebezpiecznych fundamentalizmów.

Koncepcja powstawała już na początku lat 90:

Od: bradsi, 27 sierpnia 1992
Temat: Nieudokumentowane API

Możemy dokumentować interfejsy programistyczne o których wiemy, że są używane przez nasz zespół d/s aplikacji [np. MS Office] oraz niezależnych dostawców oprogramowania. Jest to dobra praktyka. Nie jest to jednak tak proste jakby się wydawało, ponieważ niektóre wywołania funkcji zależą od kontekstu i wymagają znajomości kody źródłowego [Windows] [...]
Największą przewagą naszego zespołu d/s aplikacji jest dostęp do kodu źródłowego systemu operacyjnego. Dopóki ten stan rzeczy się utrzymuje, problem [który mają firmy trzecie z nami] będzie istniał.

Faktycznie Mr Jimmal od dawna zakładał, że nasz zespół d/s aplikacji nie ma dostępu do kodu źródłowego [Windows] [..]
Kiedy powiedziałem mu, że to nie jest prawdą, z jego twarzy dało się wyraźnie odczytać reakcję "O Kur..".
więcej..

Praktycznym rozwinięciem przedstawianych tu idei został format MS Office Open XML, często spontanicznie zwany też OpenOffice XML, na cześć wciąż błądzącej i powtarzającej swoje mantry konkurencji. Przy jego powstawianiu udało się sprawnie zachować przewagę konkurencyjną wypracowaną przy okazji wprowadzenia formatów binarnych DOC/XLS/PPT: przede wszystkim przyklejenie żywotnych funkcji programu do konkretnego systemu operacyjnego oraz pominięcie specyfikacji istotnych funkcji, np. obiektów osadzonych. Całości dopełniło oznaczenie nieudokumentowanych funkcji jako opcjonalne: nikt przecież nie jest zmuszony do pisania programu doskonale współpracującego z MS Office. Użytkownikom oczekującym doskonałej zgodności, według założeń projektowych formatu, powinien wystarczyć MS Office. Koszta poniesione przez firmę przecież uzasadniają to, że MS Office Open XML jest narzędziem promującym właśnie produkty tej samej firmy; każda inwestycja ma mieć przecież określoną stopę zwrotu.

Przy procesie standaryzacji MSOOXML da się zauważyć szereg innych nowatorskich posunięć, m. in. przekonano specjalistów od normalizacji, że duży, ponad 6000 stronicowy materiał (w USA wszystko musi być duże) opisujący formaty dokumentów, wcale nie musi posiadać choćby jednej implementacji w postaci aplikacji by stać się standardem ISO. W wyniku prac normalizacyjnych powstał standard ISO: Office Open XML (OOXML), istotnie różniący się od oryginalnej specyfikacji Microsoft. Historia pokazała słuszność tej raz obranej drogi, gdyż pełna implementacja OOXML nadal nie istnieje, ani nie jest nawet w planach. Nikt też zresztą nie wie kto będzie producentem tejże ani czy jest to możliwe wobec wewnętrznej sprzeczności fragmentów standardu. Dla wielu obserwatorów stan ten ma jednak niewątpliwą wartość podobną do filmów z otwartym zakończeniem - zmusza to do myślenia, każdy może sobie dopisać ciąg dalszy. Dyskusjom często nie ma końca, a większość i tak utożsamia obecną na folderach reklamowych nazwę Office Open XML ze standardem ISO, podczas gdy reklamowany format MSOOXML, czyli format MS Office 2007.

Na rynku dostępnych jest coraz więcej rozmaitych konwerterów, czytników online i offline, a wewnętrzne audyty u dużych klientów badające zgodność z wiodącymi pakietami oprogramowania są oceniane jako wskaźnik postępu. Nigdy tak wielu (konsultantów i pośredników) nie zawdzięczało tak wiele tak niewielu nadmiarowym, zmyślnie zaplanowanym standardom. Konieczność aktualizacji oprogramowania do obsługi dokumentów raz na około trzy lata to bezcenny zasób, który każdy zatroskano o przyszłość branży winny jest odpowiedzialnie pielęgnować. Za resztę klienci zapłacą ze swoich podatków i w marży sprawnie ukrytej np. w cenie sprzętu.

Ostatnimi czasy w hierarchii ważności miejsce standaryzacji zajęło pojęcie wolności wyboru. Oczywiście chodzi o wolność wyboru standardu. Kiedyś format powstały przez skorzystanie z nieskrępowanej wolności wyboru zwano formatem własnościowym, nawet gdy był on udokumentowany lecz zależny od konkretnej implementacji programu. Te czasy minęły. Każdy producent może teraz mieć swój standard i chodzić w glorii chwały, tym większej im większy jest wolumen sprzedaży. Łatwiej jest też w imię wolności wyboru promować własny standard, zamiast przystępować do prac standaryzacyjnych w komitetach najeżonych przedstawicielami konkurencji (gdzie prace wymagałyby trudnego konsensusu, np. w OASIS).

Pracom komitetów zajmujących się niekorzystnymi standardami nie trzeba się jednak przyglądać z daleka. Zawsze można wysyłać do nich swoich przedstawicieli. Zacierając nieprzyjemne wrażenie można też przygotować odpowiednie obwieszczenia dla prasy (tania reklama!) na temat nadchodzących przełomowych zmian. To daje czas by konkurencyjny standard dało się przygotowywać na swój sposób i swoim rytmem. W samym czasie po notatce prasowej nasza część rynku już wstrzymuje oddech -- ogranicza zainteresowanie niekorzystnymi dla nas standardami.

Nowo powstały, rzekomo nadmiarowy standard, niekoniecznie będzie zgodny z rezultatem prac innych komitetów standaryzacyjnych, ale i na to da się znaleźć sposób aby nie zaszkodzić wizerunkowi. Wystarczy pojęcie standardu zastąpić pojęciem interoperacyjności między wieloma standardami. Znaczenie tego słowa i tak już niemal nikt nie rozumie, a nieliczna grupa epigonów jedynie patrzy jak się ono dezawuuje.

Niejako premią dla lojalnych klientów, którzy "przeszli" ze starych binarnych formatów DOC/XLS/PPT na MSOOXML może być opublikowanie specyfikacji starych formatów. Kiedyś wiązałoby się to z nieuzasadnionymi kosztami, bowiem według zeznań w jednym z procesów sądowych, sam producent nie dysponował dokładną dokumentacją wspomnianych formatów (była to też linia jego obrony). Teraz nie jest to już problemem, ponieważ dokumentacja została odtworzona na potrzeby nowo powstającego MSOOXML oraz na żądanie wyrażone w prawomocnych wyrokach sądowych. Udostępnianie ważnych specyfikacji formatów jako demonstracja dobrej woli i otwartości, lecz dopiero w momencie gdy znaczenie formatów nieuchronnie się zmniejsza, jest taktyką opłacalną i ze wszech miar godną naśladowania.

Krzepiące jest też to, że wzorce wytyczone przy zasŧępowaniu formatów binarnych MS Office przez MSOOXML są nadal aktywnie wykorzystywane. Istnieje bowiem jeszcze rodzina z formatów binarnych MS Office, a mianowicie formaty baz MS Access. Faktem jest, że formaty te nie mają jak dotąd swojego odpowiednika w MSOOXML, wobec czego nie nastał jeszcze czas na demonstrację otwartości:

Pytanie: Potrzebuję uzyskać dostęp danych w plikach MS Accessa na komputerach zaopatrzonch w systemy Unix/Linux oraz systemy typu mainframe. Wymagany jest chociaż dostęp do odczytu. Potrzebuję oficjalnej dokumentacji formatów od Microsoft lub alternatywnych procedur napisanych w języku C++, które mógłbym użyć na platformie Unix aby uzyskać dostęp do moich plików MDB.

Odpowiedź: Aktualnie nie mamy żadnych planów co do udokumentowania formatu MDB programu Accessa czy też formatu MDF programy MS SQL Server.

więcej..

Przy założeniu, że żaden partner z którym należy się liczyć, np. sąd dużego kraju lub Komisja Europejska, nie wystosuje odpowiedniego żądania, być może uda się wspomniane formaty pozostawić zamkniętymi na zawsze.