SRE is a job function. By design, it's intended to be equivalent in pay and status with developers (SWE) to overcome the bias against operators and sysadmins in organizations. This is an important recognition because cloud-first operations requires a lot of automation and coding expertise that previous operations roles did not demand.
DevOps is really a process definition with Lean system thinking and code workflow priorities. Many people will tell you that it is NOT a job function but a culture or approach. DevOps for developers generally means CI/CD pipelines and owning code into production. DevOps for operators generally means building configuration automation and integrated monitoring tools. In this was, DevOps highly complementary of the SRE job function.
I've been writing a lot about this on my personal (robhirschfeld.com) and company (rackn.com/sre) blogs. I'd be happy to discuss this in more detail here.
Looking at commits to the code base alone is a risky way to judge engagement. It would be like saying you cannot use AWS unless you contribute to the code. We saw the same false logic in the OpenStack community that drive a lot of marginal activity into the code base instead of demanding operability.
We really want these projects to have vibrant ecosystems. Canonical (and others) is contributing to that and helping users build solutions based on the existing code base. Adding features is great. Adding users is equally important.