If Ubuntu/Canonical wants to modify the source code of a software package and get their patch upstream so they don't have to continuously carry it from version to version... they should be dealing with the direct upstream software and NOT Debian. Debian is not going to be a patch middleman between Ubuntu and an upstream software project.
If you are talking Debian produced software packages or packaging related changes that are distro specific... then it would be appropriate for Ubuntu to go through Debian.
So the claim that you can't see Ubuntu because they are go through Debian is just wrong. I don't think anyone from Ubuntu/Canonical nor Debian would claim that.
It is my understanding that LWN started doing this type of analysis on the Linux kernel some time ago, scripts that I believe GKH is using and has perhaps improved upon. I bring this up because LWN's findings have been exactly the same so far as I can tell. When Jon started publishing articles with his results I emailed asking why Ubuntu/Canonical and Debian didn't show up anywhere. If there was a flaw in the way he was gathering the data that was somehow excluding Ubuntu/Canonical and Debian... or if it was basically harder to identify them if some developers were using non-organizational email addresses. I believe Jon's answer was basically... no, I don't think I have a flaw and I don't think that their developers are being attributed to other catagories (like unknown or independent)... and that it just appears they do not contribute much to upstream kernel development. Now, I don't want to speak for Jon... so he can certainly clarify if he wants to. :)
Here is a clarification I want to make though... the blog posting protesting GKH's presentation says that his data is flawed and inaccurate with regards to Ubuntu/Canonical. It isn't that it is somehow flawed JUST toward them... but that it isn't perfect and is flawed in general. Measuring what he is trying to measure is quite difficult. Jon has pointed out near the beginning when he started reporting on the kernel... that there was no perfect way to measure... but that it was worth trying to measure even if flawed... and can certainly be improved over time. The methodology they use is the best they have been able to come up with.
I don't think adding meters like... how many patches per capita/employees... and is going to offer useful information... but if the consensus is to add such things, be my guest. It would probably be just as useful as adding patches as a percentage of userbase size.