While I’m not specifically opposed to this, you have to be careful about the edge cases and how they end up being rated. SQLite is a great example for the variables you started with:
> Size of team
3, with no outside contributions accepted into the core.
> The language
C
Those two, presumably, would end up being heavily weighted towards having a low score.
> Testing methodology
Here they’d probably get some points back based on their ~10:1 test lines vs code ratio.
Just because the kidz doan' like it, does not mean it's bad.
1 is the loneliest number (have to be an old fart to get that), but big teams can be a problem (Camel is a horse designed by committee). I'd say the experience and track record of the principals are a big factor (see "Linux" and "Git").
i think you have it backwards. giant teams == big risks, esp. if there isn`t strict and formal processes to eval the new contributors
3 people are easy to evaluate, have been on the project forever, and presumably know what they`re doing.
C shouldn`t be a problem per se -- again, it`s been around a lot, and while it makes it easy to bork pointers, it`s not a meme language that we don`t know much about
> Size of team
3, with no outside contributions accepted into the core.
> The language
C
Those two, presumably, would end up being heavily weighted towards having a low score.
> Testing methodology
Here they’d probably get some points back based on their ~10:1 test lines vs code ratio.