>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?
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?
FWIW, Atom's community manager wrote a long comment in one of the Kite plugins' Github issues:
> 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.
It would be challenging to be proactive about it, but it was be a clear solution when they get caught.
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.
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 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.
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.
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.
The image they show in the post shows that they were fairly clearly saying "Where enabled, your code is sent to our cloud":
Sure, it is not exactly hilighted there, but I wouldn't say that they were trying to hide that either.
Taking over the minmap autocompletion projects and adding these features still feels a bit sleazy, but the installer was honest about how it worked.
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." 
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.
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.
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:
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.
I'd generally prefer not to have the git(1) incantation hanging around in an unrelated function.
Here's the original code from the "git-rev" package:
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?
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. 
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.
 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.
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.
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.
It probably doesn't matter if it was intentional hostility or unintentional incompetence. Either way, it needs to be fixed.
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.
The ultimate decision to actually _implement_ all of those changes in those existing open source projects lies with the project maintainers/owners.
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.
I'm not masking anything. If you would like to read between the lines, then by all means, feel free.
I'm looking at this whole situation without passing any judgement. Looks to me like we have a classic case of a company completely failing to execute properly on an idea.
Did they fail? Yes, spectacularly. Was there malicious intent, or some form of intentional shady practice going on? I think the current evidence doesn't support that.
That said, by deed and by words (per their apology) they executed on an "ends justify the means" business model. They wanted more business, they came up with the idea of buying open source projects, took a stab at integrating their functionality with the projects, and people didn't like it.
Don't tell me the people don't have a right to choose how they respond to Kite, business reputation is an actual thing and you can't browbeat people into ignoring their feelings on the issue.
Regardless, whether their strategy was malicious and/or shady is a value judgement best left to the individual, and there appear to be a variety of opinions on the matter. Note that @abe33 does not list Kite as an employer, so it would appear he's hedging his bet on how awesome this idea is.
I didn't say anything about race anywhere. way to read between the lines again and attempt to make my original comment look WAY more inflammatory than it actually was.
I was more equating it to large groups of people getting up-in-arms and angry without actually taking a step back and looking at the whole situation.
To say that is a lynch-mob mentality is 100% accurate.
"lynch" is a racially-coded word in 2017. Google "lynch racially coded" and check the first few hits. That's the mine you unintentionally stepped on here.
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.
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.”
The title “Staying Open” is so full of BS it hurts.
Yes, open-source developers should get paid. But if they take this route, they may lose credibility within the community.
Point is, if we don't consider this sort of behaviour malicious then we can expect to see this more and more often.
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.
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.
Copyright (c) 2017 Manhattan Engineering, Inc - All Rights Reserved
Reproduction of this material is strictly forbidden unless prior written
permission is obtained from Manhattan Engineering, Inc.
> -The MIT License (MIT)
> +Copyright (c) 2017 Manhattan Engineering, Inc - All Rights Reserved
> -Copyright (c) 2013-2016 Kite & contributors.
> -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.
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.
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.
The first link in this write-up is to this story which gives the background:
>Although Kite has no business model yet, it’s widely
>thought in Silicon Valley that having users is the
>first step toward profitability.
>a $4 million venture capital-funded startup
> How a VC-funded company is undermining the open-source community
>A San Francisco startup called Kite is being accused
>of underhanded tactics.
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.
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.
> 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  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" , 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.
why u no Elixir support?