Open Source Release Syncing

One problem that we’ve encountered with jQuery, and that I did not foresee by any stretch, was the difficulty in synchronizing releases with other projects and companies. Specifically, when certain projects need the latest copies of your code by a certain time in order to make it for inclusion.

There’s two classes of problems, as far as I’m concerned:

  • When a project is including a library for the benefit of its users (plugin authors, module developers, theme writers, etc.). Generally these deadlines are much more important. Having a release come out in time, to synchronize, could influence the next year of development in the project. Missing the deadline causes users to be stuck with old code and deprecated APIs.
  • When a site needs a copy of the library in order to meet an upcoming deadline. These can be easier to meet. Typically the issue here is a single, problematic, bug fix – or important API addition. Thankfully, it’s usually sufficient enough to just build a nightly for them, to get them started – it’s not always a requirement that they be using the final version of a release.

Broken down within those two categories there’s a degree of freedom: A site, or project, could be Free Software (and open source) or closed – and generally proprietary. How you choose to deal with each of those categories is completely up to you. For example, as an open source project yourself do you give more leverage to other open source projects in the hopes of future collaboration? or do you give more attention to corporate projects in the hopes of more eyeballs and potential donations?

At the jQuery project I’ve generally split our time indiscriminately but with a sleight bias towards Free Software. By biasing towards Free Software projects we’re able to get better mind share amongst developers – who are our key users. For example, getting jQuery support in Drupal was a major victory for us as it meant that all future Drupal module developers would be compelled to, at least, examine jQuery to see if it suits them well, or not. While there isn’t, necessarily, a financial reward to working closely with Free Software the eventual market control will be quite significant and useful for further leverage.

The actual synchronization process, itself, can be quite challenging. Frequently, only corporations tend to have rigid release schedules (which can be a good thing, as it gives you a tangible goal to work against). Whereas open source projects will have loose deadlines like “sometime within the next two weeks,” which are especially problematic. The only solution here is to become really good at communication. I wish I could say that I had some magical tool that made it easy, but that’s definitely not the case – and it’s only barely gotten easier with time.

The result of this whole process is that you end up having to keep really close tabs on your big-name users. This is why I constructed the jQuery Evangelism team. They work hard to ping our most influential users to make sure that we keep on top making them happy. Sometimes this means some level of tech support, bug triage, and even free consulting – but the end result is most-definitely worth it.

I want to take a look at some of the best partners that we’ve had for the jQuery project, in terms of pay-off, from the work that we’ve put towards on synchronizing our releases.

Drupal – Partnering with Drupal has been huge for us. They use jQuery all throughout their system and recommend it to all of their module and theme authors as the JavaScript authoring interface of choice. They were our first partner and we’ve learned a lot from working with them. It’s because of them that jQuery is dual-licensed under the MIT and GPL (they are a GPL-only shop). Because we were able to bend to help them we saw a huge increase in our user base. We’re in the process, right now, of synchronizing for their upcoming Drupal 6 release (and will be doing an extra jQuery 1.2.3 release for them, to help them out).

WordPress – This has been a, relatively, new partnership for us but we’re already starting to see some of the benefits. WordPress’ use of jQuery was gradual. At first they included it as an optional include for theme authors, then they migrated the admin interface to use jQuery, and then finally made jQuery the library of choice for plugin and theme developers. We haven’t done much, explicit, synchronization with them, yet, but this is definitely something that we should work on.

BBC – They recently redesigned their homepage to use jQuery and Interface. Unfortunately, we found out them too late and we weren’t able to help them (they had been having troubles with jQuery UI and were forced to revert to using the Interface plugin). This is a case where synchronization would’ve helped but will need serious improvement in the future.

Digg – They’ve been our most loyal, and dedicated, corporate partner. We’ve worked hard to resolve weird bugs, included specific features, and push new releases out to help their projects. In return they’ve redesigned the Digg homepage to use jQuery and use it in the Digg iPhone application. We have a great line of communication here, which has been excellent.

Google – Projects at Google, using jQuery, have started to pop up which has been really exciting for us. Coordination with them has been much more challenging as it’s generally on a team-by-team basis (most decisions as to which libraries should be used are done by the developers themselves rather than by the corporation). However we’ve had a lot of success in communicating with them on the jQuery developer mailing list and have received numerous bugs and patches, which has been quite helpful.

Adobe – This is one of our upcoming partners. We’ve been working with them to try and make sure that some of their upcoming releases go smoothly. This is a case where a corporation will be providing copies of jQuery for developers to use (a different use case for us, as this is typically coming from open source projects). We’ll be seeing a lot more from this partnership in the upcoming months, which will be exciting. They’ve been great about keeping communication open – conference calls, emails, and patches – a great partner.

Mozilla – This is probably our highest communication-level partner, for the simple fact that I work at Mozilla (which tends to get developers excited, when they know that they have someone whom they can ask questions of). Additionally, however, our relationship has gone well beyond that – including the integration of our test suite into Mozilla’s test suite. I’ve also worked hard to make sure that the release of Firefox 3 would go as smoothly as possible with jQuery. Obviously this is one of our most fruitful partnerships – playing on both teams will have that effect.

In the end, the synchronization of releases is an interesting problem. It’s, generally, un-related to the actual code of an open source project but instead completely hooked to its process. I feel like a lot of projects leave administration and process by the wayside, and for that tend to suffer in the long run. It’s a lot of hard work but the benefit that you’ll receive, through your successful partnerships, is just too strong to ignore.

Posted: January 25th, 2008


Subscribe for email updates

21 Comments (Show Comments)



Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.


Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig

Infrequent, short, updates and links.