He lives and labors and hopes

Vanavond las ik over de “Tesla Model S“, en de vraag die bij mij dan op komt is of het bedrijf dat Nikola Tesla als inspiratie neemt dat ook waar maakt. Na te lezen dat Elon Musk de baas was wist ik eigenlijk al voldoende en eindigde logischerwijs op een pagina met Tesla quotes waarbij ik dit juweeltje tegen kwam:

The scientific man does not aim at an immediate result. He does not expect that his advanced ideas will be readily taken up. His work is like that of the planter — for the future. His duty is to lay the foundation for those who are to come, and point the way. He lives and labors and hopes.

De man met oneindig veel patenten, met een dagelijkse impact op ons leven maar die eigenlijk nooit de erkenning kreeg (en nu buiten de nerds nog vrij onbekend is) blijkt dit altijd begrepen te hebben. En wat hij zegt over ‘de wetenschapper’ is denk ik waar in veel bredere zin…

Een van mijn favoriete anekdotes uit de 2008 campagne was de blunder van Hillary waarbij ze Marthin Luther King jr. afzette tegen Lyndon B. Johnson. Het idee erachter was dat MLK (lees Obama) fantastische speeches kon geven en mensen inspireerde, maar dat de pragmatische president LBJ (lees Hillary) er voor nodig was om dat concreet te maken in wetten.
Deze vergelijking bleef me bij omdat hij zo raak is, maar net op een andere manier dan ze bedoelde. Wat er aan klopte is niet dat Johnson het karwij afmaakte, maar dat hetgeen Johnson bereikte een succes met vele vaders en moeders was. Sommigen zichtbaarder dan anderen, vele onzichtbaar en een massa aan gezichtlozen die nooit herinnerd zullen worden.

Om er een voetbalmetafoor bij te pakken (riskant met mijn gebrekkige voetbalkennis): het doelpunt wordt gemaakt door de spits die de bal inkopt. Echter diezelfde spits had het doelpunt niet kunnen maken zonder de vleugelspeler die de bal precies goed voor gaf, zonder de middenvelder die met een loopactie ruimte creëerde en zonder de verdediger die onder druk de bal bij die medespeler wist te krijgen en het tij keerde.

Tesla was geen volledig onzichtbare speler op dat veld, maar wel snel vergeten. Wat hij echter begreep is dat je niet de scorende spits hoeft te zijn om echt iets te bereiken, dat is niet voor ieder weggelegd. Om echt-echt iets te bereiken kan je ook zaadjes planten, ruimte creëren waar die niet was, of zelfs alleen een vergissing voorkomen op het juiste moment.

Dat besef kwam uit de mond van de spits die altijd scoorde, maar z’n naam nooit terug zag omdat een ander altijd nog even als laatste de bal aanraakte. Om hem zelf te quoten toen hij hoorde wie de credits voor Radio kreeg:

Marconi is a good fellow. Let him continue. He is using seventeen of my patents.

Nb. Voor de volledigheid: hij klaagde Marconi later alsnog aan en won uiteindelijk de rechtzaak… nadat ze beide waren overleden.

Democratie keert zich tegen zichzelf?

Na het lezen van een artikel met bovenstaande titel (excl vraagteken) van het medium ToneApp begon er bij mij wat te koken (verder overigens een zeer sympathiek initiatief, nog sympathieker wanneer een Android app verschijnt). Het is een artikel dat aan elkaar hangt van non sequiturs en “straw man” argumenten. Discussie over democratie is essentiëel: de invulling, de werking van bestaande democratie en alternatieven moeten altijd bespreekbaar blijven. Ik val dan ook niet over het artikel om dogmatische redenen, ik val erover omdat een dergelijk bijeenraapsel van drogredeneringen geen aanvulling is voor het debat.

Hoe ik hierop wil reageren? Ik denk dat ik het maar gewoon op meta niveau stap-voor-stap door ga nemen.

De inleiding

Traditioneel natuurlijk de plek waar je de vraagstelling introduceert die je wil beantwoorden, de plek waar je de status quo uiteenzet en misschien ook de plek waarbij je de lezer uitdaagt om door te lezen. Met de eerste 3 zinnen zet de schrijver zijn vraag dan ook direct neer: “wie gelooft er nu nog in democratie“. Hij vervolgt met de stelling dat “vrede, welvaart en democratie niet vanzelfsprekend meer bij elkaar horen“. Wat blijkbaar de stelling is van iedereen die gelooft in democratie? Ik zou zeggen straw man, maar laten we verder lezen…
Hij vervolgt met het aanhalen van de bekende Churchil quote over het “minst slechte systeem” en werpt de stelling op dat parlementaire democratie negatief is voor het vinden van oplossingen. Iets dat gelovigen in democratie volgens hem “onder ogen moeten zien“.

Wat hij hier in feite gedaan heeft is een stelling opwerpen dat democratie een soort religie is met gelovigen. Dat democratie als systeem faalt wanneer het niet verbonden is met vrede en welvaart. Churchil had ongelijk, of misschien ook niet want alternatieven hoor ik (nog?) niet. Maar in ieder geval zijn de straw man gelovigen waarschijnlijk naïef: zij hebben immers onder ogen te zien wat volgt.

1. Verlammende tegenstelling

Hier wordt al duidelijk hoe de bewijsvoering tegen “democratie” zal gaan lopen. We gaan een vogelvlucht krijgen van democratieën die niet werken of waar zaken fout gaan. Helaas wordt hierbij niet een specifieke implementatie zoals Nederland of de Europese Unie uitgewerkt maar wordt het een hak-op-de-tak optelsom. We beginnen met mijn guilty pleasure: De VS.

De VS zien zichzelf graag als het lichtende voorbeeld van democratie. Hier is enorm veel op aan te merken, ik zal niet het volledige scala hiervan doorlopen maar om een paar voorbeelden te noemen:

  • Het electoral college welke reeds 4 mannen met een minderheid van stemmen president maakte, meest recent en bekenste voorbeeld was natuurlijk George W. Bush.
  • De Senaat, waar iedere individuele staat 2 senatoren voor mag leveren voor een totaal van 100 senatoren voor 50 staten. Dit leidt tot het bizarre verschil dat een inwoner van Wyoming (576.412 inwoners) zesenzestig keer zo belangrijk is als een inwoner van Californië (38.041.430 inwoners).
  • Het “First past the post” systeem voor het kiezen van congresleden en senatoren, waar het nodige op aan te merken is als democratisch systeem.
  • Gerrymandering waar zowel de democraten in het verleden als de republikeinen momenteel zich zwaar schuldig aan maken.

Verder zou ik nog verder kunnen gaan over invloed van lobbyisten. Over de invloed van levenslang zittende rechters in de supreme court. Over de macht van de president.
In feite kan ik veel harder losgaan dan de auteur. Ik zou echter losgaan op de implementatie van democratie in de VS. Ik zou hun systeem emblematisch, noch representatief, noch als voorbeeld van een functionerende democratie willen aandragen. Dat is wat de schrijver wel poogt te doen. Hij doet dat met een oversimplificatie van het probleem in de VS welke de plank feitelijk volledig mis slaat.

