Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Ontwikkelaars KHTML ontevreden over houding Apple

Het rommelt tussen Apple en de ontwikkelaars van KHTML, de fundering waar de nog steeds populairder wordende browser Safari op gebouwd is. De samenwerking tussen het bedrijf en het open source-team, die een paar jaar geleden nog beloofde om vruchtbaar en positief voor beide te worden, dreigt nu door gebrek aan communicatie uit te lopen op een fiasco. KHTML is een zogenaamde render engine, een component dat platte HTML-tekst vertaalt naar de grafische weergave waar het gros van de internetters zo graag naar kijkt. Een complex en essentieel onderdeel voor een browser dus. In eerste instantie waren de ontwikkelaars blij met de keuze van Apple, omdat zij in ruil voor hun hulp en ondersteuning konden profiteren van de verbeteringen die het bedrijf aanbracht in de code. Nu Apple echter steeds meer overstapt op zijn eigen aftakking, WebCore genaamd, voelen zij zich gebruikt. Het bedrijf zou al langere tijd veel meer verbeteringen aanbrengen in zijn eigen aftakking van de code dan in het originele project, en overweegt volgens een bron van News.com zelfs helemaal te op te houden met de kruisbestuiving van WebCore terug naar KHTML.

Safari logoOmdat de broncode onder de GPL-licentie is uitgebracht kan niemand de KHTML-ontwikkelaars tegenhouden om de verbeteringen van WebCore op eigen houtje over te nemen, maar er zijn verschillende redenen waarom dat makkelijker gezegd dan gedaan is. Ten eerste kost het veel tijd en zou de hulp van Apples ontwikkelaars hierbij dus meer dan welkom zijn. Verder is de architectuur van WebCore aangepast ten opzichte van KHTML om beter aan de specifieke eisen van Safari en Mac OS X te voldoen, waardoor lang niet alle nieuwe code (rechtstreeks) gekopiŽerd kan worden van het ene naar het andere project. KHTML is immers meer gericht op de desktopomgeving KDE en de daarbij horende browser Konqueror. Een laatste obstakel is dat manier waarop Apple bugs oplost en features toevoegt niet door alle open source-ontwikkelaars even hoog wordt gewaardeerd. De commerciŽle instelling van het bedrijf levert nu eenmaal niet altijd de meest elegante code op.

Zack Rusin van het KHTML-project heeft zijn problemen met het gedrag van Apple kenbaar gemaakt in open brief aan het bedrijf. Daarin vraagt hij vooral om betere samenwerking, onder andere door toegang te krijgen tot de bugdatabase, betrokken te worden bij discussies over wijzigingen aan de architectuur en meer inzet voor het originele project. Apple zelf heeft op dit moment nog geen commentaar gegeven, maar uit een bericht van een Safari-ontwikkelaar aan News.com blijkt dat het bedrijf hele andere richtingen op zit te denken. Zo wordt een verse start voor het KHTML-project gesuggereerd op basis van de WebCore-code, en sluit men zelfs de rechtstreekse integratie van WebCore in KDE niet uit. Gezien het kwaad bloed dat Apple in de KHTML-ontwikkelgemeenschap heeft gezaaid lijkt dat echter niet bepaald een waarschijnlijk scenario. De combinatie tussen idealistische en commerciŽle belangen lijkt in dit geval dus niet goed uit te pakken voor de eerste groep. In de woorden van Rusin:

"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches. [...] At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."

Door Wouter Tinus

12-05-2005 • 19:21

46 Linkedin Google+

Bron: News.com

Reacties (46)

Wijzig sortering
Morele argumenten zijn niet erg sterk om dat ze subjectief zijn. Vaak zijn ze ook niet efficient.
Het is naief om te denken dat open source niet misbruikt gaat worden voor commerciele doeleinden. Dat weet je als je je code toevoegt. Als je niet wilt dat je code misbruikt wordt (of als je het in ieder geval moeilijk wilt maken), dan moet je closed source software maken zoals ze dat bij veel commerciele bedrijven doen.

Het is hetzelfde in de wetenschap: je maakt je resultaten openbaar en dan gaat er een bedrijf mee aan de haal om er geld mee te verdienen. De oplossing is natuurlijk simpel: patenten. Maar dat zal wel vloeken in de kerk zijn hier :+
KHTML is gewoon GPL. Het is inderdaad een "library", en niet zozeer een volledig programma. Maar dus niet LGPL. (QT, de widget toolkit van oa KDE is bv ook GPL en niet LGPL, als je een library maakt betekend dat echt niet dat je er direct LGPL voor zou moeten gebruiken)

Apple heeft de KHTML code gepakt, en deze ge"forked" en daar een product van gemaakt genaamd "Webcore". In het begin zorgde ze ervoor dat wijzingen in "Webcore" (wat specifiek voor OSX is) ook terug gegeven of in ieder geval doorgeven werden aan het KHTML project. Daar is men nu mee gekapt.

Men is dus nog wel steeds verplicht alle source van "Webcore" onder de GPL uit te brengen. Dat doet Apple ook. Er is echter een verschil tussen je source online zetten en een werkbaar open source project. Alles wat verder met development van Webcore te maken heeft (bug tracker, test rapporten, source managment, etc), zit achter gesloten deuren bij Apple.

Safari maakt gebruik van Webcore, maar het zijn technisch gezien 2 verschillende programmas. Dus Safari valt niet onder de GPL.

Wat het KHTML-team graag wil is dat Apple ipv van Webcore los ontwikkelen de wijzigingen van Webcore in KHTML integreerd, zodat wijzigingen die Apple in de toekomst maakt direct in KHTML komen, waardoor Apple kan profiteren van de wijzigingen die het KHTML team maakt.

