Kite Responds to the Minimap and Autocomplete Issues | Hacker News Reader

Kite Responds to the Minimap and Autocomplete Issues

kite.com

116 pointsadamsmith68 comments

An apology that starts with 4 paragraphs of self-congratulation is not a real apology at all. Nothing of the article reads as being genuinely regretful of the strategies taken - it's just sorry for being caught.

>Unfortunately, while trying to make programmers’ lives a little less complicated, we instead made them more complicated.

Barely an admission of guilt, and even that can't get past without patting themselves on the back for the noble cause they 're profitably working towards. Yes, Kite, your pay-for service clearly has my best interests in mind. I forgive you for being too stupid to grasp your superior approach. How about actually finding fault with hijacking projects for advertising in the first place?

Buying a popular addon with the express purpose of subverting its original intent for commercial monetization seems like it should be against Atom's TOS

This instance is razor thin close to being malware

What's to stop the next enterprising company from intentionally uploading all your code to their servers? Modifying your code? Or holding your code hostage? Atom has git support backed in, so how likely is it an addon could inject code and commit it without you ever seeing that it happened.

Atom's automagic update approach to addons can't survive this kind of exploitation. If I have to re-vet every addon every time there's an update, their entire ecosystem just turned to shit.

Do we need virus scanners for Atom packages now? An addon that scans repos to see if the primary contributor suddenly changed?

Maybe Github should have an informal policy that punishes bad actors by penalizing how they're listed in Atom's built-in package browser. Or create a convention of documentation that is machine-readable and easy to preview in the editor's package-updater tool. But making blanket rules regarding commercialization would likely have unwanted unintended effects.

FWIW, Atom's community manager wrote a long comment in one of the Kite plugins' Github issues:

https://github.com/atom-minimap/minimap/issues/588#issuecomm...

> As a steward of the Atom editor and the Atom package ecosystem, I'm of course concerned about packages being used for nefarious purposes. But I'm also loathe to impose blanket rules on what is or isn't valid functionality for packages without some very well-thought-out rationalization and justification for those rules. I've been watching this topic hoping that the smart people here would give me some ideas

> [an analogy to the value of advertising in other contexts]

> ...I'm definitely keeping my eye on this kind of thing and if advertisements become a problem, I'm sure that the Atom team will consider specific rules. I just don't think we're there yet.

For starters, packages should probably be considered non-transferable. If someone buys a package, they shouldn't keep the existing rankings and ratings.

It would be challenging to be proactive about it, but it was be a clear solution when they get caught.

Picking nits I think you mean adware not malware. I think it's worth making the distinction.

Giving ad networks tracking information of your editor usage and possibly access to the code you're working (which they didn't do, but the original statement was 'close to being malware') on is beyond mere adware.

Adware always had telemetry. But I get your point. Let's call it spyware then if we think companies might use our source as a consequence. I find it highly unlikely but admit it is possible.

Literally the only distinction is how many lawyers they're packing.

I think what it really means is this:

If I'm the maintainer of an OSS plugin with 3m users, I'd better be _very_ careful about what I do with it, and keep my SSH keys, etc., _safe_. It's a responsibility not to be taken lightly.

Practically speaking, it means you have to be comfortable with knowing you have a (tiny?) chance of being hit with a remote code exploit at any time. Avoiding that means disabling auto update and other such conveniences. Personally, I treat developer computers as untrusted by default.

Eh I didn't get the "sorry for being caught" vibe. They admitted they failed to listen to early customer feedback.

But still it sounded like a marketing piece as much as an apology, which is bad because authenticity is everything after a PR blowup like this.

Repeatedly highlighting their open source creds didn't make me want to trust them more, it made me question how they didn't know it was a bad idea in the first place... and if business people were the ones making the calls instead of the OSS developers.

This was a risky thing to do, even despite the luxury of looking back in retrospect, this seems like something you have to do very carefully if you are going to integrate ≈remote cloud services into text editor plugins, let alone commercial backed features.