2. Welvaart zonder democratie

Deze alinea begint met de stelling dat China met haar bestaan bewijst “dat vrede en welvaart ook zonder democratie mogelijk zijn“. Merk hierbij op dat vrijheid schijnbaar geen voorwaarde is voor een goede staatsinrichting. Verder is dit een reactie op de straw man dat dit schijnbaar onlosmakelijk met het begrip democratie verbonden is.
Echter die zaken zijn niet eens het ergste wat er mis is met deze stelling: Het ergste is namelijk dat deze feitelijk gewoon totaal onwaar is, en niet zo’n beetje ook. China als voorbeeld nemen van “welvaart” is eigenlijk alleen mogelijk als je denkt dat de zomerspelen van 2008 representatief zijn voor de honderden miljoenen platteland bewoners.

De daaropvolgende voorbeelden van Indonesië, India en Turkije volgen eigenlijk hetzelfde stramien als de vergelijking met de VS. De uitwassen worden genoemd, simplistisch weergegeven en als representatief voor alle vormen en implementaties van democratie aangedragen.

3. Machtsspel ipv representatie

Dan komen we toch eindelijk zelf aan bod. Want het falen van de regering Rutte ligt aan de Eerste Kamer, deze is immers volgens de schrijver om staatsrechtelijke toetsing van wetten in het leven geroepen. Een grotere misvatting over onze geschiedenis is vrijwel niet mogelijk.
Ik quote de website van de Eerste Kamer over hun reden tot oprichting: “De zuidelijke leden wilden dat hun adel een vaste plaats in het parlement kreeg. Hoewel de noorderlingen niet enthousiast waren, besloten zij de Belgen hun zin te geven. Bovendien was koning Willem I niet afkerig van een Eerste Kamer, mits hij maar kon bepalen wie daarin zitting zouden krijgen.

Discussie over de rol (en mogelijke afschaffing) van de Eerste Kamer voer ik graag en steun ik ook. Het lijkt mij wél essentieel de functie die de Eerste Kamer zichzelf graag toebedeelt te waarborgen (zie bijvoorbeeld Wetsvoorstel Halsema). Maar dit is een discussie die de schrijver verder niet schijnt te willen voeren, een klaagzang is waar we het mee moeten doen.

4. Opleggen wil meerderheid

Ik kan deze alinea samenvatten als: democratie werkt niet in Arabische wereld, ze zijn niet seculier en een dictatuur van de meerderheid. Helaas klopt dit voor een belangrijk deel. Wat dit echter precies bewijst over democratie in algemene zin is onduidelijk. Ik zou persoonlijk de hier bedoelde “democratieën” niet als democratie aanduiden. Dat komt waarschijnlijk omdat ik een democratisch bestel als meer zie dan het hebben van stemrecht.

5. Persoonlijke belangen

Ook deze kan weer kort: Berlusconi is evil, Bouterse is evil, en dat kan dankzij democratie.
Ook hier is weer de vraag wat de schrijver precies wil bewijzen. De weg van een dictatuur/overheersing naar een volwaardige democratie is lang en moeizaam. Dit zien we overal. Maar wat het (tijdelijk?) mislukken van individuele democratieën precies aan het volledige begrip afdoen is niet duidelijk. Wat het alternatief is waarbij dit niet mogelijk was geweest ook niet, ik zou persoonlijk inschatten dat dit probleem bij de andere historische staatsvormen makkelijker danwel de status-quo was.

6. Focus op kortetermijnwinst

Dit is een punt waarmee ik het zeer eens kan zijn. Dit is echter vooral een verantwoordelijkheid van ons allen die stemmen in deze democratie. De schrijver kijkt hier helaas niet naar hoe het opgelost kan worden, maar wederom alleen naar hoe de huidige vorm van democratie (nog?) geen gewenste resultaten geeft.

Optelsom

Nu komen we op het punt waarop de schrijver zijn voorgaande punten gaat optellen en ze volledig representatief voor alle vormen van democratie gaat verklaren. Echter die stap zet hij net niet. Zoals eerder moeten we het met een “onder ogen zien” tekst doen: Eerst klopt hij zichzelf op de borst dat hij de lijst tot 6 punten beperkt heeft. En dan noemt hij enkele tegenargumenten en zet deze zonder enige vorm van argumentatie weg als dom, naïef optimisme.

De alinea die hierop volgt toont eigenlijk de kern van het misverstand in één zin: “Democratie is middel geworden in plaats van doel!” roept onze schrijver vol ontzetting uit. Waarom het een doel is een waarom dat doel nagestreefd moet worden zet hij helaas niet uiteen. Ik denk dat dit is wat hij fundamenteel niet begrijpt: democratie is een middel en niet een doel. Doelen zijn zaken als vrede, welvaart, geluk en vrijheid. Democratie is een middel, het “minst slechte” middel om met Churchil te spreken, om zo dicht mogelijk bij die doelen te komen. Het is het nastreven waard om die doelen te bereiken.
De realisatie die daarbij hoort is dat middelen vrijwel altijd voor zowel goed als kwaad aan te wenden zijn. Dit is de realiteit waartegen de schrijver zich eigenlijk keert, blijkbaar in deze alinea plots hopende op een perfecte wereld waarin democratie perfect is en als doel nastreefbaar.

Het O-woord

Goed, we zijn er. We hebben de inleiding, de data en de conclusie gehad. Nu komen we bij de discussie van de resultaten. Wat is het vervolg dat de schrijver aan het voorgaande wil geven?

Hij begint weinig verrassend met wederom het representatief verklaren van Berlusconi en nu ook Putin als voorbeelden van democratie in werking. En legt terloops de subtitel uit: het “O-woord” is onregeerbaar. Dat wij in enkele jaren te weinig stabiliteit van regeringen gezien hebben is onmiskenbaar waar en zeker een discussie waard. Dus laten we eens kijken met welke oplossing hij komt…

Het moment waar ik het hele artikel op wachtte. Na alle uitvergrootte en algemeen verklaarde voorbeelden, na de niet opeenvolgende argumenten en de straw man tegenstanders ging hij met iets komen: een toets voordat je moet stemmen.
Ik was lichtelijk teleurgesteld.

Dan maar de echte conclusie van het stuk, of in ieder geval wat hij opschreef als laatste zinnen: “Iedereen maakt zich op dit moment zorgen over hoe het Westen uit de crisis zal komen. Het is zaak daarvoor niet alleen de beurzen in de gaten houden, maar ook de democratie.
Wederom iets waarmee ik het geheel eens kan zijn. Maar hoe hij denkt dat zijn stuk een representatief beeld gaf of iets constructiefs daaraan toevoegt is mij geheel niet helder.

