7 ms·

Totally legit concern. when we started working on this we realized if we wanted to index tens of thousands of libraries, we wouldn't be able to ship the entire

Totally legit concern. when we started working on this we realized if we wanted to index tens of thousands of libraries, we wouldn't be able to ship the entire index along with the client. Hence the cloud-based architecture. We've thought a lot about privacy and written up our thoughts here: kite.com/security. The short answer is: we don't index anything on your computer that you don't explicitly ask us to, and our plan is to earn trust the hard (i.e. only) way: transparency, published policies, and a track record of good decision making.

mpfundstein 10y ago
how easy is it for one of your programmers to look at code that is currently residing on your cloud?
IanCal 10y ago
How big is the index? Could you offer it as an option (even paid)? I imagine some would be happy using up a good few gigs and paying a bit more to not have to post their code to you.
matthewaveryusa 10y ago
I'm sorry but the true intention is to have recurring revenue and not have licensing issues with open-source software you're leveraging on your backend. It's fine to be a capitalist, and I'm looking forward to using and paying for kite once my language of choice is supported, but come on, just be honest that you need a source of income to create this amazing product and this model is the one that fits the bill best. Again, there's nothing wrong with that. I'll gladly give you 1TB of HD space, help seed the giant chunk of data, and pay a bit moreif that's what it takes.
- alexflint 10y ago
  It wouldn't be a viable business unless we thought we could add real value _and_ thought that we could capture some of that value. Yes, being on the cloud allows us to set up an attractive subscription model. But Kite won't succeed as a business unless it turns out to actually be a value-add over local solutions. That's what we're betting on.
- rdslw 10y ago
  This. This reason applies to a lot of todays web apps. with the emphasis of recurring revenue.
qntmfred 10y ago
/security has a broken link to /smart also, "The short answer is: we don't index anything on your computer that you don't explicitly ask us to" you should say that on /security that's a pretty important point. I read in last year's HN post that you collect user's terminal commands. Is that still true?
- alexflint 10y ago
  No we don't do anything with the terminal any more (and in particular we do not record terminal commands in any way)
  - anonymousjunior 10y ago
    You're alienating a huge portion of your market by not supporting Emacs and Vim
infogulch 10y ago
In the future you might want to consider a self-hosted version for enterprises that require by policy more security than your current offering. For $$$.
- pvg 10y ago
  It's listed on their site.