Clearly there was going to be a wide gap between the users expectations of a static local OSS plugin (as they almost always are) and what they changed it to. It had to be handled very carefully - if at all. They should have made a separate add-on plugin IMO and pushed it via the documentation of other plugins they own...

The 2nd sentence is an apology: "Over the last few days, Kite has been knocked around in social media (and the actual media) over several moves we made to expand our user base. It was a humbling experience, and I’d like to apologize to the entire open source community for our handling of these projects."

It seems to me that even this apology is for how the deed was publicized, not that they regret doing it at all.

The completely unpenitent doublespeak eliminated any remaining faith I had in this company's ethics. At the start of this controversy I thought it was at least possible the founders somehow just didn't think through the decision adequately, but they aren't willing to accept and apologize for reality.

The clear dark pattern here should also have been addressed: Kite is listed with all its shiny features, whereas the alternative simply gets called inaccurate and incomplete. Local analysis does have some clear advantages over Kite, even excluding important privacy concerns. What if you're offline or are in an area with poor network coverage?

https://kite.com/static/media/autocomplete-python-flow.690d3...

The use of dark patterns is more of a policy/"culture" thing that people won't exactly "knock" (although there was a comment on the HN thread last week about this) or demand the removal of, but it does speak to how Kite is willing to operate, not just pre-minimap fiasco, but going forward too.

Edit:

The link to the PR in the post isn't the point here, it's the propensity to write misleading copy targeted at thousands of devs who had never heard of Kite that went unaddressed. Open source is extremely trust-based (how hard was it to believe that a text editor plugin of all things was doing funny things?), and Kite needs to talk about whether it will continue to behave as a potential bad actor.

Right now, all the post contains is an apology for a PR fiasco that occurred due to something akin to a miscalculation, not a deliberate onboarding strategy.

https://github.com/kiteco/kite-installer/pull/50 was linked from the post, but it's not merged

It looks like they did (or are going to) address it: https://github.com/kiteco/kite-installer/pull/50

> Let’s be clear: the absolute last thing we wanted was for someone’s code to get synced to our servers without their knowledge.

I don't buy it. The UX was dark-patterned to enable this very thing, and this reads like damage control when it's clear it wouldn't fly under the radar.

If it were the last thing Kite wanted, there would be a big warning that this option uploads your code to their servers. Or some mention of the upload at all. Or it wouldn't be the foundation of Kite's business.

> Or some mention of the upload at all

The image they show in the post shows that they were fairly clearly saying "Where enabled, your code is sent to our cloud":

https://kite.com/static/media/autocomplete-python-flow.690d3...

Sure, it is not exactly hilighted there, but I wouldn't say that they were trying to hide that either.

As a third party to this debacle, all I have to go on is the comments people have made, but a few of them have asserted that that language was added later on and some initial versions of this change either outright lacked that warning, or else used styling tricks to make it difficult to notice. I lack the time and/or motivation to go digging through the commit history for that plugin, but maybe someone more enterprising could do so and verify if that warning was always present and presented in such a visible fashion.

It's been in there for quite some time, and there have been a variety of commits that carried some variation of the same "we analyze your code in the cloud" message:

https://github.com/kiteco/kite-installer/commit/c52c5daa672c...

Taking over the minmap autocompletion projects and adding these features still feels a bit sleazy, but the installer was honest about how it worked.

Their entire permissions messaging is encapsulated in the user connecting the presence of the word "enable" in both the description and on the button. That's it.

> Staying Open: Kite Responds To The Minimap and Autocomplete Issues

I have two problems with that title:

1) Implies that you were open in the past, which Kite really wasn't, and 2) "Issues" is an understatement and borderline misleading. A more accurate term might be "debacle".

> Kite has been knocked around in social media (and the actual media)

"Knocked around" - sounds like victim language to me. You weren't knocked around - you were:

1) Caught red-handed, 2) Called on the carpet for your deceptive and bad business practices, and 3) Lost reputation and standing because of the choices you made.

