geen cathedral of bazaar, maar een bazedral: html en ontwikkelstijlen

Geen cathedral of bazaar, maar een

bazedral

HTML en ontwikkelstijlen

Iris Beerepoot

Bachelorscriptie

Jan Simons

Universiteit van Amsterdam

December 2015

Abstract

HyperText Markup Language (HTML) is een opmaaktaal die structuur aanbrengt aan

webpagina’s. Deze internetstandaard bepaalt daarmee grotendeels de vorm van het Web.

Twee organisaties werken tegelijkertijd aan de ontwikkeling van de standaard: het World

Wide Web Consortium (W3C) en de Web Hypertext Application Technology Working

Group (WHATWG). Daarnaast spelen internetbrowsers een grote rol in de ontwikkeling

van HTML. Dit onderzoek vergelijkt het W3C en de WHATWG met het cathedral - en

bazaar -model van ontwikkelen zoals beschreven door Eric Raymond. De organisaties bev-

atten elementen van beide modellen, resulterend in een bazedral : het model waarin HTML

wordt ontwikkeld.

HTML en ontwikkelstijlen i

Inhoud

1 Introductie 1

2 Overzicht van de literatuur 3

2.1 Vorm of content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Internet Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Internetstandaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Ontwikkelstijlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Welke instanties hebben invloed op de standaard? 7

3.1 De geboorte van HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 XML als de toekomst van het Web . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Kritiek op de standaard en het ontstaan van een nieuwe organisatie . . . . . 8

3.4 Een verkeerde keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Internetbrowsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 De WHATWG 11

4.1 Het ontwikkelproces van de WHATWG . . . . . . . . . . . . . . . . . . . . 12

4.2 Een living standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 De WHATWG als bazaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 De WHATWG als cathedral . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Het W3C 21

5.1 Organisatiestructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 Het W3C als bazaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Het W3C als cathedral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 De browsers 28

6.1 Van PC naar mobiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Hickson en DRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

HTML en ontwikkelstijlen ii

7 Een bazedral 34

7.1 Perspectieven op de samenwerking . . . . . . . . . . . . . . . . . . . . . . . 36

7.2 HTML-ontwikkeling: bazaar of cathedral? . . . . . . . . . . . . . . . . . . . 37

8 Conclusie 40

9 Emotion Markup Language 44

10 Schermresoluties 2010 en 2015 50

11 Marktaandeel besturingssystemen voor mobiele apparaten 52

HTML en ontwikkelstijlen 1

Hoofdstuk 1

Introductie

De eerste gebruikers van het Web voegden van alles toe: 3D-afbeeldingen, knipperende

tekst, bewegende paragrafen, je kunt het zo gek niet bedenken (Ford z.pag.). Internet-

browsers als Mosaic, Netscape en Internet Explorer werden ontwikkeld en hadden allemaal

hun eigen regels. Wat volgde was balkanisatie van het Web: een webpagina geschreven

voor Internet Explorer kon niet worden weergegeven in Mosaic, en dus ontstonden aparte

gebruikersgroepen die alleen onderling konden communiceren. Er was eerder een verzamel-

ing Webben dan een enkel Web. Het was afhankelijk van de browser of een webpagina

goed kon worden weergegeven. Behoefte was er aan standaarden die compatibiliteit tussen

verschillende browsers konden garanderen, zodat webpagina’s browseronafhankelijk wer-

den.

Hoe ontwikkel je zulke standaarden? Verschillende ontwikkelstijlen zijn mogelijk. Je

kunt een aantal deskundigen aanstellen en hen een standaard laten ontwikkelen, maar

je kunt de verantwoordelijkheid ook bij de gebruikers, de webontwikkelaars, neerleggen.

Zij zijn tenslotte degenen die de standaard moeten gaan gebruiken. Daarnaast is het

ook belangrijk dat de browsers bereid zijn de uiteindelijke standaard te implementeren.

Als Microsoft en Google namelijk niet dezelfde standaard aan willen nemen, zijn webpa-

gina’s geschreven voor Microsoft’s Internet Explorer mogelijk incompatibel met Google’s

Chrome. Het kan dus ook een goede strategie zijn om de browsermakers een grote rol te

geven in het ontwikkelproces.

HyperText Markup Language (HTML) is een standaard die structuur aanbrengt aan

webpagina’s en is een van de meest fundamentele technologieen van het Web. Webontwikke-

laars geven met behulp van HTML aan welke onderdelen van de webpagina, zoals de titel

en paragrafen, waar staan. Zo weten de browsers hoe ze de pagina weer moeten geven

aan bezoekers van de pagina. Bijzonder aan HTML is dat verschillende ontwikkelstijlen


een rol spelen. Twee organisaties, de Web Hypertext Application Technology Working

Group (WHATWG) en het World Wide Web Consortium (W3C) werken los van elkaar

aan de ontwikkeling van HTML en brengen eens in de zoveel tijd een nieuwe versie uit.

De manieren van ontwikkelen van de twee zijn fundamenteel verschillend en dat geldt

ook voor hun ideeen over hoe kwaliteit van de standaard het beste kan worden gewaar-

borgd. Ze houden er ontwikkelstijlen op na die sterk met elkaar botsen en een steeds groter

wordende kloof veroorzaken (Shankland z.pag.). Daarnaast hebben de browsermakers ook

ideeen over hoe het verder moet met het Web. Om meer duidelijkheid te verschaffen

over het debat rondom de ontwikkeling van HTML, stelt dit onderzoek de vraag: welke

ontwikkelstijlen spelen een rol bij HTML en hoe verhouden die zich tot elkaar? Het zal

niet alleen proberen in kaart te brengen welke partijen inspraak hebben in de ontwikkeling

van de standaard en tot welke ontwikkelstijlen zij behoren, maar ook in hoeverre deze

verschillende stijlen elkaar complementeren of juist tegenwerken tijdens de ontwikkeling

van de toekomst van het Web.


Hoofdstuk 2

Overzicht van de literatuur

2.1 Vorm of content

We denken dat content belangrijker is dan vorm, maar misschien is het tegendeel wel

waar. Dat zeggen de auteurs Lovink en Rossiter (2011). Een film duurt meestal ongeveer

90 minuten, maar waar het echt om gaat is de inhoud van die film, toch? Volgens Lovink

en Rossiter zijn de vormeigenschappen echter van grote invloed. Omdat de film niet

korter dan een uur hoort te zijn, maar ook niet langer dan twee uur, zijn er keuzes

gemaakt in het toevoegen en weglaten van content. De vorm bepaalt voor een groot

gedeelte de content. Daarom zijn het de onderliggende structuren, de vormeigenschappen,

waar we aandacht aan moeten gaan besteden (427). Er schuilt namelijk een enorme

hoeveelheid macht in het bepalen van standaarden: ”Whoever sets the standard has the

power” (ibid.). Lovink en Rossiter vragen zich daarom af waarom er zo weinig mensen

zijn die zich interesseren in de technische structuren om ons heen, of het nu gaat om

bouwvoorschriften of internetprotocollen. Het idee dat ”een gesloten groep technocraten”

onze blik op de wereld bepaalt, moet volgens hen leiden tot bezorgdheid. Voorbeelden

van vragen die we onszelf zouden moeten stellen zijn: hoeveel invloed hebben giganten

als Google, Apple en Facebook op onze visuele cultuur? (428). Hoeveel invloed hebben

browsers nu werkelijk op datgene wat wij zien op het internet?

2.2 Internet Governance

Dit zijn vragen waar het onderzoeksgebied Internet Governance zich onder andere mee

bezig houdt. Volgens Laura DeNardis refereert Internet Governance ”aan beleids- en

technische coordinatievraagstukken gerelateerd aan de uitwisseling van informatie over het

internet” (1). Het gaat hier dus nadrukkelijk niet om content, maar om vorm. Internet


Governance-onderzoekers richten zich op het ontwerp, de manipulatie en coordinatie van

de architectuur van het internet. Lawrence Lessig omschrijft het onderzoeksgebied als ”een

mix van regulatie van code en de regulatie van de instanties die deze code reguleren” (1408).

We moeten volgens Lessig nadenken over hoe bestuurders besturen, wie de wetgevers zijn

en hoe zij de wetten schrijven (1409).

2.3 Internetstandaarden

Een van de onderdelen van Internet Governance is de analyse van het design van inter-

netstandaarden (DeNardis 6). Internetstandaarden, ook wel internetprotocollen genoemd,

zorgen ervoor dat verschillende informatietechnologieen met elkaar kunnen communiceren.

Het MP3-formaat bijvoorbeeld is zo’n standaard. Het zorgt ervoor dat je een MP3-bestand

af kunt spelen op zowel een computer als een MP3-speler en sommige televisies. Elk be-

sturingssysteem, of het nu Microsoft’s Windows of Apple’s OS X of iets anders is, kan een

bestand met dit formaat afspelen. Vraagstukken over het design van internetstandaarden

hebben vaak betrekking op de openheid van de standaard (7): wie mogen er deelnemen

aan het ontwikkelproces? Wie hebben toegang tot de informatie over de ontwikkeling van

de standaard? Wordt de standaard openlijk gepubliceerd? Hoe vaak? Kan de standaard

gratis worden geraadpleegd?

2.4 Ontwikkelstijlen

De mate van openheid van informatie en deelname is een belangrijke keuze die instanties

die te maken hebben met standaarden moeten maken. Eric Raymond beschrijft in zijn

revolutionaire artikel ’The Cathedral and the Bazaar’ uit 1999 twee fundamenteel verschil-

lende ontwikkelstijlen. Aan de ene kant is er het cathedral -model,

”carefully crafted by individual wizards or small bands of mages working in

splendid isolation, with no beta to be released before its time” (24)

Kenmerkend aan dit model is een strakke organisatie en centrale planning. Het grootste

gedeelte van de commerciele wereld maakt gebruik van dit model. Aan de andere kant is

er het bazaar -model,

”a great babbling bazaar of differing agendas and approaches (...) out of which

a coherent and stable system could seemingly emerge only by a succession of

miracles” (ibid.).


Figuur 2.1: Een kathedraal, gekenmerkt door een strakke organisatie en centrale planning

