Pomosty

Wednesday, February 2. 2011

Dziś odbyła się debata „Standardy jako pomost łączący Open Source i oprogramowanie własnościowe”.

Forma: kameralna. Atmosfera: miła. Parę rzeczy warto wspomnieć, trochę też sprostować.

Były dwa główne tematy. Raz: o standardach ogólnie, czy są potrzebne, co się zmieniło od pamiętnej zawieruchy przy przepychaniu MSOOXML na siłę w ISO. Dwa: rozprawka na temat "co pozwala oszczędzać publiczne środki i dlaczego standardy".

Punkt po punkcie:

Pojęcie zgodności ze standardami nie było zbyt często używane. Używano po prostu ukutego terminu interoperacyjność, promowanego też globalnie przez Microsoft. Dla mnie nadużywanie tego terminu to "rozmywanie" sprawy, bo jest on na tyle pojemny i obejmuje tyle aspektów (interoperacyjność sieci, systemu, wiedzy, usług), że od razu rozmowy zaczynają skakać po obszarach telekomunikacji, motoryzacji, elektroniki użytkowej ("co mnie obchodzi co jest w iPadzie czy telewizorze"), czy warstw niższych sieci. Co do tego ostatniego to akurat Tomasz Barbaszewski trafnie wskazał, że bez otwartych standardów TCP/IP, bez pracy wyśmiewanych nierzadko naukowców nie byłoby Internetu w obecnej postaci. Novell ze swoim NetWare, IBM z Token ring i Microsoft z NetBEUI i parę innych firm raczyło by nas swoimi rozwiązaniami.

Nagminne, zanim słusznie tego nie wypomniała Elżbieta Andrukiewicz (ekspert od procesu normalizacji z PKN), mieszało się pojęcie otwartego oprogramowania ze standardami. To tak jakby zakładać, że standardy są zabawką dla inicjatyw typu wolne oprogramowanie, zaś absolutnie nie dla projektów gdzie kod źródłowy jest zamknięty. Zwłaszcza otwarte standardy. Albo też z drugiej strony: jeśli jest postulat zastosowania otwartego standardu w jakimś tworzonym przez nas programie to od razu ma on (program) być zgodny z definicją open source. Oba przekonania są całkowicie błędne. Było też odniesienie do standardów de-facto, które oczywiście z normami nie mają nic wspólnego, bo chodzi o "standardy" definiowane przez produkty (samym zachowaniem i być może wyglądem).

Ryszard Dałkowski z MS: "Obecnie 80% oprogramowania open source jest rozwijane na platformie Windows". Cisza na sali, oklasków póki co brak. Nie wiem jaki był zamysł pana Ryszarda, ale chyba chodziło o coś innego, np. o to że 80% oprogramowania open source działa także na Windows. Taką tezę można zaryzykować. Można sądzić, że dzięki inicjatywom firmy Microsoft jest tak zaledwie w niewielkim stopniu, bowiem ta jeśli już promuje oprogramowanie open source, które działa na Windows, to przede wszystkim takie które działa tylko tam (np. serwis CodePlex). W pełni zrozumiałe, nie mamy bowiem do czynienia z organizacją charytatywną. Gloria zbawcy się zatem producentowi Windows nie należy, nie zawadzi przyjazna zachęta "dzięki i prosimy o więcej" (odważniej?). Jako jeden z założycieli projektu KDE on Windows twierdzę, że te (załóżmy 80%) oprogramowania działa także na Windows, jednak pomimo wielu cech tego systemu, a nie dzięki nim.

Sprawdzenie: serwis CodePlex zawiera 1 [słownie JEDEN] projekt w języku C++ w jakimś stopniu stosowalny poza Windows; dla porównania popularny SourceForge oferuje w tej dziedzinie 6858 projektów (w momencie pisania tego tekstu).

