I don’t mind when software fails

I wrote this post about the Roller upgrade to blogs.sun.com thinking all would be as painless as previous upgrades (blogs.sun.com has been running all versions of Roller starting with pre-1.0). But I actually had a hard time pushing it out because of some timezone bug which I couldn’t really understand. Hours (minutes?) after the upgrade I noticed this and pinged the engineering team who responded really quickly with a fix. Unfortunately, the patch didn’t fix all the problems I was seeing, so I had to do some more testing to provide a better test case. Eventually, less than 48 hours later (and much other things done) the service was fixed.

Granted I was talking to the people that both operate the service and write the code (blogs.sun.com serves as a beta tester). It’s certainly not like having full support starting from level 0 and walking you through the entire process. You do have to go through due diligence before you ask (which is actually good – how many times did you find the answer yourself because you actually spent the time writing the question in plain text?). Looking back on this I’m really not upset with the whole issue (although I use the service to carry out my daily job) because it was solved in a timely and professional manner.

I could have looked at the source code (I’ve done that previously) but I couldn’t seriously afford to spend possibly a day diving into unknown code (last I looked at it is must have been version 1.0). Having someone who knows the codebase just helps you solve the issue in a fraction of the time. Of course if I had no one to turn to, I would have been glad I had the source.

So it’s not about having software that never fails, it’s really about what you’ve planned you could do when it does. And with Open Source just like with any other software, support matters.

Author: alexismp

Google Developer Relations in Paris.