Standardizace a Open Web

S argumentací, proč jsou důležité webové standardy, jsme hotovi. Přístupnost pro všechny (accessibility), stabilita, řízení kvality, nekomplikovanost a jednoduchost používání, to vše nám pomohlo už dávno tuto debatu odložit. Weby hájící tyto ideje, vytvořené jen proto, aby propagovaly webové standardy — jako jsou Webové standardy pro byznys Chrise Heilmanna nebo Projekt webových standardů — nebylo nutné od jejich vzniku v polovině první dekády tohoto století vůbec měnit.

Něco se však změnilo, způsob, jakým se standardy vyvíjejí — záležitost pravděpodobně stejně důležitá jako standardy samotné. Další komunitní debata tedy není o webových standardech jako takových; ale o tom, jak se mají webové standardy standardizovat.

Co je ve standardu?

Myšlenka, že standardizace je důležitá, se odráží v jazyku, jakým popisujeme projekty a komunity. Například na domovské stránce JSON API se konstatuje, že to je “Standard pro budování aplikačních programovacích rozhraní v JSON”. Na stránce často kladených otázek (FAQ) se JSON API popisuje jako specifikace,[1] vývojáři o jeho použití hovoří z hlediska toho, zda je vyhovující. Konkurenční projekt, HAL, se na svém webu odkazuje na vizuální jazyk standardizace — tok stránky připomínající formální dokument žádosti o komentář (Request For Comment, RFC), předtím, než jste přesměrováni na skutečný RFC Komise pro technickou stránku Internetu (Internet Engineering Task Force, IETF).

Tyto projekty ilustrují sjednocování myšlenek o standardech, které, pokud by zůstávaly opomíjené, by mohly vést ke zmatkům.

Tyto projekty ilustrují sjednocování myšlenek o standardech, které, pokud by zůstávaly opomíjené, by mohly vést ke zmatkům. Obě specifikace, JSON API i HAL, jsou de facto standardy — idea přistupovat k běžně se vyskytujícímu problému pomocí osvědčeného postupu, která se organicky šíří vývojářskou komunitou.

Specifikace, které máme sklon považovat za běžnější, jako jsou ty pro HTML a JavaScript, jsou standardy dobrovolného konsensu, což znamená, že mezinárodní orgány nastavující standardy a odvětvová konsorcia souhlasily s tím, že budou pracovat na těchto specifikacích a akceptovat je, a také vytvářet podněty pro jejich implementaci. Ale i v prostředí dobrovolného konsensu mohou odlišná mínění technologii rozštěpit — JSON (nezaměňujte s JSON API) má v současné době dvě konkurenční specifikace dobrovolného konsensu: jednu se skupinou standardů Ecma, druhou s IETF.

Všechny standardy budou mít specifikace, ale ne všechny specifikace jsou standardy.

Přestože zde ve všech případech používáme termín “standard”, všechny specifikace nebyly vytvářeny stejně. Někdy se dokonce setkáme s takovými žádostmi o komentáře (RFC, Request For Comments) pro technické specifikace, z nichž se nikdy standardy nestanou, protože jsou to teoretické ideje o tom, jak by něco mohlo fungovat; tedy, všechny standardy budou mít specifikace, ale ne všechny specifikace jsou standardy.

Tvorba standardů

“Oficiální” standardy jsou specifikace, které prošly procesem dobrovolného konsenzu. Existuje potenciálně jasná cesta pro projekty, aby se vyvinuly z de facto specifikace do projektu, který je standardizovaný prostřednictvím dobrovolného konsenzu:

1. Vývojář identifikuje problém a navrhne řešení komunitě;
2. Komunita poskytne zpětnou vazbu a navrhne další potenciálně alternativní řešení ve veřejných kanálech, jako jsou GitHub nebo Google Groups;
3. Komunita dosáhne masového konsenzu a předá specifikaci nějakému orgánu pro standardy;
4. Vývojáři implementují řešení, zatímco standardizační orgán standard formalizuje a uzákoňuje.

