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. While we had good intensions, we inadvertently angered many in the open source community in the process – and we’ve now taken steps to address those concerns.

We’re big believers in open source – we’ve made contributions as individuals and as a company. (For example, see the GitHub pages for Cedric, Antonio, Oscar, Joachim, and myself.) But we messed some things up. As outlined below, we’re trying to fix the issues we created, and we’re eager to hear additional feedback from the open source community.

tl;dr Here are the steps we’ve taken:

• Last week we reverted documentation links from minimap. (commit)
• We added a third-party contributor to the minimap repository to review proposed changes before they are introduced. (link)
• We modified the autocomplete-python install flow to encourage users to more deliberately choose between Kite and Jedi as their code engine – and to make it clear that Kite analyzes code in the cloud. (pr)
• We’re building a private cloud version of Kite for companies. (link)
• We’re working more actively with the open source community to solicit feedback and concerns before introducing changes to OSS projects. (looking for remote community manager; reach us here)
• We’ll be communicating more clearly with the community when changes are made.

The story

It’s Monday morning. I wake up, and do the same thing I’ve done every other Monday morning: check Hacker News.

It’s the dream of every startup founder. 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? 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.

We reached out to the author of an Atom plugin called autocomplete-python. We told him about Kite, how we used machine learning to build a type inference engine that outperforms anything else out there, and we proposed forming a business relationship to work together.

We knew we needed to be careful about one thing: Kite uses large data models to do its job, so we built it to be cloud-powered. We believe that all future code engines will live on powerful cloud-base servers as people use machine learning to code more easily. The drawback of that approach is that users don’t yet expect code engines to live in the cloud. We need to be transparent about Kite’s approach – and we need to give users control over which code gets synced to the Kite cloud for analysis.

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

So here’s how we approached it. When users installed autocomplete-python, they would be shown a “Choose your code engine” screen. (More on that below.) If the user chose Jedi, they would be all set. If they chose Kite, we would walk them through two more steps: one where they needed to input their email address, and a final step which explains the security issues. We described how Kite works on the initial and final steps. If a user didn’t go through all steps, Kite would not be installed.

If a user is working in a directory that isn’t whitelisted in Kite, we show a little dialog in their editor asking if they’d like to enable Kite for the relevant directory.

This seemed to work pretty well. Many users are happily using Kite after signing on through autocomplete-python. (Again, more on this below.)

So we looked for ways to repeat that approach. We reached out to Cédric Néhémie, the developer of Atom’s most popular plugin, minimap.

We were so blown away by his knowledge of Atom’s APIs and his work on minimap that we hired him. He’s built Kite’s deep integration into Atom. (And he did a great job.)

It was just hard to see how Kite could provide value for minimap users. We didn’t want to just show a straight-up ad for Kite. So here’s what we came up with: when minimap users were in a Python file, they would see links to documentation for any top packages imported in their code.

It looked like this (links in the bottom right):

These links would open the relevant documentation in one of our docs pages which include a download link for Kite. These pages look like this (example):

This was a really bad idea.

We didn’t do a good job communicating what was happening – and some minimap users were worried their code was being sent somewhere. (It wasn’t.)

Moreover, the minimap integration just didn’t make sense from the beginning. We told ourselves that we would improve and iterate on the feature, but we didn’t prioritize it. And we didn’t listen to the community feedback.

What now?

We want to do better. Here are some of the steps we’ve taken:

• Last week we reverted documentation links from minimap. (commit)
• In response to requests from the community, we gave minimap write permissions to a third party trusted developer. (link)
• We have made changes to the “Choose your engine” screen to make it less opinionated and to encourage users to make more deliberate decisions. (pr)
• We have also added more prominent disclosure and safeguards in the autocomplete-python flow to make sure users understand their code is synced to, and analyzed in, our cloud. (see above pr.)
• We are building a private cloud version of our servers, Kite Enterprise, so companies can deploy Kite servers on their own AWS and Azure accounts. (link)
• And we are making changes to how we engage with the community, soliciting feedback whenever changes are made to any open source repository. (We have also begun looking for a community manager—remote ok!—to help ensure we do better.)

Conclusion

We built Kite to end the constant copy-paste-search back and forth that plagues our modern coding experiences. We want to empower developers to spend more time on the parts of the job we all love.

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

We will incorporate what we’ve learned from this situation into our discussions with the community moving forward. We would love to hear feedback from you on the steps we outlined above – and any other thoughts you have about how we can make Kite better. (HN thread here.)