Strong opinions, weakly held

Practical open source

Tim Bray on answering questions about Android for developers:

Quite a few of the developers who walked up haven’t learned about Practical Open Source; that you can answer an immense number of questions by just downloading the system source code and plowing through it.

One of my standard two part interview questions of late is, “When is the last time you solved a problem by looking at the source code for a library or framework you use?” and then getting them to explain what they found out. I consider it a strong warning sign when a developer doesn’t bother to download the source to the open source tools they use or isn’t willing or able to answer their own questions by reading the source code.


  1. Yesbut, if there’s inadequate documentation or no fora for addressing questions, it’s usually a good indicator of source code that is similarly impenetrable to understanding (ie. lack of clear structure and commenting). Reading the source code is a last resort (though I generally do it before posting to a mailing list or forum).

    That’s like trying to fix an engine by taking it apart first.

    Also, if there are bugs in the source, and no documentation to go by (or specification), you end up writing to the buggy code, as opposed to getting stuff fixed. Then when the API is fixed, you have to fix your stuff all over again.

  2. @Jason!

    Then, I think the next interview question becomes, “What was the last framework bug you submitted a patch for?”

  3. Well, then we start to blur the line between library user and library developer. It’s quite possible that all library users aren’t going to be developers (through either needing to spend time doing their actual job, or through legal entanglements preventing them from contributing).

    I know that’s kind of an “old corporate” mindset, I suppose; but I guess I have a hard time imagining a “how did you fix something that wasn’t even your product” kind of questions. Usually we call the vendors and tell them to fix their stuff, but my field doesn’t use a lot of Open Source.

    To be fair, the article linked goes into great detail about all the awesome documentation Android has, and indeed it’s in the big G’s best interests to have that there for people. My point was that I personally start groping through the source as a last resort (and that gives me the impression that I’ve already been failed by the developer to have it come to this), but other people may do it differently.

  4. I’m with you.

    In my view, reading the source is after I try and use the package documentation. Many times, if I’m trying to find a viable option for something, I try for the best documentation and API first. While I have gone to the source before, for most situations I run into, my needs are usually better served by trying another library. The last couple of times I’ve dive into reading Gem or CPAN module, it’s been because my options are limited or, as happened to me in the fall, finding out why an existing module is performing poorly.

Leave a Reply

Your email address will not be published.


© 2022 rc3.org

Theme by Anders NorenUp ↑