Většina vývojářů, které znám, jsou chytří, vynalézaví a preferují cestu nejmenšího odporu; díky filozofii komunity softwaru s otevřeným kódem (OSS, Open-source Software), že všechny chyby jsou malé, inklinují ke spolupráci na řešení problémů oboustranného zájmu. Je to dost průzračná, ne zcela nová idea, a Manifest rozšiřitelnosti Webu je v podstatě výzva k akci implementovat právě na tomto procesu více vývojářských zpětných vazeb.

Je vzrušující pomyslet si, že příští oficiální webové standardy možná vzejdou z komunity vývojářů, ale v praxi byla tato cesta k oficiální standardizaci znejasněna. Poprvé to zakusila Komunitní skupina responzivních obrázků (Responsive Images Community Group, RICG) když navrhla specifikaci pro element picture — poukázala na potíž způsobenou tím, jak HTML zpracovával responzivní obrázky. RICG navrhla faktické, vývojářsky vybudované řešení Pracovní skupině pro technologii webových hypertextových aplikací (Web Hypertext Application Technology Working Group, WHATWG), udržovatelce “živého” HTML standardu. V dobře zdokumentované sérii událostí WHATWG prakticky vývojářské řešení zavrhla ve prospěch vágně specifikovaného řešení, které vytvořili v průběhu několika málo dní. Kdyby nebylo zanícení a vytrvalosti komunity a vedení RICG, vývojářské řešení by bylo zmařeno.

Kdyby nebylo zanícení a vytrvalosti komunity a vedení RICG, vývojářské řešení by bylo zmařeno.

Specifikaci RICG nakonec WHATWG a W3C akceptovaly, ale praktická zkušenost se standardizačním procesem určitě zanechala v ústech vývojářů nepříjemnou pachuť. Bylo by dost snadné soustředit naši pozornost na vylepšování tohoto procesu pro komunitní skupiny jako je RICG, a web by určitě byl lepším místem pro vývojáře, kdybychom tak učinili — nebylo by ale pěkné, kdybychom mohli definovat standardizaci ne jako “proces, který vyrobí technologii”, ale jako “proces, kterým se dohodneme na technologii”?

V realitě je otevřená standardizace v podstatě silový a politický proces a svým způsobem zasahuje do toho, jak přemýšlíme o projektu Open Source a o řízení komunity. Řekneme-li to slovy vlivné eseje Erica Raymonda (Katedrála a bazar), budovali jsme webové technologie na veřejně přístupném trhu s étosem otevřeného kódu, ale standardizace těchto technologií je činnost podobná stavění katedrály.

Když pátráme, jak standardizovat technologii, potřebujeme rozpoznat pnutí neodmyslitelně spojené s budováním katedrál, z něhož se později stanou ústřední autority, které budeme muset odmítnout. Naši výzvou je nalézt rovnováhu mezi kapitalizací benefitů pocházejících ze standardizačních procesů, aniž by přitom docházelo k erozi ideálů naší komunity. Naštěstí existují dlouhé historie standardizačního úsilí v jiných odvětvích a komunitách, které mohou pomoci proniknout do podstaty standardizace webu.

Staré modely pro moderní standardy

Open source komunity se mohou dost přiučit z historie a starších modelů řízení všelijakých organizací zabývajících se standardy — skutečně, konsorcia webových standardů, jako jsou Ecma International a W3C, už mají obdobné organizační struktury, je však užitečné porozumět předchozímu umění, z něhož odvozujeme základnu komunity pro nastavování standardů. Konec konců, mentalita “co funguje, na to nesahat“ platí jen z dlouhodobého hlediska, pokud od samého začátku chápete, proč to funguje.

Dobří programátoři vědí, co mají psát. Skvělí vědí, co mají přepsat (a použít znovu).

Eric Raymond