Gdy wspomniano o Europejskich Ramach Interoperacyjności 2.0, padło z sali pytanie czy nie daje do myślenia zdefiniowana tam dowolność (continuum). Bez wątpienia jest to doskonały obszar dla lobbingu ze strony tych którzy na ten cel mogą przeznaczyć niemałe środki. Zanim wyrwiemy włosy z głowy, warto jednak wspomnieć, że Ramy są jedynie rekomendacjami, a więc póki coś bezsensownego nie przyjdzie w rozporządzeniach na poziomie krajowym, sprawa nie jest stracona. Jest tu podobieństwo do statusu polskich norm oferowanych przez uprawniony byt: Polski Komitet Normalizacyjny. Wszystkie są one dobrowolne co do stosowania o ile jakieś rozporządzenie (np. przepis prawa budowlanego) nie odnosi się do stosowania jakiejś normy w formie nakazu.

W rozmowach starałem się odnosić do zrozumiałego dla ogółu przykładu, tj. standardów zapisu dokumentów. Od razu kojarzyło się to z konfliktem standardów MS Office Open XML (MSOOXML) i OpenDocument Format. Tak, konfliktem, bowiem nie wiedzieć czemu (?) oba są w ISO (odpowiednio: ISO/IEC 29500 i ISO/IEC 26300). To w konsekwencji trochę rozgrzewało atmosferę. Może to i dobrze.

Odnośnie skakania po tematach, sięgnięto nawet do norm przeciwpożarowych: "zawór hydrantu powinien być ustandaryzowany, bo nie wiadomo jaki model wozu strażackiego przyjedzie do pożaru". To jest racja i dobry przykład (zaraz po rosyjskich torach niezgodnych z polskimi) lecz wyciągnięto od razu sprawę odcienia koloru hydrantu - że nie powinien być on opisany w standardzie, a ewentualnie w innym dokumencie, wobec czego nie ma sensu trzymać się standardu ściśle. Sądzę jednak, że chodzi o to iż nie ma sensu definiować aspektów nie związanych z opisywaną przez standard domeną problemu. Nie oznacza więc to, że format dokumentów biurowych może sobie darować np. opis sposobu zapisu obiektów osadzonych (OLE), a jeśli sobie nie daruje to można go zignorować w implementacji zwanej pełną. I tak np. format MSOOXML jest tu nadmiernie liberalny, wspomina nawet z nazwy implementację (!) infrastruktury komponentowej KParts z KDE, która w KOffice nie jest stosowana od wersji 2.0. Nie sposób więc być zgodnym w tej kwestii z MSOOXML, przez co także i MS Office nie jest. Co więcej przeglądając w treść specyfikacji MSOOXML w ISO, poradzono sobie z podobnymi niedomówieniami przez oznaczenie danych cech jako opcjonalne, co nie jest rozwiązaniem problemu a zamiecieniem pod dywan (by było jasne OpenDocument ma też niedopowiedzenia, czyli jest obszar wymagający uzupełnień, nie ma jednak odniesień do konkretnych implementacji). Z drugiej strony może sobie darować zapisywanie informacji w dokumencie o podłączonych u użytkownika drukarkach, gdyż absolutnie nie należy to do domeny problemu. Podobnymi rzeczami jednak z kolei niepotrzebnie zajmuje się format MSOOXML.

W abstrakcie do debaty napisano, że Microsoft mocno inwestuje, wspiera standardy i działalność w organizacjach standaryzacyjnych. Chwała Mu za to i pozdrowienia dla Ryszarda Dałkowskiego, świeżo upieczonego Manager d/s strategii Open Source w MS. Stąd jednak jeszcze daleko do aktywnego uczestnictwa np. w OASIS Open Document TC. Microsoft był w nim obecny od dawna, przed wystąpieniem o standaryzację MSOOXM w ISO. Przedstawiciele MS byli jednak nieaktywni w czasie gdy ważyły się losy formatu pod względem jego zawartości. Aktywność przedstawicieli, jak wskazuje Rob Weir z IBM (OASIS, ISO), zwiększała się jednak gdy zbliżał się każdorazowo finał w kolejnym etapie przygotowywania standardu. Zgłaszana była spora liczba nieadekwatnych do etapu prac uwag, na które trzeba było odpowiedzieć. Również uwag, które nie miałyby racji bytu gdyby MS zdecydował się na współpracę od początku. Pewnie dezorganizowało to prace co najmniej raz, ale mamy ODF 1.1 i 1.2 uwzględniające uwagi także niżej podpisanego (przysłane mailem!).

