Unlike other companies, we don't jump in to upstream projects and throw weight around to influence a project to make it more marketable for us. Kubernetes has a vibrant, and powerful core contributor base already. When it makes sense, for any changes we make, we'll be happy to package those back upstream. Primarily, our contributions to Kubernetes is around operations. What happens 1 week, 1 month, 1 year after setting up a cluster.

GKE is great, but GKE is Google only. It's not on-prem, it's not cross cloud, and it's not portable. That's important to some people. Our contributions to cluster/juju is the distillation of our operational knowledge in running Kubernetes everywhere. The same upstream k8s, deployed with the same tooling, everywhere.

Not all value can be measured in commits :)

The way you start this off is a pretty poor response to my original question, whereas the rest is fantastic. It isn't about throwing one's weight around or even making it more marketable, but about improving the product for new use cases (such as Apprenda wanting to better Kubernetes via the on-premise sig).

Thanks for your response, I was curious as to the value add and this helps.

Thanks for the feedback, my original sentence may have been a bit hasty, but the core of the message is there. I see Canonical's role as the expediter/server in a kitchen instead of donning another chef hat when dish are piling up to go out. We want to celebrate and get the amazing work of the community into as many hands as possible.

We participate in SIGs as well, sig-on-premise being one we co-chair and co-founded. We've planning on helping the project in ways other than code contributions.

Sorry I meant even Apprenda has actual golang feature commits. That was my point Re: Apprenda and contributions.

This seems to be Canonical's general direction. It just makes me sad that is is more on marketing than engineering. I wish it was more of both as clearly Canonical does Linux + marketing better than basically anyone or there wouldn't be so much Ubuntu everywhere :)

We're participating in the on-prem sig now that it's been acked, along with Apprenda, CoreOS, Mirantis, and I'm sure some others.

In defense of Canonical, it's preferable that an organization leave the code alone rather than influence it for their own benefit. If Canonical is able to offer a useful embellishment upon k8s without changing much k8s code, good for them. (I have no stake in this personally, though I am still a bit spiteful toward Canonical over Unity :p )

Operational ease of use and distribution is our contribution, and we've only just recently joined the Kubernetes community, but as pointed out we see our role value as getting Kubernetes into as many hands as easy and quickly as possible.

EDIT: My first response might of come off as rude, so I fixed it.

That's fair, your response seems reasonable, and Canonical has done an excellent amount of this. Setting up kubernetes is hard, but should be surmountable by anyone wanting to seriously use it. Fixing it when it breaks, or figuring out how to run apps when there are issues is what is hard. Perhaps I rely too much on core engineers to fix those issues when it happens and discounted the value add proposition of Canonical on this.

Thanks for the excellent response!

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.