Hacker News Reader

Comment by alexflint | Hacker News Reader

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.

View on HN

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.

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.

This.

This reason applies to a lot of todays web apps. with the emphasis of recurring revenue.

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.

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.

So, how much megabytes (compressed) does it take to store all of your corpora?

Couldn't it just load based on requirements.txt?

Bit more context, a full pypi mirror is 500GB. But I guess that's lots of wheels etc.

Code + tarballs + wheels + history; yeah, I can imagine that 500GB is not that out of the question.

That's a fair comment, but how many libraries does a typical Python projects use? I'm going to go with 100-150,the index needed will be under 100MB.

JavaScript projects tend to have more dependencies, but those tend to be smaller and will have a smaller index.

Solving this 'problem' would lose Kite money, so I don't fault them for not attempting it.

> Solving this 'problem' would lose Kite money, so I don't fault them for not attempting it.

I think it really boils down to: what happens when their servers are compromised; how much liability will Kite assume for the lost IP? My guess is: None.

They don't even have a discoverable privacy policy, just a blog post! Going into the purchase pipeline, there's no service contract, just a "sign up for an account and give us your CC".

To support your point, Eclipse has zero problem providing auto-completion with JavaDoc information using nothing but local class files. [0] It will also use source or JavaDoc archives to provide full documentation, if they are available.

[0] I know this, because it's a complete pain to use class files which have been stripped of debug data. Suddenly autocompletes look like "someFunction(String arg0, Thing arg1)" with no other supporting information.

EDIT: Just took a look, the indexes for a few workspaces I have are all under 50MB.

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.

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

/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?

No we don't do anything with the terminal any more (and in particular we do not record terminal commands in any way)

You're alienating a huge portion of your market by not supporting Emacs and Vim

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 $$$.

It's listed on their site.

Yup, we released Kite Pro today (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); 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

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

https://kite.com/enterprise

Reply on news.ycombinator.com