Ideologické počátky orgánů pro webové standardy sahají až do 19. století, k tehdejšímu prvotnímu úsilí standardizovat telegrafii a inženýrství prostřednictvím různých výborů a komisí, jako jsou Americká společnost inženýrského stavitelství, Americká společnost strojního inženýrství a Americký institut elektroinženýrství. Mnohé z nich pořádaly pravidelné “kongresy” — od předchůdců z viktoriánské éry až k dnešním konferencím o webovém vývoji — které pomáhaly vytvářet standardy a podrobněji definovaly identitu profesionálního inženýra.

Jak se začaly inženýrské discipliny postupně překrývat, bylo jasné, že kooperace mezi těmito průmyslovými asociacemi bude nezbytná, proto se v roce 1918 utvořil „Americký výbor pro inženýrské standardy (American Engineering Standards Committee), aby povzbudil a podpořil kooperaci a koordinaci standardů mezi jednotlivými skupinami. Výslednou strukturou byla jistá “organizace organizací”, která usnadňovala budování konsenzu mezi mnoha inženýrskými organizacemi, každá z nich se skládala u odlišného sdružení inženýrů z odlišných sad firem.

Dnes je AESC známý pod názvem Americký národní standardizační ústav (American National Standards Institute), ale jeho sto let starý model řízení — s hojnými komunitními krizemi a ideály — se odráží ve skupinách webových standardů. Tehdy, jako i nyní, organizační polemiky často vznikají mezi praktiky “nakupovací kultury” a akademiky “školské kultury”. Jisté množství pnutí mezi skupinami je zdravé, aby se ideje pohnuly vpřed, a tyto rané skupiny vyvinuly organizační prostředky, jak podle potřeby tenze vytvářet a uvolňovat. Současná výchozí odpověď k polemikám v open-source softwaru je rozdvojit dotyčnou specifikaci, vyprodukovat síť soupeřících táborů, které jsou stimulovány tak, aby zdůrazňovaly rozdílné a ne shodné oblasti.

Když soupeří ideály

“Otevřenost” je stěžejním ideálem Open Web komunity, a zároveň slovo jakoby potřísněné blátem. Rétorika otevřenosti znamená komunikovat sadu uspokojivých hodnot, a tyto hodnoty jsou často závislé na řečníkovi a publiku. Ve své knize Otevřené standardy a digitální epocha profesor Andrew Russell poznamenává, že “pro jednotlivce je ‘otevřený’ zkratkou pro transparentní, vlídný, zúčastněný a podnikavý; pro společnost v širším slova smyslu otevřený znamená obrovitý vzrůst toku zboží a informací prostřednictvím globálního, tržně orientovaného výměnného systému”.

Protože nemáme k dispozici jedinou definici, která by vyhovovala všem zúčastněným, míváme sklon chápat “otevřený” ve smyslu “všezahrnující”.

Standardizace je na druhé straně často proces, který definuje, co něco je pomocí toho, čím není. Russell poznamenává, že širším společenským cílem standardizace technologie je vytvořit nějakou “soudržnou a flexibilní síť”, která by podporovala složité sociální a ekonomické aktivity. Proces výroby standardů tedy znamená začlenit širokou škálu postupů a idejí s politickými, ekonomickými a kulturními dimenzemi — to vše může mít strategickou důležitost pro tvůrce, implementátory, konečné uživatele i širokou veřejnost. Když to chápeme takto, jsou standardy technicky-orientované instance diplomacie.