If anything, it was you, Kite, who "knocked around" millions of minimap users by your irresponsible and unethical actions. In fact, reading the Github issue thread, it looks like your actions may have cost Atom some users.

Shame on you guys. The backlash wasn't anything that Kite's actions didn't warrant.

> How did we get ourselves here? We started Kite with the idea that machine learning....

Please don't attempt to turn your apology into an advertisement for your business. Maybe that's not what you intended, but that's how it reads to me. I'd feel better about this blog post if it talked less about how awesome Kite is and more about how awesome the open source community that held you accountable is.

-------------

While I appreciate that Kite is (somewhat) owning up to its mistakes, I'm concerned that, had there not been such a vocal community backlash, Kite would never have self-corrected this move.

I think hiring a Community Manager is a step in the right direction for Kite. Hopefully, he/she will work with the open source community to tell anyone else who tries to pull these types of shenanigans to, "Go fly a kite." [1]

[1] http://idioms.thefreedictionary.com/Go+fly+a+kite!

> As we considered our options, we had a novel idea: buy an open source plugin, reward the author for their work, and expose new users to Kite.

That’s the root of the issue. Someone built a well, and offered its water for free to the community. Theirs was a good-faith effort that you subverted when then you paid the maintainer to help you turn people who came to the well into customers.

I don’t understand how you didn’t see that as problematic from the outset – at the very least, you could have first created an open API (akin to LSP) where others could add their own Kite-like service. That would have respected the spirit of open sourcing.

At companies like my former employer, developers were given the power and responsibility to vet their own tools. Despite somewhat strict compliance needs we were able to allow junior developers to customize their own IDEs and plugins, since personalization is crucial for productivity. One of those compliance needs was, crucially, that _source code in its full form must not leave the developer's machine except en route to the git repo._

We were comfortable with this posture because the Atom/Sublime/VSCode plugin ecosystem has largely been dominated by honest OSS projects, especially the most popular ones. Thanks, Kite, for ruining that for everyone. I will now personally vet every plugin that my junior devs install from here out thanks to your example.

We've seen it happen before though: http://www.infoworld.com/article/2929732/open-source-softwar...

This problem applies not only to editor plugins but all sorts of things nowadays: npm packages for Node.js devs in particular seem like a great way to get viruses, given how hundreds of dependencies get pulled in, sometimes to save 2 or 3 lines of code. Here is an example in the Node package for Postmark (an email service provider) which had a dependency for literally 4 lines of code: https://github.com/wildbit/postmark.js/pull/14/files

As developers, we need to be willing to reinvent the wheel when needed, instead of blindly installing dozens of 3rd party packages. And we should vet things we install no matter what.

to be fair with that specific example, they changed from a purpose-built function, to a shell call including (albeit extremely simple) text parsing.

I'd generally prefer not to have the git(1) incantation hanging around in an unrelated function.

The dependency "git-rev" uses a shell-call too, so this PR doesn't change much apart from removing the dependency itself.

Here's the original code from the "git-rev" package: https://github.com/tblobaum/git-rev/blob/master/index.js

The main problem here is one of trust. If you're going to share your code with a third party like Kite, even without getting into the possible legal issues involved, you have to be damn sure you trust the company. Kite's culture has already shown to be deceptive, and these actions are really not drastic enough to imply they're committed to change.

Guys it's not OK to just hijack open source projects. You need to make (or fork) new plugins specifically for kite, not hire a bunch of developers of popular autocomplete plugins and have them shadily change their plugin to use Kite as a completion engine.

they didn't. they just had them add _support_ for Kite. It was up to the user to enable it. I'm failing to see the issue here. I mean, yes, their UIs needed work, but they admitted to that mistake and have since fixed it (according to the article).

Your comment makes me think this is more of an open-source lynch mob rather than someone looking at this objectively.

Company needs users. Plugin has users. Plugin does things company's flagship product _could_ do (and it is _free_). Company reaches out to Plugin developer and they come to an agreement to add support for the flagship product into the Plugin, but the new support is _not_ enabled by default.

