Experts and open source

Posted by Jim Jagielski on Monday, October 1. 2007 in Programming

Now that Ben and Rod's blog-oriented discussion regarding open source support is over, it's a perfect opportunity for me to add my 2 cents. This isn't in response to either of their PoVs, or their companies, but rather my take on the whole topic. First of all, I agree with the point that one can be an an expert on a software package without being a committer on that project (although it certainly does help). What is a danger, of course, is when someone or some company claims to be "expert" in a codebase, when they are no such thing, basing their claim on the assumption that, well, since they have access to the source code, they can suss through the code and find and fix any bugs, which is what you need an "expert" for anyone. Access to the source does not create expertise, nor does expertise in one codebase automatically imply expertise in others.The best way to illustrate that, I think, is via Ben's auto mechanic anology. Certainly, if I have a Toyota and it's having trouble, going to a verified Toyota mechanic is a safe course of action. But even if I have a Ford, I'd still feel pretty comfortable doing that, since, when all is said and done, the similarities between the designs of the cars are so close that expertise in one pretty much translates well to expertise in the other. But this is not the case in software. The differences between software codebases are staggering. It would be like calling your auto mechanic when your refrigerator or dishwater went on the blink. After all, they are both mechanical devices, right? I can only think of a small number of cases where that would even remotely be acceptable. I guess if you had time to wait, you could handle the downtime involved with someone reading the code and getting at least somewhat up to speed on it before they can even start debugging the issue at hand. But certainly not in production environments. And enterprise customers, with production environments, need agressive SLAs and require and deserve that demonstrated expertise. In open source support, it's depth which is critical and key, not breadth.

Page 1 of 1, totaling 1 entries


Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!