Hey Adam, I still remember sitting in a cafe with you after Xobni when you were contemplating what to do next and Kite was a just a gleam in your eye. Sorry to hear this one didn't pan out, and all the best going forward!
Kite is saying farewell and open-sourcing its code
211–220 of 547 posts
Re: Kite is saying farewell and open-sourcing its code
#212sorry to see this happen, but there were early signs.
kite was that autocomplete solution that required you to have an account right? and they shipped your code to their servers? i remember trying it. some of us raised early concerns but our voice is not the loudest.
so again, the main problem is that kite was an intrusive solution for corporate networks. a developer needs to justify, through millions of layers, a solution like it. that it is safe to run it in a corporate environment.
why are you comparing yourselves to copilot? it's github!
not a single CISO will blink at trusting github, or microsoft, or google. a startup? it's not the kind of product that's helpful on a hobby project. the individual developer will pay where it makes sense. it makes sense in the corporate environment where there is tons of code to write.
so yeah, okay, that new terminal thing called warp. that autocomplete in the terminal called fig. you all ask people to create accounts and ship their data home? don't act surprised later.
Re: Kite is saying farewell and open-sourcing its code
#213"Our diagnosis is that individual developers do not pay for tools. Their manager might, but engineering managers only want to pay for discrete new capabilities, i.e. making their developers 18% faster when writing code did not resonate strongly enough." I never used Kite, but I've tried Github Copilot twice, and found it marginal at best (and distracting at worst - which is why I turned it off both times). If Kite wa…
I'd be curious to hear about services/tools developers do pay for. The diagnosis that developers do not pay for tools seems off to me. A few tools that I put on the company card when I worked at a Big Tech Co as an IC: * DataGrip (Jet brains) * Colab Pro (Google) * Postman Pro These were all small $ enough where I didn't need to justify the expense. It was just assumed that if I thought the tool was worth the $, it w…
Yeah I called BS when I read that line too. I pay for plenty of dev tools. Similar list to you.
* JetBrains (PyCharm professional, DataGrip, and Goland) ~$250/yr
* Lucidchart (Diagramming) ~100 /yr
* Paw (HTTP Client) ~$50 /yr
* Docker Pro ~$60 /yr
I think there's probably more, but I'm not at my work laptop to look, but those are the big ones. Those are only individual subscriptions. There's also huge costs when associated with things like Gitlab Premium ($20 - $100 /user/month), CI/CD, Code coverage tools, security scanners, etc. Companies pay A LOT for development tools.
If Kite thinks that the problem why no one will pay $9/mo for their service is because developers or their company's are cheap, they need to re-assess. The reason they couldn't sell their service is because it wasn't providing enough value to justify it. But companies are paying hundreds of dollars a month per developer in most cases for various tools. The extra $9 for Kite isn't the dealbreaker if there was enough value from it.
Re: Kite is saying farewell and open-sourcing its code
#214“Our 500k developers would not pay to use it. Our diagnosis is that individual developers do not pay for tools.” I don’t like depending on something I could lose in a month or tethers me to the internet. I consider that more a service than a tool. I’d prefer to just buy something once that just works, but that business model might be dead too since people will pirate things that aren't tethered to some serverside com…
I think it’s a combination of a few behaviors: Developers have this “if I can do it myself albeit in 10 times more time I won’t pay for the service even if it doesn’t make any financial sense whatsoever” and “This is cool but requires investment of my time while not providing way out of they start to suck or disappear” and “this is clever but what I need is help with the boring bits” mentality.
The stuff most developers are comfortable paying for is things like hosting, tools that do something the developers find very boring or have no domain overlap and don’t have viable free alternative.
“Why would I pay 9.99 if I can set up a free alternative in a few days and host it myself for 4.99? If I can’t host it myself I don’t trust you anyway”
Re: Kite is saying farewell and open-sourcing its code
#215"Our diagnosis is that individual developers do not pay for tools. Their manager might, but engineering managers only want to pay for discrete new capabilities, i.e. making their developers 18% faster when writing code did not resonate strongly enough." I never used Kite, but I've tried Github Copilot twice, and found it marginal at best (and distracting at worst - which is why I turned it off both times). If Kite wa…
Copilot had 400k paying customers within it's first month [1]. I'm not a fan of mass generalization about large cohorts of people. Will everyone use a tool? Of course not. You just need dedicated early adopters that see the value add.
Without having tried it I'm assuming either their product was not good enough or their marketing department isn't strong. Developer really tend to neglect the latter.
[1] https://www.ciodive.com/news/github-copilot-microsoft-softwa...
Re: Kite is saying farewell and open-sourcing its code
#216Earlier quoted context omitted.
plus, again, they had zero developer trust because of all the ultra shady stuff they did
What shady stuff they did?
The only shady thing that I recall is that they quietly added telemetry into Atom after they took over maintenance of it, without communicating this to Atom users.
Re: Kite is saying farewell and open-sourcing its code
#217Earlier quoted context omitted.
I pay for copilot. It saves me a modest number of minutes of time per week. That's worth a small fee. And before someone jumps in: I and my other co-founder who also uses copilot (We are the only two in the company who do, I think, without checking) are the compliance team. We're both very senior and use copilot basically a line or three at a time as a smart autocomplete. It's still worth it.
> [we] use copilot basically a line or three at a time as a smart autocomplete. I think this is the best way to think of CoPilot. GitHub is selling it like its going to write all your code for you, but in reality it is just next-generation auto-complete. That's not a bad thing. In some ways I'd argue its actually better. GitHub needs to change its marketing because even most developers seem to think that its out ther…
I found copilot to be less useful than autocomplete. Typical autocomplete suggests things that actually exist and work in the codebase. While Copilot would suggest things that look superficially like names that exist or ways I might have named it, but very often just wrong.
I find typed languages like Rust or Typescript make VS Code super powered and provides much more value than copilot.
Re: Kite is saying farewell and open-sourcing its code
#218Earlier quoted context omitted.
It's interesting, the ones I've spoken to are extremely suspicious. "GitHub Copilot blocks your ability to learn." Is a common refrain. I don't see ANY industry-wide consensus on whether GitHub Copilot truly helps developers right now. The only scenario I can get anyone to agree on is generating templates. Aka, JSON or CSS files that you then edit.
Everyone I've spoken to who has actually used it thinks it works extremely well. This includes pretty experienced developers. I've never heard anyone claim it blocks the ability to learn - if anything it's the opposite. Many people like how it shows you APIs you weren't aware of.
I think copilot works very well.
But I did find that I need to turn it off at certain stages when learning (or re-learning) a programming language. It's seemed counterproductive until you have a good grasp on the basic syntax of the language. But the "showing you new APIs" does seem to be a thing that actually helps.
In general, you should not be accepting code completions that you don't understand. I'm usually stricter, in that I only typically accept completions that line up with what I was planning to type anyway.
Re: Kite is saying farewell and open-sourcing its code
#219Earlier quoted context omitted.
I wonder if this says something about the nature of test code?
Test are always mostly boilerplate and rarely include anything crafty. 95% of tests are: instantiating a class, running a method, and then asserting that the result. Tests do not or should not be crafty creative code snippets. They are boring functional code blocks by design and most are very similar, only changing out inputs and assertions between tests.
I'd go so far as to say if your test is doing something crafty, you're doing tests wrong. Maybe in a mock or fixture, but that's a write-once sort of affair.
I also don't apply DRY (don't repeat yourself) to tests. Tests should be independently readable beginning to end, no context needed. After all, the true value of a unit test is to take a block of code too complicated to easily fit in your mind, and break it down into a series of examples simple enough to fit.
Re: Kite is saying farewell and open-sourcing its code
#220Earlier quoted context omitted.
It's interesting, the ones I've spoken to are extremely suspicious. "GitHub Copilot blocks your ability to learn." Is a common refrain. I don't see ANY industry-wide consensus on whether GitHub Copilot truly helps developers right now. The only scenario I can get anyone to agree on is generating templates. Aka, JSON or CSS files that you then edit.
It doesn't block your ability to learn any more than any auto suggestion systems. But I guess it depends on what you value in terms of learning, for me, copilot allows me to focus on the larger architectural problems while not having to worry about the exact syntax of certain things (DSL query language, middleware express, typescript def annotations, etc). Every time I don't have to context switch to look up some tec…
I observed one guy become very resistant to reading the docs as they believed copilot obsoleted them. Programming in Ruby, the copilot suggestions will run but since you didn't read the docs you won't know that the output doesn't actually work or doesn't do what you think it does since it was intended for a different situation.