I think the article is technically referring to traits commonly found in project leads in open-source. As opposed to, people who make only occasional, minor contributions to well-established projects, or just toss up random code snippets on a blog, never to be updated again.

I am not at all criticizing the value of these other forms of contributions to open-source. But I am skeptical that an interviewer could draw useful conclusions when reviewing someone's open-source contributions if they are minor. To examine the points of the article:

1. "Knowing how well they write code": If they aren't a chief maintainer of a project, it's not really that easy to tell which random contributions are theirs. You need some fairly large and organized example, for this to be a practical review.

2. "Knowing how to patch": I don't think the vast majority of projects have to deal with this situation. So while it is useful experience, it doesn't seem more likely that someone in the open-source world would have that experience.

3. "Passion": Again, most people aren't going to be deeply passionate about contributing 1 or 2 pages of code to a 10-year-old project that has thousands of revisions. The people who will be passionate are the ones who wrote the thing from scratch and are improving it to this day.

4. "Support": This is actually a paradoxical case, where the people merely using open-source software (and having never seen the code) may be more qualified to support software over time, than the developers. This is because developers spend their time, well, developing, and would be overwhelmed if significant time was just support. Plus, see #3, how many people would be passionate about a project that is a support burden?

5. "Saving money": This is more a reason to use open-source software, than a reason to hire any particular person because of their open-source experience.