Inna szybka myśl: najpierw istniał format Open Office XML, w którym swój początek mają prace nad OpenDocument. Microsoft obwieścił wtedy nazwę Office Open XML (widać podobieństwo?). Runda druga: najpierw istniał open source. Microsoft wymyślił inicjatywę Openness. To chyba ta odpowiedzialna za powstanie 80% oprogramowania open source? Do przemyślenia dla tropicieli nowych zastosowań zasady 3 razy E w dziedzinie nazewnictwa.

Sprawa zmęczenia tematem. W 2006 napisałem Przewiduję, że Microsoft będzie kontynuował walkę narzędziami dezinformacji typu FUD. Pokazuje to samo użycie słowa Open w nazwie implementacji swojego wewnętrznego formatu, lata po powstaniu komitetu d/s OpenDocument. Jest to doskonałym sposobem na skuteczne przekonywanie obecnych i przyszłych klientów, że MS OpenXML i OpenDocument to jedno (jest to absolutnie nieprawdziwe). Mamy 2011 i co? Na sali podczas debaty wśród specjalistów padają stwierdzenia, że oba formaty są w zasadzie do siebie takie podobne i nie ma różnicy który format aplikacja obsługuje. Nie omieszkałem wspomnieć, że sensowna implementacja obu naraz to ciężar nie do udźwignięcia nawet przez średniej wielkości firmę. Zgadzam się, że temat mający swój kulminacyjny punkt w 2008 roku przy nadużyciach MS w ISO nie jest teraz sexy w "prasie kolorowej" i większość osób wcześniej zainteresowanych jest już nim teraz znużona. Czy oznacza to jednak, że postulaty już nie obowiązują bo pojawiły się tematy zastępcze: kolorowe zabawki o nazwie iPad albo slogany typu przetwarzanie/przechowywanie w chmurze - zupełnie niezależne od postawionego wyżej problemu?
Problem wskazania jednego formatu dokumentów, w który ma inwestować świat nie został rozwiązany; nie został też wskazany możliwy, realistyczny sposób jego rozwiązania. Wobec zmęczenia materii nie odniosłem się nawet do czyjegoś stwierdzenia sugerującego, że sam fakt stosowania języka XML zapewnia zauważalną zgodność między dwoma formatami (zgodność "za darmo" jest taka jak przy alfabecie łacińskim: zarówno język polski jak i francuski stosują jakiś wariant alfabetu łacińskiego, ale jakoś na złość teksty francuskie nie chcą samoistnie tłumaczyć się na nasz język ojczysty).

Ryszard Dałkowski z MS przedstawił jeden "fakt" odnośnie wczesnych dni MSOOXML: format ten rzekomo ma oferuje funkcje używane w serwisach sieciowych, a OpenDocument nie, co uzasadnia niezgodę MS na przystąpienie do grupy producentów rozwijającej OpenDocument. Jednak MSOOXML może miał mieć te funkcje, lecz ich nie ma. Fakt: Nie znam takiej sekcji w specyfikacji MSOOXML, zarówno z ECMA jak i z ISO. Taka postawa "chcieliśmy współpracować, ale jesteśmy tacy innowacyjni że by nas nie zrozumieli" to takie samo mydlenie oczu jak upieranie się przy tym, że świat się skończy jeśli MSOOXML zerwie z muzealnym podejściem do informatyki i nie będzie definiował tagu <rób-spacje-jak-Word-95>.

