> Perhaps we could have contributed code to an existing library to add support for the older browsers our users had? Many of the libraries had previously supported some of our "problem" browsers, and actively chosen to drop that support.

That's correct - jQuery use to have support for IE 5.5 and Safari 1.3 but support for both were dropped after 1) No significant number of users supported either of those browsers and 2) There were no longer any extra resources to dedicate to supporting them.

> We felt it was unlikely they would be enthused about bringing back old browsers they were probably glad to see the back of!

There would've only been one way to find out: To ask! The BBC was a big user of jQuery back in 2007 and we would've bent over backwards to make sure everyone was happy - especially if they were (apparently) willing to contribute code/patches to help solve existing problems.

Unfortunately we didn't find out until the Glow efforts had already been started - it's just water under the bridge at this point.

It's ok though. The BBC is happy with their set up (which is really all that any organization should look for in a library) and we've all learned a lot since then. C'est la vie.

Or maybe you wouldn't. I guess it all depends. If you happened to decide the BBC's goals were becoming contradictory to your own then who knows which way you'd bend? The point is YOU would be in a position to say yes or no to their needs, and no offense but to tell a very large company like the BBC, "trust me, I'll make sure you're happy, now build all your web pages on top of my library" is not particularly reassuring.

And I don't think anyone has to be a mindreader to know what you'd say if they submitted a patch that meant you'd have to lose some of the selectors you now support and run more slowly in order to add support for a browser with 1.5% market share.

They looked into it and determined it wasn't cost effective to maintain a parallel fork. Okay, whatever. Their needs are unique and they came up with a unique solution, so what? This isn't a zero sum game.

> C'est la vie.

Indeed. For organizations that don't have to give full support to the same minority browsers that the BBC does, then of course it makes sense to use an off-the-shelf library like JQuery. No one ever suggested otherwise.

At the point you felt it wasn't working out, you could simply fork it.

> it wasn't cost effective to maintain a parallel fork

But it's cost effective to write a new library from scratch. Err, right.

Who says we are ?

No everyone within the organisation agrees that Glow is wanted or was even needed. Certainly not everyone is happy with how this has come about.

NOT TRUE, if you know how to write plugins. Using some basic knowledge of Javascript (closures, scope, etc) this is very easy to remedy. The problem is that many are too lazy to avoid using the "$" alias, so plugins are often written to depend on it. If you take your "lazy" plugin and wrap in a closure, you can be sure that it will work even when jQuery.noConflict is called... yes, i can hear it now "but when true is passed to noConflict, even the global JQuery variable gets reassigned..." So? Read the source. It gets reassigned very predictably to _jQuery. So, write your plugins like this if you need to support cases where jQuery.noConflict(true) is called:

(function($) {

$.fn.lazyPlugin = function(opt) { // ... }

})(jQuery || _jQuery);