- adamsmith 10y ago
  Yup, we released Kite Pro today (https://kite.com/pro); https://kite.com/pro); please consider purchasing it if you find Kite helpful :) Over the last year we've focused on knocking out the core product experience. We're now going to focus more on Kite Enterprise (https://kite.com/enterprise); https://kite.com/enterprise); if on prem is of interest please get in touch. As mentioned we are also exploring Kite Enterprise now that we've gotten the core product more
sroussey 10y ago
I have no inside knowledge here, but I would guess a Kite Enterprise would be a future offering. Like GHE.
- Vendan 10y ago
  https://kite.com/enterprise https://kite.com/enterprise
falcolas 10y ago
At first blush, the "we wouldn't be able to ship the entire index along with the client" makes perfect sense. However, I have found that I can store the entirety of the raw Python 2.7 documentation to disk in under 15 MB. It's mostly text, so it compresses absurdly well (2mb, gzipped). And if it was just an index of all the functions with little to no markup, it would be even smaller (this doesn't even account for the fact that all of Python's documentation is typically already on disk, in the modules themselves). So, given that these indices could be obtained as needed, I'm not sure I buy this argument anymore. If we can justify the download of a 20mb for a set of plugins, I think that we can justify a 2mb download to document the entirety of a language's standard library. As a few points of comparison, Atom's download is around 80MB, Docker 110MB, PyCharm is around 175mb, and a ctags file that covers over 8,000 source files (including boto2/3, aws-sdk-go, the python standard library (both 2.7 and 3.5), the go standard library) is about 6 MB compressed.
- alexflint 10y ago
  Right, but the python standard library docs are just a tiny tiny fraction of all the documentation in our index, and the documentation itself is just one corpus out of many.
  - xkxx 10y ago
    So, how much megabytes (compressed) does it take to store all of your corpora?
  - OJFord 10y ago
    Couldn't it just load based on requirements.txt?
- mynewtb 10y ago
  Bit more context, a full pypi mirror is 500GB. But I guess that's lots of wheels etc.
  - falcolas 10y ago
    Code + tarballs + wheels + history; yeah, I can imagine that 500GB is not that out of the question.

mpfundstein 10y ago

how easy is it for one of your programmers to look at code that is currently residing on your cloud?

IanCal 10y ago

How big is the index? Could you offer it as an option (even paid)? I imagine some would be happy using up a good few gigs and paying a bit more to not have to post their code to you.

matthewaveryusa 10y ago

I'm sorry but the true intention is to have recurring revenue and not have licensing issues with open-source software you're leveraging on your backend. It's fine to be a capitalist, and I'm looking forward to using and paying for kite once my language of choice is supported, but come on, just be honest that you need a source of income to create this amazing product and this model is the one that fits the bill best. Again, there's nothing wrong with that. I'll gladly give you 1TB of HD space, help seed the giant chunk of data, and pay a bit moreif that's what it takes.

alexflint 10y ago
It wouldn't be a viable business unless we thought we could add real value _and_ thought that we could capture some of that value. Yes, being on the cloud allows us to set up an attractive subscription model. But Kite won't succeed as a business unless it turns out to actually be a value-add over local solutions. That's what we're betting on.
rdslw 10y ago
This. This reason applies to a lot of todays web apps. with the emphasis of recurring revenue.

qntmfred 10y ago

/security has a broken link to /smart also, "The short answer is: we don't index anything on your computer that you don't explicitly ask us to" you should say that on /security that's a pretty important point. I read in last year's HN post that you collect user's terminal commands. Is that still true?

alexflint 10y ago
No we don't do anything with the terminal any more (and in particular we do not record terminal commands in any way)
- anonymousjunior 10y ago
  You're alienating a huge portion of your market by not supporting Emacs and Vim

infogulch 10y ago

In the future you might want to consider a self-hosted version for enterprises that require by policy more security than your current offering. For $$$.

pvg 10y ago
It's listed on their site.
adamsmith 10y ago
Yup, we released Kite Pro today (https://kite.com/pro); https://kite.com/pro); please consider purchasing it if you find Kite helpful :) Over the last year we've focused on knocking out the core product experience. We're now going to focus more on Kite Enterprise (https://kite.com/enterprise); https://kite.com/enterprise); if on prem is of interest please get in touch. As mentioned we are also exploring Kite Enterprise now that we've gotten the core product more

sroussey 10y ago

I have no inside knowledge here, but I would guess a Kite Enterprise would be a future offering. Like GHE.

Vendan 10y ago
https://kite.com/enterprise https://kite.com/enterprise

falcolas 10y ago

At first blush, the "we wouldn't be able to ship the entire index along with the client" makes perfect sense. However, I have found that I can store the entirety of the raw Python 2.7 documentation to disk in under 15 MB. It's mostly text, so it compresses absurdly well (2mb, gzipped). And if it was just an index of all the functions with little to no markup, it would be even smaller (this doesn't even account for the fact that all of Python's documentation is typically already on disk, in the modules themselves). So, given that these indices could be obtained as needed, I'm not sure I buy this argument anymore. If we can justify the download of a 20mb for a set of plugins, I think that we can justify a 2mb download to document the entirety of a language's standard library. As a few points of comparison, Atom's download is around 80MB, Docker 110MB, PyCharm is around 175mb, and a ctags file that covers over 8,000 source files (including boto2/3, aws-sdk-go, the python standard library (both 2.7 and 3.5), the go standard library) is about 6 MB compressed.

alexflint 10y ago
Right, but the python standard library docs are just a tiny tiny fraction of all the documentation in our index, and the documentation itself is just one corpus out of many.
- xkxx 10y ago
  So, how much megabytes (compressed) does it take to store all of your corpora?
- OJFord 10y ago
  Couldn't it just load based on requirements.txt?
mynewtb 10y ago
Bit more context, a full pypi mirror is 500GB. But I guess that's lots of wheels etc.
- falcolas 10y ago
  Code + tarballs + wheels + history; yeah, I can imagine that 500GB is not that out of the question.