Misschien is het dat het “benoemen van problemen” erg populair is. Je roept iets dat fout zit, maakt het groot en probeert er heel verstandig en wijs bij te kijken.
Dat er zaken fout zitten zijn we snel eens. Echter het begrip “democratie” verbinden aan alle mogelijke uitwassen helpt niet, dit versimpelt de discussie tot een punt waarop deze zinloos is.

Voor mijn conclusie keer ik graag terug naar iets dat ik eerder schreef: (parlementaire) democratie is een middel. Het is een middel waarmee je vrijheid kan bieden en kan garanderen. Waarmee een eerlijk en gelijkwaardig bestaan in een staat te controleren is. Het is een middel dat welvaart kan stimuleren en vrede kan bestendigen. Maar het is geen doel op zich, noch is het exclusief voor deze positieve doelen bruikbaar.
Daarom is het een middel dat we continu moeten bewaken voor misbruik. Waarin we moeten waarborgen dat er voor iedere kracht ook een tegenkracht is, zo zorgende voor evenwicht en representativiteit van instituties.
En daarbij hoort een echte discussie over wat democratie is, wat het doet en wat het bereikt. Een dicussie hoe we dit begrip, dit principe en dit middel implementeren. Of wat het alternatief is.

How packages changed the way I approach Application development

There’s many ways of approaching a new project. In the distant past I just started writing and everything was a bit of code on its own with includes for the shared dependencies. One might argue I was using something like MVC-pull, with Views being the main actors that pull in what they needed. Though I wouldn’t call it that as I wouldn’t have known what that meant back then.

Enter CodeIgniter and other frameworks. Instead of starting from the ground up I would hit the ground running. Once the framework was figured out “all” that was left was deciding on how to design the Application within the confines of the Framework. It works quite well, many common tasks are figured out already and you get a pretty complete toolbox right from the get-go. Allowing you to learn more techniques in a shorter amount of time.

This approach has been panned by those critical of monolithic frameworks for the same reason I used the word “confines” above: instead of an optimal solution you handicap your options before you even get started. In many situations this will still be a good bet though, if you know the framework well you’ll be able to develop quickly and satisfy customers for a good price. Maybe not the optimal solution from a code point-of-view, but it works and you are using a reliable base upon which to build.

But the landscape has changed. Instead of the monolithic frameworks of old we now get a choice of many highly decoupled ones. At the same time Composer arose to manage our external package dependencies for us. This allows one to easily pick and choose the best tools for the job. Of course some tools work better together than others, but the direction is clear and I only expect the options to get better with time.

For small projects I’ll keep using existing frameworks. But for larger applications that benefit from their own unique application structure I’ll pick HTTP and routing components that best fit my application design. Thus no longer going the wrong way around to fit my application into a framework’s structural design.

The initial investment is even comparable to that of working with the entirety of a framework: you always have to invest in understanding the inner working to get the most out of it. But now you can drop whatever you don’t like or agree with, in favor of something better. For a project I’m working on right I’m looking to Sf2′s HttpKernel with a Router & MVC structure I’ll write myself. Probably using Zend’s Form class, Twig for templating and Doctrine’s DBAL for database access. Though I might still switch to Frank’s Cabinet.
I’ll figure that out when I get to it. At the time I need it, instead of being bound to the big framework choice of old that bound you to their libraries for the entirety of a project.

One last thought on this: it also decreases your own dependency on the tools written by others. When you build your application on the libraries from multiple sources you won’t have to rewrite the entire application when one of those is no longer developed or gets a completely revamped new version. If you build it right you only have to swap out a single component instead of the whole.
It was you that build the application’s structure, which can remain the same and only needs changes to accomodate a new piece.

A fond farewell to FuelPHP

After having been actively involved in FuelPHP development for over 1.5 years I have decided to leave the framework. It has been a good run and a very educational experience. But open source development takes time and for the past 5 months I haven’t been able to find that time. As some will know, I spend a lot of time developing what I hoped would turn into FuelPHP version 2.0. While I feel very good about what came out of that I don’t see it becoming distinct enough from other offerings to be worthwhile. It’s been the basis for a few products of mine but I won’t do any more work on it (except for bugfixing).

Looking back to late 2010 I remember where I came from. Having been a CodeIgniter developer for over 3 years I had become disillusioned with the lack of progress and I wanted to start taking advantage of PHP 5.3. I had been hacking the core of CI for the last few months by that time and I knew it no longer had a future for me. But looking at Kohana, Cake and ZF1 I didn’t really see me getting into those.

At about the same time Dan Horrigan and Phil Sturgeon started out on their own little adventure named “Fuel”. Getting involved in discussions on IRC and providing the first Cache library I became something I had never planned on: a framework’s core developer. Harro Verton and Frank de Jonge soon joined to complete the team.

Developing Fuel’s first version (and renaming it to FuelPHP along the way) tought me more about PHP than much of the previous years combined. And, as is often the result of learning, I discovered I was doing it wrong. Well, “wrong” is of course a matter of opinion. But the static way was slowly going the way of the dinosaurs for me. Combined with growing a real appriciation for Unit Testing I decided to put all of that into practice.

During that time Dan had already started on what he wanted to become version 2. And in about the same way I had become a core developer, I ended up taking over the effort and leading the charge.
Developing and thinking about version 2 was possibly even more of an educational experience than version 1 had been. It grew to a state close to maturity in a matter of months, enough for me to start developing on top of it. But again I realized I had made some decissions along the way I no longer felt good about, and it really needs a rewrite to overcome those.

But if I did that, would it really offer something unique over the new frameworks like Symfony 2, ZF2 and others? The landscape has changed a lot since I left CodeIgniter, the offerings have become much more interesting. Combined with the quick rise of Composer one can now easily build his/her own toolbox from many sources without being tied to a single framework. An approach that was gaining my appreciation quickly.

At the same time the thoughts above were developing in my head I made a few choices in my life, among which was the way I do business. It left me no free time to work on Fuel and I started to drift away. In part because I had to work with CakePHP (which I dislike with a vengance), Joomla (which is the biggest pile of shit I’ve ever worked with), ZF2 (which I enjoy) and Symfony components (which I really liked).

All of this means my departure from FuelPHP has turned into little more than a foregone conclusion. But a conclusion I regret because of the worthwhile experience it has been and because of the responsibility I feel towards the community and especially Frank & Harro. A conclusion, nonetheless, which I cannot escape.
I wish FuelPHP all the best for the future and see the work Frank & Harro do with much appreciation. Having been part of this for the birth and growth I can tell from experience how much of one’s personal time goes into a product like Fuel. Appreciate the people who are willing to take on that task, contribute back whenever possible and treat them with the respect they so very much deserve.

Discrimantie namens de staat

De “weigerambtenaar”, een bizar begrip dat eigenlijk precies zegt wat het is: een ambtenaar die weigert zijn functie te vervullen. Die weigering is gebaseerd op een zelfverklaarde principiële overtuiging dat dit van de Bijbel niet mag, onder andere afkomstig uit een bijbelboek dat daarnaast ook grote aandacht besteedt aan de onreinheid van menstruatie - misschien dat daardoor vrouwen maar 60% de waarde hebben van een man. Deze principes wegen hen zo zwaar dat ze niet langer hun onafhankelijke taak als vertegenwoordiger van de staat kunnen vervullen: dat weigeren ze.

Eind vorig jaar leek dit dossier afgesloten te zijn met de motie Van Gent waar de PVV onverwacht vóór stemde. Het VVD-CDA kabinet wil deze motie echter niet uitvoeren en maakt van hun val gebruik om het nog maar even uit te stellen. Dit mooie wapenfeit liet het vertrekkende Groenlinks-kamerlid natuurlijk niet verloren gaan, dus komt er een nieuwe motie. Dit keer met nog meer steun omdat de VVD niet langer naar de pijpen van de SGP hoeft te dansen.
Daarmee is de discussie weer geopend, partijen als de SGP en Christenunie zien zich opeens als grote voorvechters van vrijheid.

Maar welke vrijheid gaat het hier dan eigenlijk precies om? Betreft dit een vrijheid van meningsuiting? Of gaat het om de vrijheid van godsdienst? (voor zover deze verschillen) Of is het dat zij die homoseksuelen als gelijkwaardig zien geen tolerantie opbrengen voor hen die een andere mening zijn toegedaan?

Laten we duidelijk zijn: de vrijheid van meningsuiting noch die van godsdienst is in het geding. Het staat de individuen vrij om deze mening te zijn toegedaan, deze te uiten en hun interpretatie van het geloof dat dit blijkbaar voorschrijft te belijden. Maar het gaat hier specifiek om mensen die in functie als trouwambtenaar een directe vertegenwoordiger zijn van de Nederlandse staat, op dat moment is hun verantwoordelijkheid groter dan die aan henzelf.

De verleiding is groot om vergelijkingen te maken met hoe tegen het stemrecht van vrouwen werd aangekeken, hoe over het volwaardig burgerschap van niet-blanken werd gediscussieerd en vooral hoe in het verleden ook beroep is gedaan op ‘geweten’ bij het trouwen van raciaal gemengde stellen. Dat wordt alleen maar verder onderstreept wanneer iemand als André Rouvoet met het argument komt dat dit nog maar 10 jaar wet is. Een dergelijk argument zal ongetwijfeld voor de SGP ook reden zijn om moeite te hebben met passief kiesrecht van vrouwen. 10 jaar of 100 jaar, wat is dat nou helemaal op 2000 jaar christelijke beschaving?

Waar het hier om draait is dat een ambtenaar in functie iemand is die het Koningkrijk der Nederlanden vertegenwoordigt naar het volk. Die verantwoordelijkheid is groot en weegt ongetwijfeld zwaar. Die verantwoordelijkheid betekent vooral dat er geen ruimte is om het onderscheid te maken tussen de persoon en de ambtenaar wanneer in functie. Het weigeren om deze functie voor een specifiek identificeerbare groep te vervullen is vrijwel de definitie van discriminatie (Van dale: “het maken van ongeoorloofd onderscheid“). Dat dit gedaan wordt vanuit de persoon en niet namens de staat is een moeizaam excuus.

Deze discriminatie is momenteel namelijk niet alleen de zaak van deze individuele weigeraars. Bij de invoering is besloten om alleen te eisen dat homo’s overal kunnen trouwen, niet om dit tot volwaardig deel van de functieomschrijving van iedere trouwambtenaar te maken. Hiermee is deze vorm van discriminatie dus eigenlijk geïnstitutionaliseerd: met het treffen van een specifieke maatregel voor de weigerambtenaar is hij een onderdeel geworden van onze rechtstaat.

De ruimte was begrijpelijk als overgangssituatie, emancipatie gaat immers zelden zonder slag of stoot. Maar zoals André Rouvoet ons herinnerde: er zijn inmiddels 10 jaar voorbij. Wordt het niet tijd dat we van onze ambtenaren vragen om hun functie uit te voeren?

Context matters

(originally posted on fuelphp.com)

This is the 3rd part in a series of blogs on the philosophical design choices behind FuelPHP 2.0. The earlier parts were on the biggest changes and on MVC in general.

Context is what gives meaning to otherwise meaningless or ambiguous statements. This holds true not only in language but in programming as well, or at least it should. Those of you who used HMVC may have run into problems in the earlier versions of FuelPHP when Views weren’t aware of their context. A statement in the View using Uri::segment() might have a different meaning depending on during which Request it was rendered, instead of the meaning it had when the View was created. This was caught and solved early on, but as explained in the earlier blogs, 2.0 will solve this in a more fundamental way.

What do you mean by ‘context’?

The concept of context is similar to Namespaces in PHP: the context (or namespace) gives meaning to particular statements (function/method calls). A call to a model Category may have a different meaning within a webshop and within a weblog. It probably broadly still refers to the same concept, but its context and contents are different. In most cases a category of webshop products (Webshop\\Model\\Category) will have different demands than a category of blogs (Weblog\\Model\\Category). The concept didn’t change (they might even share a base model they’re based on), but the context changed and asking for the category’s items will give wildly different returns.

Another (more basic) example was already given in the introduction. Because of the static interface of FuelPHP 1.x the static calls don’t have any context and thus their return was the same, no matter whether it was called from the main Request or the child of a child of a child request. This was solved by adding a concept of an active request that determined the context of such a call. This made Uri::segment() return something different while the main request was active from when the same call was made while a child request was active.

The next iteration of Fuel will solve this differently: as we’ll become more object oriented every View, Request, Application, etc. will be aware when it was created and/or to which context it belongs. These internal references will allow you to request information directly from a specific context. To illustrate this: when you make a call like $this->app->forge() from the controller you are telling the Controller’s Application to forge an object within it’s ‘context’. And when you call $this->app->env->forge() you are making the same call but to the greater context of the Application’s Environment.

At the same time we’ll keep the active request and introduce the active application references to allow static calls that are also context-aware. This is the ‘weaker’ solution of the 2, as it requires something akin to a global context – something that makes your applications much harder to unit test. (at the same time it will still use the internal references behind the scenes)

Types of context

Now we know what context is we need to define the types that are available during your application’s runtime. One might argue that each class is its own context and one would be right about that, so for clarity we’ll limit the discussion here to those types of context that have a greater importance within FuelPHP.

Environment

The environment consists of those settings, values and functionalities that are defined by the operating system, by the webserver and by PHP itself. These make up a context that should be considered static during at least each HTTP request (should not be changed after FuelPHP’s initialization). Locale and language are examples of this, changing those during runtime might give your output half one locale and the second half the other. The mess of which is obviously something you’d never want.

But also PHP core language concerns should be considered part of the environment. You can’t redefine a classname for example, thus if you’ve loaded a class once with a specific name you can’t load a class with the same name (note: the namespace is part of the classname). Functions, classnames, constants and variables are an important part of the context in which you code lives.

Application

Each application has its own configuration and specific concerns for that application. If you need multiple applications to interact with each other (possible as of 2.0) you need these to be completely separate. But it’s not just the configuration, you will also have utility classes and objects that need the configuration or keep track of your running application – those should live within it’s application context.

Request

The concept of a request in FuelPHP is similar to that of HTTP but not quite. In the 1.x branch each HMVC Request will have its own URI and may have some overwrites but essentially still lives within the same HTTP Request as the main Request does. As of 2.0 this will change and a Request will live within the same Application context as it’s parent Request, but it will also have it’s own context with completely different input variables.

How does this work

In the 1.x branch there is only a very limited Environment context, it consists mainly of a name that allows you to change some configs based on it. But most of its initializing happens in the Fuel class after loading the application main config. This means it is not only tied to the Application, but it is actually so intertwined with it that it cannot truly be seen as different. And when you want more than one application to exist (in runtime or otherwise) this will quickly get you into trouble, as the fixed truths of one application may differ wildly from those of another.

And as the environment should stay constant between Applications, so should the Application constant remain constant between Requests. As noted before, the 1.x branch makes too little difference between Requests. One possible problem with this is that one might want to use the same types of data retrieval for AJAX as one does from within PHP. The way to solve that is to make a Request from PHP that looks the same as a HTTP Request from JavaScript would look. Something that is hardly possible when the input variables cannot fully be controlled. This also exemplifies why the Application’s context should remain constant, otherwise the AJAX Request and the HMVC Request might still lead to wildly different results.

Context 2.0

FuelPHP 2.0 will introduce an Environment object and Application objects that wrap you application. These will maintain the types of contexts discussed here. This is also why Dependency Injection became a central part of 2.0. The Environment and Application objects each have their own object containers that maintain instances within the context to which they belong. But they also have their own forges  (factories) that determines the class to construct based on context.

All Applications one creates within the Environment object will retain a reference to this Environment for context. All Requests created with an Application will be aware of their Application context as well, and indirectly be aware of their Environment via the Application. And the same goes for each and every object instance created.

While 2.0 will still keep track of which Application and Request are currently running, it is no longer the way in which context is determined. The 1.x branch needed to reactivate a Request instance in order to provide the correct context when a View was rendered. In 2.0 the View has object references to its context and doesn’t need any environmental context changes to be able to render itself within the proper context. (FuelPHP will still track this and reactivate/deactive for Backwards Compatibility though, but it doesn’t need it)

In practice

One of the first places where this has already been put into practice has been Oil. Previously Oil was basicly a separate bit of logic, it used FuelPHP’s main parts of course but the application flow of it was completely separate from the logic in a normal request. There where a few downsides to this, for one we’d need to explain the logic of running an Oil task separate from the logic of running a normal HTTP request. Another was that Oil was fully dependant upon 1 application you created, and not really capable of switching between them. The new setup makes Oil a full application within its own right, which can interact with any other application or even package you choose. Because of the new context-awareness a command you give to Oil will be executed within the context of the app upon which you make Oil act, instead of within the context of Oil (another one of the downsides that lead to problems).

The way Oil does this is to instantiate another application by requesting it from the Environment. Then a request is made to that application to execute a request within its context and the result is returned. This will happen in full isolation and non-dependant upon Oil’s context:

// Load the application at 'fuel/example' (remember: applications are packages themselves)
$app = $env->loader->load_application('fuel/example');

// To request something from the other app, make a request upon it and get the response
$response = $app->request('migrate/up')->execute()->response();

The above is just an example but it shows how one might migrate a specific application from another (Oil for example). This would be done by tasks which are now specialized controllers instead of plain classes, this will make the same power available through the command line as you have in a normal request and allow you to work with multiple applications. Something that will be possible and reliable because of the improved context awareness.

MVC in (Fuel)PHP

(originally posted on fuelphp.com)

While developing FuelPHP 2.0 we took a critical look at all established web application concepts. Nothing was considered out-of-bounds, not even the most well known of all: Model-View-Controller.

When attempting to explain the concept of ViewModels within our framework I often get the question shot back “but what advantage does that have over a controller?” The problem this signifies isn’t that the ViewModel duplicates functionality, rather it’s a symptom of a fundamental misunderstanding of the Controller concept – indeed the whole MVC pattern.

Don’t feel bad if you are one of those people scratching your head over this, it’s a logical consequence of the common and widespread implementation in PHP and other web frameworks. But that’s not where MVC originates, the pattern was designed in the context of old fashioned PC applications. For this type of applications the environmental constraints are very different from those imposed on your web application by the HTTP protocol. And to understand this difference we have to start there.

The origins of MVC

The fundamentals are of course always the same: a seperation of concerns. You divide the logic between the concerns of your application (the controller), the data retrieval/manipulation (the model) and user interaction (the view). But the implications of this in a continous persistantly running application are very different from those on the web that need full request-response processing for each user interaction.

I have seen it argued that this very difference makes the MVC pattern unfit for the web, but I always felt that’s missing the point. The seperation of concerns is always a good idea, a principle more logically sound than MVC is hard to find. The problem however is that the common implementation of a controller and a view no longer fit their original concepts. And when you don’t separate the concept from the implementation, such a charge is actually more of a straw-man argument than an actual critisism.

The common implementation

With a display language (HTML, Javascript) that is different from the backend (PHP, Python, Ruby) some new hurdles need to be taken that were not a problem in the original implementations.

Views used to be entities that generated what was displayed and ran the user interaction. Not the actual actions that the interaction lead to, but it did make sure those interactions were routed to controllers that decide what to do with them. In PHP however the views were HTML, with which came the logical consequence that they are best kept logic-free. Otherwise you’d get an unreadable mix of HTML and PHP in a single file. Something you would expect a decent framework to prevent.

This however does create a problem: the View specific logic has no place anymore…

…and it is where the problem starts for Controllers. People tend to solve this problem by putting the display logic (that has little to do with running the application) into the controller instead. It prevents the unwanted mixture of HTML & PHP in the View, but creates a new mixture of application and view concerns in the Controller. Which completely breaks our original intend when implementing the MVC pattern: seperating concerns.

Another problem is that the concept of a Controller changed. A controller was meant to be a functional entity that handles the application flow and interacts with Models and Views. For the web the Controller was implemented as a class with methods that the routing might lead to. But in almost all cases this fundamentally changes the concept. No longer a single functional entity, but more a container for a set of entities. Entities that for most developers are not considered as smaller parts of a bigger whole. The routing ends up deciding which method is called and the controller has no say in this and is actually little more than a container label.

Which introduces the concept of routing in a web framework. Without the persistant state of a PC application we can’t couple a View interaction directly to a Controller call, it needs a new HTTP request to do that. And the new request runs completely isolated from the previous one. Routing adds a new layer of logic to this that takes the input and decides which controller will be used.

Ok… why does this matter?

Obviously these implementations were done for a reason and they are not bad in themselves. But the problem of an implementation that gets copied instead of the concept is that the concept and its intentions get lost. Which is what happened with MVC. Views became incapable of doing anything functional, and of the controller concept little more was left than buckets of loose sand.

Something new arose that shouldn’t really bear the MVC label anymore.

But things also started to get a little bit confusing. The Laravel framework for example introduced the concept of MVR (Model-View-Router) with routes that contained Closures instead of Controller class paths. The problem here is not the executable routes themselves, a fine concept we have implemented as well. The confusing part is the label, which implies that this is something new and different while it isn’t: An executable route is a functional entity that handles the application execution based on user interaction, also known as a Controller.

(note: this is not meant to be a dig at Laravel, it is just an example of how mixed up the terminology has become)

How does FuelPHP handle this?

In our current stable 1.x branch we handle Controllers pretty much like everyone else. Routing is done to methods (“actions”) and the Controller is little more than syntax. Closures/callbacks are also allowed and handled differently from Controller classes (implying they’re not controllers).

ViewModels are already a part of the solution. They are functional entities that handle the view logic and decide which “view” (HTML template) to call. This allows you to remove any view-specific concerns from your controllers. In our implementation, ViewModels are not really a new concept. They are in fact more of an implementation of what Views should be in MVC. Making the common PHP implementation (of view files containing HTML and variables) little more than another resource loaded by the ViewModel, just like a config or language file might be loaded.

In the current alpha of 2.0 we went back to the original concept even further. Routing is no longer a simple bit of string manipulation to translate an input URI to something that maps to a Controller’s classname. Instead, routing now always returns something executable, whether that is a Closure, a callback or… the common instance of a Controller class. This last part is handled by giving the Controllers a PHP magic method __invoke(). This will allow instances of the class to be called like a Closure.

The executable controller returned by routing gets passed an array of URI segments that may help it decide what to do. In the case of a controller class this will most likely be calling an ‘action’-method.

While this will be mostly philosophical to many users, with little practical implications, it is not trivial. Interpretation and implementation of concepts is important. And to keep the concept of MVC relevant and useful we should remember how the pattern was meant to be implemented, not just the implementations we learned first. This is part of our job while continuing to develop our framework, especially when working on a new version and re-evaluating concepts and implementation.

FuelPHP: Why the 2.0 changes?

(originally posted on fuelphp.com)

A question that has been asked many times about 2.0 is “why the big changes”, in this blog I will attempt to explain the choices made and place them in context. But let me also begin by saying that if there weren’t any big changes in it, it wouldn’t be a 2.0 version but just a 1.x version that got bumped beyond its station.

First to ease some of the fears: we will make a static interface available for 2.0 classes and a Legacy add-on that will almost completely mimic the 1.x usage. And for those classes that already work primarily with objects after forging them: little will change but for the way you forge them.

A bit of history

Fuel began when Dan broke with CodeIgniter because it had become stale in his, mine and many other minds. It’s codebase had been written originally for PHP4 and as they never took a leap and broke with the old base it was basicly still a PHP4 framework at the time (and even though they got the community involved to expand it, the architecture remains unchanged).

With the CodeIgniter experience and knowledge he started Fuel and was joined by Phil, myself, Harro and Frank. All of us came with backgrounds in an array of frameworks such as Ruby on Rails and Kohana, but mainly CodeIgniter. We had the desire to create a more modern framework, for PHP 5.3 taking on board some of the lessons learned by other frameworks.

I feel that with 1.0 and especially 1.1 this was a goal we reached. For me the framework allowed my applications to grow beyond what would have been possible in CI.

But as we improved we also took some baggage with us that stayed in one way or another. We got rid of the Singleton-like core class concept and implemented everything as static Multitons. Which is an improvement over CI, but still has the downside of a global scope. And this became at the same time our biggest boon (easy static syntax and instances available when required) and our biggest limitation (global scope).

The global scope gave as various problems when we started to think about where we wanted to take the framework next. But most of all it was very hard to unit test some of the most essential core classes. And the lack of unit tests has given us problems with each release that should have been easily preventable.

The next step

Some of the plans for 2.0 already entailed:

  • wrapper objects for applications (allowing multiple active applications in runtime)
  • wrapper object for the environment setup
  • input overwrites for each HMVC request
  • replacing the multitons with a Dependency Injection Container (DiC) behind the scenes

As you may conclude this means some new layers that give more context to your application than currently available. Right now each application is at the same time its environment and really doesn’t differ that much from the controller context. To get that to a level that allowed for nesting multiple application objects that live within an environment object, I had to eliminate pretty much all the global scope available. Which in the end came down to eliminating all static methods as all those broke context and could take an application context from global while working inside another.

When the essential core classes became ignorant of global so had everything else. Where 1.x had had essentially no inversion of control, 2.0 is suddenly using a DiC and setters all over the place. Where the global state had been binding things together in 1.x, the 2.0 code is held together by a beautiful object graph.

What does this mean?

The most important improvement is that it will be possible to test every class in full isolation, thus making unit testing much easier. Having the core fully unit tested will also be a requirement for the first 2.0 release.

Most of the core classes you use regularly won’t really change. Views will still be Views, Controllers are still the same thing and most of the current libraries will be ported over with little functional changes (except for those mentioned on the roadmap). But as you may have understood by now the big change is that the Core packages of 2.0 will no longer contain static classes. That doesn’t mean that the syntax is gone for everyone though, those of you who don’t mind a global state but do want the new and unit tested codebase will still be able to make the old calls on the new codebase using static calls. And of course nothing has to change either in your own classes, if they were static or if they aren’t fit for usage with a DiC: autoloading will still work as before and no code needs to be changed on that account.

But what will the new non-static syntax look like? Some of that is not yet clear, and we are still thinking about improving it. But one thing is for sure: any core class object always needs to come from somewhere, either as an Environment, Application or Request property or from the Application DiC. Classes like the Controller and ViewModels (renamed to Presenter in 2.0) will have references to the Application object that created them.

Here’s an example:

// 1.x / 2.0-legacy-enabled
$var = Input::post('var');
// 2.0
$input = $this->request->input;
$var = $input->post('var');

And for other things the difference is smaller:

// 1.x / 2.0-legacy-enabled
$val = Validation::forge();
$view = View::forge();
// 2.0
$val = $this->app->forge('Validation');
$view = $this->app->forge('View');

I know this looks like a step backwards to some of you, which is why we will keep the static interface alive. This might look somewhat like the CodeIgniter loader but is completely different. It acts just like the existing forge() methods in each class, pumping out instances to be used however you like.

We realize many of you fell in love with the simplicity of the mainly static auto-loaded class names. Where you can start working with a class by just talking directly to it without a loader, but there is also a significant downside to that. When it comes to unit testing there are two strategies called called “Stubbing” and “Mocking”, which involve faking a class to see what one class is passing to another. This is near-impossible to do if class A is talking to a static class B, as there is no way for us to “inject” a fake class B.

It also helps massively with HMVC, as Input::get() is global, but we want to have different input available so that HMVC requests emulate HTTP requests perfectly. Doing this allows developers to build up API-driven systems, then use HMVC to call that API, cutting out a HTTP request. But with the static usage the global query string of a controller could interfere with the HMVC request, causing all sorts of problems.

The static interface will continue to exist via a Static package and the Legacy add-on, but the purely OO usage is now the bread-and-butter of Fuel.

The bottom line

We are moving forward to become a better designed, unit tested and in general more flexible framework. For that it is necessary to break with some of the baggage that limits us in what is possible. At the same time we do not want to leave our 1.x users in the cold, which is why development of the Legacy package is a big and important part of the 2.0 development. But we did separate these to make both a clean break and at the same time be able to provide backwards compatibility.

A short note about the speed and memory usage resulting: at this point baseline 2.0 compared to 1.1-dev showed to be about the same speed (~7% slower on a Linux server, ~25% faster on Windows laptop) as wel as memory usage (<2% more on Linux, ~7% less on Windows). These are too early for any final conclusion on it, but are indicative of what is possible.

[late update march 13th: 2.0 is now about 7% faster and uses 8% less memory on Linux after some more optimizing]

Ik ben een Wetenschapsfundamentalist… en daar ben ik trots op

(origineel geplaatst op d66blog.nl/jelmer-schreuder)

Daar kwam hij weer eens langs. Altijd als de rechten van religieuzen en ongelovigen recht getrokken worden komen dit soort termen weer naar boven. “Secularisme” heet dat eigenlijk, maar dat wil een partij als de Christenunie ook graag als een vies woord af doen. Vannacht was het echter een koning onder scrabble-woorden: Wetenschapsfundamentalisme. In eerste instantie irriteerde dit “verwijt” van mevrouw Wiegman-van Meppelen Scheppink me, tot ik me realiseerde: Ik ben er een.

Ik laat de inleiding van de definitie van de wetenschap graag aan iemand met wat meer credits op dat vlak dan ikzelf:

Scientific method, although in its more refined forms it may seem complicated, is in essence remarkably simple. It consists in observing such facts as will enable the observer to discover general laws governing facts of the kind in question. The two stages, first of observation, and second of inference to a law, are both essential, and each is susceptible of almost indefinite refinement.
Bertrand Russell (zie pagina 1 van look inside op Amazon)

De wetenschappelijke methode betekent dat je hypothesen vaststelt op basis van onafhankelijk verifiëerbare feiten. Deze moeten de competitie aan met andere hypothesen en zijn ten aller tijden onderhevig aan controle en nieuwe inzichten. De wetenschappelijke methode is dus eigenlijk fundamenteel onfundamentalistisch.
Deze houdt namelijk dat niets houdbaar is wanneer een beter of meer objectief bewijs voor een andere hypothese vindbaar is.

Wetenschapsfundamentalisme lijkt dus niet alleen contradictio in terminis, dat is het ook.
Als geuzennaam voor fundamenteel onfundamentalisme vind ik het echter fantastisch. Laat ons dit “verwijt” oppakken.

Ik ben een wetenschapsfundamentalist, en daar ben ik trots op.

Netneutraliteit: de frontlinie tegen libertair evangelisme

(origineel geplaatst op d66blog.nl/jelmer-schreuder)

Komende week zal het er op aankomen, de kamer zal beslissen wat het woord netneutraliteit betekent in Nederland. Verrassend genoeg gaat het hierbij niet om controle vs vrijheid, kinder-porno bestrijding of zelfs copyright bescherming: de bottom line is vrije-markt vs vrije-markt, of zoals ik het in de titel verwoorde: liberalisme vs liberteins evangelisme. Het ideaal is de vrije markt, evolutie in de markt is het middel en vrijheid van keuze is het doel. De vraag is niet of of we concurrentie en vrije keuze voor de consument willen, maar of die echt bestaat in het voorstel van de andere partij. Netneutraliteit is hiermee voor even de frontlinie tussen de liberale stromingen. Onze vrijheid staat op het spel en het zal de PVV zijn die kiest tussen vrijheid voor de consument en vrijheid voor de telecomaanbieder.

Ik zal hier niet de gehele discussie over de basis van netneutraliteit doornemen, deze is eerder door Nu.nl, Bits of Freedom, Wikipedia en Webwereld (ook deze) reeds in volle glorie uitgewerkt.

Waar ik hier op in wil gaan zijn de reacties vanuit VVD hoek op kritiek op hun voorstel. Ik quote Afke Schaart (@afke1 op twitter):

  • Als het aan de pseudoliberalen van D66 ligt gaan de kosten voor data voor iedereen omhoog. En dan weer klagen dat ze omlaag moeten..” (twitter)
  • Als PVV oppositie steunt leidt dat tot flink meer kosten data abo’s. Als dat 25 Euro extra wordt is het “Geeltje van Geert” geboren!” (twitter)
  • Alleen Chili heeft prijsdifferentiatie verboden. Willen we dat voorbeeld volgen? Dat is funest voor ons investeringsklimaat.” (vvd.nl)
  • Nieuwe businessmodellen nl. helemaal nog niet bekend! Ik ken ze niet. Europese Commissie doet onderzoek, waarom nu al ingrijpen in de markt?” (twitter)
  • Het alternatief is dat de rekening van een relatief kleine groep ‘grootverbruikers’ terecht komt bij de grote massa. Ik vind dat niet eerlijk. Internet moet wel betaalbaar blijven.” (vvd.nl)

Laten we proberen te destilleren wat de hoofdargumenten zijn van de VVD in reactie op kritiek. Ik moet hierbij een beetje interpreteren aangezien mevrouw nergens direct uitlegt waarom de prijzen meer zouden stijgen bij de voorstellen van de andere partijen. Als ik hierbij iets weglaat of verkeerd interpreteer, sta ik open voor kritiek.

  1. Voorstel D66 laat geen differentiatie meer toe en daardoor gaat de prijs omhoog
  2. Iedereen betaalt mee aan “grootverbruikers”, het voorstel van de VVD maakt dit “eerlijker”
  3. De Europeese Commissie heeft nog niets besloten

Het derde punt is natuurlijk het meest vermakelijke. De euro-sceptische VVD die vaak de mond vol had over Brusselse invloed, zien hier nu een goed argument in voor uitstel (…en afstel?). Ik zou hier verder inhoudelijk zelf op in kunnen gaan, maar ik laat hierbij graag het woord aan Eurocommissaris en Vice-President van de Europeese Commissie Neelie Kroes (VVD):

  • Die verantwoordelijkheid ligt bij de landen zelf” (WebWereld)
  • Internetproviders zouden de toegang tot hun diensten of inhoud niet mogen beperken vanuit commerciële overwegingen. Het mag enkel voor de beveiliging of ter bestrijding van spam” (ZDnet.be)

Inmiddels is mevrouw Kroes zoals bekend een onderzoek gestart om te kijken wat vanuit Brussel mogelijk is. Wie de stukken hierover leest leert dat naming and shaming de voorlopige stategie lijkt te worden. Wat echter niet vergeten mag worden is dat Europa door de omvang altijd trager zal bewegen dan de nationale politiek, en waar men hier voor wil waken is dat de Europeese Commissie straks niet hoeft te reageren op de onwenselijke praktijk van een gefragmenteerd internet.

Daarnaast doet mevrouw Schaart alsof onze mobiele operatoren moeten concurreren met het buitenland. Echter iedere aanbieder die hier opereert concurreert slechts met andere aanbieders die hier opereren. De regels zouden onze aanbieders niet benadelen ten opzichte van het buitenland omdat iedere (buitenlandse of binnenlandse) aanbieder die hier haar diensten aanbiedt zich aan de zelfde regels moet houden. Als onze aanbieders het internet wel willen fragmenteren, in het buitenland staat niets hen in de weg om daar op die wijze te concurreren.

Maar laten wij ons nu richten op de hoofd argumenten 1 en 2.

1. Voorstel D66 laat geen differentiatie meer toe en daardoor gaat de prijs omhoog

Dit argument bestaat uit 2 onderdelen: het verbieden van differentiatie en de bewering dat de prijs dan omhoog gaat. In de simpele voorstelling van zaken die de VVD op dit punt bezigt, lijkt dit zelfs nog wel logisch: differentiatie bevordert concurrentie, minder differentiatie verlaagt dat en bij minder concurrentie gaan de prijzen omhoog. Dit argument loopt echter spaak op twee essentiële punten:

1. differentiatie blijft mogelijk op bandbreedte en dataverkeer,

2. dit is alleen waar als bij het tegenvoorstel geen andere problemen zijn.

Dit laatste komt neer op het volgende: mevrouw Schaart gaat er zonder bewijs of zelfs argumentatie vanuit dat de fragmentatie van het internet op basis van apps & websites niet tot hogere prijzen leidt.

Als ik straks moet bijbetalen voor WhatsApp en Facebook pakketten, zou ik snel meer kwijt kunnen zijn. Zeker als ik ook nog een YouTube pakket nodig heb om dat ook af en toe te mogen bezichtigen. En wie betaalt er dan voor mijn dataverkeer? Of moet ik eerst dataverkeer & snelheid inkopen en moet ik dan nog bijbetalen voor wat ik er mee doe? Of moet ik een YouTube pakket inkopen en betaal ik (als iemand die af en toe een filmpje kijkt) mee aan mensen die de hele dag niets anders doen? Of een combinatie van het voorgaande: koop bandbreedte in die ik niet mag gebruiken voor YouTube want daarvoor moet ik weer apart bandbreedte inkopen?

Het is nu duidelijk dat ik vermoed dat het meer gaat kosten in het voorstel van de VVD dan met het amendement Verhoeven cs.

2. Iedereen betaalt mee aan “grootverbruikers”, het voorstel van de VVD maakt dit “eerlijker”

Deze bewering van mevrouw Schaart is zo volledig onjuist, dat ik haast niet weet waar ik moet beginnen. Wat zij zegt is juist waar het voorstel van Kees Verhoeven ons beschermt en haar voorstel helemaal niets aan doet. In het voorstel van D66 neem je internet af als geheel, hoe je daar gebruik van maakt is aan jou en niet aan je provider. Als jij een beetje mail ophaalt en af en toe Nu.nl bezoekt neem je een kleine databundel en betaal je dus niet mee aan de “grootverbruikers” die de hele dag Youtuben. En als je een “grootverbruiker” bent dan koop je natuurlijk een grotere databundel.

In het voorstel van de VVD is juist geen aanmoediging voor dit soort “eerlijke” prijsdifferentiatie, het laten betalen voor specifieke websites zegt niets over het “grootverbruik”. Hier valt nog veel meer over te zeggen, bijvoorbeeld dat WhatsApp vrijwel geen dataverkeer genereert en ook Skype eigenlijk peanuts is. Echter het bovenstaande is de kern waar het om gaat, al die andere punten zijn slechts bijzaak.

Liberalisme of liberteins evangelisme

De droom van vrijheid in het liberalisme is simpel: concurrentie en keuze op een vrije markt. Liberteinen geloven dat er maar één oplossing is voor ieder probleem: dereguleren. Regels stellen is slecht en maakt de vrije markt kapot. Dergelijke ideeën zijn reeds vele malen achterhaald en ik zou er niet eens een economische crisis voor nodig hebben om daar tegenin te gaan.

Liberalisme draait om die vrije markt van ideeën, van geld, van goederen en gedachten. Liberalisme is een complex evenwicht tussen jouw vrijheid en de mijne, waar die van mij begint en waar die van jou eindigt bepaalt ons beide vrijheid. Wetgeving tegen monopolies, wetgeving tegen discriminatie en wetgeving als idee op zich laat zien dat om die vrijheid tussen jou en mij (of mij en KPN) ook regels nodig heeft. Deze regels beperken ons niet maar zorgen ervoor dat Ingrid van Engelshoven voorzitter kan zijn van D66 tegen de voorkeuren van de SGP en dat Microsoft het bestaan van Apple niet onmogelijk kan maken.

Natuurlijk schieten sommige regels te ver door en gaat het soms mis. Maar het is niet “pseudoliberaal” om de vrijheid van ideeën op het internet te handhaven ten koste van de vrijheid van Vodafone om mij geld te vragen voor WhatsApp. We worden ook niet zomaar Chili als we de kansen van de kleine ondernemers op internet veilig stellen door te voorkomen dat ik straks aan KPN moet betalen om de websites van mijn klanten mobiel bereikbaar te krijgen. In tegendeel zelfs: als slechts de grote jongens het kunnen betalen om op internet te zijn, komen we dichter bij de onvrije samenleving.

Het liberalisme is geen evangelie, het is een continue discussie tussen ons allen hoe wij onze vrijheid kunnen garanderen. Vereng die niet tot een “geeltje van Geert”, Chili of pseudo-wat-dan-ook. Voer deze op de inhoud, leg uit waarom je dingen vindt en roep niet zomaar “bij hullie wordt het duurder”.

Denk alsjeblieft nog even heel goed na voor je beslist of committeert.

Dat is mijn oproep, niet alleen aan mevrouw Schaart maar aan de gehele Tweede Kamer, als zij binnenkort bepalen of wij tot de eerste landen met echte internetvrijheid behoren of op dit gebied onze kans op een voorbeeldfunctie in de wereld laten schieten. Ooit hadden wij lef en legaliseerden wij het homo-huwelijk, gedoogden wij soft-drugs en maakten wij een einde aan uitzichtloos lijden.

Laat ons dat lef hervinden.

Voor de volledigheid: het amendement Verhoeven cs is mede ingediend door Martijn van Dam (PvdA), Sharon Gesthuizen (SP) en Bruno Braakhuis (GroenLinks). Jhim van Bemmel (PVV) heeft in eerste instantie steun toegezegd. Bits of Freedom heeft een aanmoediging/complimenteer pagina aangemaakt met hun contactgegevens.

Aan de andere kant kunt u de contact gegevens van Afke Schaart hier vinden als u haar deelgenoot wilt maken van uw (beschaafde!) afkeuring.