Když se v roce 1977 zřizoval podvýbor mezinárodní organizace pro standardizaci (International Organization of Standardization, ISO) za účelem vývoje otevřených standardů, poznamenal Charles Bachmann, že “přídavné jméno ‘otevřený’ nutně vede k závěru, že všichni účastníci přicházejí do systému jako rovnocenní partneři”. V realitě však participující nepřicházejí často k jednacímu stolu jako rovnocenní partneři — rozvoj snahy o propojení otevřených systémů, OSI (Open Systems Interconnection), byl zmařen organizačními mocenskými hrátkami a růstem konkurenční technologie, TCP/IP. Rovnost, jako ideál pro tvorbu otevřených standardů, však přetrval. Tento ideál pramení v hlubokém setrvávajícím odporu proti centralizované moci, což se, podle Russella, odráží v historiích mnoha organizací nastavujících standardy. Prosadit tuto vizi rovnosti a dosáhnout úspěšné implementace někdy znamená skrývat konflikty a potíže před těmi, kdo se nacházejí vně zasedací místnosti — což není přesně takové transparentní chování, jaké by se někdy mohlo očekávat od “otevřeného“ systému.

Pokud jsou standardy skutečně dohodami mezi rovnocennými subjekty, pak řídící autoritou je právě tato dohoda. A pokud je nastavení standardů odmítnutím centralizovaného řízení, pak se proces standardizace stává procesem kreativní destrukce. Je to ideologický kruh života otevřených standardů: nějaká skupina vyrobí konsenzuální standard nějaké technologie; jak tento standard cirkuluje, nějaká nová strana poukáže u existujícího standardu na nějakou slabinu nebo na případ užití, který nebyl vzat v úvahu. Původní skupina si pak musí udělat čas na požadavek nové strany a standard přepracovat, jinak čelí tomu, že bude zamítnuta i se svým standardem. Když dotyčná skupina původní skupinu odmítne, zformuje konkurenční skupinu a standard, a celý cyklus začíná nanovo.

Je to komplikované

Web, do něhož vplétáme standardizace Open Web, je sám o sobě dost spletitý — politické, ekonomické a sociální vztahy mezi lidmi, technologiemi, firmami a odvětvovými skupinami je obtížné zjistit na první pohled. Při inspekci zblízka je vidět, že tyto organizace a komunity jsou složité systémy formující složitou síť — tak složitou, že jsem byla nucena vytvořit tento interaktivní síťový graf Open Web standardů, abych při svém výzkumu měla o nich pořád přehled.

Než začnete překotně vytvářet složitou, decentralizovanou síť skupin open source standardů, patrně stojí za zmínku, že složité systémy časem selžou ve sto procentech případů. Decentralizovaná síť možná umožní zažít ve většině případů menší selhání, ovšem klíčem k dlouhověkosti systému je, aby selhával chytře — a pokud mě výzkum vůbec něco naučil, tak to, že standardizace selhává na lidském, ne technologickém faktoru. Ať už je to dobře, nebo špatně, složitost není viróza — takže abychom se jí vyhnuli, je potřeba udělat složitost standardizačního systému konzumovatelnou, aniž bychom přitom vynechali ze svých úvah smysluplné části procesu.

Když v komunitě absentuje koordinace, následuje metody prostý entuziasmus — lapený někde v Bermudském trojúhelníku konkurenčních standardizačních orgánů, implementátorů, to je komunita vývojářů. Chceme-li aby se projekty řízené komunitou staly oficiálními, mezinárodně uznávanými standardy, potřebujeme rozumět dopadu našich procesů řízení stejně tak, jak rozumíme technickým specifikacím pro naše technologie.

O autorce

Jory Burson

Jory Burson je provozní ředitelkou (Chief Operations Officer, COO) v Bocoup, což je firma zabývající se technologií Open Web. Když nezajišťuje dlouhodobou realizovatelnost mise firmy Bocoup, ani lidi nenudí organizační psychologií, najdete ji, jak se potlouká se svým psem někde v Somerville ve státě Massachusetts. Jory se také nedávno věnovala street artu, ale nikomu to neříkejte.

[1] Pozn. př. Ve skutečnosti je na domovské stránce také uvedeno slovo Specifikace, nikoli Standard.

O překladu:

Článek byl převzat a přeložen pro interval.cz se svolením serveru alistapart.com

Přeložil: RNDr. Jan Pokorný
Znění původního článku najdete na Standardization and Open Web