Rýsuje se vážnější konflikt mezi Apple a tvůrci KHTML?
13. 05. 2005, 6:08 · Nakousnutá jabka
Na povrch probublala asi déle trvající nespokojenost tvůrců KHTML se spoluprací ze strany Applu – i když dodržuje licenční podmínky, příliš nepomáhá vývoji KHTML samotného. KHTML je, jak jistě víte, základem pro WebCore, renderovací jádro, na kterém je postavený prohlížeč Safari a další webové služby v Mac OS X.
Když se Apple v roce 2002 rozhodl pro KHTML místo Gecka, jádra Mozilly, a v lednu 2003 to oznámil na MacWorldu spolu s uvedením Safari, bylo to považované za další vzorovou ukázku spolupráce Apple a open-source sféry, neboť například jádro systému, Darwin, je také uvolněné jako open-source a vývojáři se v něm mohou radostně vrtat dle svých potřeb (mám ale pocit, že Apple uvolňuje novou verzi Darwina AŽ po uvolnění systému, který je na něm založen, takže nelze ze zdrojáků zjistit, jaké změny se chystají). První reakce ze strany vývojářů KHTML byly poměrně radostné, Apple totiž (byť se zpožděním, neboť se pracovalo v utajení) uvolnil pro KHTML všechny změny, které v engine udělal, což ostatně činí nadále.
Sám však nepoužívá přímo KHTML, ale WebCore, což je do určité míry modifikované KHTML, zabalené do volání, které pak používá Safari (omlouvám se pokud příliš zjednodušuji, opravte mě případně v diskusi). WebCore a JavaScriptCore jsou uvolněné jako open-source, takže je možné je dále používat v podobě od Apple (a také již existují porty pro Linux). Právě to, že Apple používá WebCore a nikoliv přímo KHTML komplikuje situaci – Apple sice modifikuje KHTML, ale tak, aby to zapadlo do jeho jádra, nikoliv původního KHTML.
To všechno znamená, že na základě KHTML vlastně existují dva renderovací enginy – samotný KHTML a WebCore. Apple všechny úpravy z WebCore jednou za čas dává k dispozici vývojářům KHTML, ovšem ti z toho příliš odvaření nejsou. Kritizují Apple, že jejich vývoj je příliš nekonzistentní, že dostávají pouze úpravy samotné, které je nutné posléze někdy dost pracně implementovat do původního KHTML, že Apple je příliš tajnůstkářský a nedovolí jim nahlížet do bugreportovacího systému, o špatné dokumentaci nehovoře. Apple tak z pohledu vývojářů KHTML dělá do určité míry špatnou reklamu – uživatelé KHTML očekávají, že funkce které se objeví ve WebCore budou rychle a snadno implementovány do KHTML, předpokládají, že je to snadné a také se domnívají, že pokud se stránka zobrazuje dobře v Safari, bude se dobře zobrazovat i v Konqueroru – což však není pravda, neboť tu rozdíly jsou.
Na dané téma se objevilo poměrně dost příspěvků na blozích vývojářů KHTML, od rozhořčeného, přes smířlivější , až po pokus o zhodnocení situace a jak z toho ven, přičemž autor sám konstatoval, že zájmy a cíle obou skupin jsou prostě rozdílné.
Je zajímavé, že bezprostřední rozbuškou se asi stalo usíli Dave Hyatta, dříve jednoho z programátorů Mozilly a spolutvůrce Chimery a nyní programátora Apple, který upravil WebCore tak, aby prošel tzv. Acid 2 testem – lidé kolem KHTML reagovali na dotaz uživatelů “kdy budou všechny změny zapracované do KHTML” jednoduše: “pravděpodobně nikdy”.
Zatímco Apple je tlačen termíny a obvykle se zaměřuje na implementaci konkrétních funkcí, takže někdy něco obětuje, vývojáři KHTML časem tlačeni nejsou a mohou si s některými věcmi vyhrát lépe. Proto je v něčem lepší WebCore, v něčem KHTML.
Docela zajímavý výstřel vyšel ze strany Apple (psal o tom Cnet), kdy Maciej Stachowiak, jeden z vývojářů Safari teamu napsal, ať je tedy KHTML opuštěno a dál všichni pokračují na WebCore, které se Apple bude snažit udělat multiplatformní – otázkou je, nakolik vážně to bylo míněno a především, zda by se tím odstranily existující problémy, které vedly ke špatným pocitům ze strany vývojářů KHTML. Pokud by Apple nezměnil přístup, byly by za chvíli obě strany na tom samém, jako nyní.
Přiznám se, že z toho, co jsem přečetl a pochopil, nemám pocit, že by bylo možné Apple vytknout, že porušuje nějaké dohody či licence. Apple se chová tak, jak mu licence umožňuje a určuje, tedy na základě cizí práce vyvíjí svůj produkt a změny uvolňuje k dalšímu použití. Mám spíš pocit, že vývojářům vadí, že jim Apple dělá tak trochu špatné image, že by mohl být aktivnější v zpětné implementaci změn do KHTML – což ale po něm asi licence nijak nepožaduje, a že by se lepší komunikací dalo lépe pracovat na vývoji, který by prospěl jak KHTML, tak WebCore (což je bezpochyby pravda, stačí pročíst komunikaci ve vývojářském listu, kde se každou chvíli pánové z obou skupin pěkně dublují). Uvidíme, co se z diskuse vyvine, pochybuji velice, že by Apple, který si Safari a WebCore docela hýčká, chtěl přejít na jiný engine (pravděpodobně jedině Gecko z Mozilly, licencovat si Operu by asi nebylo ideální, možná by šlo reanimovat jádro z IE 5 pro Maca…), a také asi nelze očekávat, že by jedna skupina šla té druhé příliš na ruku a naopak.
Dá se předpokládat, že zastánci otevřeného software budou Apple hanět a dožadovat se jeho větší aktivity, zatímco pragmatici konstatují, že dělá přesně to, co mu licence dovolují a nijak je podle všeho neporušuje. Apple je komerční firma a tak využívá to, co může – s tím asi každý, kdo začne vytvářet open-source program musí počítat. Jsem zvědav, jak se situace bude vyvíjet dále, zda Apple podá vstřícnou ruku nebo se pojede v takto vyjetých kolejích.
brrrr…. neměl být příspěvek v blogu zařazen do rubriky “horrror”?
— jakub 13.5.2005 13:29 #
Osobně mě přístup Applu mrzí, považoval jsem ho za firmu spolupracující s OSS vývojáři, a v mých očích si touhle kauzou uškodil (pokud ji nějak rozumně nevyřeší).
— dawyd 13.5.2005 13:48 #
Mám ale spíš dojem, že vývojáři KHTML víc fnukají, než aby pracovali. Apple to mohl dávno už zabalit, udělat prostě a jednoduše fork, říct že na KHTML kašle a dělat si na svém OSS písečku (jako to třeba udělal s Darwinem vs. FreeBSD).
To, že změny ve WebCore nejsou jednoduše přenositelné do KHTML je přece jasné, ne? Vždyt je tam spousta případů, kdy to jinak ani nejde. Jestliže třeba text-shadow používá funkci Quartzu, místo aby jí implementoval sám, tak to rozhodně nelze Apple vyčítat. Prostě je třeba si v KDE vykasat rukávy a začít stíhat…
Možná se zapomíná na to, jak směšné a nekompatibilní bylo KHTML jádro předtím, než do toho vstoupil Apple.
— zzen 13.5.2005 14:52 #
— Pepa 14.5.2005 09:48 #
— FrankRyba 14.5.2005 14:27 #
Jinak události se začínají stávat zajímavějšími: CNET: Open-source divorce for Apple’s Safari?
— Jan Brašna 14.5.2005 16:22 #
Konecne niekto napisal poriadny text a nie PR/media bullshit.
— Juraj. O 14.5.2005 18:32 #
— Jan Brašna 14.5.2005 19:08 #
FrankRyba: Bojovat proti Mozille na ostatních platformách naprosto nemá smysl. Myslím, že většího úspechu dosáhnou, pokud se společně s FireFoxem budou snažit držet standardů co nejvěrněji. Na okraj: $100M investuje do RH pan Dell, Michael, nikoliv firma.
[7] Tohle je vážně dobrý, souhlas!
Jan Brašna: Mělo by to kopat za KHTML vývojáře, ale nedělá to. Přijde mi to dost objektivní.
— zzen 14.5.2005 19:30 #
— pepa 15.5.2005 10:40 #
Dobře navržený kod – jistě. Přehledné formátování – jistě. HTML a CSS kompatibilita – rozhodně ne! V té době bylo Gecko někde úplně jinde.
— zzen 16.5.2005 00:16 #