Wherein lies the problem?

"Lynch mob?" Really?

There was a guy calling for a communist-style "purging" of anyone involved with this company in the last thread. I think you're underestimating how mad people get about free plugins for their (incredibly bloated and inefficient) code editor.

The problem is that the screen was not clear enough. Users just press Continue, Continue, Agree, OK, Share all my user directory, Install, OK, Close. They never read the small or big letters, they just click the green button. The "Enable local engine" looks like a "Cancel" button.

That's how you get installed an unwanted browser bar, a new amazing search engine, and the Norton security pack for 60 days.

If you see the screenshot carefully, by default they are asking permission to upload to their servers the content of your user directory "Enable access in Users/kite". Go and take a look at all the info you have in the subfolders of your user directory. [1]

My guess is that most people just expected that the current file was uploaded, not all the py files. Perhaps only the current line, not all the file. And many didn't read the dialogs and they just pressed enter.

[1] They only support Phyton, so they uploaded only the .py files, but I guess that in the future they can extend the search types to C and upload the .c, .cpp, .h, .inc, ... files too. Do they have to ask again or the current permissions are enough? What if they extend the search to .doc and .xls? What if they extend the search to images? Go again and take a look at all the info you have in the subfolders of your user directory.

Once again, that sounds more like a fundamental flaw in the service/software and less like malicious intent.

I'm probably not going to use their service any time in the future, but to imply they intentionally put users in the dark is kind of a stretch.

More like, they failed to communicate how their service worked. Also, they failed to provide a clear distinction between the two options for completion engines that described both objectively.

Honestly, it sounds to me like they were just overly-excited to sell their service, and didn't take a step back and say "hey, do you think this wording makes Jedi look a little overly-bad?" They could have done with some user-acceptance testing on this, for sure.

Or, "hey, should we try to put our ads in the minimap package?"

It probably doesn't matter if it was intentional hostility or unintentional incompetence. Either way, it needs to be fixed.

I feel like part of the disconnect is that Kite uploads source code to servers. In a perfect world with perfect security and 100% honest people, this is no big deal. The world doesn't work like that.

The last thing that I or my employer wants is our source code sitting on someone else's server - even if it's for code completion. My employer's code is proprietary. Period. If I mistakenly enabled Kite when working on some of this source, it's a huge deal. That is grounds for termination, and I am sure there are many other programmers who are in the same boat.

It's probably not a big deal that someone's code is on there, but there are big implications. It doesn't matter that it probably won't be seen. If the source has been leaked to a 3rd party, it would be negative. My employer doesn't give two flips about fundamental flaws and malicious intent. They care if it did or did not happen.

> Company needs users.

sure, that's fine

> Plugin has users.

Still no problem here.

> Plugin does things company's flagship product _could_ do (and it is _free_).

Yep, all kosher.

> Company reaches out to Plugin developer and they come to an agreement to add support for the flagship product into the Plugin, but the new support is _not_ enabled by default.

… and there's the problem, that's not what happened. First it's not entirely clear, but it's implied that they paid the developer to add support for Kite, that may or may not be OK, but at the very least it raises some questions. Secondly, they made Kite the default choice when installing the plugin, and also had some shady dark patterns in the chooser dialog to try to bias people towards using Kite while downplaying the risks it poses.

Even with all that, that's not what really got people furious, all that, although shady, isn't really wrong per say.

Where they went wrong, was when they then went out to a different plugin, that had nothing at all to do with the product the company was offering and shoehorned extra functionality into that plugin specifically for the purpose of showing their products ads to users. To be clear, they chose the plugin specifically because it was popular, not for any other reason, this was PURELY a marketing driven decision. Had they picked another plugin that did something similar, I.E. showing links to docs for libraries being imported, and then worked with that developer to link to their docs that showed the ads that might be one thing (still a bit shady), but no, they wanted to get the most ad impressions they could, so they added a completely unrelated feature into an existing plugin. Further muddying the waters, they didn't just "partner" with the developer for a "business relationship", they straight up hired the guy, which raises all kinds of questions about their relationship to this open source project.