Podniosłem sprawę sensu tłumaczenia norm informatycznych z angielskiego. Tzw. normy okładkowe to praktykowany sposób na cięcie kosztów normalizacji w Polsce (tłumaczy się głownie abstrakt i tytuł, reszta - po angielsku, a sprzedaje kopie na normalnych zasadach). Ponieważ odbiorcy norm takich jak MSOOXML czy OpenDocument to z zasady wyłącznie osoby techniczne które i tak, choćby dla precyzji języka, wybiorą oryginał angielski, sensu tłumaczenia długich tekstów (MSOOXML to przeszło 6000 stron) na polski nie widzę. Można zadać sobie pytanie: kiedy ostatnio czytałem tekst normy ISO 90002? Pewnie nigdy. A słyszeć, słyszałem. Chodzi o to by laik mógł sprawdzić certyfikat zgodności produktu z normą a nie czytać zdanie po zdaniu i weryfikować zgodność normy. Nie-laik też nie będzie wczytywał się w normę w celu weryfikacji produktu. Skorzystać może bowiem z analogicznych do W3C HTML Validator narzędzi dla OpenDocument czy MSOOXML, które są efektem ubocznym implementacji tych formatół. Proste, a nie oczywiste nawet wśród specjalistów na sali. Warto powtórzyć: w dziedzinie informatyki świat jest w omawianych dziedzinach jeszcze w średniowieczu.

Wspomniano też sprawę patentów. To osobna kwestia, której być może poświęcona będzie jedna z kolejnych debat. Patenty mogą występować w rozwiązaniach opisanych przez standardy i to otwarte standardy. W praktyce podstawowa rzecz, jaką można powiedzieć w dziedzinie patentów jest następująca: niestwierdzenie zagrożenia patentowego oznacza jedno: niestwierdzenie zagrożenia patentowego, nic więcej. Warto mieć nadzieję że do Polski nie trafi zmora patentów na oprogramowanie (algorytmy), bo sytuacja w USA jest taka, że również MS jest chłopcem do bicia przez trolli patentowych (są to firmy czekające na to, aż "ofiara" zarobi wystarczająco sporo na jakimś rozwiązaniu i wtedy można uderzać bo rzeczywiście jest po co). Mówiąc o zabezpieczeniach, były wspomniane inicjatywy wymiany pul patentowych między wielkimi koncernami jak i mniejszymi firmami. Nie jest to znak naszych czasów bo w branży motoryzacyjnej firmy w celu ochrony problemami patentowymi chętnie się stowarzyszały, na czele z Fordem przed II wojną światową. W świecie open source jest choćby Open Invention Network, wsparte co najmniej 800 patentami m.in. przez firmy IBM, NEC, Novell, Philips, Red Hat i Sony. Jest to szczególnie interesujące w obliczu bieżącego przejęciu firmy Novell przez Attachmate, jak i prób przejęcia patentów Novella przez CPTN. Po pomyślnym przegłosowaniu na Akademy 2010 do OIN w grudniu 2010 dołączyło stowarzyszenie KDE zrzeszające wielu twórców oprogramowania, w tym niżej podpisanego. Daje to jakąś ochronę przed pewnymi roszczeniami patentowymi. Nic więcej.

Jestem jak najbardziej zadowolony z debaty i spotkania. Zarysowana została istota i ważność tematu norm bez względu na to czy oprogramowanie jest własnościowe czy też nie. Organizatorom i prowadzącemu (red. Edwin Bendyk, zapewne poruszy kiedyś temat w Polityce) należą się szczere podziękowania.

Some rights reserved by thebristolkid

Related entries by tags:

