We are looking for software engineers who are excited about containers, and container orchestration with Kubernetes. Who also have a passion for building DevOps tools that make it easier for people to build, deploy and scale their software on the Azure cloud.
Experience with container runtimes such as Docker, Rkt, runC, containers and how they are enabled by the underlying OS components.
* Experience with workload/container orchestration using Kubernetes or similar platforms.
* Experience with Golang.
* Experience with Linux.
* Experience with terraform or ansible.
* Experience with building, shipping and operating reliable, distributed solutions.
* Ability to engage in site-reliability engineering practices.
We are looking for software engineers who are excited about containers, and container orchestration with Kubernetes. Who also have a passion for building DevOps tools that make it easier for people to build, deploy and scale their software on the Azure cloud.
Experience with container runtimes such as Docker, Rkt, runC, containers and how they are enabled by the underlying OS components.
* Experience with workload/container orchestration using Kubernetes or similar platforms.
* Experience with Golang.
* Experience with Linux.
* Experience with terraform or ansible.
* Experience with building, shipping and operating reliable, distributed solutions.
* Ability to engage in site-reliability engineering practices.
Sure, that’s a valid concern. I think there are some other aspects of projects to consider than only the the org vs individual distinction though.
For example, I first wrote about nginx-proxy and docker-gen 4 years ago (http://jasonwilder.com/blog/2014/03/25/automated-nginx-rever...). Since then, both projects have gone through continued releases with bug fixes, updates and new features. Between the two projects, there are about 110 different contributors and I am no longer the top contributor on one of them.
The projects are MIT licensed and free to be forked or maintained independently if neeeded.
There’s a large community of users that write blogs, help with issues, and even create derivative works inspired or derived from the project.
Finally, I’d add that a lot of orgs behind projects are really just an individual that wants to make a useful closed source project open for others. The org or company name attached doesn’t necessarily mean a company is going to support it any better than a dedicated individual or community that cares about it.