Apple stelt (mogelijk) ook zoiets voor, maar dan dat zei verder gaan waar ze gebleven zijn (webcore dus) en dat KHTML meer toegang tot de development van Webcore krijgt.

Uiteindelijk willen beide partijen wel samenwerken lijkt me, maar beide (met name Apple) willen de ultime controle over het project bij zichzelf hebben.
Apple levert de code gewoon, alleen doet dat in te grote brokken die niet hapklaar genoeg zijn voor de Open Source gemeenschap. Dit is inderdaad niet zo netjes, en ik zie niet in waarom ze het niet anders doen, maar het breekt geen regels. Zolang de veranderingen in de code aangeleverd worden is er naar mijn mening niets aan de hand behalve flink wat werkverschaffing voor de niet-apple ontwikkelaars.
't is heel simpel: wat Apple doet mag. Of het _slim_ is wat ze doen is een heel ander verhaal: Apple's patches worden niet/nauwelijks in KHTML opgenomen en dus zullen de codebases steeds verder uit elkaar gaan lopen. Op zich niks mis mee, maar Apple kan nu op zijn beurt niet meer profiteren van het werk wat in KHTML gebeurd.

Dit gedrag is erg typerend voor bedrijven die OSS code gaan gebruiken. Initieel veel werk overnemen, en op het moment dat ze die code zelf kunnen uitbrengen het project forken zodat ze op eigen kracht een "voorsprong" kunnen behalen. Niets mis mee opzich, MAAR:

Wat ze niet in lijken te zien is dat ze zichzelf met deze houding afgesloten hebben van een hele boel gratis mankracht, van programeerwerk tot Q/A.

Ach ja, ze komen daar over een jaartje ook wel achter. Gebeurd elke keer; niet druk om maken.
Zoals al aangegeven doet Apple niets illegaals. Toegegeven: ik ben er niet blij mee. Ik zou liever zien dat Apple op dit punt meer met de open-source gemeenschap samenwerkt.

Toch heb ik begrepen dat forken op zichzelf niets vreemds is in de open-source wereld. Er wordt van veel open-source software forks gemaakt die lastig te integreren is met de originele software. Dit alles begreep ik uit de thread bij Slashdot over dit onderwerp.

Dit alles neemt niet weg dat Apple op andere punten veel opener is qua broncode. Neem bijv. Bonjour (technologie die kortgeleden nog bekend stond onder de noemer Rendezvous en ook bekend is onder de naam zeroconf). Apple heeft Rendezvous in eerste instantie ontwikkeld en er een open-source project van gemaakt. In de Linux wereld zijn steeds meer applicaties te vinden die gebruik maken van de technologie).

Naast Rendezvous heeft Apple ook van launchd een open-source project gemaakt. Apple wil met launchd verschillende software vervangen, waaronder cron en applicatie launchers. Meer over launchd is te vinden op Slashdot. Launchd is een nette vervanger voor de vele verschillende launchers e.d. die in de Linux wereld te vinden zijn. Het geheel is bijv. te configureren met XML bestanden.

Daarnaast is natuurlijk de "achterkant" van OS X open-source, onder de noemer Darwin.

Een ieder die een erg negatief beeld heeft van dit nieuwsitem moet ook nog even deze pagina lezen (van een khtml ontwikkelaar bij KDE). De KDE ontwikkelaars zijn blijkbaar vooral ontevreden met kritiek uit de open-source wereld. Hun werk wordt vaak gezien als simpele kopiŽn van de broncode, terwijl het vaak allemaal ingewikkelder is.

EDIT: Een ieder die meer wilt weten van lauchd, lees dit artikel op Ars Technica en bekijk de man page bij Apple.

Het Safari weblog is trouwens geschreven door David Hyatt. David Hyatt was 1 van de orginele Mozilla ontwikkelaars en is dus niet onbekend met de open-source wereld. Zie dit nieuwsbericht uit 2002.
Wat voor een afspraken zou je dan moeten maken? "Jullie maken geen gebruik van OS X specifieke function calls want anders ...". Ja, wat anders? De KHTML ontwikkelaars kunnen in deze situatie niets uitrichten. Hun engine valt onder GPL en dus kan iedereen KHTML pakken, in stukjes hakken en er aan veranderen wat ze willen. Ook zonder toestemming van de ontwikkelaars. Het is natuurlijk erg prettig als men _wel_ het fatsoen opbrengt om mee te blijven helpen met de ontwikkeling maar dat is, zoals je nu ziet, niet verplicht. IMO niet bepaald netjes van Apple. Wel soort van begrijpelijk aangezien zij verder moeten en niet altijd kunnen wachten op een aantal vrijwilligers die in hun vrije tijd aan KHTML werken en die vrijwel altijd een nette oplossing willen ipv 'een oplossing'. Ben benieuwd hoe dit verder uit gaat pakken. Overigens is er wel een soort van reactie geweest van de Apple kant:

http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054

Of ja, vooral een melding dat de kritiek ontvangen is en dat er naar geluisterd wordt (iig door Hyatt).
Waarschijnlijk wordt Safari steeds populairder omdat:

a) Steeds meer OS9 gebruikers naar OSX overgaan
b) IE niet meer geleverd wordt met 10.4 en al niet meer standaard in 10.3
c) Het aandeel van MacOS langzaamaan toeneemt.

Camino, Omniweb, Opera waren er al lang voor Safari. Firefox doet het goed op het mac platform maar is duidelijk niet speciaal voor de mac gemaakt: het gevoel mist er nogal bij. Vandaar dat veel mensen FF naast Safari gebruiken, met name voor de extensies.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True