This was a perfect storm of bad decisions, they started out making some questionable decisions, nobody really noticed and they got good results back, so they decided to crank it to 11, and then when people did notice and called them out on it they initially doubled down and then finally went into full damage control mode.

I get what you are saying, but I still don't see much of an issue here.

The ultimate decision to actually _implement_ all of those changes in those existing open source projects lies with the project maintainers/owners.

In the first case, the project maintainer/owner was asked to make the change, and it's implied possibly paid to do so. But as previously stated, that particular case wasn't that bad, since the only thing shady there was the use of some dark patterns to bias people towards Kite while somewhat obfuscating that it would disclose their source code.

In the second case, because they hired the project maintainer/owner, that made Kite effectively the project owner, and as was established, the thing people are really angry about was the second case. So yes, Kite is 100% to blame as the project owner (via hiring the project owner).

I suppose there are probably two lessons to learn here. First, if something is a major open source project that's widely used, it would be a good idea to make sure there are multiple project owners/maintainers with veto powers to keep each other in check. That wouldn't stop a company from hiring ALL the owners/maintainers on a particular project, but it would at least increase the difficulty, particularly if they were geographical distributed potentially forcing the company to work out employment in multiple countries.

Secondly, when a company acquires an open source project, they are obligated to follow the norms and expectations of the open source community, at least if they don't want to have said community complaining about (and eventually forking) their newly acquired project. Since presumably they found value in the project, it's in their best interest to not upset the community thereby reducing or destroying that value. As such, any action they take that could be construed as giving favor to their commercial products over others (particularly other open source products), or which would introduce ads into the project, need to be considered VERY carefully and great care needs to be taken around how those sorts of things are implemented and introduced. In particular making sure all your ducks are in a row by making sure you get buy in from a significant portion of the products user base before rolling the changes out.

On the one hand, I agree with the sentiment.

On the other hand, if it is really that shady, it is on the open source developer to say 'no.' As described here, it doesn't seem that shady. There was a choice between Kite and Jedi for the one plugin, and for the other plugin, it was basically an AD.

On the gripping hand, I really want open source developers to get paid, this seems like a way for open source developers to get paid. It makes me more sympathetic to the idea that this was poor execution of an ok idea.

I'm in that boat as well. Initially, I was thinking this all was done with ill-intent. But now that we have heard Kite's side, it sounds more like just poor execution of a good idea.

It was good execution of a very bad idea.

> We’re on the HN homepage, with 900 upvotes, and passionate comments. All great, except for one thing: we are the scourge of the internet. How did we get ourselves here?

Well it's not surprising, is it?

From the outline article:

>> Then he blew this reporter off. “I apologize in advance that I can't answer any further questions,” he wrote. “I need to focus on other parts of the business, including continuing to improve the product for our users, and conflict like this is always doubly distracting.”

Fuck Kite. This is obvious damage control after the backlash of their severe betrayal of the open source community. They’re not sorry they did what they did; they're sorry they got caught.

The title “Staying Open” is so full of BS it hurts.

Retroactive 'Openness' is not open. Openness is when you let us know before you do shit like this, not after you're caught.

As others have pointed out, the key issue is that Kite thought it was a good business practice to ask a hired open-source developer to integrate Kite ads into their heavily used projects. They wanted a shortcut to users at the expense of open-source ethics.

Yes, open-source developers should get paid. But if they take this route, they may lose credibility within the community.

I interviewed with Kite a number of years back. From that experience, I am entirely sure that they really had no malicious intent with any of this. That being said, I did tell them that IMHO they were severely underestimating the privacy concerns of developers. Looks about right.

They had no malicious intents? Like in they had no intentions of hiring open-source maintainers, taking over their codebases and quietly injecting their product?

Point is, if we don't consider this sort of behaviour malicious then we can expect to see this more and more often.