(bron: http://www.deviantart.com/art/Saigon-Notre-Dame-Basilica-319809424).

Kenmerkend aan dit model is een decentrale organisatie die in een vroeg stadium en

frequent nieuwe versies uitbrengt. Het belangrijkste verschil tussen de twee modellen is

de mate van openheid van informatie en deelname. Het bazaar -model is ook wel bekend

onder de naam open-source1, een directe verwijzing naar de openheid van de ontwikkelstijl.

Het bekendste voorbeeld van een bazaar is het besturingssysteem Linux.

HTML is een standaard die structuur aanbrengt aan webpagina’s en is daarmee belan-

grijk voor de vorm van het Web. In lijn met het onderzoeksgebied Internet Governance zal

dit onderzoek zich richten op het design en de ontwikkeling van HTML en de door Lovink

en Rossiter aangemoedigde vraag stellen: welke instanties spelen een rol bij de ontwikkel-

ing hiervan? Daarnaast zal dit onderzoek de mate van openheid van die instanties aan

het licht proberen te brengen en daarmee bepalen tot welke ontwikkelstijl zij behoren: de

cathedral of de bazaar. Tot slot zal duidelijk moeten worden hoe die verschillende stijlen

zich tot elkaar verhouden bij het ontwikkelen van HTML: of ze daadwerkelijk zo lijnrecht

tegenover elkaar staan als een cathedral en bazaar.

1Open-source software is software waarbij de broncode vrij toegankelijk is. Iedereen kan het bekijken

en ermee doen wat hij of zij wil.


Figuur 2.2: Een bazaar, gekenmerkt door een decentrale organisatie en frequente

activiteit (bron: https://busradraws.wordpress.com/2014/07/27/drawing-a-bazaar-khan-

al-khalili/).


Hoofdstuk 3

Welke instanties hebben invloed

op de standaard?

3.1 De geboorte van HTML

In 1993 werd de eerste standaard voor de structuur van webpagina’s gedoopt tot HyperText

Markup Language, oftewel HTML (Ford z.pag.). Met behulp van zogenaamde HTML-tags

kon een webontwikkelaar bijvoorbeeld aangeven wat de titel van een webpagina was:

<title>HTML-pagina</title>

Op deze manier wist een internetbrowser welke titel er bovenaan het scherm moest

komen te staan. HTML is, zoals de naam al zegt, een ’markup language’, oftewel een

opmaaktaal. Het is geen programmeertaal. Interactiviteit wordt doorgaans geregeld door

middel van andere talen, zoals Javascript.

Het World Wide Web Consortium (W3C) nam de verantwoordelijkheid voor het ontwikkelen

van de HTML-standaard op zich. In november 1995, januari 1997 en december 1997 bracht

het W3C respectievelijk HTML2, HTML3 en HTML4 uit (W3C Technical Reports).

3.2 XML als de toekomst van het Web

In 1998 besloot het W3C HTML niet verder te ontwikkelen (Lawson en Sharp xi). Volgens

hen lag de toekomst van het web in een andere standaard, namelijk Extensible Markup

Language (XML). HTML4 zou de laatste versie zijn van het originele HTML. Het W3C

bracht daarna XHTML uit, bestaande uit elementen van HTML en XML-syntax. Dit

was nog niet zo’n grote verandering. Vervolgens ging de organisatie echter XHTML


2.0 ontwikkelen, wat wel een enorme verandering was ten opzichte van de voorgaande

standaard. Het W3C wilde een toegankelijker Web creeren, een waar blinden en mind-

ervaliden ook mee konden werken (Ford z.pag.). Webpagina’s zouden met behulp van

de nieuwe standaard de content beter moeten kunnen beschrijven. Om dit te kunnen

bereiken kwam het W3C met nieuwe technologieen en sub-standaarden. Een voorbeeld

hiervan was W3C’s Emotion Markup Language. Deze opmaaktaal maakte het mogelijk

om aan elk element op de webpagina een emotie toe te kennen. Op de volgende manier

zou je bijvoorbeeld een element een plezier-waarde van 0.5 kunnen geven:

<emotion dimension-set="http://www.w3.org/TR/emotion-voc/xml">

<dimension name="pleasure" value="0.5"/>

</emotion>

Een webontwikkelaar kon kiezen uit een waslijst aan emoties, verdeeld over 12 cat-

egorieen1. De belangrijkste categorie, ’big6’, bevatte de emoties anger, disgust, fear, hap-

pinness, sadness en surprise. Als deze standaard op grote schaal geımplementeerd zou

worden, had je een browser kunnen openen en er bijvoorbeeld voor kunnen kiezen louter

blije gedachten te lezen.

3.3 Kritiek op de standaard en het ontstaan van een nieuwe

organisatie

Het mocht niet zo zijn. Het idee om het hele Web te voorzien van emoties was leuk, maar

er kleefden ook nadelen aan de nieuwe standaard die het W3C aan het ontwikkelen was.

Met name het feit dat XHTML niet backwards-compatible was, oftewel compatibel met

eerdere versies, zorgde voor veel kritiek. Webpagina’s geschreven in HTML werkten niet

meer in de nieuwe standaard (Lawson en Sharp xi). Een groep Opera-medewerkers was

niet onder de indruk van de nieuwe standaard gebaseerd op XML. Ian ”Hixie” Hickson,

Opera-medewerker op dat moment, vertelt:

”In 2004, the W3C had a workshop, the ’The W3C Workshop on Web Applica-

tions and Compound Documents’, where we (the browser vendors) argued that

it was imperative that HTML be extended in a backwards-compatible way. It

was a turning point in the W3C’s history-you could tell because at one point

1Zie Appendix A voor het XML-bestand met alle mogelijke emoties.


RedHat, Sun, and Microsoft, arch-rivals all, actually agreed on something, and

that never happens.

The outcome of that workshop was that the W3C concluded that HTML was

still dead, as had been decided in a workshop in 1998, and that if we wanted

to do something like HTML 5, we should go elsewhere. So we announced a

mailing list, and did it there.” (Lawson z.pag.)

Zij begonnen te werken aan een nieuwe specificatie: een document waarin de regels van

de standaard zijn gespecificeerd. Deze versie, HTML5, moest een verbetering worden van

HTML4, maar wel backwards-compatible zijn. Een groepje Mozilla-medewerkers sloot zich

ook aan (Lawson en Sharp xi). De groep noemde zichzelf de Web Hypertext Application

Technology Working Group (WHATWG) en werd geleid door Ian Hickson. Apple steunde

de groep en hield de voortgang nauwlettend in de gaten. Hickson verhuisde van Opera

naar Google en mocht zich bij Google volledig richten op de ontwikkeling van de standaard.

3.4 Een verkeerde keuze

In 2006 besloot het W3C dat de overstap naar XML-syntax misschien niet de juiste was

geweest (xii). De organisatie riep een gloednieuwe HTML-werkgroep in het leven om naast

XHTML, ook weer aan HTML te gaan werken. Deze groep koos ervoor het werk van de

WHATWG te gebruiken als basis voor een nieuwe HTML-standaard. Een vreemde situatie

ontstond: twee groepen werkten simultaan aan de ontwikkeling van HTML. De WHATWG

vervolgden hun werk aan HTML onder leiding van Ian Hickson, terwijl het W3C nu ook

weer aan de HTML-standaard werkte, met als belangrijkste deelnemers Sam Ruby van

IBM, Chris Wilson van Microsoft, Paul Cotton van Microsoft en Maciej Stachowiak van

Apple.

In 2009 stopte het W3C definitief met het ontwikkelen van de XHTML-standaard, en

zette al haar middelen in op de nieuwe HTML-standaard (xiii). XML had de strijd met

HTML verloren. Het initiele design van XML was misschien beter dan dat van HTML,

maar het gebrek aan backwards-compatibility bleek een onoverkomelijk struikelblok.

3.5 Internetbrowsers

Opvallend is dat de browsermakers een grote rol spelen in de ontwikkeling van HTML. De

personen die de dienst uitmaken bij zowel de WHATWG als W3C’s HTML-werkgroep zijn


medewerkers van browsermakers. Het zijn dus niet in de eerste plaats de webontwikkelaars

die de regels bepalen. Dit wordt bevestigd door Ian Hickson in een interview:

”The reality is that the browser vendors have the ultimate veto on everything

in the spec, since if they don’t implement it, the spec is nothing but a work of

fiction.” (Lawson z.pag.)

De browsers hebben dus op twee manieren invloed op de standaard. Neem bijvoorbeeld

Google Chrome. Google is in de eerste plaats betrokken bij de WHATWG via Ian Hickson.

Als Google bij de publicatie van de nieuwe HTML-specificatie alsnog niet tevreden is, kan

zij nog besluiten de specificatie niet te implementeren. Als Google het niet implementeert,

wordt de nieuwe standaard simpelweg niet in gebruik genomen door haar gebruikers.

Duidelijk is nu dat drie instanties belangrijk zijn bij het standaardisatieproces van

HTML: de WHATWG, het W3C en de browsers. Dit zijn de bestuurders, de wetgevers

van het Web. Het zijn de medewerkers van de browsermakers die grotendeels bepalen

hoe webontwikkelaars een pagina structureel op moeten bouwen. Maar bestaan deze

organisaties ook daadwerkelijk uit ”gesloten groepen technocraten” die onze blik op de

wereld bepalen, zoals Lovink en Rossiter beschreven? Gesloten als een cathedral, met een

centrale planning en strakke organisatie, of meer als een bazaar, decentraal georganiseerd

en open voor deelname voor wie dan ook?


Hoofdstuk 4

De WHATWG

De WHATWG omschrijft zichzelf als ”a growing community of people interested in evolving

the Web” (WHATWG FAQ). Iedereen mag deelnemen en er zijn geen lidmaatschapsgelden.

Ontwikkelplatform GitHub en een mailinglijst zijn de belangrijkste middelen van commu-

nicatie tussen de leden van de groep. Het ontwikkelproces van de organisatie werkt als

volgt. De WHATWG werkt aan een klein aantal standaarden, waarvan HTML de belan-

grijkste is. Elke standaard heeft een of enkele zogenaamde Editors. De Editor van HTML

is Ian Hickson. Hickson is verantwoordelijk voor de gehele HTML-specificatie. Voorstellen

voor aanpassingen en de discussies daaromheen komen bij hem terecht. Hij besluit, met

behulp van de genoemde voor- en tegenargumenten, of het voorstel de moeite waard is om

aandacht aan te besteden. Volgens de website van de WHATWG is dit geen op consensus

gebaseerd proces (ibid.). Het doel van de discussies binnen de WHATWG is niet om

iedereen te overtuigen. Het idee is om iedereen met argumenten te laten komen, zodat de

Editor een weloverwogen beslissing kan nemen. Er is geen garantie dat iedereen tevreden

wordt gesteld en er wordt niet gestemd. Het is geen democratie: de Editor heeft het laat-

ste woord. Een kleine toezichtcommissie kan besluiten de Editor te vervangen als deze in

hun ogen verkeerde keuzes maakt. Dit is echter nog nooit gebeurd, ook niet bij de Editors

van de andere standaarden. Het is niet volledig duidelijk uit welke personen de toezicht-

commissie op dit moment bestaat. Wel is duidelijk dat de oorspronkelijke commissie, zoals

die in 2004 is ontstaan, uit de volgende leden bestond (WHATWG Charter):

• Anne van Kesteren

• Brendan Eich

• David Baron

• David Hyatt


• Dean Edwards

• Hkon Wium Lie

• Ian Hickson

• Johnny Stenback

• Maciej Stachowiak

Interessant is hier dat Ian Hickson, destijds in ieder geval, zowel de Editor van de

HTML-standaard was als een van de negen leden van de groep die moest besluiten of de

Editor zijn werk wel goed deed.

4.1 Het ontwikkelproces van de WHATWG

Stel dat een webontwikkelaar een voorstel zou willen doen voor een verandering aan de

huidige specificatie. Volgens de website van de WHATWG moet hij of zij daarbij tien

stappen volgen (WHATWG FAQ):

1. Vergeet de oplossing, die komt later wel. Concentreer je op het probleem.

2. Beschrijf het probleem. Wat zijn de use cases/praktijkvoorbeelden? Een prak-

tijkvoorbeeld is een voorbeeld van een situatie waarin een gebruiker iets wil doen.

Beschrijf de vereisten voor deze praktijkvoorbeelden.

3. Betrek er meer mensen bij. Vraag andere webontwikkelaars om hun opmerkingen en

ideeen. Wijzig de praktijkvoorbeelden zo nodig en vul aan. Hoe meer webontwikke-

laars bijdragen, des te beter worden de praktijkvoorbeelden.

4. Als je bovenstaande stappen goed hebt doorlopen en de andere leden overtuigd hebt

dat het hier om een probleem gaat dat echt opgelost moet worden, heb je je taak

volbracht. Anderen kunnen het nu overnemen. Bedenk wel dat, hoe goed je voorstel

ook is, het kan zijn dat degene die de taak krijgt met een oplossing te komen, er niet

zo gepassioneerd over is als jij. Dit kan er uiteindelijk toe leiden dat de oplossing

geen succes is. Het kan daarom goed zijn betrokken te blijven bij het proces, door

de volgende stappen ook te doorlopen:

5. Onderzoek bestaande oplossingen, en bedenk nieuwe oplossingen. Hou deze zo simpel

mogelijk en richt je voornamelijk op de belangrijke praktijkvoorbeelden. Stuur deze


lijst met oplossingen, oud en nieuw, naar de WHATWG. Vraag browsermakers om

feedback. Misschien passen sommige van de oplossingen niet in de architectuur van

de browser. Als de browsermakers er niets in zien kun je het beter achterwege laten.

6. Bepaal in hoeverre elk van de oplossingen een voordeel oplevert met betrekking tot

de praktijkvoorbeelden. Hier zou duidelijk moeten worden wat de meest geschikte

oplossing is.

7. Vraag de Editor de oplossing te accepteren en te implementeren in de specificatie.

8. Vraag browsermakers de nieuw gespecificeerde oplossing te implementeren in de

browsers, al gaat het maar om een experimentele implementatie. Dit kan uitwijzen

of er een goede beslissing is gemaakt of dat een andere oplossing toch meer geschikt

is.

9. Pak een van de praktijkvoorbeelden als experiment om te testen of de oplossing juist

geımplementeerd is. Je loopt hier wellicht tegen fouten in de browserimplementatie

of in de specificatie aan.

10. Neem deel aan de designdiscussies die volgen. Nieuwe praktijkvoorbeelden kunnen

zijn ontstaan en in het geval van goede voorstellen dienen deze stappen weer door-

lopen worden om de specificatie actueel te houden.

Beginner op het gebied van standaardontwikkeling, ’Newbie’ Mike Gavrilov deed afge-

lopen maand via de mailinglijst een voorstel voor een verandering in de HTML-specificatie

(WHATWG October Archive). Hij begint als volgt:

Hi to all!

Excuse me I am newbie here.

I want make a proposal for displaying thousand separator in numeric

input fields.

Most users would be more satisfied if in any <input type="number"

value="1234567890.0123456789" /> would seen as 1 234 567 890.012 345

678 9

of course thousand separator must depend of local settings.

1234567890.0123456789 = 1,234,567,890.012,345,678,9

Anyway thousand separator will not be sended to the server when the

form is submitted and not be accessed from Javascript for example:


<input id="input1" type="number" value="1234567890.0123456789" />

console.log(document.getElementById(’input1’).value);

//return: 1234567890.0123456789

Ie thousand separator affects only the display of numbers for

improving readability.

--

Best Regards,

Mike Gavrilov.

Domenic Denicola ziet wel wat in het voorstel van Gavrilov, maar is niet overtuigd dat

browsermakers positief tegenover implementatie zullen staan:

In general, this type of thing is hard to get support for these days.

Implementers are more interested in getting stuff like web components

in place so that authors can produce better controls, without waiting

for them to be debated, standardized, and implemented everywhere. I

think it’d be a worthwhile improvement, especially since custom

elements are unable to participate in the form control ecosystem

(constraint validation, form submission, etc.). But we’re going to

need implementer interest before anything gets done here.

Soooo ... any implementers interested in solving this problem?

Een aantal andere leden mengt zich in de discussie en argumenten gaan over en weer.

Gavrilov stelt nog voor om beter te definieren wat er nu precies bedoelt wordt met ”number

type”, maar een ander lid gelooft daar helemaal niet in:

Good luck with that. Everyone seems to feel it’s a different thing.

Dit moedigt Gavrilov niet aan om zijn enthousiasme door te zetten. De discussie is

erg informeel en meningen worden niet onder stoelen of banken gestoken. Gavrilov geeft

uiteindelijk toe geen nieuwe argumenten meer te kunnen bedenken en vraagt zich af of dit

betekent dat zijn voorstel verworpen wordt of dat iemand hem verder kan helpen. Hickson

grijpt in en sluit de discussie:


You may find more details about how things work here in our

FAQ: https://whatwg.org/faq

HTH.

--

Ian Hickson

http://ln.hixie.ch/

Things that are impossible just take longer.

Hickson geeft in een interview aan moeite te hebben met dit soort situaties:

”There are a few things that are hard. One is saying ”no” to people who have

clearly spent the time to come up with a good idea. The sad truth is that I

reject almost everything that I and anyone else thinks of, because if I didn’t,

the spec would be a thousand times more bloated than it is now. We get

proposals for all kinds of things, and we have to have a very high bar for what

goes in. There’s also the danger that if we add too many things to the spec

too quickly, the browser vendors will each implement their own bit and it’ll be

a big mess that won’t help Web authors.

So I have to make judgements about what is worth adding and what isn’t,

and that’s hard. I’ve upset a lot of people by rejecting their ideas,” (Lawson

z.pag.)

4.2 Een living standard

Het proces van ontwikkeling waar de WHATWG gebruik van maakt, leidt tot een living

standard : een standaard die continu bijgewerkt wordt aan de hand van feedback gegeven

door webontwikkelaars, browsermakers en andere geınteresseerden:

”the days where the specifications are brought down from the mountain and

remain forever locked, even if it turns out that all the browsers do something

else, or even if it turns out that the specification left some detail out and the

browsers all disagree on how to implement it, are gone” (WHATWG FAQ)

Dit betekent echter niet dat nieuwe functies zomaar worden toegevoegd. Zoals ook

al duidelijk werd uit het tien-stappenproces en uit de discussie met Gavrilov, vindt het


veranderen van de specificatie alleen plaats na zorgvuldige afweging van alle voor- en

nadelen. De WHATWG streeft er bovendien naar de specificatie te allen tijde backwards-

compatible te houden, tenzij dit ten koste gaat van veiligheid. Het Web is continu in

ontwikkeling, en dus is de specificatie ook nooit compleet, vinden zij. Dit laatste heeft wel

effect op de stabiliteit van de specificatie. Volgens de WHATWG is de specificatie ”min of

meer stabiel”. Volledig stabiliteit wordt niet gegarandeerd. De WHATWG kiest bewust

voor een living standard, omdat er aan finished snapshots (waar het W3C gebruik van zou

maken) volgens hen een groot nadeel kleeft: webontwikkelaars volgen dan als het ware een

specificatie waarvan algemeen bekend is dat er fouten in zitten. Bij de specificaties van

het WHATWG is dit niet het geval. Als bekend is dat er een fout in de specificatie zit,

wordt deze zo snel mogelijk verholpen en kan de ontwikkelaar met de nieuwste versie aan

de slag.

4.3 De WHATWG als bazaar

Het gebruik van een living standard is een belangrijk kenmerk van de ontwikkelstijl van

de WHATWG. De link met het bazaar -ontwikkelmodel van Linux is daarmee snel gelegd.

Volgens Eric Raymond kan Linux’s ontwikkelstijl worden omschreven als: ”release early

and often, delegate everything you van, be open to the point of promiscuity” (24). Hij

onderscheidt een aantal kenmerken van het bazaar -model dat ook van toepassing is op het

ontwikkelproces van de WHATWG:

1. Goede software ontstaat wanneer een ontwikkelaar behoefte heeft aan iets (25).

Vele uren besteden aan iets dat je niet interessant vindt, werkt niet. Het werkt veel

beter als iemand ergens tegenaan loopt en gemotiveerd is om er een oplossing voor

te vinden. Wel is het zaak om deze ontwikkelaars niet te demotiveren, zoals mogelijk

het geval is bij Gavrilov. Het is belangrijk dat ze steeds met nieuwe ideeen komen,

ook als eerdere voorstellen van hen zijn verworpen. Hickson: ”some of the most

productive members of the community now are people who’ve had many of their

ideas rejected, but they stuck around long enough to see a few of their ideas make

it in” (Lawson z.pag.).

2. Goede ontwikkelaars weten wat ze moeten schrijven, uitstekende ontwikkelaars weten

wat ze moeten herschrijven (Raymond 25).

Een eigenschap van een uitstekende ontwikkelaars is luiheid. Zij weten dat het gaat

om resultaat, niet om moeite. Het is vaak beter om te werken vanuit een bestaande


oplossing, goed of slecht, dan vanaf nul te beginnen. Linus Torvalds, de belangrijkste

man achter Linux, is ook niet vanaf nul begonnen. Hij begon met het hergebruiken

van code van een bestaand besturingssysteem. Uiteindelijk is er niets overgebleven

van die code, maar het voorzag hem wel van een basis. De WHATWG heeft ook

niet een volledig nieuwe standaard ontwikkeld. De groep gebruikte de bestaande

standaard van het W3C en is die verder gaan ontwikkelen.

3. Wees bereid om onderdelen weg te gooien (26).

De eerste keer dat er een oplossing wordt gezocht, is het vaak nog niet duidelijk wat

het probleem precies is. De tweede keer wordt dit al veel duidelijker. Wees daarom

bereid om opnieuw te beginnen. Een van de tien stappen van het ontwikkelproces van

de WHATWG is het vragen om feedback van browsermakers. Als de browsermakers

de oplossing niet willen implementeren, heb je er niets aan. De WHATWG adviseert:

”Strike those solutions and don’t grieve about the loss” (WHATWG FAQ).

4. Als het project je interesse niet meer wekt, draag het dan over (Raymond 27).

Volgens Raymond is het belangrijk dat de leider van een project bij zichzelf nagaat of

hij nog wel genoeg motivatie heeft. Bij de WHATWG is het zo dat taken gedelegeerd

worden aan de hand van interesses en kwaliteiten. Het is niet zo dat Hickson

de volledige specificatie in zijn eentje schrijft. Hij bepaalt of een voorstel wordt

goedgekeurd en vervolgens wordt bepaald welke ontwikkelaars ermee aan de slag

gaan. Dit zou volgens Raymond voor goede kwaliteit moeten zorgen.

5. Behandel gebruikers als mede-ontwikkelaars voor een snelle en kwalitatieve ontwikkel-

ing (ibid.).

Torvalds’ ontwikkelstijl was revolutionair en dat kwam met name doordat hij zijn

gebruikers liet helpen met het ontwikkelen en het opsporen van fouten in het systeem,

ook wel bugs genoemd. De WHATWG doet dit ook. De gebruikers van de standaard,

de webontwikkelaars, helpen de WHATWG met het aanpassen van de standaard en

het vinden en oplossen van bugs.

6. ”Release early, release often” (28).

Frequent nieuwe versies uitbrengen is een integrale eigenschap van zowel Torvalds’

ontwikkelstijl, als die van de WHATWG met haar living standard. Voor de intro-

ductie van Linux geloofde men dat vroege versies vrijwel altijd vol met bugs zitten.

Je wilt niet dat je gebruikers versies gebruiken waar veel fouten in zitten, dus breng


je pas een versie uit wanneer die fouten eruit zijn. Torvalds bewees dat het frequent

uitbrengen voordelig kan zijn: gebruikers wijzen je op bugs en dus hoef je zelf minder

tijd te besteden aan het opsporen ervan.

7. ”Given enough eyeballs, all bugs are shallow” (29).

Hoe meer gebruikers/mede-ontwikkelaars je hebt, des te gemakkelijker is het om

problemen op te lossen. Meer gebruikers brengen meer kennis met zich mee. Ook

kan het bijvoorbeeld zijn dat een gebruiker een bug tegenkomt, maar niet weet hoe

deze moet worden opgelost. Iemand anders heeft die kennis wel, en dus is het juist

die combinatie die nodig is. Daar komt bij dat een grote groep ontwikkelaars er ook

voor zorgt dat het proces snel verloopt. De meeste discussies op de mailinglijst van

de WHATWG worden binnen twee a drie dagen opgelost. Zo hoef je niet lang te

wachten op feedback, want er zijn altijd wel een paar leden die reageren.

4.4 De WHATWG als cathedral

Toch voldoet de WHATWG niet volledig aan het beeld dat Raymond schetst van een

bazaar. In zijn artikel zegt hij dat fouten in het bazaar -model zo snel worden opgelost

omdat er ”a thousand eager co-developers” zijn die de standaard afspeuren naar fouten

(29). Een bezoek aan de mailinglijst van de WHATWG wijst uit dat er tussen 1 septem-

ber en 4 november 2015 maar 36 leden deel hebben genomen aan een discussie via de

mailinglijst. Figuur 4.1 laat zien dat er een klein aantal leden is dat frequent deelneemt aan

de mailinglijstdiscussies. Zoals verwacht springt Ian Hickson eruit, maar ook bijvoorbeeld

Anne van Kesteren (werkzaam bij Mozilla), Boris Zbarsky (Mozilla) en Philip Jagenstedt

(Opera)1. Het lijkt erop dat er twee soorten leden actief zijn op de mailinglijstdiscussies:

een klein groepje zeer actieve bijdragers, en een grotere groep leden die een enkele keer

van zich laat spreken. De eerste groep, die voornamelijk uit browsermedewerkers lijkt te

bestaan, heeft waarschijnlijk de meeste invloed op de standaard. Figuur 4.2 geeft weer

welk organogram de WHATWG lijkt te hanteren in de praktijk. Geen decentraal geor-

ganiseerde bazaar zoals Raymond die beschreef, maar een hierarchische organisatie met

Hickson en zijn veto-recht bovenaan.

Het andere veelgebruikte ontwikkelmedium van de WHATWG, het platform Github,

trekt ook geen grote groep co-ontwikkelaars. Slechts 25 ontwikkelaars hebben over de jaren

heen bijgedragen aan de HTML-standaard via GitHub (WHATWG Contributors HTML).

1Informatie gevonden op www.LinkedIn.com


Figuur 4.1: Visualisatie van de WHATWG-leden die tussen 1 september en 4 november

hebben bijgedragen aan een discussie via de WHATWG-mailinglijst. De grootte van de

naam geeft de frequentie aan van deelname van die persoon.

Figuur 4.2: Zo zou het organogram van de WHATWG er ongeveer uit moeten zien, op

basis van de afgelopen periode. Ian Hickson staat aan het hoofd van de hierarchie, maar

dient wel verantwoording af te leggen aan de toezichtcommissie. Onder Hickson bevindt

zich een aantal actieve leden. Daaronder komen de minder actieve leden.


Een aantal van dezelfde namen komt hier terug: Ian Hickson, Anne van Kesteren en Philip

Jagenstedt. Geen duizend enthousiaste mede-ontwikkelaars dus bij de WHATWG, maar

hooguit enkele tientallen. Hierdoor is de rol van Hickson ook anders dan die van Torvalds.

Linux is zo’n complex systeem met zoveel bijdragers dat Torvalds een fulltime baan heeft

als opzichter: zijn rol is het in goede banen leiden van het werk van anderen. Hij verricht

in verhouding tot Hickson niet veel uitvoerende werkzaamheden. Hickson is overal van op

de hoogte en weet precies waarom welke keuzes zijn gemaakt in de specificatie.

Volgens Raymond is het bij een bazaar -project ook belangrijk dat een leider zijn mede-

ontwikkelaars behandelt als zijn meest waardevolle middel (32). Zo zorg je ervoor dat ze

met goede ideeen blijven komen. Mike Gavrilov leek na zijn voorstel in de mailinglijstdis-

cussie juist ontmoedigd te worden om ooit nog eens een voorstel te doen. Hij kreeg van de

andere leden niet de antwoorden waar hij om vroeg en ook Hickson was niet bereid zijn

vragen te beantwoorden, maar verwees hem door naar de website van de WHATWG. Uit

deze mailinglijstdiscussie blijkt niet dat Hickson Gavrilov ziet als een waardevol bezit.


Hoofdstuk 5

Het W3C

Het W3C noemt zichzelf een ”international community that develops open standards to

ensure the long-term growth of the Web” (W3C ). Deze omschrijving ligt dichtbij die van de

WHATWG: ”a growing community of people interested in evolving the Web” (WHATWG

FAQ). Beide organisaties zijn ’samenlevingen’ die zich inzetten voor de groei/ontwikkeling

van het Web. Ze hebben een gemeenschappelijk doel, maar verschillen in mening over hoe

dat doel het beste bereikt kan worden. Waar de samenleving van de WHATWG bestaat

uit een Editor en een groep vrijwillige leden, bestaat de samenleving van het W3C op dit

moment uit 411 lidorganisaties en 79 fulltime medewerkers (W3C About). De organisatie

wordt geleid door de initiator van het Web, Tim Berners-Lee, en CEO Jeff Jaffe. Om als

organisatie lid te worden van het W3C dien je contributie te betalen. Deze contributie

verschilt per land en soort organisatie. Nederlandse organisaties die bijvoorbeeld vanaf 1

januari 2016 bij willen dragen aan de ontwikkeling van W3C-standaarden, betalen tussen

de 68,000 euro (voor commerciele bedrijven met een omzet van meer dan 800 miljoen

euro) en 1,950 euro (voor organisaties met minder dan tien werknemers) per jaar voor

een lidmaatschap (W3C Membership Fees). Samen met subsidies, sponsors en donaties

vormen contributies de belangrijkste inkomsten van het W3C (W3C Facts).

5.1 Organisatiestructuur

De organisatie van het W3C bestaat uit vijf actoren (ibid.):

1. De Adviescommissie: bestaat uit vertegenwoordigers van alle 411 lidorganisaties.

Deze commissie heeft als voornaamste taak het beoordelen of het proces van de

ontwikkeling van standaarden goed verloopt. Daarnaast stelt zij de Adviesraad en

de Technische Architectuur Groep (TAG) aan.


2. De Adviesraad: adviseert de organisatie op het gebied van strategie, management,

rechtszaken, processen en conflicten.

3. De Technische Architectuur Groep (TAG): documenteert de regels voor Webarchi-

tectuur en houdt zich puur bezig met technische zaken.

4. W3C directeur en CEO: zorgen ervoor dat beslissingen binnen het W3C genomen

worden op basis van consensus. De directeur vervult daarnaast een rol als Hoofd

Technisch Architect en is verantwoordelijk voor de technische rapporten.

5. Werkgroepen: bestaan uit vertegenwoordigers van de lidorganisaties en gastdeskun-

digen. De werkgroepen produceren de standaarden van het W3C. De werkgroep die

de HTML-standaard produceert, is de HTML-werkgroep.

Zie voor een visuele weergave van de organisatiestructuur van het W3C het organogram

in figuur 5.1.

Elke lidorganisatie beschikt over een zetel in de Adviescommissie en heeft toegang tot

W3C-informatie (W3C Process). Ook mogen zij deelnemen aan workshops, symposia en

werkgroepen. Het doel van de werkgroepen is om tot een recommendation, of aanbeveling,

te komen:

”A W3C Recommendation is a specification or set of guidelines that, after

extensive consensus-building, has received the endorsement of W3C Members

and the Director”

In oktober werd HTML5 door het W3C gepubliceerd als officiele aanbeveling, wat

twee dingen betekent: het betekent dat de leden van het W3C de standaard zorgvuldig

onderzocht hebben op fouten, en dat je als ontwikkelaar niet kunt worden aangeklaagd

als je HTML gebruikt zoals het in de specificatie is beschreven (Shankland z.pag.). Om

dat laatste maken de meeste webontwikkelaars zich geen zorgen, maar veel W3C-leden

zijn daar wel bij gebaat. Een HTML5-element bijvoorbeeld, genaamd Canvas, werd al

vroeg gebruikt in Apple’s browser, Safari. Volgens Microsoft-werknemer Paul Cotton moet

Microsoft wachten met het gebruik van de technologie tot het W3C deze heeft opgenomen

in de officiele specificatie, wil het bedrijf er zeker van zijn niet tegen octrooikwesties met

Apple aan te lopen. Voor Cotton is de officiele specificatie van het W3C dus interessanter

dan de living standard van de WHATWG. Waar de WHATWG gelooft dat er geen sprake

kan zijn van een afgeronde specificatie, maar pleit voor een min of meer stabiele specificatie

die constant wordt geupdatet, wil het W3C haar gebruiker juist zekerheid en stabiliteit


Figuur 5.1: Zo zou het organogram van het W3C er ongeveer uit moeten zien. Tim

Berners-Lee en Jeff Jaffe staan als respectievelijk directeur en CEO aan het hoofd van

de organisatie. Vertegenwoordigers van alle lidstaten vormen de adviescommissie, die de

adviesraad en Technische Architectuur Groep aanstelt. De uitvoerende werkzaamheden

worden gedaan door de werkgroepen, die weer bestaan uit vertegenwoordigers van lidor-

ganisaties en experts.


bieden door elk element zorgvuldig te testen op compatibiliteit. Hickson gelooft in de

living standard van de WHATWG, maar is naast zijn rol als Editor bij de WHATWG,

ook werkzaam als Editor van de HTML-specificatie bij het W3C (W3C Technical Reports).

Naast stabiliteit is consensus een andere kernwaarde van het W3C (W3C Process).

Consensus wil zeggen dat: ”a substantial number of individuals in the set support the

decision and nobody in the set registers a Formal Objection”. Besluiten worden of via

e-mail, of tijdens vergaderingen genomen. Als je niet bij de vergadering aanwezig bent,

kun je geen Formeel Bezwaar indienen en kun je het voorstel niet tegenhouden. Als het

niet tot een consensus komt, kan er eventueel nog gestemd worden, maar dit gebeurt alleen

als alle pogingen tot een consensus tot niets hebben geleid.

5.2 Het W3C als bazaar

Niet alleen de WHATWG, ook het W3C heeft een aantal eigenschappen gemeen met het

bazaar -model van Raymond:

1. Goede ontwikkelaars weten wat ze moeten schrijven, uitstekende ontwikkelaars weten

wat ze moeten herschrijven (Raymond 25).

Net als de WHATWG borduurt ook het W3C voort op bestaand werk, een belangrijk

kenmerk van de open-source ontwikkelstijl. Toen de organisatie in 2006 besloot

HTML weer te gaan ontwikkelen, deden ze dat door het werk van de WHATWG als

beginpunt te nemen en vanuit dit punt verder te ontwikkelen, een proces dat ook

wel forking genoemd wordt. Ook in de jaren daarna heeft het W3C elementen van

de WHATWG specificatie gekopieerd en aangepast. De WHATWG is hier niet blij

mee:

”The W3C publishes some forked versions of these specifications. We have

requested that they stop publishing these but they have refused. They

copy most of our fixes into their forks, but their forks are usually weeks to

months behind. They also make intentional changes, and sometimes even

unintentional changes, to their versions. We highly recommend not paying

any attention to the W3C forks of WHATWG standards.” (WHATWG

FAQ).

Netjes of niet, het is een eigenschap die volgens Raymond het bazaar -model ken-

merkt.


2. Wees bereid om onderdelen weg te gooien (Raymond 26).

Dit is een tweede eigenschap die zowel de WHATWG als het W3C gemeen hebben

met het bazaar -model. In oktober 2006 besloot het W3C dat de keuze voor XML

niet goed had uitgepakt. Berners-Lee:

”Some things are clearer with hindsight of several years. It is necessary

to evolve HTML incrementally. The attempt to get the world to switch

to XML, including quotes around attribute values and slashes in empty

tags and namespaces all at once didn’t work. The large HTML-generating

public did not move, largely because the browsers didn’t complain. Some

large communities did shift and are enjoying the fruits of well-formed sys-

tems, but not all. It is important to maintain HTML incrementally, as

well as continuing a transition to well-formed world, and developing more

power in that world.” (Berners-Lee z.pag.).

Het is niet gemakkelijk om iets op te geven waar je jarenlang aan hebt gewerkt, maar

het is soms wel cruciaal om tot een beter product te komen. Het W3C heeft dat in-

gezien en vertoont daardoor overeenkomsten met het bazaar -model van ontwikkelen.

3. ”Given enough eyeballs, all bugs are shallow” (29).

De HTML-werkgroep van het W3C bestaat uit 385 deelnemers, waarvan 105 experts

uitgenodigd door het W3C en 280 afgevaardigden van de lidorganisaties, bedrijven

als Microsoft, Google en Chinese zoekgigant Baidu (Participants of the HTML Work-

ing Group). Dit is een groter aantal deelnemers dan bij de WHATWG het geval is.

Het is echter moeilijk te zeggen hoe actief deze deelnemers zijn in het ontwikkelpro-

ces. Het zou heel goed zo kunnen zijn dat er ook in deze groep slechts een klein

aantal personen is dat actief bijdraagt aan de ontwikkeling van de standaard. Wel

is zeker dat als een voorstel een consensus heeft bereikt, dat wil zeggen dat geen

van de deelnemers een bezwaar indient, de deelnemers akkoord gaan met de ver-

andering in de specificatie. De deelnemers, veelal medewerkers van browsermakers,

geven hiermee aan naar het voorstel te hebben gekeken en geen problemen tegen te

zijn gekomen. Ze geven hiermee ook aan de verandering te zullen implementeren

in de browsers, wat cruciaal is voor het W3C. Voor het W3C is het daarom belan-

grijk zoveel mogelijk browsermakers in de ontwikkeling te betrekken. In het geval

van HTML-ontwikkeling binnen het W3C geldt niet zozeer dat meer deelnemers


zorgen voor minder bugs, maar wel dat meer deelnemers zorgen voor een bredere

implementatie van de specificatie.

5.3 Het W3C als cathedral

Het W3C heeft een drietal kenmerken gemeen met het bazaar -model van ontwikkelen, maar

dat wil niet zeggen dat de manier van ontwikkelen van de organisatie ook echt moet worden

gezien als een bazaar. Een van de belangrijkste kenmerken van Linux en het bazaar -model

is dat nieuwe versies frequent worden uitgebracht (Raymond 28). Het W3C doet dit niet.

De HTML5-aanbeveling van het W3C verscheen in 2014, pas 15 jaar na HTML4.01 (W3C

Technical Reports). De organisatie wil pas een versie uitbrengen wanneer ze van mening

is dat er geen fouten meer in zitten en de standaard in elke browser goed zou moeten

werken. Dit gaat tegen de bazaar -ontwikkelstijl in.

Daarnaast gaat de bazaar -ontwikkelstijl ervanuit dat goede software ontstaat wanneer

een ontwikkelaar behoefte heeft aan iets (Raymond 25). Raymond:

”too often software developers spend their days grinding away for pay at pro-

grams they neither need nor love. But not in the Linux world–which may ex-

plain why the average quality of software originated in the Linux community

is so high.” (ibid.).

Bij de WHATWG wordt hier goed gebruik van gemaakt: een webontwikkelaar loopt

tegen een probleem aan en doet een voorstel om het probleem te verhelpen. Bij het

W3C is dit anders. Het W3C bestaat uit een aantal fulltime medewerkers en een aantal

lidorganisaties dat contributie betaalt. De werkgroepen bestaan uit enkele van die full-

time medewerkers en vertegenwoordigers van de lidorganisaties, vaak medewerkers van

browsermakers. Alleen van de door het W3C uitgenodigde experts die ook deelnemen

aan de werkgroepen is het niet gezegd dat ze betaald worden voor hun bijdrage aan de

werkgroep. Dit wil niet per se zeggen dat de kwaliteit hierdoor lager ligt, maar het past

wel meer bij een cathedral -ontwikkelstijl dan bij een bazaar.

Tot slot is er nog een derde kenmerk van het bazaar -ontwikkelmodel waar het W3C

niet aan voldoet. Volgens Raymond is het belangrijk dat gebruikers behandeld worden

als co-ontwikkelaars (27). De W3C maakt het de gebruikers, de webontwikkelaars, echter

moeilijk bij te dragen aan de standaard. Als je geen medewerker bent van een van de

lidorganisaties en niet wordt uitgenodigd om deel te nemen door het W3C, houdt het


op. Het W3C richt zich op de browsermakers en hun bereidheid om de specificatie te

implementeren, niet zozeer op haar gebruikers.


Hoofdstuk 6

De browsers

Ian Hickson over het standaardisatieproces van HTML:

”You may ask why browser vendors have a prominent role in this process. The

answer is simple. The specification is not magical; it cannot force browser

vendors to do anything they don’t want to do. If I write something in the spec

and they don’t implement it, there’s nothing we can do: the feature doesn’t

really exist, it’s just fiction, and we’ve all wasted our time. To avoid wasting

my time, I try to work with the browser vendors to make sure that what I

specify is something they’re willing to implement.” (WHATWG What You

Can Do).

Uit deze quote van Hickson blijkt nog eens hoe groot de rol van de browsermakers is in

de ontwikkeling van de HTML-standaard. Een voorbeeld van de macht die browsermakers

kunnen uitoefenen op standaarden is de moeizame relatie tussen Apple en Adobe’s Flash.

Flash is een technologie waarmee animaties, video’s en webapplicaties kunnen worden

gemaakt en afgespeeld. In april 2010 plaatste Steve Jobs, destijds CEO van Apple, een

bericht op de website van Apple, genaamd ”Thoughts on Flash” (Jobs z.pag.). Jobs zegt

hierin dat ”the avalance of media outlets offering their content for Apple’s mobile devices

demonstrates that Flash is no long necessary to watch video or consume any kind of web

content”. Verder zegt hij dat nieuwe open standaarden, zoals HTML5, de toekomst zijn

voor zowel mobiele apparaten als PC’s. Jobs deelde hiermee een grote klap uit aan Flash

en maakte de weg vrij voor de HTML5-standaard (Ford z.pag.).


Figuur 6.1: Aandeel gebruik internetbrowsers op desktop-PC’s in 2010 (bron:

http://www.netmarketshare.com/)

6.1 Van PC naar mobiel

Waarom is het zo belangrijk in welke technologie Apple de meeste mogelijkheden ziet?

Figuur 6.1 laat zien dat Apple’s browser Safari ten tijde van Jobs’ bericht slechts een

aandeel van 3.89% had.

Als Microsoft en Mozilla (maker van Firefox) wel een voorkeur zouden hebben voor

Flash, zou er voor Adobe nog weinig aan de hand zijn, zo lijkt het. Er wordt echter steeds

vaker gebruik gemaakt van mobiele apparaten om informatie op het Web te benaderen.

Waar men een aantal jaren geleden nog voornamelijk achter een PC zat om informatie op

webpagina’s te bekijken, gebeurt dit tegenwoordig vaak door middel van apps op smart-

phones en tablets1. Apple had in 2010 met besturingssysteem iOS het grootste mark-

taandeel in besturingssystemen voor mobiele apparaten, namelijk 42,17%2. Nog steeds

heeft het bedrijf een groot marktaandeel, alhoewel ze ondertussen voorbijgestreefd is door

Google’s Android besturingssysteem.

Apple heeft er bij de bouw van het iOS-besturingssysteem nadrukkelijk voor gekozen

Flash niet toe te staan op de apparaten die op iOS zouden draaien: iPhones, iPods, iPads

(Ford z.pag.). Volgens Adobe zou dit een bedrijfsstrategische keuze zijn geweest: Apple

zou zo haar App Store hebben willen beschermen. Volgens Jobs is het tegendeel echter

waar. Hij zegt dat Flash een gepatenteerd, en dus gesloten, systeem is en daarom tot

1Zie Appendix B voor het verschil in schermresoluties tussen 2010 en 2015. In 2010 kwamen smartphone-

of tabletresoluties nog niet eens voor in de meest gebruikte schermresoluties. Inmiddels staan er meerdere

smartphone-schermresoluties in de top zeven.2Zie Appendix C voor het verschil in marktaandelen besturingssystemen tussen 2010 en 2015.


problemen leidt. Flash is voor iedereen beschikbaar, maar is alleen via Adobe verkrijg-

baar en wordt ook volledig beheer(s)d door Adobe. Jobs geeft toe dat Apple ook vele

gepatenteerde producten in het bezit heeft, maar hij vindt dat voor het Web andere regels

gelden: ”we strongly believe that all standards pertaining to the web should be open”

(ibid.).

Volgens Jobs is een groot gedeelte van de video’s en applicaties op het Web afspeelbaar

zonder Flash. Het is dus niet zo dat iPhone-, iPad- en iPod-gebruikers veel activiteit

mislopen door de keuze van Apple om Flash niet toe te laten in het systeem. Daarnaast

zorgen Flash-applicaties vaak voor veiligheidsproblemen en wil Apple dat voorkomen. De

applicaties zorgen er ook nog eens voor dat de batterij van gebruikers sneller leeg raakt

en Flash kan niet goed omgaan met de vingeraanrakingen van gebruikers die juist zo

inherent zijn aan mobiele apparaten. De belangrijkste reden voor Apples keuze volgens

Jobs is echter dat software van een derde partij vaak leidt tot een beperking van de vrijheid

van ontwikkelaars en een lagere kwaliteit van het platform:

”Our motivation is simple - we want to provide the most advanced and innov-

ative platform to our developers, and we want them to stand directly on the

shoulders of this platform and create the best apps the world has ever seen.

We want to continually enhance the platform so developers can create even

more amazing, powerful, fun and useful applications. Everyone wins - we sell

more devices because we have the best apps, developers reach a wider and

wider audience and customer base, and users are continually delighted by the

best and broadest selection of apps on any platform.” (ibid.)

Interessant is hier de vraag op grond waarvan browsermakers en, belangrijk ook, ap-

plicatieplatformmakers als Apple, dus besluiten welke technologieen zij ondersteunen en

welke niet. Jobs legt de nadruk op het idee dat ontwikkelaars van apps en uiteindelijk

de gebruikers beter af zijn zonder Flash, maar voor Apple zal het ook vooral belangrijk

zijn dat zij niet afhankelijk is van een derde partij. Door geen software van derden toe

te laten in haar systeem, houdt Apple zelf de controle. Door de HTML5-standaard te

verkiezen boven Flash, kiest Apple voor een meer open technologie. Apple is vanaf het

begin betrokken geweest bij de ontwikkeling van HTML via het WHATWG, en is tevens

een lidorganisatie van het W3C. Het bedrijf kan hierdoor meer invloed uitoefenen op

de ontwikkeling van de HTML-standaard dan dat het de ontwikkeling van Flash kan

beınvloeden. Apple is een grote speler op het gebied van webbrowsers en mobiele bestur-

ingssystemen en dus is het voor zowel het W3C als de WHATWG belangrijk Apple te


betrekken in het HTML-ontwikkelproces. Als Apple het niet eens is met een verandering

van de HTML-specificatie kan ze ervoor zorgen dat vele iPhone- en iPad-gebruikers er geen

gebruik van kunnen maken. Bij het W3C zit het idee dat goedkeuring van browsermakers

nodig is al ingebakken in het systeem van het selecteren van leden. De grote browser-

makers zijn lid van het W3C en kiezen een aantal vertegenwoordigers die aan de discussies

deelnemen. Als er een consensus is bereikt, gaat iedereen akkoord met de verandering en

beloven zij de verandering te implementeren.

6.2 Hickson en DRM

Hickson moet er namens de WHATWG voor zorgen dat browsermakers het eens zijn over

een verandering in de specificatie. Op de vraag of Hickson vindt dat browsermakers teveel

invloed hebben op de ontwikkeling van de standaard, zegt hij dat hij juist graag een nog

actievere houding zou willen zien van sommige browsermakers (Lawson z.pag.). Hij krijgt

bijvoorbeeld erg weinig feedback uit de Microsoft-hoek:

”Even when asking them about their opinion on features they are implementing

I rarely get any feedback. It’s very sad. If I e-mail them a question about how

I can best help them, I usually get no reply; at best I’ll get a promise that

they’ll get back to me, but that’s it.”

Het is echter ook weer niet zo dat Hickson al zijn keuzes met betrekking tot HTML

af laat hangen van de wensen van de browsermakers. Hij heeft een sterke eigen mening

en spreekt die regelmatig uit. Een voorbeeld hiervan is het beveiligen van video’s tegen

kopieren (Bug 10902 ). Voor HTML5 was er geen standaard voor het weergeven van

video’s op een webpagina. Deze video’s konden alleen worden afgespeeld door middel van

plug-ins, zoals Adobe’s Flash. Met HTML5 hebben webontwikkelaars de beschikking over

een video-tag gekregen, waarmee ze video’s in een webpagina kunnen verwerken zonder

gebruik te maken van plug-ins. Het verschil tussen een video die wordt afgespeeld via

plug-ins van derden en een HTML5-video die direct is ingesloten in de webpagina, is dat

de laatste (vooralsnog) geen kopieerbeveiliging kan hebben. Plug-ins als Flash beschikken

wel vaak over een vorm van kopieerbeveiliging, ook wel Digital Rights Management (DRM)

genoemd.

John Foliot maakte in september 2010 een melding voor een bug op de W3C-website,

genaamd ”<video> element needs to support some form of DRM solution” (ibid.). Volgens

Foliot kan de video-tag alleen breed worden geaccepteerd wanneer er een vorm van DRM


wordt geboden. Zo niet, dan zullen makers van videocontent altijd gebruik blijven maken

van plug-ins van derden als Flash en Silverlight. Hickson, Editor van de bugmeldingen bij

het W3C, kapt de melding snel af:

Status: Rejected

Change Description: no spec change

Rationale: DRM is evil.

Foliot geeft echter niet op en heropent de melding. Hij zegt het recht van de Editor

zijn mening te geven over de politieke aspecten van DRM te respecteren, maar eist een

technische onderbouwing van het besluit:

”The current rationale is not a rationale, it is an opinion, and as such is

unacceptable. Commercial content licensees (such as Netflix or Blockbuster)

will require a means to protect content they want to stream over the web, and

without a means to do so they will continue to turn to 3rdparty solutions such

as Flash or Silverlight to achieve this.”

Argumenten voor en tegen gaan over en weer in de discussie. Lachlan Hunt, medew-

erker van Opera, zegt dat DRM een ”dom idee” is en dat enige vorm van DRM binnen

HTML technisch gezien vrijwel niet kan slagen. Verder zegt hij:

”So the only thing DRM does is let the entertainment industry control innov-

ation and participation in the market, under their own terms and conditions,

and any one who doesn’t comply with their demands is locked out. We abso-

lutely do not want that.

So, no, we will not support any form of DRM in HTML5, and I’m fairly sure

we will strongly resist any attempt to introduce such measures into WebM or

Ogg media. Please close this bug.”

Foliot vraagt zich vervolgens af uit wiens naam Hunt nu eigenlijk spreekt:

”I am curious to know who this ”we” is you are speaking for. Is Lachaln

speaking on behalf of the W3C, Opera Software, or himself, the editor and a

small group of engineers who want to pretend DRM out of existence by placing

their hands over their ears and chanting ”lalalalalala”?”

Volgens Hunt spreekt hij voornamelijk voor zichzelf, ”as Opera generally doesn’t have

any official position on these things”. De vraag van Foliot is daarom wel terecht: waarom


spreken van ”we” wanneer je eigenlijk alleen voor jezelf spreekt? Foliot brengt het nog een

stapje verder en spreekt de tegenstanders van DRM vervolgens aan als ’the Royal We’s’.

Hickson reageert later nog en geeft een langere uitleg van zijn besluit om DRM niet toe te

laten in HTML. Hij legt uit dat er bij DRM bij definitie sprake is van een ’geheim’ voor de

gebruiker. Dat ’geheim’ is vaak een soort code die de gebruiker krijgt als hij of zij betaalt.

Als DRM technisch gezien al geımplementeerd kan worden, is het vijandig tegenover de

gebruiker: het beperkt de gebruiker om te doen wat hij of zij wil doen. Dit druist volgens

Hickson in tegen het principe van het Web: iedereen moet content kunnen reproduceren,

knippen, plakken, aanpassen, etc.

Stel dat Google op Hicksons besluit zou vertrouwen: Google zegt dat zij tegen DRM

is en het dan ook niet in haar browser wil hebben. Ze vindt dat gebruikers alles moeten

kunnen doen met content, en daarin dus niet moet worden beperkt. Google implementeert

de video-tag en staat plug-ins van derden niet toe. Voor makers van commerciele video-

content als Netflix en Blockbuster is er dan geen mogelijkheid om video’s weer te geven in

Chrome met kopieerbeveiliging. Ze kiezen er wellicht voor geen video’s weer te geven in

die browser, waardoor abonnees alleen films en series kunnen kijken via andere browsers.

Het marktaandeel van Google Chrome kan daardoor gaan dalen. Hetzelfde geldt voor de

browser waar Hunt voor werkt, Opera.

Bovenstaande is volledig hypothetisch, maar het geeft wel aan dat Hickson en sommige

andere medewerkers van browsermakers niet per se het belang van browsermakers voorop

stellen. De open filosofie van het Web en de vrijheid van gebruikers weegt wel degelijk

mee voor de ontwikkelaars van HTML.


Hoofdstuk 7

Een bazedral

De WHATWG en het W3C lijken op het eerste gezicht lijnrecht tegenover elkaar te staan:

het W3C pleit voor stabiliteit, terwijl de WHATWG ”min of meer stabiele versies” van

de standaard uitbrengt. Het W3C publiceert eens in de zoveel jaar een nieuwe HTML-

specificatie, waar de WHATWG uitgaat van een living standard, die continu wordt aange-

past. Voor het W3C moeten lidorganisaties contributie betalen of worden uitgenodigd om

deel te nemen, terwijl de WHATWG iedereen toestaat deel te nemen aan de discussies

via de mailinglijst. Hierdoor krijgen webontwikkelaars bij de WHATWG de gelegenheid

hun mening te geven, in tegenstelling tot bij het W3C, waar vrijwel alle pijlen gericht zijn

op browsermakers en experts. Belangrijk verschil tussen de twee is ook de wijze van het

maken van beslissingen: bij het W3C moet er sprake zijn van consensus voordat een veran-

dering in de specificatie wordt geımplementeerd, bij de WHATWG is het Editor Hickson

die het laatste woord heeft.

Toch zijn de organisaties sterk met elkaar verweven en hebben ze verschillende ei-

genschappen met elkaar gemeen. Zie figuur 7.1 voor een overzicht van de verschillen en

overeenkomsten tussen het W3C, de WHATWG en de browsers. Het W3C heeft wat be-

treft het sporadisch uitbrengen van updates en de beperkte deelnamemogelijkheden veel

weg van het cathedral -model van ontwikkelen, maar heeft ook eigenschappen die meer bij

het bazaar -model passen, zoals het kopieren van bestaand werk en het raadplegen van vele

partijen voordat er een beslissing wordt gemaakt. De WHATWG is van mening dat het

Web continu in ontwikkeling is en dat de HTML-standaard daarom ook altijd in beweging

moet zijn. Ook kan iedereen deelnemen aan de discussies. Beide eigenschappen passen

goed bij het bazaar -model van ontwikkelen. Net als het W3C geen pure cathedral is, is

de WHATWG echter ook geen pure bazaar. Hickson heeft een rol die niet kan worden

uitgelegd in termen van een bazaar. Zijn rol gaat meer richting die van een kardinaal die


Figuur 7.1: Overzicht van de verhoudingen van het W3C, de WHATWG en de browsers.


dienstdoet in de cathedral. Daarnaast is er bij de WHATWG slechts een klein aantal leden,

vaak medewerkers van browsermakers, dat actief deelneemt aan discussies. Ook dat zorgt

ervoor dat de organisatie niet voldoet aan het beeld dat Raymond schetste van een bazaar.

Het cathedral - en bazaar -model van ontwikkelen zijn twee extremen, met daartussenin een

groot grijs gebied.

7.1 Perspectieven op de samenwerking

Ondanks dat de twee organisaties veel met elkaar gemeen hebben, botsen hun manieren

van werken met elkaar. WHATWG’er Danny Ayers stelde via de WHATWG-mailinglijst

eens de vraag wat nu eigenlijk de rol is van het W3C in de ontwikkeling van de standaard

(Hickson z.pag.). Volgens Hickson vroeg het W3C de WHATWG na het XML-debacle of

ze samen wilde werken, maar voelt het voor hem alsof de W3C-medewerkers het liefst als

enige partij verantwoordelijk voor de HTML-standaard hadden willen zijn. Hij verzekert

Ayers dat de WHATWG op geen enkele manier probeert te concurreren met het W3C,

en het liefst een goede samenwerking met de organisatie ziet. Elk bestuurslid van het

W3C is uitgenodigd om lid te worden van de WHATWG, maar van dat aanbod wordt

vaak geen gebruik gemaakt. Volgens Hickson probeert de WHATWG lezers daarnaast

altijd te verwijzen naar zowel de W3C-specificatie als de WHATWG-specificatie, ondanks

dat het W3C dat andersom niet doet. Het kostte de WHATWG bijvoorbeeld ruim een

jaar om het W3C ervan te overtuigen te verwijzen naar de WHATWG-specificatie in die

van het W3C. Een ander voorbeeld van het gebrek aan welwillendheid van het W3C om

de WHATWG te erkennen als co-organisatie is de eerdergenoemde brief van Berners-Lee

waarin hij uitlegt waarom het W3C zich weer zou gaan richten op HTML. Hij verwijst

daarin niet een keer naar de WHATWG, terwijl de WHATWG in tegenstelling tot het

W3C, wel in HTML was blijven geloven en het W3C daarnaast werk heeft gebruikt van de

WHATWG om mee verder te gaan. Hickson hoopt dat het W3C afscheid neemt van het

proces van officiele aanbevelingen en WHATWG’s model van living standards gaat volgen:

”I would welcome the W3C moving to the ”living standard” model so innate to

the way the Web works for all of its Web specifications. It’s already effectively

been using it for CSS and XML for the past ten years, and for HTML for the

past four. The WHATWG has no interest in monopolising this model; we’re

using it because we honestly believe it’s the best way of improving the Web,

not to lay claim to the center of HTML development.”


W3C CEO Jeff Jaffe is het hier niet helemaal mee eens. Hij reageert op de discussie die

is ontstaan over de vraag: wat is nu beter, de ontwikkelwijze die zijn W3C hanteert, of die

van de WHATWG (Jaffe z.pag.)? Volgens Jaffe hebben beide ontwikkelstijlen voordelen.

Een uitstekende Editor die goed samenwerkt met collega’s kan vele malen efficienter zijn

dan een werkgroep die tot een consensus moet komen. Miljarden gebruikers en miljoenen

webontwikkelaars zijn echter afhankelijk van webstandaarden en er moet worden voldaan

aan de wensen van zoveel mogelijk van hen. Jaffe vind het daarom belangrijk dat zij

geloven dat er bij HTML-ontwikkeling sprake is van een eerlijk proces, waaraan ze zelf

kunnen deelnemen. Een eerlijk proces houdt in dat men in beroep kan gaan op besluiten,

want zelfs de beste Editors kunnen fouten maken. Ook moet er rekening gehouden worden

met de verschillende belangen die een rol spelen op het web: denk aan de belangen van

browsermakers, appontwikkelaars, gebruikers met een handicap, onderzoekers, docenten,

auteurs, etc. Daarnaast vindt Jaffe transparantie belangrijk. Het moet duidelijk zijn

waar de organisatie aan werkt en waar het zit in het ontwikkelproces. Er moet een goede

balans zijn. Standaarden mogen niet worden gedomineerd door een persoon, organisatie,

of groep: ”The web, being an infrastructure dedicated for the benefit of all people needs

to be assured that it remains open of undue influence by interest groups”. Een Editor

mag dus niet teveel invloed hebben op de standard. Het hebben van een Editor met

veel invloed zoals Hickson bij de WHATWG heeft wel een belangrijk voordeel: besluiten

kunnen snel worden gemaakt. Volgens Jaffe kan het W3C-ontwikkelproces dat gericht

is op consensus hierdoor veel leren van het proces van de WHATWG op het gebied van

snelheid en flexibiliteit, maar is zoeken naar een breed consensus nog steeds erg belangrijk.

7.2 HTML-ontwikkeling: bazaar of cathedral?

Wie heeft er nu gelijk? Het maakt eigenlijk niet echt uit, zegt Paul Ford (2014). Het

W3C werkt aan de nieuwste versie van de HTML-standaard en de WHATWG probeert de

veranderingen van het Web bij te benen, ”terwijl ze publiekelijk haar ogen rolt naar het

W3C” (ibid.). Er worden soms felle discussies gevoerd, en soms is het een tijdje stil. De

WHATWG wil dat het W3C stopt met het kopieren van haar werk, maar HTML is al sinds

1993 het kindje van het W3C. De organisatie heeft de standaard weliswaar een periode

verwaarloosd, maar is niet bereid deze over te dragen. De twee hebben een overeenstem-

ming. Het is een ongemakkelijke overeenstemming, maar het is er wel een. Volgens Ford

is dat een vooruitgang, en al een hele overwinning op zich. Het werkt op deze manier.

Browsers worden steeds sneller en zijn meer betrouwbaar dan voorheen. Browsermakers


concurreren met elkaar om het Web sneller te maken, maar geen van hen is bezig de

kern te veranderen. Het W3C en de WHATWG hebben er samen met de browsermakers

voor gezorgd dat webontwikkelaars nu kunnen genieten van betere compatibiliteit tussen

browsers en besturingssystemen. Het is de combinatie van de verschillende organisaties

en bijbehorende ontwikkelstijlen die dit mogelijk heeft gemaakt. Eric Raymond zei:

”It is fairly clear that one cannot code from the ground up in bazaar style.

One can test, debug and improve in bazaar style, but it would be very hard to

originate a project in bazaar mode.” (Raymond 37).

In de beginperiode van een standaard als HTML is het volgens Raymond dus slim om

gebruik te maken van een top-down cathedral-model. Het W3C heeft tussen 1993 en 2004

inderdaad gebruik gemaakt van zo’n soort model: de organisatie komt met een voorstel,

daar komt een besluit uit, en dit wordt geımplementeerd door de uitvoerende tak. De

WHATWG heeft het in 2004 overgenomen en nam een soort bottom-up bazaar -model

aan: iedereen mag met een voorstel komen en deze wordt beoordeeld door de Editor.

Andersom zou waarschijnlijk niet hebben gewerkt, de bottom-up ontwikkelstijl van de

WHATWG was niet geschikt geweest voor de beginjaren van HTML.

Raymond:

”someone who chose that problem to solve because of a fascination with the

problem itself–which, in software as in other kinds of creative work, is a far

more effective motivator than money alone.” (44).

Dit past meer bij de bottom-up WHATWG-aanpak: gebruikers van het Web lopen

ergens tegenaan en komen met een voorstel. Dit zou volgens Raymond een betere mo-

tivatie zijn dan een fulltime W3C-medewerker die een oplossing moet bedenken voor een

probleem van iemand anders. Zonder de WHATWG zouden oplossing voor problemen

van de gebruikers van het Web wellicht blijven steken door gebrek aan motivatie, terwijl

browsermakers wel hun aanpassingen door blijven voeren. Door de WHATWG is HTML

er voor de gebruikers, niet alleen voor de browsermakers.

”Perhaps in the end the open-source culture will triumph not because co-

operation is morally right or software ”hoarding” is morally wrong (assuming

you believe the latter, which neither Linus nor I do), but simply because the

closed-source world cannot win an evolutionary arms race with open-source

communities that can put orders of magnitude more skilled time into a prob-

lem” (Raymond 41).


Figuur 7.2: De bazedral : een combinatie van bazaar - en cathedral -elementen.

Volgens Raymond zal het open-source bazaar -model uiteindelijk zegevieren, omdat

closed-source organisaties het niet kunnen winnen van de hordes ontwikkelaars die samen-

werken aan problemen. De vraag is echter of er een model moet zegevieren. Bij de

ontwikkeling van HTML is het juist de combinatie van bazaar - en cathedral -elementen die

belangrijk is. Zonder de WHATWG hebben de gebruikers minder in te brengen en zouden

webontwikkelaars nu misschien webpagina’s structureren aan de hand van XML-emoties.

Zonder het W3C waren de beginjaren van de ontwikkeling van de standaard moeilijk

geweest en zou HTML misschien niet zo breed geımplementeerd zijn, aangezien browser-

makers de zekerheid willen die alleen het W3C hen kan bieden. HTML-ontwikkeling

gebeurt niet via een bazaar - of cathedral -model, maar via een combinatie van elementen

van beide modellen, die samen de bazedral vormen.


Hoofdstuk 8

Conclusie

HTML is een bijzonder geval binnen de internetstandaarden. Twee organisaties, het W3C

en de WHATWG, werken simultaan aan de ontwikkeling van de standaard, maar hebben

heel verschillende ontwikkelstijlen. Volgens Eric Raymond zijn er twee ontwikkelstijlen mo-

gelijk: het cathedral -model en het bazaar -model. Het W3C neigt wat betreft ontwikkelstijl

naar het eerste en de WHATWG naar het tweede, maar ze hebben beide elementen gemeen

met het andere model. Het zijn twee extremen en in het geval van HTML-ontwikkeling

komt de pure cathedral en de pure bazaar niet voor. Het W3C en de WHATWG staan

niet zo lijnrecht tegenover elkaar als bij de twee modellen volgens Raymond het geval zou

zijn.

Behalve de WHATWG en het W3C spelen ook de internetbrowsers een hele grote rol

in de ontwikkeling van HTML. Browsermakers moeten bereid zijn eventuele veranderingen

in de standaard te implementeren en dus is het belangrijk hen in het proces te betrekken.

Het gevolg is dat met name het W3C erg gericht is op de goedkeuring van de browser-

makers. Bij de WHATWG is de slagingskans van een voorstel voor een verandering vooral

afhankelijk van de goedkeuring van Editor Ian Hickson. Ook hij hecht veel waarde aan

de mening van de browsermakers, maar is ook bereid daartegenin te gaan, wanneer het

ten koste gaat van de openheid van het Web. Zowel het W3C als de WHATWG on-

derhouden goede relaties met de browsermakers, maar de onderlinge verhouding verloopt

moeizaam. Ze hebben verschillende ideeen over hoe de standaard het beste verder kan

worden ontwikkeld, maar hebben eenzelfde doel voor ogen: een snel en betrouwbaar Web

dat voor iedereen toegankelijk is, vanaf elk apparaat. Beide organisaties pleiten voor open-

heid, en ook de browsermakers zien het liefst open technologieen, weliswaar om een andere

reden: open technologieen bieden bedrijven als Apple meer controle over hun systemen

dan gesloten technologieen van derden.


Alhoewel de WHATWG en het W3C het zelf misschien niet zo zien, complementeren

de twee elkaar wel degelijk. Juist de verschillende combinaties van cathedral - en bazaar -

ontwikkelelementen hebben de standaard gebracht tot waar het nu is. De browsercom-

patibiliteit waar de organisaties voor hebben gezorgd heeft definitief een einde gemaakt

aan de balkanisatie die in de beginjaren van het Web was ontstaan. Het Web is sneller

en betrouwbaarder dan ooit en biedt webontwikkelaars veel mogelijkheden. Er is niet een

model dat beter is dan de ander, en er hoeft geen model te winnen. De combinatie van

cathedral - en bazaar -ontwikkelelementen die samen de bazedral vormen, werkt. Wellicht

zou toekomstig onderzoek kunnen uitwijzen of de bazedral in andere gebieden van het Web

ook wordt toegepast of kan worden toegepast, zodat we het Web nog beter kunnen maken

en ontwikkeling nog efficienter kunnen maken.


Bibliografie

Berners-Lee, Tim. ”Reinventing HTML.” Web log post. Decentralized Information Group

(DIG) Breadcrumbs. Massachusetts Institute of Technology 27 (2006).

<http://dig.csail.mit.edu/breadcrumbs/node/166>.

Bug 10902. 5 december 2015.

<https://www.w3.org/Bugs/Public/show bug.cgi?id=10902>.

DeNardis, Laura. ”The emerging field of Internet governance.” Yale Information Society

Project Working Paper Series (2010).

Ford, Paul. The Group That Rules The Web. New Yorker. November 2014. 2 november

2015. <http://www.newyorker.com/tech/elements/group-rules-web>.

Frequently Asked Questions Working Group. 14 november 2015.

<http://www.w3.org/2007/04/html-ie-faq>.

Hickson, Ian. Re: Please explain the role of the W3C in the continuing development of

HTML. Februari 2011. 8 december 2015. <https://lists.w3.org/Archives/Public/www-

archive/2011Feb/0022.html>.

Jaffe, Jeff. Decision by consensus or by informed editor; which is better?. W3.org. Okto-

ber 2014. 10 december 2015. <http://www.w3.org/blog/2014/10/decision-by-consensus-

or-by-informed-editor-which-is-better/>.

Jobs, Steve. Thoughts on Flash. Apple.com. April 2010. 29 november 2015.

<https://www.apple.com/hotnews/thoughts-on-flash/>.

Lawson, Bruce. Interview with Ian Hickson, editor of the HTML 5 specification. The Web

Standards Project. Mei 2009. 2 november 2015. <http://www.webstandards.org/2009/05/

13/interview-with-ian-hickson-editor-of-the-html-5-specification/>.

Lawson, Bruce, en Remy Sharp. Introducing html5. New Riders, 2011.


Lessig, Lawrence. ”Open code and open societies: values of internet governance.” Chicago-

Kent Law Review 74 (1998): 1405.

Lovink, Geert, en Ned Rossiter. ”Seriality for All: The Role of Protocols and Standards

in Critical Theory.” Interoperabel Nederland, The Hague: Forum Standaardisatie. 2011.

Participants of the HTML Working Group. 14 november 2015.

<http://www.w3.org/2000/09/dbwg/details?group=40318public=1order=name>.

Raymond, Eric. ”The Cathedral and the Bazaar.” Knowledge, Technology, Policy (1999).

Shankland, Stephen. HTML5 is done, but two groups still wrestle over Webs future.

CNET. Oktober 2014. 2 november 2015. <http://www.cnet.com/news/html5-is-done-

but-two-groups-still-wrestle-over-webs-future/>.

W3C. 13 november 2015. <http://www.w3.org/>.

W3C About. 13 november 2015. <http://www.w3.org/Consortium/>.

W3C Facts. 13 november 2015. <http://www.w3.org/Consortium/facts>.

W3C Membership Fees. 13 november 2015.

<http://www.w3.org/Consortium/fees?countryCode=NLquarter=01-01year=2016results>.

W3C Process. 13 november 2015. <http://www.w3.org/2005/10/Process-20051014>.

W3C Technical Reports. 2 november 2015. <http://www.w3.org/TR/>.

WHATWG Charter. 8 november 2015. <https://whatwg.org/charter>.

WHATWG Contibutors HTML. 12 november 2015.

<https://github.com/whatwg/html/graphs/contributors>.

WHATWG FAQ. 7 november 2015. <https://wiki.whatwg.org/wiki/FAQ>.

WHATWG October Archive. 9 november 2015.

<https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Oct/>.

Hoofdstuk 9

Emotion Markup Language

<?xml version="1.0" encoding="UTF-8"?>

<emotionml version="1.0" xmlns="http://www.w3.org/2009/10/emotionml">



<vocabulary type="category" id="big6">

<item name="anger" />

<item name="disgust"/>

<item name="fear"/>

<item name="happiness"/>

<item name="sadness"/>

<item name="surprise"/>

</vocabulary>

<vocabulary type="category" id="everyday-categories">

<item name="affectionate"/>

<item name="afraid"/>

<item name="amused"/>

<item name="angry"/>

<item name="bored"/>

<item name="confident"/>

<item name="content"/>

<item name="disappointed"/>

<item name="excited"/>


Hoofdstuk 10

Schermresoluties 2010 en 2015


Figuur 10.1: Schermresoluties 2010 (bron: http://www.netmarketshare.com/)

Figuur 10.2: Schermresoluties 2015 (bron: http://www.netmarketshare.com/)


Hoofdstuk 11

Marktaandeel besturingssystemen

voor mobiele apparaten


Figuur 11.1: Marktaandeel besturingssystemen voor mobiele apparaten in 2010 (bron:


Figuur 11.2: Marktaandeel besturingssystemen voor mobiele apparaten in 2015 (bron:
