I'm also one of the founders. We all have extensive open source experience, have grown up in open source communities, and love open source. We're not committing to 100% open source yet. We'll be pragmatic.
We all want to open source as much as useful to the community, rather than just a code dump. This will probably look like open sourcing the individual libraries we use to build the client, rather than a single open-but-monolithic client. The client is written mostly in javascript[1] so we'll be publishing modules on NPM when the modules we need don't exist already. I think we'll need to build a Go client library pretty soon also. So, for the purpose of code re-use and learning, we'll be open source.
I'm sure we'll also be sharing the complete source for the purpose of security audits. If this is your concern, the answer is Yes, we'll let customers see the code they're relying on for their infrastructure.
Hope that helps!
rch
My first concern is - how does this work? If you are generating new keys, does that mean you could SSH into my servers if you were compromised?
We are essentially acting as an easy-to-use, "client focused", Certificate Authority for SSH and X.509.
So, in the simplest threat model, yes, if our hosted SaaS version is compromised, your infrastructure is threatened. We believe many of our larger customers will adopt an "on premise" style deployment for this and other reasons -- doing this on premise is not very different than their threat model for a central LDAP server or other identity provider many have today.
Having said that, we are incorporating all the best practices you would see in a CA for other purposes, and believe for some segments this is a viable and major improvement over their current security practices.
[1] - http://venturebeat.com/2015/05/11/scaleft-launches-with-800k...