Why the fork does the BBC need its own jQuery?

Of course it’s good news that the BBC’s in-house Javascript library, Glow has been released as open source. It’s a very respectable chunk of code, with some quite nice built-in widgetry. But why on earth should the BBC have its own Javascript library in the first place? Its ‘lead product manager’ – itself a worrying job title – justifies its existence as follows:

The simple answer can be found in our Browser Support Standards. These standards define the levels of support for the various browsers and devices used to access bbc.co.uk: some JavaScript libraries may conform to these standards, but many do not, and those that do may change their policies in the future. Given this fact, we decided that the only way to ensure a consistent experience for our audiences was to develop a library specifically designed to meet these standards.

They’re clearly sensitive to this question, as there’s a whole section about it on the Glow website itself, specifically referencing my own current favourite, jQuery. ‘On reviewing the major libraries we found that none met our standards and guidelines, with browser support in particular being a major issue,’ they explain.
So why not contribute to something like jQuery, to make up for its deficiencies? Isn’t that the whole point of open source? ‘Many of the libraries had previously supported some of our “problem” browsers, and actively chosen to drop that support… Forking an existing library to add the necessary browser support was another option, and one that might have had short term benefits. However, as our fork inevitably drifted apart from the parent project we would be left with increasing work to maintain feature parity, or risk confusing developers using our library.’
I’ve written here in the past in praise of the BBC’s browser standards policy, and I stand by that. But I’m afraid I’m not buying this defence of their decision to reinvent the wheel – and, it must be noted, ending up with results remarkably close to jQuery. The best argument seems to be the risk that libraries which currently meet their standards might not in the future; or that they might have to do work to keep a fork in sync. And even if that should happen, the worst case scenario is that they’d have to churn out a load of new Javascript. Which is what they’ve chosen to do anyway.
Plus, crucially, this isn’t about a bunch of geeks directing their spare-time volunteering efforts in one direction, rather than another. These are people being paid real money, taxpayers’ money, to do this, at a time when the BBC is supposed to be trimming its ambitions. If they’re at a loose end, perhaps they might want to address the News homepage’s 416 HTML validation errors, and abandon the ‘table’ markup.

5 thoughts on “Why the fork does the BBC need its own jQuery?”

  1. As I read your post I was thinking that maybe the Beeb’s decision to create their own library was to include support for the myriad mobile devices they need to serve to. But section 1.1 of the Browser Support Standards v3.4 states that “[this standard] does not cover PDAs, mobiles, and other mobile devices”.
    It’d be really nice to see a major player with real money behind it contribute to an open source project.

  2. You answered your own question: “the worst case scenario is that they’d have to churn out a load of new Javascript. Which is what they’ve chosen to do anyway.”
    But putting it that way sounds like it’s an even proposition should they want to proactively protect themselves from a possible “worst case scenario,” this in spite of the other issues that make controlling your own framework at a Very Large Corporation (like oh say Google or Yahoo?) a good choice, as was already discussed recently here http://news.ycombinator.com/item?id=696623 and here http://news.ycombinator.com/item?id=694380 .
    And wouldn’t the folks at [insert any other framework here] question why the “people being paid real money, taxpayers’ money” at the BBC were spending their working days contributing to jQuery and not [insert any other framework here]? As it is now all frameworks can freely take or contribute to Glow under the Apache 2 license. To me that’s the important point here.

  3. Hi Simon – please don’t be worried by my corporate sounding job title, I’m really just a developer at heart.
    I can assure you that we thought long and about the issues you raise before going ahead with Glow, and we’ve had plenty of healthy debate internally along exactly the same lines.
    A few things helped tipped the balance in favour of developing Glow, some of which I’ll summarise quickly.
    1. Glow is an evolution of several older libraries that we have developed over many years, it’s not that we sat down one day and said “hey, why don’t we build a JavaScript library, that’d be fun”. We’ve been building libraries for our own use for years, this is not a new thing for us, it’s just the first one we’ve open sourced.
    2. Continuing to develop our own library means that we have complete understanding of the software, there are no “black boxes” which we cannot open.
    3. This means the core development team is able to provide a valuable internal support role for the other developers around the BBC. We are able to give help and training to other teams, ensuring they know exactly how to use the library (and JavaScript generally) in the most efficient way. Open source communities are great, we’re not knocking them, but they are not always able to respond with the speed and level of detail that as an organisation we require.
    4. Creating the library ourselves means we have been able to ensure it contains exactly the features that our business requires. Even if we did adopt another library, we would most likely still need to create the specific widgets and other bespoke features we need on top.
    5. Controlling the release schedule also means we have been able to make prompt updates with bug fixes as and when required, without needing to wait for agreement from external project owners. This is crucial to maintaining the level of quality our audience deserves.
    These sorts of issues (along with browser support, the cost of maintaining forks, etc) all contributed to our decision to keep JavaScript library development in house. It was not a simple decision, but one I am happy with.
    Finally, please note that we are far from closed to adopting open source solutions in the future, where it makes sense. For example, we are strongly considering using John Resig’s Sizzle CSS selector engine in the next major version of Glow. This would be relatively easy to integrate, solve a discrete task very well, and we would donate back any code that helped keep it in line with our browser support requirements. If it saves money and helps maintain quality, bring it on.
    All the best,

  4. Thanks for the response, Steve. As I said in the post, it’s clear you’ve considered the options – and good on you for that. But I can’t help feeling the resulting decision is a classic case of a large organisation being inevitably inwardly focused. That doesn’t necessarily make it the wrong decision; but to me, it feels counter to the way the prevailing wind is blowing in the industry generally. That said, if you see immediate benefits, and feel it gives you valuable safeguards, who am I to condemn it?

  5. Seems to me that the bigger you are, the more you need to think about it before pinning yourself to something like jQuery (or anything, really). It’s pretty easy to change a small bit of code from one framework to another should it become necessary to do so. If your site is short-lived, you won’t ever have to worry about it. But the BBC ? Big decision.
    You described it as your ‘current favourite’ which sums up the situation pretty well ! How sure are you that it’ll be your favourite in 5 years ?
    I saw their hand-rolled CMS about 10 years ago, as they decided nothing in the marketplace met their requirement. Pretty good it was too – and probably a decision they didn’t regret.

Comments are closed.