Actually, they are NOT entitled to dividends. That's part of the myth, and is covered in the book. You should give it a read. The author covers some historical cases which are often misinterpreted, and lead to the confusion. In the case of dividends entitlement, the case you're drawing from is https://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Co.
She's a lawyer and professor in precisely this area. You could read the wikipedia article, and try to confirm your bias. Or, you can read the book, written by an expert, and broaden your perspective.
Sup Jorge! You named the big ones. There are a bunch of others, as well. IMO, try to get your comparison down to just two. That's a reasonable set to dive deep on.
For a lighter overview, I think the big features are: team workflow, security, and CI/CD pipeline.
Team workflow is just how easy it is to get going / share with your team. IMO, ECR or GCR will have a natural edge here if you're already on their cloud. Tagging is important too, but I think everyone supports that.
Security is both the details of transport (SSL, etc), and whether your containers are getting scanned. Quay.io and Docker Hub both do security scanning for private repos. Quay has a slight edge in that public repos also get scanned thanks to Clair. I believe GCR and ECR lag behind here.
CI/CD pipeline is important because your registry becomes a big chunk of your build. This is what's going to really take time to investigate and dig into. You want to make sure it's easy to add hooks to git or w/e, and troubleshoot build issues (good logging, auditing, etc).
Full disclosure I work at CoreOS and with the Quay folks. That said, I also think they're constantly probing into cool frontiers. I think Clair changed registry security. The team's also started doing cool stuff for k8s users [1].
Lastly, I'm not totally sure on this last bit, but I think Docker Hub has a slight usability edge if you're on Docker EE (swarm).
Summarizing: I think big cloud vendors will naturally always lag a little behind. They'll make up for it with convenience if you're already on their cloud. Registries whose main purpose is to be a registry (like Quay) will naturally innovate a little faster.
I've met Keith a few weeks ago at the NodeJS NYC meetup. Great dude, who genuinely wants to make development better. Polybit seems particularly cool for front-end / designers, mobile devs, and anyone else who'd rather build an app than fret over the high availability, scalability, or etc.
What I'm saying is: cool idea + Keith's very approachable if ya wanna pick his brain about the design :)
"Back in the day math was slow and error-prone and we created the computer. Now, it’s software development that is slow and error-prone."
I'd argue Math is still slow and error-prone. Ask any math PHD candidate. Computation is fast, but Math itself has more layers, and more branches than ever. Sound familiar?
That said, some smarties are trying to remove unnecessary layers in programming.
I feel like rump/Uni-kernels are looking to simplify the stack. [1] The clear linux project is removing some pieces from the stack. [2]
TL;DR Math is about as noisy as programming :/
I don't buy the premise. But, I enjoyed the read!
I dig the One Metric That Matters (OMTM) concept. I've worked on projects with 30 metrics, and figuring out whether things are "going well" quickly turns into a debate.
Tangential:
I wish these online slideshare allowed slide comments or inline annotations. Dying to know what the Brahe + Kepler page was about :)
In reality in computer science, just about the only thing that’s really science is when you’re talking about algorithms. And optimization is an engineering. But those don’t actually occupy that much of the total time spent programming. You know, we have a few programmers that spend a lot of time on optimizing and some of the selecting of algorithms on there, but 90% of the programmers are doing programming work to make things happen. And when I start to look at what’s really happening in all of these, there really is no science and engineering and objectivity to most of these tasks. You know, one of the programmers actually says that he does a lot of monkey programming—you know beating on things and making stuff happen. And I, you know we like to think that we can be smart engineers about this, that there are objective ways to make good software, but as I’ve been looking at this more and more, it’s been striking to me how much that really isn’t the case.
Aside from these that we can measure, that we can measure and reproduce, which is the essence of science to be able to measure something, reproduce it, make an estimation and test that, and we get that on optimization and algorithms there, but everything else that we do, really has nothing to do with that. It’s about social interactions between the programmers or even between yourself spread over time.