Here's an even better proposal - lets try immeasurably hard to stop re-inventing words and maybe use words that people would generally understand without an accompanying definition. Where, for instance, software actually means software and tech actually means technology. :p
That's very nice, but "Tech" sometimes means an industry now, not the technology itself. Same for software. There is software the code, and Software the industry. Nobody invented a new word, but we have to understand what we're talking about in context.
Culture isn't a great answer to throw around when people are asking hard questions about a program that is the financial backbone of a company. In fact its downright snooty to presume that allegations like this stem from folks who have experienced a different corporate culture. People generally get to know what a company's culture really is like from the folks who leave that company. And there are tons of those folks from Google. The point is, whether you appreciate Google's internal culture of candour or not or its lack of silos, that's just not the way to respond to allegations regarding the way Google makes serious profits.
Quay.io is a great product and if you're happy with it we don't recommend moving to Gandalf.io.
Gandalf.io went live yesterday and still very much in early beta and we're still improving the functionality and experience. The reason we decided to set up Gandalf was because we think this is a huge potential market with space for at least 3-4 players. We also think docker containerisation is more than just enterprise devops preserve and want to lower the threshold for startups and individual developers to get started.
Gandalf.io has an auth layer wrapped around the standard docker registry and you can access it via SSL using the docker api (this includes the docker CLI). We're still examining ways in which we can strengthen the security of the system and are open to suggestions and insights.
Github based builds are in the upcoming release slated for next week. Sign up for the free plan and you'll be notified by email when that happens.
Our goal is to integrate your docker workflow very tightly with github. The user will be able to decide which features to switch on and off and whether to write or only read! Obviously we'd rather announce these features when they're ready and we'd rather collect the data upfront so we don't have to prompt the user once again when they sign in.
That seems like an OAuth anti pattern. Why would you ask the user for every permission when they're signing up? That can only hurt conversions. Ask for the bare minimum, and then request more permissions if the user does something within the app that needs them. Especially for something as sensitive as this, you want people to feel safe using the product and you can't do that by scaring them when they hit "Sign Up with GitHub."
I do agree that's something we might have to change if the signups slow down. And we need to do a cost-benefit on that perhaps. At the moment, folks are signing up though :)
Which perhaps shows how little "folks" care about who they share their data with. Additionally I have private organisation repos that I really don't want you taking a peek at. Sorry, no dice for me unless this is tightened up.
You're right. We received more than a few brickbats for this since yesterday. So we changed the github oauth request scope. As it stands now, the data we request is only the user scope which includes the user's private email address (https://developer.github.com/v3/oauth/#scopes). We'll add additional scope requests if a user elects to use our upcoming github build feature.
We will. But we won't be offering an enterprise plan while we're in beta :)
Sure we're sending a signal that we're not ready for enterprise folks. I can be candid in saying that we'd rather be the digital ocean of dockers than an AWS. at this point :p
I assure you we've debated this a lot before putting out that pricing. There is a way to do this and do this well. For us pricing docker hosting competitively is the best way to do it, especially for a startup ecosystem that is only just beginning to wake up to the potential of docker-based testing and deployment.
