Another company blog without a link to the company home page. I had to manually type your company URL to try to learn what this is all about. It is absurd how common this is.
BTW, your landing page at elastic.io could use some work. The slideshow runs much too fast (I had to hit the back button at least ten times to read it) and it didn't really explain the service you're providing (or explain why it's valuable, though I suppose "avoid billing surprises" is nice.)
Great idea! We also thought about this one. As we will re-sell cloud APIs it will be definitely a good feature to protect our users from slashdot effects.
I wonder if anyone at Elastic has talked with anyone at Github as, it seems to me, if Elastic gets any significant traction, this does nothing to help github (though perhaps I'm overlooking something) and leads into a 'Tragedy of the Commons' scenario wherein everyone is depleting a shared public resource for their own personal gain knowing full well that it isn't sustainable long term.
Agree. Also with our current implementation right now we might pose a bit too much load on Gists (which is actually only our fault), however it's only first step. We want to give our users their data at hand, I could imagine a potential independent 3-rd parties storing our data where other companies (Facebook) will use it on our behalf. Users private data will be more protected, and portable. So if I would like to switch (Facebook --> Google+, hypothetically) I would just revoke access from one site and give it to another.
Wow, so they moved off requiring you have a Twitter account to requiring you have a Github account. Keeping in mind that requiring any 3rd party account to use your own service is a bad idea, this sounds even worse.
Have you ever tried to sign up for a Github account? Last I checked they made you perform a bunch of scary crypto stuff on your local machine before they'd let you in. I gave up at that step, as it would have required downloading and installing a bunch of random software to pull off. No idea why they would make people do that (and it's why I still don't have a github account), but...
To limit your service to only accept customers who have navigated that minefield? Sounds like the ultimate form of adding friction to your signup process.
No idea why you would think github is a minefield.
> Last I checked they made you perform a bunch of scary crypto stuff on your local machine before they'd let you in.
Generating an SSH key is 'scary crypto stuff' ? One would hope anyone using git, and really any developer would have already done this many times before.
> I gave up at that step, as it would have required downloading and installing a bunch of random software to pull off.
You mean install a single program, git, which is sort of a perquisite for using, well, git? The windows installer includes the programs needed to create an ssh key and macos / almost any *nix distro will already have them installed.
I think its pretty clear that elastic.io is targeted at developers and I can't possibly imagine a developer having any issue signing up for github, installing git and generating an ssh key. If such developers exist they are likely very new to development and thus probably aren't a good match for a beta signup anyway.
I sincerely hope that this is a troll comment. I suppose it's subjective, but I don't consider "ssh-keygen -t rsa" to be scary, and I would've thought that most developers would've already have OpenSSH installed (which is the only dependency for generating keys, not "a bunch of random software.")
Do you really have no idea why they would make people do that, though? Maybe it's so that your source code can be securely protected so that only you can access it and modify it?
I'd really like to know if the original comment was a troll, joke or otherwise as well. According to the posters profile he is actually a developer of several services.
If it wasn't a joke of some kind I'd like to make a note to never trust any sensitive data of any kind to his products.
Considering generation of an SSH key 'scary' is a pretty strong indication to me that there is no tangible level of security being implemented.
Thnx for your comments Jason. Indeed any 3-rd party sign-in module lower down the conversion, however, on a given stage it's intentional. We would like to speak out to developers, and to those who are familiar with basic principles of open source software. So Github account is kind of filter for now.
I can certainly understand the sentiment, but requiring a Github account still seems arbitrary and limiting. There are lots of great open-source developers who don't use git or github.
For example, I'm a ruby developer, so yes most of the open source development I do involves Github. But even I know about (and use) projects like zip-ruby [1] on Bitbucket or redmine [2] on svn.
It's a cool idea (storing user data in their own github accounts), but it sounds like a nightmare when it comes to security and data validation. No longer can you trust what gets into your database and instead you would constantly have to validate the data you import.
I suppose that makes the service more like an API where the service generates the code to run on it rather than the user.
Yes, that's definitely a problem. For our use-case where we want to follow SW engineering best practices like versioning, continuous integration, etc. we thought reuse of git as a repository and them to user will be a good thing.
Some feedback on your main site: Each slide has a lot of words, and I can't figure out how to pause it. I'm signing up for the beta because I _think_ I know what your site does, but I'm really not sure. I'd be more comfortable if I could see all 4-5 pictures at once, which could easily fit horizontally on my monitor.
Edit: OK, I was able to read all of the captions via "View Source"
The caption on the blog (unseen before you notice the ribbon, and unreadable before you select it) should be on the main page. http://i.imgur.com/KyRQD.png
GREAT! Now get rid of the silly github requirement (and don't return to the even more silly twitter requirement) and give your users the option of storing it in github or retrieve their data some other way.
I can't even begin fathom the decision process that concluded in requiring github.
Exactly. Primary motivation was to have a simple versioning for user data flow and Git repository management overhead was too much, however after we implemented it we realized that data portability is a by-product of that.