Posted by Jarosław Staniek in Pakiety biurowe, Standardy at 21:30 | Comments (6) | Trackbacks (0)
Defined tags for this entry: media, msooxml, opendocument, patenty, spotkania, standardy

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Z tym tłumaczeniem norm to nie całkiem się zgadzam. Jeśli chodzi o ISO 29500 to raczej
masz rację, ale już jeśli chodzi o rodzinkę ISO 27000 to raczej nie.
Jeśli np. mamy
skorzystać z "Dobrych praktyk" (ISO 27002) to raczej warto je mieć po polsku -
tym bardziej, że norma jest skierowana raczej do specjalistów od wdrażania TQM, a nie
do specjalistów IT.
Wdrożenie ISO 9000 też wymaga znajomości odpowiedniej
normy.

W sprawie "hydrantu" - istotny jest interfejs! Jak interfejs nie
będzie zestandaryzowany chałupa się spali i kropka. :(

pozdrówka z krakówka!

#1 Tomasz on 2011-02-03 12:12 (Reply)

Tak, wszyscy się generalnie zgadzaliśmy co do tego, że odnośnie norm typu ISO 2700x,
to jasne że sekcje przeznaczone dla osób obsługujących wprowadzenie i utrzymanie normy
w organizacji powinny być tłumaczone i lokalizowane do lokalnych uwarunkowań, choćby
nawet nie miały odniesień do przepisów prawa. 29500-minus-śmieci czy 26300 są
zapisywalne niemal w całości w języku formalnym, z czego korzystają zresztą
walidatory (to może jest dobra metryka rozróżniająca kategorię norm?).
Nieporozumienia wczoraj były pewnie spowodowane tym, że sądzono iż generalizuję fakt
niepotrzebności tłumaczeń, a nie taka była moja intencja.

#1.1 Jaroslaw Staniek on 2011-02-03 14:25 (Reply)

Panie Kolego,
trochę Pan pojechał z tym CodePlex. Jest tam (tylko lub aż) 120
projektów z tagiem C++. Co oznacza, że narzędzia (aplikacje i biblioteki) są
skierowane do programistów C++. Stwierdzenie, że jest tylko jeden projekt jest sporym
nadużyciem.

#2 P on 2011-02-15 18:57 (Reply)

Witam. Stan jaki podalem był na dzień pisanie artykułu. Wpisałem C++ w pole
wyszukiwania.
Teraz w zaleznosci tego czy klikne tag po prawej stronie czy w innym
miejscu (jest to dość niespójne) wyników widzę od 4 do 22 projektow.
Przykładowo
http://www.codeplex.com/site/search?query=c%2B%2B&sortBy=Relevance&tagName=%2cc%2b
%2b%2c daje 22, nie 120.
Ważny jest też fakt, że fraza czy tagi C++ dotyczą
projektów wymagających MSVC++ i to czesto zawierają wymóg korzystania z .NET
assemblies, kodu zarządzanego. Moja kwerenda dotyczyła przenośnego C++, nie managed.
Zatem nawet z tych 22 projektów wykroić można przenośnych pewnie jeszcze mniej. Trudno
wskazać liczbę 120 podaną przez Pana, niemniej dziękuję za uwagę.
Nawet
zakładając liczbę 120 dla projektów C++, jak się ona ma do 20598 projektów, których
deklaruje CodePlex? To jest 0.6%.

#2.1 Jaroslaw Staniek on 2011-02-18 10:54 (Reply)

Hehe a niech robią przenoszą programy na windowsa. Użytkownicy windowsa poznaja
aplikacje np z kde i potem łatwiej będzie im się przesiąść na linuksa.

#3 Daniel on 2011-02-16 14:27 (Reply)

ciekawy koment... na temat patrzę raczej filozoficznie :) czyli od strony biznesowej...
tzn analizy sektora, gier strategicznych itp... dlatego fajnie poczytać docinki
techniczne które są dla takiego misia jak ja kosmosem...

Ryszard Dałkowski - a
myślałem że są limity brawury... szkoda że ktoś nie parsknął
śmiechem...

pzdr... niech się wam wiedzie w kaligrze ;)

#4 wilq on 2011-02-21 04:35 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	HTML-Tags will be converted to Entities. Enclosing asterisks marks text as bold (word), underscore are made via _word_. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry