It's tremendous that (as far as I can tell) this has all been architected and developed internally at the BBC. So refreshing in the current climate of public entities outsourcing everything. Much better value for money - and more to the point demonstrates that complex projects can be successfully completed internally.

The generation/serving of the pages is a triviality compared to the delivery of the video. In the past the BBC used to serve all video in house but now they just use the "big three" CDN providers.

I think some of the infrastructure maintenance (and maybe general development too) is outsourced. About a year ago I was on a service management training course in London along with some Siemens staff who were working on the iPlayer project.

Siemens took over the BBC's R+D depts as part of the outsourcing deal which means they now run pretty much all the technical services.

BBC outsources to Siemens,

This includes handing over all it's unique skills

Siemens, then bills the BBC for stuff it already knew how to do.

Management demonstrates with many Powerpoints how this is saving everybody money.

When I worked a summer in a management consultancy we produced powerpoints for the BBC showing that it was a waste of money.

but don't let that trouble you.

Ah yes of course Siemens. They who provided the BBC's £2bn phone network - which apparently barely functions.

I'd be interested to hear why they chose PHP. (It's not exactly the framework-du-jour, so they must have positively chosen it).

Also, it seems to me that the web page serving would be the most trivial part of iPlayer. Scaling the video and recommendation database is probably a more interesting topic.

Shocking to hear that someone has chosen a tool based on its merits rather than how fashionable it is...

Indeed. That's why I was asking for what reasons they chose PHP, i.e. what do they perceive it's merits to be.

Exactly the way I felt!

You might want to read aboout how web infrastructure works at the BBC: http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fail...

I'd point out that the "perl+SSI" codebase was actually mod_perl, Catalyst, DBIx::Class etc. using SSI as a sort of primitive ESI replacement to ease caching of partial pages.

The strange politics that led to the perl on rails monstrosity apparently aren't universal.

One reason might be the ability to hire quality developers in sufficient numbers. The BBC is big, with developers (both internal BBC and external contracts) working all over the UK on a wide range of output.

That's what I was thinking. Ruby, Perl and Python are all fine alternatives if you can find people with those skills.

... or train them.

and any good developer can pick up and be proficient in PHP quickly

which is in my opinion PHP's greatest strength and greatest weakness. Weakness because not-so-good developers think they are good while writing code using register globals, no input validation, no escaping output, etc..

It's possible that somebody higher up with an enterprisey mindset just signed a deal with Zend. Including paid support and whatnot.

Ironic that this returned the following error when I tried to read it: "Error 500 - Internal Error. This might be because: We are experiencing abnormal traffic to our network." :-)

I'm thankful that they shared their analysis. Does it really detract from their work that they used Excel to graph it?