Whether or not we consider this behavior to be malicious has no real bearing on whether they had malicious intent. I'm sure they think that adding Kite support to these plugins is great for everybody. But they have different priorities and opinions. I can easily accept that they had no malicious intent, but simply failed to realize that other people would feel differently about the changes they made. And that's definitely a problem, they should absolutely have realized that they were doing something people would not like. But when you're excited about your own product it can be hard to recognize that other people aren't.

Don't get me wrong, I think they're absolutely in the wrong here. I just also think it's important to understand motivations and reasoning instead of just attributing everything to malice. Otherwise you can't prevent this from happening again.

The updated dialog still feels kinda slimy (https://github.com/kiteco/kite-installer/pull/50). It makes no mention that search and usages are paid add ons (https://kite.com/pro).

We're sorry? start by changing this

https://github.com/kiteco/atom-plugin/blob/master/LICENSE

Reproduction of this material is strictly forbidden unless prior written permission is obtained from Manhattan Engineering, Inc.

From "Update LICENSE" (2017-01-13) https://github.com/kiteco/atom-plugin/commit/fc1b1ab6efafcd4...

> -The MIT License (MIT)

> -

> -Permission is hereby granted, free of charge, to any person obtaining a copy

> [...]

IIRC this is perfectly legal with the MIT license. But legal doesn't mean community friendly or a good idea.

Edit: Ups. I forget:

> -The above copyright notice and this permission notice shall be included in all

> -copies or substantial portions of the Software.

Not buying it at all.

How does the announcement of Kite Enterprise (twice!!) fit within the supposed "apology"?? It has absolutely nothing to do with either project.

It's ironic actually. Within their "apology" they are doing the EXACT same thing they are apologizing for: sneaking in some more advertising of their products.

This is one disgusting company.

Just in case someone here didn't already say this:

Do not use Kite.

It's software that was made by people who are fine uploading your code to their servers. The kind of people who should be out of business as soon as possible.

This comment is very sightly off-topic for this story, but 100% on topic for HN, and so many people might find it useful that I feel compelled to write it.

The first link in this write-up is to this story which gives the background:

  https://theoutline.com/post/1953/how-a-vc-funded-company-is-undermining-the-open-source-community

And I wanted to draw attention to something remarkable from that write-up. Without any irony, completely straight-faced, the writer nonchalantly included the line:

   >Although Kite has no business model yet, it’s widely
   >thought in Silicon Valley that having users is the
   >first step toward profitability.

The article had introduced the startup as:

   >a $4 million venture capital-funded startup

That's not a valuation but the size of the round.¹ The title and subtitle of the article are:

   > How a VC-funded company is undermining the open-source community

and:

   >A San Francisco startup called Kite is being accused
   >of underhanded tactics.

Now what I wanted to bring attention to in this comment is the fact that it is possible to nonchalantly mention that a startup has no business model, and is a $4 million VC-backed business, but this tells you nothing about the startup: except that it is based in Silicon Valley/San Francisco.

I really want to emphasize this geography to you, because people here are skeptical.

We had a recent article here on "Ways a VC says no without saying no". One person wrote ², in complete denial:

   >a few years ago when trying to raise a Series A. We
   >were getting the "location" excuse over and over. It
   >usually went something like, "we love what you are
   >doing, and we would probably invest in you, but your
   >location is a non-starter for us." The truth, as was
   >illuminated to me during, is that they just aren't
   >interested. If you were a compelling enough business for
   >the investor, your location would not be a factor. If
   >you can prove that you are succeeding in your location,
   >then the location obviously isn't an issue.

VC after VC after VC mentioned the exact words "your location is a non-starter" but this person is in denial.

I wanted to use this story to illustrate that you do not even need a business model in order to raise money in Silicon Valley/San Francisco. It is there in black and white and without comment, mentioned off-hand in a story about something different. Memorize these fourteen words. Memorize these words now: "A San Francisco startup"; "$4 million venture capital-funded"; "has no business model yet."

Just memorize it. It is the difference between the success and failure of your startup and if you read this comment carefully and take it to heart, this comment can become the most important one you will have read in the past five years.

¹ https://www.crunchbase.com/organization/kite-com

² https://news.ycombinator.com/item?id=14815785

VCs really need to look in the mirror. We often say on the internet that Innovation can come from anywhere, but VCs don't believe that at all. VCs are only interested in funding their friends living a few blocks away or some college kids living in NYC or SFO. VCs are the only people who can help in spreading the wealth around. Why not fund a startup in Des Moines or Harrisburg. That would help grow those cities and also reduce the stress on cities like SFO. Also it would save valuable money for the startups as those cities cost far less.

It is nice to see a more extensive explanation, even as the motive is to save face. But the apology, like the incident itself, feel like symptoms of a flawed strategy.

> How did we get ourselves here? We started Kite with the idea that machine learning could help eliminate the repetitive parts of programming. We spent three years building the initial product - and it works. Our software has really great completions, conveniently sorted by relevance instead of the alphabet, among other features that are proving useful to coders.

> We’re proud of the tools we’ve built - the problem we faced was finding a way to tell potential users about the thing we created. As we considered our options, we had a novel idea: buy an open source plugin, reward the author for their work, and expose new users to Kite.

Many eminently useful plugins and software have been able to endear themselves via word of mouth and user happiness; Homebrew, Bootstrap, and Atom come to mind. And plenty of programmer-optimized software can even charge good money, such as Textmate and PyCharm.

Advertising isn't a bad way to get exposure, but yeah, I do agree that Kite's approach was "novel". It'd be as if the official CDN version of React wrote console messages about how great Instagram's new Snapchat-like features are. Even if Kite's injection of self-promoting code into a popular plugin was harmless, it felt exactly like the kind of shady tactic that people cynically suspect user-data-in-the-cloud companies to partake.

The critique of Kite was not the only Kite-related article to get a huge number of HN upvotes; Kite's initial announcement and a followup about Python features got 1,138 and 553 upvotes [0] respectively. That (plus the VC funding and connections you already had) is enough to get a critical mass of interest. If Kite hasn't gotten the desired userbase a year later, advertising isn't the solution. In each of those HN discussions, as well as on Reddit, the primary concern was the cloud hosting of code. Maybe it is impossible for Kite to be full-featured as a locally-hosted product, but most users seemed unconvinced because they were apparently unable to see the value of Kite over what offline IDEs are able to do.

Kite's response shouldn't have been "the same concerns were raised for tools like Dropbox and Github [which]are now used without hesitation" [1], but to focus on a minimal viable local product that would become popular enough to have the same kind of trust/popularity that Github and Dropbox earned (hard to imagine either being successful if not for their generous free plans). Undertaking a strategy that re-emphasized people's concerns about the cloud and Kite's unclear privacy policies is just not a good look.

[0] https://hn.algolia.com/?query=kite&sort=byPopularity&prefix&...

[1] https://www.reddit.com/r/Python/comments/4erjy4/kite_program...

So I guess this is the kind of thing that RMS wanted to prevent when he talked against unofficial packages and repos in Emacs.

Hope these guys run out of funding

I generally think HN'ers are too quick to boycott, but this seems like a level of malicious action that will be very difficult to recover from, both for Kite and it's principals (including the maintainers who sold out their user base).

Taking over an unrelated open-source project and attempting to monetize it's users (without being very open about what you're doing) is unethical in and of itself.

Using dark-pattern UX to manipulate those users into making poorly-informed decisions is even worse, and doing it in a way that potentially violated privacy and confidentially expectations is even worse than that.

I admire the commenters here who chalk this up to an honest mistake, but my viewpoint is a bit more cynical than that. The most likely truth is that knew what they were doing, knew it was wrong, and did it anyway because it benefited them.

Now they come out with a self-congratulatory crisis management non-apology which seeks to minimize their bad actions at every turn. I'm not buying it.

@OP: This will probably get ignored, but on https://kite.com/languages

why u no Elixir support?

Reply on news.ycombinator.com