> Our diagnosis is that individual developers do not pay for tools.
I know this first hand, building a developer tool startup and failing to reach any level of revenue. In the end, the tech was bought out by a larger company to recover a fraction of our VC investment.
The challenge is that when you're building software for developers, they already know how it must work.
It's like trying to sell magic tricks to magicians. Sell magic to regular people, and you'll see some significant revenue.
I've used Kite before. It was ok. But I am a SWE. It's entirely possible that Kite would have seen major adoption if the push was towards non-technical folks trying to get their feet wet in software. Eg: Data scientists or business.
The reason why BI tools sell so well at the moment is that you have tons of C-level execs that like the appeal of a business-optimizing tool requiring little to none of any actual software development.
Let that be a lesson to everyone. You can't blow away developers. They're just too damn ~~smart~~ well-informed.
Edit: Another anecdote: A buddy of mine built a bespoke OCR and document indexing/search tool. He has ~60 paying clients (almost exclusively law-firms and banks) that primarily work with printed pages on paper. No Saas. No free tier. The client data resides on an on-premise Windows box, avoiding issues with sensitive data in the cloud etc.
He's a solo dev with support contracts and nets something like $1000/month from each client.
For your average lawyer/paralegal, the ability to locate and reference a single page from thousands of pages in under a second is magic. So they pay for it wholeheartedly.
I’m a web developer. My company pays for JetBrains IntelliJ for me. And I love it. But, if I had to pay for it out of my own pocket, I’d use VS Code instead. I’ve used both and IntelliJ is superior to VS Code, but not to such an extent that I would pay my own money for it. But I’m more than happy to have my company buy it for me.
JetBrains IDE's is the most notable exception of dev tools I personally pay for, insane value and productivity makes it a no-brainer purchase given its instant ROI from time saved. Life's too short to not maximize your productivity for a few $'s.
JetBrains is a great example. People pay them because the product is by far the best and the cost is reasonably humble. I think it wouldn't make the same total revenue if they were selling it for twice the price.
Most software sales are more elastic and would sell closer to half the number of units at twice the price, not meaningfully increasing revenue. (This can be good or bad, depending on the industry and the competition.)
I'd pay for it if I did enough programming in my day-to-day life that it would justify the cost. But I only occasionally get into the swing of doing a project, and even then I've never made money off of any of them.
I still have my university email (graduated in 2020) so I've been renewing my student license that gets me a free license for the occasional times I use them.
I kinda wish they'd just go for the Winrar or Docker business model, where it's free for individuals but businesses have to pay up.
Also, even though it's "expensive" for an individual user, you own a full version forever!!! That makes the several hundred dollar price tag much less of an issue.
Yeah, I jumped in when they first did subs back in 2015 (IIRC). Nowadays, the charge seems pretty trivial for what you get, though I think they may have just raised it on me a little to closer to $175.
I also jumped into a personal O'Reilly Safari subscription way back when the price wasn't as high as it is now, and I've kept that grandfathered subscription up as well.
I think between the two, it ends up being a bit less than $500 a year. That's not very much at all against a tech salary, and the O'Reilly sub actually has been quietly useful for work projects now and again too.
My basic take is 1) A builder should have their own set of tools whether they hew wood or numbers (and not everything fits neatly into Visual Studio Code, though I probably use that as much or more than Jetbrains); and 2) if I ever do manage to squeeze out a profitable side project in CA, I want my argument that I'm not using my employer's resources in any way shape or form to be very very solid.
In CA, who owns the resources is the difference in who owns that product. For the same reason, I always buy my own cell phone and pay my own cell phone plan, even if a corporate phone is otherwise forced on me, and always own my own laptop as well for any personal development that comes up.
It's a touch on the paranoid side, I guess, but I just feel better knowing I can be as independent as I want to be with my tech stack. With my own tech library to lean on, a nearly universal set of build tools licensed specifically to me, and my own devices for communication and development, I feel very comfortable that there's no implied shared resource argument that can be made.
JetBrains IDEs are the only dev tool I pay for as well. I write kotlin professionally and for fun and the Intellij + Kotlin experience is the most I've enjoyed writing code since my early days learning Ruby.
Kotlin is such a lovely language, and I really like that it was made by JetBrains because that means I can count on a top notch IDE/development experience.
The fact that Kotlin was created by JetBrains and appears to require their IDE to be productive is the reason I have no interest in it. I'm totally blind and while JetBrains IDE's are technically accessible with my screen reading software they are difficult to use unlike VSCode which makes an effort to be plesent to use with screen reader software not just technically possible to use.
I've always used VSCode and I really don't see what it is that JetBrains can do that VSC can't. Any time there's a new language I'm picking up I can almost always count on a good extension to provide all the necessary intellisense I need.
Good to hear they've done a better job with their screen reader accessibility as well. I learned to use VoiceOver a month ago (I do a lot of front-end dev work) and ever since then I've had a lot of appreciation for any app/site that manages to pull do it well
Who said that kotlin requires intellij? Not a rhetorical question. I've never heard that claim before. Afaict there's nothing about the language that would make it impossible to use in another ide.
This is one point that worries me about Kotlin (which I like a lot). Is it even practical developing in Kotlin using something other than IntelliJ?
All of its toolsets come from the same company, which could kill it one day.
Yes, but the work you do has commercial value to you also, based on its merits alone.
Example: without Intellij, you deploy some back end code interacting with an OCR solution.
Example: with Intellij, you can build the whole OCR solution yourself.
Doing the latter translates long term into higher salaries and more money in your pocket. You have to talk about what you did in interviews and your answers will be reflected in the offers you get.
The only way this would not apply would be if you can say “I am absolutely sure I will never move on from, or be laid off by, my company,” which is not a recommended strategy in this economy.
Few times I tried JetBrains rider trial because was fed up with Visual Studio performance issues and occasional crashes. But rider won't even compile my solution OOTB. Meh.
I’m coming to feel this way about github copilot, especially as a solo dev right now. Is it perfect? No. But it works often and spits out code that’s a good enough template or good enough, and is something i’d likely find on stackoverflow anyway. It’s kind of like I’m reviewing a junior/mid dev’s code and almost like I have a second person working with me which I find very valuable.
Disagree. The comment I replied to was about personally paying for tools. My read was that they meant for personal use. And you started the snark, not me.
regardless I think a point was missed that you might end up pushing up code produced by copilot that could get your company in legal trouble
While I think this concern has a lot of merit, I use Copilot a lot almost always just as a fancy autocomplete. I wouldn't ever let it produce a completely new piece of code for me and I imagine most other devs using it have the same practices so this critique never really hit
I personally pay for Intellij but lately I've found it harder to motivate when vscode provides a very similar experience and especially since Python is supported out of the box for vscode.
I personally find JetBrains IDEs' capabilities exceed that of VSCode. The IDE just feels better thought out to me. However, the convenience of VSCode Web/GitHub Codespaces far exceeds that of JetBrains IDEs', so that's where I'm at now - on-demand web-based IDEs and a thin client.
After trying it a bit more I am slightly leaning towards keeping Intellij again. Mostly because of being better at the small things. Like more readable file tree-view and better project search tools.
Secondly, not everything and everyone from Russia is bad. But if you subscribe to that narrative, good for you and good luck finding a tool that comes close to JetBrains.
Could you point me to a couple videos of Czech JB devs talking at Czech conferences in Czech?
Asking seriously. Because I was a russian speaking Ukrainian until recently and used to listen to tech podcasts and talks in russian all the time, for years, starting back when JB products just started gaining popularity. Not once was the company or it's products regarded as Czech by russians. It was always talked about as russian, all the podcast guests from JB were russian, all the conf speakers were russian.
Now, it wouldn't be the first time russians appropriated something that wasn't theirs. Which is why I'm asking if there are actually any signs of JB operating in Czechia outside of company being registered there. All I can find is JetbrainsCZ youtube channel with whopping 44 views on its single office walk video.
They say they had three R&D offices (out of 6) in Russia and closed them in March 2022.[1] 131 out of 161 open positions on their career page list Prague as one of the possible locations.[2]
Why should an multinational IT company aiming at developers talk in a local language? How does a heritage of founders matters? Google is half a russian company by that metric, as in "Sergey Brin".
JetBrains is a Czech company because it was created in Czech Republic and is operated from Czech Republic. They've had significant development resources in pre-war Russia, like many big companies, because it was a cheap and good. As the war started, they've rescued whoever they could and closed their russian offices.
The war started in Feb 2014, just saying. JB closed offices only when they become afraid of getting squashed by new USA secondary sanctions, not because they opposed war.
Depending on what you count you could give a number of other dates, some significantly earlier than 2014. The current massive offensive, which is significant enough that pointing out they reacted then and not in 2014 or some other date is at best being facetious & disingenuous, started in force in Feb 2022.
JetBrains where silent when the war started. I was a bit worried what would happen. Then they announced the closing of the dev offices in Russia. They said that they needed to extract some people before announcing. It’s not an easy task relocating hundreds of people.
Well, there we go. The grandparent comment argued that JB is a russian company (as in employing mostly russians) and it may not be a right thing to do continuing to pay pretty salaries to people responsible at the very least for letting their country slip into genocidal fascism, while they enjoy their new life in Europe and the regime they helped raise continues murdering Ukrainians and kidnapping their children.
> Could you point me to a couple videos of Czech JB devs talking at Czech conferences in Czech?
Do you have examples of them not talking Czech at Czech conferences? Not talking a particular local language at an international conference is not a significant metric IMO. A great many companies from all over the world send people out to speak English (or at least American!) at conferences. As a linguistically ignorant Englishman this is rather useful to me, but it doesn't make those companies not French, not German, not Indian, not Chinese, etc.
Heck, if (caveat: speculation, I've not looked into this at all) Russian is a common enough second language in the country (or at least amongst local+visiting delegates for conferences about these subjects) then some talks at a conference in the Czech Republic being in Russian would not be surprising, much like you see many talks in English/American countries where English is not an official language (and similar for other languages that are significantly more common if you count people with them as second+ languages as well as native speakers).
> used to listen to tech podcasts
The issue is more acute with podcasts than conferences: the audience is international, so they might not have the luxury of using their native language while serving a large enough target audience.
> Because I was a russian speaking … listen to tech podcasts and talks in russian all the time
I see much room for confirmation bias here. What reason would they have, beyond national pride which is valid of course, to make a point of explaining “we aren't Russian BTW” on a Russian language podcast? Especially give that could be seen as a bit of a down-play of the Russian audience if national pride works the other way against them.
This sort of fundamentalism isn't what stimulates societies to make peace, which you ostensibly want. The way to peace is tolerance and getting Russia to see that too, not drawing lines in the sand and beating your chest. That leads to more war. It is easy to see examples of this, as the US has been doing this for as long as it's existed (at least, when it wasn't at war with itself - and even then).
If you think what the US did in the middle east was bad, you ABSOLUTELY should stop helping america profit. Just because nobody has the balls to actually punish america for the horseshit we have pulled, doesn't mean it's not the correct thing to do.
I have been paying for Resharper (and now Rider and DataGrip) for over fifteen years. Some companies where I worked paid for it other didn't but it didn't matter. It improves the quality of my code and I believe it gives me a competitive edge. It also helps keeping me sane as I work with a lot of legacy code.
I see it like a construction worker that uses his own tools instead of the broken down ones of the site. It makes good business sense that I can work faster and better when I use better tools. I also pay for other tools such as dbForge and SmartSvn/Git but Jetbrains' tools have been the longest running ones (I hope this does not sound like I am a fanboy or something).
Resharper is really great for VS, and I would probably be willing to pay for it if the performance were a bit better. Some of this is probably VS' fault. I'm excited to try CLion again once my project supports it, but from what I remember the debugging experience is not so good.
This is a product that I actually _would_ pay for as an individual. It's reasonably priced and worth the increase in efficiency and better experience. Plus their pricing is fair and flexible.
Yes, it seems fair to me to spend real money on Jetbrain's tools, if you like them.
It is strange how reluctant programmers are to spend on tools even though they are, as a rule, quite willing to let themselves be paid handsomely for their services. Yet graphic designers pay for Adobe's tools. Who can read this riddle?
Important caveat here. My only exposure to JetBrains had been through Intellij which was thoroughly unpleasant around 2012-2013. That impression has left me forever sour towards them. Surprised to hear people say that it could be a step up from VSCode.
It looks like "Fleet" is their VSCode competitor? I'm not sure if the homepage does a good job at communicating how this improves over of VSCode. First of all VSCode has an enormous ecosystem of tools which seems hard to replicate. In terms of advertised features for Fleet, it seems like the one most highlighted on the page is multiplayer, which would possibly enable others watching me code live? Sounds nerve-wracking. Although I could imagine some helpful scenarios when pair-programming or something.
Other items that are advertised don't really encourage me to want to make the leap, especially as something I have to pay for. It sounds like they could host your code, or something like that, which could be nice. An annoying part of my workflow is that I work on the same codebase between multiple machines and every time I hop between machines I have to commit the changes to a private repository that is separate from my team's repository. It seems like it would be somewhat straight-foward to have the same code shared between all machines.
Other than that I would be interested to hear on how any Jetbrains products would improve productivity.
> Surprised to hear people say that it could be a step up from VSCode.
VS Code is very* lightweight. Both in speed and in features. Comparing it with IntelliJ makes it seem very basic. Now, for some people that’s okay, but JetBrains IDEs are full-blown IDEs.
*: Compared to something like JetBrains tools, or literally any other electron software.
For TypeScript there's little difference since most of TypeScript support comes from the same language server running in the background (there's an option in the menus to restart it if it breaks, same as in vscode).
Although autocomplete is better (especially for pure JS), it doesn't warrant paying for a license IMHO. Personally, I use IDEA for TS because I use it for other languages where it blows everything else out of the water (so muscle memory).
Also, if you're doing server-side development, it has a very good built-in client for two dozen databases (which pretty much replicates the functionality of their DataGrip product), so you get decent data editing / import / export / DDL support, and excellent autocompletion for your SQL (interspersed among TS code, or not — doesn't matter).
Edit: also, 100% of their products' funtionality can be used from keyboard. I don't touch the mouse at all. I think vscode can support something like that, but with very heavy customization (and even then I'm not sure). Out of the box it pretty much forces you to use the mouse for many things.
I almost never use the mouse in vscode, emacs keybindings and the command pallete and keyboard shortcuts created any time I touch the mouse. But I also don't get everything I want, (like macros and web browsing and face customization and rectangular editing) that I get with emacs, so I only use vscode for liveshare.
Incidentally, I use and pay for tabnine (another ai assistant) in emacs and it's fantastic - single line completions are superior to whole snippets I have to read with copilot, and don't get me out of my flow.
I am surprised the tabnine company completions are way easier to work with than in vscode. With grouped backends, company lsp + company tabnine is great. I'd encourage kite users to try it. Well worth the money.
Even if JetBrains does support your language more "natively", what makes it better than using a language server?
As a student I can use JetBrains tools for free but personally, I'd much rather use something like VSCode combined with clangd than e.g. CLion, as I don't see anything that would make CLion better, while the JetBrains UI is downright cluttered.
As for keyboard use, the command pallete (Ctrl+Shift+P) is right there and should be able to do anything. And thanks to the magic of language servers you can use any editor you like, including (Neo)Vim or Emacs, while keeping most of the capability for language specific stuff.
— advanced refactoring for all supported languages: implement interface, extract interface, automatic "generification" for methods and classes, stuff like that. Saves quite a bit of manual typing.
— built-in database client (which I have already mentioned) which also provides autocompletion for database/table/column names, both for SQL queries, and various supported libraries like ORMs.
— navigation (jump to definition/declaration, find all references, etc.) works everywhere: any supported programming language, XML, files like JSON schema, YAML, you name it. For example, you can put the cursor to a primary key of a table, press your "find all references" shortcut, and it will show the list of all foreign keys referencing that primary key. Same with things like URLs on the client side (for example, the first argument to the browser's fetch() function) — put the cursor on the URL, press "jump to definition", and it will jump to the controller method that implements that URL, including the correct HTTP verb if there are multiple method for that URL. This is just one example, there are dozens of little things like that. All that makes it much easier to work with fullstack projects (to me at least).
— the UI and its "control interface" (so to speak) is consistent. For example, you use the same key combination to jump through search results, list of issues, list of references, etc. etc. Same for other key combinations — they jump make sense, you press what you think will work and it usually just works.
— it also supports fuzzy search everywhere, not just in the command palette. For example, you open up the list of databases, start typing in the name of the table (or database, or foreign key, or procedure, or whatever), and it highlights matching entries and lets you jump between them. Press Up and Down to go though its suggestions. The same mechanism works in filesystem tree, search results, issue list, and so on.
> JetBrains UI is downright cluttered
All of that can be hidden. I have the filesystem tree to the side, the main editor taking 90%+ of screen real estate, and the tab bar on the top, everything else is hidden behind a keypress.
> As for keyboard use, the command pallete (Ctrl+Shift+P) is right there and should be able to do anything
This is not the same at all. Everything can be done through keyboard shortcuts without typing in obscure commands (even though fuzzy search helps, it's pretty slow).
You should use what you think is convenient, I'm not forcing anyone. The more pressure you put on JetBrains by using the alternatives, the better for us.
My understanding is there's Fleet, their VSCode competitor, which sounds like you're referring to, and the UI refresh, which parent is referring to.
The UI refresh is the same IDE under the hood, just way simpler. I control the IDE primarily through command palette (I think many do?) so decluttering would be great- the UI is unnecessarily complex when you can press a key and type a few words to do what you want.
I feel like most of these can be accomplished in VSCode with an extension... We use GraphQL at my work and the amount of coworkers I've run into that don't have the GQL extension installed kinda surprises me. It makes a huge difference so part of me wonders if the criticisms of VSC not being "full-blown" enough is just people not being aware of available/relevant extensions (also probably why VSCode now randomly suggests possibly relevant extensions now)
In my experience JS autocomplete in IntelliJ isn't better, it just shows more stuff. Most of it unrelated and won't work / will be `undefined` if chosen.
It does, however, teach junior developers that the autocomplete is unreliable, which is a good thing I guess — I've seen juniors in statically typed languages like Java fail coding interviews because they couldn't remember any of the syntax, the knowledge was contained in the autocomplete and didn't transfer to a whiteboard.
I do agree IntelliJ's autocomplete is kinda crap out of the box. But if you turn off all the machine learning stuff it's back to being alright.
> I've seen juniors in statically typed languages like Java fail coding interviews because they couldn't remember any of the syntax, the knowledge was contained in the autocomplete and didn't transfer to a whiteboard.
Is this really a problem? How much Java code does anyone write on a whiteboard outside of an interview or teaching setting?
This is only a problem if they wanted to get hired, and then failed the interview because even the basic syntax of their language of choice is unknown to them in the slightest.
I didn't invent the rules, I'm just doing the interviews, occasionally from both sides of the table.
(However if I did invent the rules, I'd probably still require e.g. a Java developer to know Java at least a little bit. Is this really controversial?)
Their support is also often stellar - if something breaks in a free product, get ready for some free support also (read, none, DIY).
And, maybe you think fixing your IDE yourself makes you a better developer - if you are building IDEs, maybe, sure. I'm more than happy to outsource that a company which does this as its bread and butter.
Microsoft, on the other hand, sells (or tries to) enterprise office solutions. They may have optimized for a single use-case (TypeScript), outside of promoting their web-strategy (typescript), I wouldn't expect them to care one lick about VSCode, once it stops being particularly important.
To be fair, there is a FOSS binary distribution of VSCode -- VSCodium[1], though it is maintained by the community. It operates in a similar way (licensing-wise) to IntelliJ IDEA Community vs. Ultimate.
I write a bit of TypeScript recently in both VSCode and WebStorm, I also have many years of experience using both tools. Started with VSCode since it lightweight and this is what I use to edit most of the text. Unfortunately VSCode had troubles indexing the project, refactoring, figuring out types and navigating between methods. Everything works but VSCode hangs for a few seconds every time I do an action that needs a code analysis e.g. go to a method definition. Most of the time it was faster to search and replace rather than to rename a method. WebStorm was the opposite - opens in a few seconds, but then everything works instantly.
I use both, and it really depends on the language.
Something like Java is really benefitted from IntelliJ, Spring integration is excellent, but especially scripting languages like Python or JavaScript/Typescript don't get enough uplift and you might as well use VS Code.
I mean for Java. IntelliJ is made for Java. If you want to do Python, Jetbrains (the creator of IntelliJ) made PyCharm. For Javascript, they made Webstorm.
Granted; I was very junior then--and I think my issues may have been mostly related to the finnicky nature of java tooling and dependencies rather than the IDE itself.
I have to say I had the same experience with IntelliJ when developing for Android in 2013-15 or so. This year when trialing CLion I was very positively surprised by the evolution of their platform, it's easily the most usable environment for C++ development I have used.
I have experience from pure VIM, VSCode, Visual Studio for Windows, the reliable refactoring features alone are worth the price. With VSCode I would find the refactoring support not reliable and the intellisense features also might just stop working randomly depending on the project.
Prompted me to move to WebStorm also for web development, and I must say I have been very positively surprised there also.
Seems they have made some important strides in the past years, can highly recommend testing their environments out.
I think it’s because the free and OSS tools are of such a high quality for developers. There is a much bigger chasm between GIMP and Photoshop than there is between VS Code (with plugins) and JetBrains.
It’s hard for many to get over the fact that JetBrains is infinitely more expensive than VS code in dollar terms.
> There is a much bigger chasm between GIMP and Photoshop than there is between VS Code (with plugins) and JetBrains.
I don't believe this to be true. I think the difference is graphic designers tend to use much more of their toolings' functions, whereas almost every day I'm surprised someone I work with doesn't even know some IDE feature was possible, let alone how to use it. Hell, almost every frontend developer I've ever seen use either VSCode or WebStorm orchestrates everything from the built-in terminal and is baffled when they never see me use one - because it's all configured via run configurations, and that's a _basic_ feature.
That makes sense though.. Terminal commands are easy to put into team wiki or record in personal notes or put into your CI config. There is a command history, it is easy to chain commands, etc..
Unless using IDE's native tooling is making you much more productive (say its debugging does not work without it) it is better to avoid it if possible.
IDE's native tooling makes you more productive because you set it up and never interact with it. If you need to manually do stuff, or do it all the time, you can slap it behind a keybinding. My cmd+F6 to do everything that needs to be done to get the iOS app built and debugging inside a simulator is obviously going to be more productive than having to jump into the terminal every time. Ditto for the run configuration (also cmd+F6 in a different project) that spins up docker and all that blah blah to get the API server running.
This is what I'm talking about, for what it's worth, a programmer doesn't immediately see the utility in the tool and doesn't use it, and that's the story for 99% of the things an IDE does. It's always faster to do it yourself once, or twice, especially considering setup time and learning curve, so people don't make use of the tools. I see people using grep instead of their IDE search because they cbf to figure out how to do it in the IDE!
> Unless using IDE's native tooling is making you much more productive (say its debugging does not work without it) it is better to avoid it if possible.
I have a friend who works as a dev for a decently sized software editor, so he's seen his fair share of people interacting with the tools. They work mainly with Java and the company pays for Intellij for everyone.
He's often complaining about how people never try to learn the IDE and always do things manually. They usually don't really know what they're doing in the terminal, either (they mostly use Windows, so the terminal is rarely second nature).
But whenever he shows them a few nicer features, typically around refactoring and such, they're always blown away and never look back.
He has, of course, interacted with his fair share of graybeards who only use vim, but those people don't usually take ages to accomplish simple tasks.
Because I'm always disappointed with paid proprietary software eventually. Despite some shortcomings, I used Windows 7. Anything after that had a confusing interface with two settings panels, some kind of an attempt to bring a tablet interface to desktop, loss of control over my computer.
After installing NixOS, I never actually boot into Windows 10 anymore. Naturally, I never use MS Office or Photoshop anymore.
It would feel weird to buy some proprietary software, even if it is good. Why not contribute to an open source effort?
I donate to the FSF and subscribe to iTerm2's patreon, FWIW.
I have to admit, though, I think the world would be a much more drab and less productive place if open source were completely dominant. We'd all be chiding each other to donate more and pitch in more, while barely scraping by in comparison to the vast wealth sloshing around today. Maybe it would be a BETTER world if it weren't all fueled by addictive mobile games, privacy invasive advertising, etc. But we'd be a lot less rich
> It is strange how reluctant programmers are to spend on tools even though they are, as a rule, quite willing to let themselves be paid handsomely for their services.
Ability to find someone willing to pay XYZ for foobar does not imply that I am willing to pay the same amount of money for something similar.
In fact, by doing this exact transactions it means that I find such transaction advantageous for me.
Also, I had enough stories of lock-in and losing access to proprietary systems that I prefer vastly inferior open source.
Also, I am not aware of paid systems worth paying for.
I use primarily Linux (Lubuntu), git, Codium, Python, Kotlin, pgsql, Android Studio, LibreOffice, Firefox, uBlock Origin, Leechblock, sqlite.
For what I can pay that makes it worth it? For contributing back, I prefer working on code over donations (due to geoeconomical situation and ability too direct my effort precisely where I care about things over donations often being wasted)
I also pay for JB tools. But that's because it's well beyond me or other open source developers to make a product that's competitive with it, and the competition is well behind (VS Code and Eclipse are good, but once you learn IntelliJ more advanced stuff, you feel like a programming God - something worth paying for ;) ). An IDE is insanely complex nowadays. I am not sure what Kite had in mind, but to me, what they were proposing would be "just" an IntelliJ Plugin. And I don't pay, and can't see myself paying, for any plugin.
I am glad to pay for software, but I want it to be free as in freedom: I insist on being able to modify, fix, extend and share it. So all of my tools I rely on are AGPL, GPL or BSD-licensed.
Graphics designers don't have much choice because even if they decide they are entirely fine with free program, the graphics design world runs on Adobe file formats. Not the case for programming
Because developers want to be able to hack on their own tools: fix bugs, add features, whatever. Graphics designers do not have the skills to hack on their own tools, so there isn't a huge population of them sitting around going "damn, I wish I had feature X -- I know, I'll build my own editor and open source it!"
Some do. Probably over-represented on HN. Others want to work their hours and spend the rest of their time with non-technical hobbies, or with family, or literally anything else. If that isn’t you, no big deal. But we should not paint all developers with the same brush.
Enough developers want to hack on their own tools that the market is smaller than you would naively expect, counting the number of developers and how many tools they each use. It's a bit like asking "how come we're having so much trouble selling our extended warranty to professional mechanics, even though professional drivers buy extended warranties all the time?"
The real reason is that there are free alternatives. For many people, “free and open source” is the same as just “free”.
Again, I can fix most things on my car. I can afford the tools needed. But I don’t want to because opportunity cost.
One thing I have always found weird is the whole, “hey can you look at my computer? It is all slow” is considered okay to ask anyone in IT, but it (at least in the circles I was raised) inappropriate to ask a mechanic in the family to work on your car, the accountant to do your taxes, the plumber to replace your toilet.
And even with mechanics, some like to work on specific cars as a hobby, much like an engineer might want to play around with ML and work on a CRUD app for pay.
Think about having a friend who is doctor. We might often just ask them hey I have this pain in the neck what do you think could it be? It is not seen as asking them to work for you but merely asking for advise, like you might ask any friend. Advise is free right? And the person asking you for advise is happy to give their advise to you if you ask them. Reciprocity!
The problem with the computer MIGHT be very easy to fix if you know how to fix it.
But if you accept their invitation to help them then you don't want to just give up after 10 minutes. It would make you look not smart if you could not help with the problem after all. You have been hood-winked into working hard to look good.
The worst part is if you do something to their computer and some new problems appear later, you will be responsible.
I think family mechanics and accountants do get asked for help. Plumbers maybe a little less.
I think there's an accurate perception that IT work is generally air-conditioned and doesn't involve physical danger or sewage, so it's not as big of a deal to ask for help.
Simple. I told my parents if they buy either a Windows computer or an Android device, I couldn’t and wouldn’t help them (yes they can afford Apple devices). During the height of Covid, my dad had emergency surgery and I didn’t want to go see him when he was already weak (he’s better now). I sent them an iPad because it was much easier to use with FaceTime than figure out which badly integrated video calling solution that Google was pushing this week.
Good god no, I just want it to work. I used to be that way, but you can be too in love with customizing your tools to the point that it gets in the way of doing your own projects. I do not want to spend all my time carving better knife handles.
I think about writing my own IDE sometimes, but then I think how all-consuming such a project would be, and having to support a userbase made up of developers.
I don't often hack my own tools either, but it's great to have the possibility to do so.
When you really need that bug fixed for your edge case or platform, it's much easier to submit a patch rather than wait around for someone else to fix it.
Call me biased because I hate java. Oddly if a person hates Java, they should love intelliJ. I hated PyCharm because of its Java-centric heritage. I am a CLI guy. The closest I've come to loving an IDE is VSCode.
You may want to reconsider, or rather, consider the value of your own time.
If you value your time just even a little bit, consider how many of those tools are multipliers.
Obviously not 'JIRA' for a single dev, but in many cases JetBrains is worth it.
Would you wear Basketabll sneakers out for a jog? Well you could, but if you're going to run buy a pair of running shoes. Probably once a year. Costs about the same as Jetbrains for a year - as a very crude analogy.
I am in charge of the Software Team and do have financial support from the company e.g. if I deem a tool necessary it will be purchased – no, or little questions asked. It was insanly hard for met to justify, untill I saw the stuff marketing buys. Best decision to get the tool for our team
As a C dev I pay for CLion out of my own pocket. Partially because it's a great quality tool, and partially because there's not enough good quality tools for working in C on the market so I like to support the ones that do
I sat through scores of interviews and pairing sessions with developers back when Sublime was a thing and the vast majority (>90%) of devs would rather exit out of that pop-up asking for support then pay the measly $30 or whatever regardless of their massive incomes and increased productivity that Sublime brought them.
We developers are no more altruistic than anyone else regardless of the lies we fed ourselves in the early days of FOSS, internet, bitcoin, etc.
It's worth mentioning that a ST4 license is $99 USD (and ST3 used to be $80).
Still a relative drop in the bucket for how powerful ST is and how much value its users derive from it, but there _is_ a bit of sticker shock when comparing it to most other software.
I say this as someone who, as a broke college student, got very good at hitting esc every 10 times I saved (which is how often it asks). I eventually switched to VSCode, and the rest is history.
I've been using Sublime Text for as long as I can remember and being good at exiting the popup is pretty accurate, I feel as if I don't even recognize it being there anymore.
> the vast majority (>90%) of devs would rather exit out of that pop-up
Converting just 5% of users to paying customers is considered pretty good for shareware/freemium, so just because you saw a lot of people using the trial does not mean it is unsustainable. I have no idea how much the developer of Sublime Text makes, but considering that they have been around since 2008 I would assume it's definitely sustainable.
Yeah, but it's generally the kind of money that only allows having a mom-and-pop store. 1-2-5 employees, that's it. If you have a bigger initiative, you can't do it.
Instead, Mega Corp just buys you out when you burn out after many years of development, we see this happening regularly.
In general I think you are probably right. Many developer tools are small projects that can be developed by a single person, and it seems they often struggle to grow into to a bigger company. (I've experienced this struggle myself. For me, the problem was not lack of money)
On the other hand, I think Jetbrains shows that it is absolutely possible to build a huge company that sells nothing but developer tools.
There are also a bunch of mid-size companies that sell developer tools. I'm pretty sure there's more than 5 people at Navicat, Hex-Rays, or Panic, but I'm not sure how big these companies actually are.
I'm a contractor so my case is a bit different, I can't expect a client to pay for every tool I want to use. But I gladly pay for Sublime Text and Sublime Merge because it makes my work more enjoyable and effective, and this is also good for whoever is paying me.
I pay for tools independently if they are affordable and I can use them commercially (even at work, even if my employer does not pay for it). I pay for JetBrains yearly and am at the lowest renew cost as a result, so theres no incentive for me to stop paying them yearly. I also saw that you can get Visual Studio Pro for $45 a month, which is really decent considering you get a professional grade IDE all to yourself.
The other thing is they have to be tools I want to use. I am an outlier I am sure. I hear often "let your employer pay for it" but they don't always necessarily pay for the tools I need to use. Having my own JetBrains license grants me strong freedom.
They do pay, but they can not pay same amount as some corporation can. If you target individuals you need to find good pricing model for them. The best model - at least for me, that always attract me is pay for a year of subscription to updates. After 1y passes you can pay at lower rate to continue receiving updates for new features and bug fixes or you can continue to use the latest version before your support has expired. I'm hooked instantly to this since it brings me value without constant commitment. One year I may decide to extend one tool, the other I pay extension for other tool.
Jetbrains' pricing model is also good, they reduce price each year (until 3rd), so you get rewarded for having a long term subscription. If you break commitment you get the regular pricing and you start over.
I remember trying Kite, but I removed it once I saw the pricing. It was more expensive than Jetbrains IDEs (which are less than 2$ a month for individuals when you pay in a bundle - 149$ at the time) which bring much more value for the money. For me it didn't make sense to pay 20$ for just incremental improvement (if even that) over Jetbrains Intelisense.
I (=as the employee of the company) often don't want to bother to pay, because a business case, then getting the invoice right (if that is even possible and the seller allows paying by PO), then getting it paid in time, is often not worth it. Often free alternatives exist, which makes it even more a no-brainer. Never mind that as a whole we are an enormous company but software dev is not core business so really we are a small part of a whole, yet some sellers only want to sell the most expensive enterprise tier.
Sublime is too expensive. $99 is too much. They should make a special christmas offer %90 off and many (of those who will never pay otherwise) will pay.
The question is how many people pay the $99 now and how many pay the $10 then. If you can't convert 10x the people you have paying now, you will be losing money.
On the other hand I have 437 games in my Steam account and countless gadgets I don't use. I guess I can skip a couple of games and a gadget or two to pay for software I use.
That's somewhat true for me as well, but I generally pay under 5 EUR for a game. Deciding between 20 games and a text editor doesn't look so good. Though as long as Sublime Text's developer is happy with the market share and revenue it has, I wouldn't change the price.
I've paid $60 or so once, and then another $60 or so for the upgrade to version 4. I've used Sublime Text for almost 10 years, essentially every single day. A hundred bucks for a tool I use every day is not too expensive. And Sublime Text is extremely good at what it does.
> towards non-technical folks trying to get their feet wet in software. Eg: Data scientists or business.
A bit tangential to the original post, but where does this belief that data scientists are non-technical folks? I am a data scientist myself, and in my view it's way more technical than most software development. Albeit I wouldn't still call neither data scientists nor software engineers "smarter" than the average.
Sure, if you want to train your bread and butter text classifier it just takes 10 lines of boilerplate code. But you don't need an AI-assisted tool for that - you just go to hugging face, copy paste those 10 lines, done, it's certainly faster than getting some AI-assisted code editor work for you.
For everything that is a bit more complicated, you need endless adjustments to your code, and it's quite unlikely more than a handful of people before you ever wrote the same code. It is, indeed, a somewhat painful and slow process (because just "testing" your code often takes minutes, if not hours, so finding out bugs becomes annoying). And a somewhat simple, AI-based, error highlight tool might be useful to weed out the most stupid ones and save some time.
But I will never trust something like copilot (or Kite, I guess, which I never tried) to write my code for me, as the challenging parts of the work involve long-term connection between different pieces of code (data loader, loss function, model function) that are written independently but must "cooperate" in a very non-trivial way. It is not at all uncommon that I make hours-long screen sharing calls with a colleague, discussing non-trivial mathematical computations, only to end up changing one or two lines of code that don't have an immediate link with the problem we are trying to solve.
This kind of things are notoriously hard for AI to grasp, so they can't do any decent job in writing that for me. Add on top that a lot of the code you find freely online is just ridiculously bad or broken, and you might only get unusable models generated by AI engines trained on those.
So, what kind of work are you referring to when talking about "data scientists or business" in your comment?
I found that "being technical" means different things to different people.
In the software world people seem to be referred to as technical when they write software systems not as much as singular scripts.
Data science is definitely technical but a lot of code work tends to happen in Jupyter notebooks or something similar. The main challenge is in understanding the ML/AI algorithms, the possible choices for your analyses that actually make sense for the problem, ... .
Besides that, due to the AI hype, there are so many people in data science who don't know much about coding or software engineering. Therefore, helping these people might be profitable (or not).
I work at a firm with many data scientists (I am one of them -- though my title has wavered back and forth between data scientist and ML engineer). Whether or not data scientists are "technical" and in what sense could be a difficult question to answer.
I can't speak very broadly, but at least for my company most data scientists are not doing the kind of work you describe. There certainly are some folks constructing and training complex machine learning models, but I think the majority work on the level of more basic statistical models and rules of thumb, where a project's final output might be a dashboard or presentation. Arguably some might refer to this as data analysis rather than data science, but none of these terms are particularly well defined.
That's not to say they aren't technical in some sense. All of them can and do code to one degree or another (with perhaps the exception of a small number of people who've been in the industry for decades), though not all of them do so with high proficiency or attention to software engineering best practices. That also goes for some of the engineers where I work, admittedly.
All in all, the broad level of technical aptitude has grown over the past few years. But not everyone with the title of data scientist is a machine learning specialist, nor are they necessarily skilled at software engineering.
Edit: As for Copilot, I found it worse than useless. It miserably failed every test I threw at it, from machine learning to (especially) Spark data pipelines, only redeeming itself with a string handling problem -- for which the solution was still entirely wrong but at least interestingly wrong. I frankly don't see how anyone pays for it, though perhaps it's better for projects with a ton of boilerplate.
>> Our diagnosis is that individual developers do not pay for tools.
> I know this first hand, building a developer tool startup and failing to reach any level of revenue.
Just because your startup failed doesn't mean an entire category is unsustainable.
I've been living from sales of a developer tool for the last 10 years, and there are plenty of other paid developer tools out there that show developers absolutely do pay for developer tools.
Now, maybe some of the startups have unrealistic expectations. A Python documentation reader probably wont turn into a billion dollar revenue company no matter how smart it is.
But I'm pretty sure there is a market for dev tools. Maybe the market is smaller, or harder to crack than you thought, but saying "there is no way" isn't going to help anyone.
Could you talk a bit more about your success? What does it do, what pricing model do you use, how long did it take you to acquire customers, do you feel it's worth it? Asking for a friend, of course.
I don't want to talk about it in detail, because I am trying to stay anonymous on HN.
It's a Mac app, pricing model is perpetual license with paid upgrades for major new versions (every 3-5 years). Customers are roughly 50% individual devs and 50% companies who buy for their employees, and a bunch of educational licenses, but I don't earn much from them.
I got initial traction by being mentioned by some popular bloggers and twitterers, but I only started making a full time income after two or three years. I think marketing is mostly word of mouth, and lots of people using the trial version who eventually buy a license, but for the most part I have no idea how people find my app.
As for whether it's worth it -- it's a cushy job, I can take care of my kids and don't need to worry about putting in enough hours, because nobody cares how much I work.
On the other hand it does get somewhat boring after 10 years. I've been hearing the same feature requests and ideas for improvements for 10 years. My customers are all the same average tech dudes like myself. Sometimes an interesting bug shows up, and when I track it down that's the highlight of my week.
> Our diagnosis is that individual developers do not pay for tools
I believe this is incorrect. I pay for many tools, but I would not pay for Kite. The problem is not that developers don't pay for tools, but that Kite, or AI-assisted code, does not address a pain point. It's a slight improvement, but I don't feel pain when I need to write code without it.
That's different from something like CI tools that I pay for. When I need to wait long for CI to finish I get annoyed. That's when I pay.
> It's like trying to sell magic tricks to magicians. Sell magic to regular people, and you'll see some significant revenue.
Just FYI, magic tricks are basically only sold to magicians. There's a thriving market of magic shops, especially online, where magicians go to buy new tricks (in the form of books/videos), new "gimmicks", etc.
I'd wager that a significant portion of all magic that is done is actually by magicians, for magicians, and partly in order to sell magic tricks.
You used magicians selling magic tricks to other magician's earlier, then said "smart" later.
I think it's just domain awareness, and the "they're smart" trope needs to be dismantled.
I think it plays into the technocracy problems we have now. We can solve it, we need more tech. More more more. People think we can solve social/political problems with tech - insidious.
I pay for tools, even though I'm kinda broke and would prefer to save a few hundred a year - my IDE delivers a lot of value and the support is excellent (thanks Jetbrains). I installed Kite briefly but it seemed so resource hungry I switched it off soon after without ever really trying to use it. That's not a judgement on Kite, I just didn't have the time or resources to spend at the time I encountered it.
I'm sorry it hasn't worked out for them, but they get my respect for this unusually frank self-assessment, real humility, and following through on the fine words with the actions of sharing their tools they built. They achieved a lot and I hope their future endeavors are wildly successful.
The challenge is that when you're building software for developers, they already know how it must work.
Do you mean that what you built didn't worked as it should? I don't understand, I've paid multiple times for tools that I find useful, even if they weren't perfect.
This misconception has been promoted by companies with an interest in promoting their platforms, using the expeditive procedure of subsidizing (often inferior) tools, with the collateral effect of making impossible for tools vendors to compete.
But by no means it's a law of physics. Make something programmers want. It's weird how little have the tools improved in twenty years.
What’s the best book/material on how to build a business like your friend’s? Discovering the niche, and expanding the client base are the main questions.
Be it as it may, everyone I know who tried Copilot trial is now paying for it. While my company expenses it, I started paying with my own money before that.
>> Our diagnosis is that individual developers do not pay for tools.
That was a really shocking insight for me. We do not own our means of production. And suffer all the textbook consequences that follow.
Maybe unions could help with that. Imagine using union-funded licenses, compute, storage etc. to experiment with your side projects, build your prototypes without risk of losing IP to your current employer.
I've paid for jetbrains multiple times, even though it's quite expensive for someone making money in a a third world currency. I pay for copilot.
However, I would never pay for stuff that I can get free. I could talk to my company to buy it, but I would settle for something close and free if it come to that.
People in 3rd countries use pirate copies / cracks very often. In my country (Moldova) that's absolutely OK having everything pirated even in government structures. AFAIK all JetBrains products are available cracked.
I am an individual developer and I pay for my PHPStorm and GitHub CoPilot - it saves me so much time, I could never imagine. This software is completely worthy to be paid for, even considering "free" copies are available.
OCR and document scanning companies is a big deal. I have a family member that used to do sales in this area and indeed companies with a lot of records and paper are paying big to get that digitized.
Maybe I am older, having started in the late 90's. But I think developer tools nowadays are so cheap compared to my salary that I pay for them without thinking twice.
I clearly remember paying around $80 USD for a WholeTomato [1] license back in 2003 for C# when I first came out of University into my first job. And that was a glorified auto-completer.
Software has turned really cheap. The downside of is that it is almost a commodity, but the development effort has not really decreased correspondingly.
If my employee would rather not pay for a tool, why would I spend my own money to help them save money?
The blog post was quite clear on the ”the tech doesn’t work” part, which seems like a more likely reason for their demise. Selling developer tools is hard, but selling non-functional tools is exponentially harder
It is surprising to me to see that you don't view yourself as a programmer. Maybe you're not a professional software developer, but writing code for fun sure sounds programmery to me.
"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 was similar, the reason I'm not paying is that coder AIs are not providing any value.
Developers are somewhat reluctant to pay for tools but I think you can get them to pay for things that are worth it. I've been paying for code editors for years.
My experience with copilot has been very different. It easily pays for itself, and getting my employer (seed stage startup) to spring for it for the entire team was an easy sell.
Yeah it's pretty dumb most of the time. But I know that, and I don't use code from it without carefully checking it out and modifying it. But it's still a huge help. Just the time saved writing tests alone pays for it. And I've had a few spooky experiences where it feels like it knows the bug fix before I do. Think of it as a smarter auto-complete.
The technology has a long way to go, but I completely disagree with Kite here. It's already good enough to pay for. If my company didn't pay for it, I would. I already pay for JetBrains, and it costs more than Copilot. I would give up JetBrains before I give up Copilot.
My guess here is Kite positioned themselves as a free alternative to Copilot and then couldn't monetize. There very likely is more to it though.
> Just the time saved writing tests alone pays for it.
This, so much. My code since using Copilot is easily ten times better tested than it was before, and I wasn't especially lazy when it comes to testing.
Given 1-2 hand-written unit tests, Copilot can start filling in test bodies that correctly test what's described in the function name. When I can't think of any more edge cases, I'll go prompt it with one more @Test annotation (or equivalent in another language) and it will frequently come up with edge cases that I didn't even think of and write a test that tests that edge case.
(One great part about this use case for those who are a little antsy about the copyright question is that you can be pretty darn confident that you're not running a risk of accidental copyright violation. I write the actual business logic by hand, which means copilot is generating tests that only interact with an API that I wrote.)
APIs are not copyrightable (Oracle vs Google). However, the code that interacts with an API might be.
Regardless, it is interesting to think about what domains are easier to generate effective models for. I would expect it to be easier to generate a supervised model <test description> => <test code>. My intuition is also, that it is easier to generate React component code, and harder to generate feature code.
Incorrect, the case was appealed to the supreme court and the appeal was denied, so the lower court ruling held.
What was ruled by the supreme court was that Google's usage of the API (which had already determined to be copyrighted) fell under fair use in copyright law.
> Incorrect, the case was appealed to the supreme court and the appeal was denied, so the lower court ruling held.
Kind of; the appeal denied was an interlocutory appeal (an appeal before final judgement), so the lower court ruling was left in place until final resolution of the case potentially to be settled in any final appeal.
However, while copyrightability of APIs was raised on the final appeal, the Supreme Court sidestepped it, ruling that because Google’s use was fair use even if the API was copyrightable, it was unnecessary to decide the copyrightability question at all. So the Federal Circuit decision remains in place on copyrightability.
On the gripping hand, though, that decision really doesn't matter much because Federal Circuit decisions on issues outside of those it has unique appellate responsibility aren’t binding precedent on trial courts (it is supposed to apply the case law of the geographic circuit that would otherwise apply, but its rulings don’t have the precedential effect that rulings of that circuit would have.)
So, basically, as far as appellate case law, Oracle v. Google provides no binding precedent on copyrightability of APIs, but precedent that at least one pattern of API copying is fair use if APIs are copyrightable.
Which isn’t encouraging for anyone looking to protect an API with copyrights.
Testimonials of this form are near worthless to a company. Maybe it's true for you. Statistically, it's highly likely to be misleading.
People overestimate their willingness to pay for something for a number of reasons, but one of the biggest is that they incorrectly visualise what the choice to pay or not looks like. They often imagine a moment of abstract choice after which everything remains exactly the same but some small amount of money magically vanishes from their bank account. In reality, paying for something is a tedious inconvenience, and not paying for it more often takes the form of never getting round to putting your card details in than consciously deciding "this isn't worth it".
It can be taken to questionable extremes, but there's truth in the idea that the only real evidence as to what customers will do is what they actually do, not what they say they will do. I don't know if their interpretation is correct, but it sounds like Kite at least has evidence of the former sort.
It's my personal anecdote, I make no claims that other people feel the same way. If they were logical, they should though. Paying $10 to get several hundred dollars in productivity gains is a no-brainer. It's the same reason I pay for a second monitor, a properly comfortable chair and desk, a top end computer, and JetBrains. At software engineer salaries, even small productivity improvements pay off handsomely.
I don't know about software engineering more generally, but I found it worse than useless for my work in data science (machine learning and ETL pipelines), spitting out code that was so wrong that it couldn't be salvaged. I suspect there's a wide variance in the degree to which Copilot will indeed pay for itself.
It is amazing for typing out mock data. Say you're testing parsing of XML - it can easily suggest the the assertions over the data parsed from the XML.
Example test that was 95% coming out of Copilot:
https://github.com/dotnet/arcade-services/blob/61babf31dc63c...
It also predicts comments and logging messages amazingly well (you type "logger." add 7/10 times get what you want, sometimes even better), incorporating variables from the context around. This speeds up the tedious parts of programming when you are finalizing the code (adding docs + tracing).
Honestly, Copilot saves me so much time every week while turning chores into a really fun time.
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.
The best part about it for me is just the Intellisense (in Typescript). I'm using it on probably 3/5 lines that I write as a smarter version, but I rarely use it to do more than finish the current line I am writing.
I don't think it's reasonable to say either was copying. AI assisted tooling is obvious and people have been waiting decades for the tech to reach a point where they can build these tools. Kite tried to get in early - too early probably - but even if they were the very first they didn't invent the idea.
^ This, I may not use copilot as much on production code, but the testing code it produces makes it easily worth it from a time saved and coverage perspective.
> I fell for this. I enabled it because I was curious about trying new development tools, only to find out later it uploaded all of the source code on my computer to their service. What the hell.
> Since we literally build all of this our B.S. detection meter is really high.
Oh no. The only thing that's high is our conviction that our BS meter is high. We fall prey to, come up with and promote as much BS as the next person.
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 there to take away our jobs. Its not and can not. But it provides the smartest auto-complete you've ever seen and that can be useful, especially when wading through mundane parts of your codebase.
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.
Not surprisingly (Google's internal code analysis tooling is quite sophisticated), Google has added a post-processing filter to remove results that don't compile, but that's not publicly available: https://ai.googleblog.com/2022/07/ml-enhanced-code-completio...
It's really just perfect for remembering obscure things and can easily be prompted to generate the boilerplate. If you surround it with your style you will see it try to use the same techniques, however if you work on large code bases it gets annoying when it starts copying the bad habits you are trying to get rid of. In those cases it's actually kind of good for bringing to your attention that the building next door is still on fire.
I feel the problem with discussions about Copilot is that they consist of roughly two groups of people talking past each other. The first group believes that Copilot should be able to write code for whatever you tell it to write code for. The second group thinks Copilot is a fairly overpowered autocomplete.
The first group gets annoyed all the time because Copilot fails to write most code when prompted with comments, or writes inaccurate code at best. They get upset when they see that Copilot can reproduce GPL code when prompted in a specific way.
The second group most prompt Copilot by allowing it to tab a complete a line or two at a time, and they are actually super happy because Copilot is way better than any other existing autocomplete; it's basically in a class of its own. To them, the GPL issue seems a bit more abstract, because they would never use Copilot to do that anyways.
I fall pretty firmly into the second camp (can you tell?). Allow me to soliloquize for a moment. Copilot is an incredibly powerful tool, probably the most powerful one I have, but, just like any tool, you need to really learn your way around it, and understand what it can and cannot do, before you start making judgments. I'm not surprised that you turned it off after using it twice. Imagine saying you stopped using React after making two components!
Maybe I should write up a bit more about how I use Copilot, but in a nutshell I feel that it falls somewhere between a 2x-better autocomplete and (and this bit is even more interesting) a tool similar to google search, but more tightly integrated with the coding environment. The second bit is why it's so good. Imagine if I were to continuously google search everything I was doing while coding, while I was coding it. Sure, most of the time it'd just confirm you were doing the right thing, but... every now and then, Google might turn up a better strategy than the one I was currently trying. That's how I feel Copilot works all the time; it's continuously "google searching" for alternate approaches, and every now and then it'll be like, "aha, did you think of [this thing]" and really take me aback, because I wouldn't have even thought to Google for that particular bit of code / problem / strategy.
Of course, you could continuously google search everything you did as you did it, but it would be a massive waste of time. Just imagine Copilot is doing it for you, and returning what it found. Most of the time I know what I'm doing, but every now and then, the result is remarkable.
I'm not a lawyer, but my understanding is that even small snippets of licensed code can be problematic. I don't know exactly what the cutoff is, but when I tried Copilot it often suggested to auto complete snippets of code that were long enough that if I was intentionally coping them from a licensed codebase, I would handle the license. I'm not talking about whole giant functions, but small functions or large chunks of a function.
It is true that more commonly it suggested at most a few lines of obvious code which could really only be written the way it suggested, but a number of people in the comments on this article mentioned using Copilot to come up with test cases, so I think people are actually using it to suggest larger snippets of code.
Loads of devs I’ve spoken to, from junior to principal level, absolutely love Github Copilot though. Don’t know who is paying it for them, nor if Kite was significantly worse, but I think that at least Copilot has a brilliant future ahead of it.
If Copilot generates the exact same code as the source, I don't see how that process could be exempt, it's like using the clipboard on your PC with extra steps.
1) It's the code license that matters, and the depends on what license the code the developer is building is using
2) License compatibility is undecided (see eg the different views of Apache Foundation and FSF on the compatibility of ASF 2.0 and GPL)
3) It's easy for someone to deliberately produce code that violates a license. MS is a big target and you can bet license trolls would chase it on that.
3) is not a good reason. "Big fish" is not an excuse to not provide protection. The burden to protect others from harm as a direct result of a feature of a product is on the owner of that product.
Do you mind explaining why? What do you think will happen?
This is a serious question, I'm apparently just unaware of the horror-stories that can come out of breaking copyright. (Not from the US so..)
For me its most useful for helping with bash scripts and small simple stuff, just saves a huge amount of time I would spend googling and checking small things. Not sure if copyright is relevant there or not, it certainly isn't something I am worried about. Interested to hear what your fears are based on.
ML text and image generators have a habit of regurgitating training data, especially if you happen to use certain inputs or prompts that also match said data even superficially. For example, type in "fast inverse square root"[0] and get out a bunch of Quake source code.
If you use code or art generated by an AI that was regurgitating training data, you can be sued for copyright infringement.
The way that AI gets training data these days is... questionably ethical. It's all scraped off the web, because the people who make these AIs saw court precedent for things like Google Books being fair use and assumed it would apply to data mining[1]. Problem is, that does nothing for the people actually using the AI to generate what they thought were novel code sequences or images, because fair use is not transitive.
[0] This won't work in current Copilot because a) I'm misremembering the comment phrasing and b) they explicitly banned that input from generating that output.
So, this makes sense from the perspective of writing code professionally for a company. I don't buy that the risk is significant for an individual programmer, but I suppose it is plausible that lawsuits could pose a threat to a large organization.
But I find I get most pleasure out of using CoPilot for personal tasks, everyday stuff that isn't for work. Surely there is no issue there?
And to counter the note about the scraping sources-- I have recently (out of work) been experimenting with using CoPilot to translate open-source MATLAB code into python and zig. If I make something useful in this way, it will be open source and I will credit those who wrote the original code.
Surely a use-case like that last would have to tick all the moral and legal boxes?
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 technical errata in my browser is a complete win for me.
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.
I use it. It's good for boilerplate code or basically anything where you can avoid looking at the docs. For example, I was writing an ML training loop and it correctly filled in the rest of the function after I wrote the first few lines. The code is basically what's in the pytorch docs, just fit to my model and scenario.
A coworker of mine uses it, it almost seems like an unfair advantage but I can also use it too if I want to. Specifically writing hard to decipher code eg. functional composition but Copilot will spit it out.
I haven't wanted to use it personally. I'm also not a senior dev or anything so my opinion is not worth much.
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 used it for about two weeks total, over two different periods. Mostly Kotlin, Java, Typescript, small amounts of Groovy. I ended up turning it off. In my experience, it has moments of utility, but most of time it felt like it was getting in the way. The kinds of things it completed well were not the kinds of things that cost a lot of time or mental energy. I found wasting more time trying to fix things that when it got close but not quite there, than it saved in spitting out boilerplate.
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.
It's quite poor for learning a totally new set of programming language grammar.
If you're a Javascript developer of 5+ years of experience, it's probably absolutely fantastic. Not so great if you're learning a new programming language.
Please remember that Guido van Rossum is now employed by Microsoft. Yes, I am a fan of Guido van Rossum and his work, but I am always suspicious when famous people recommend their own company's products. It feels like excellent marketing/PR that is hard to resist.
I _love_ Copilot but the only reason I use it is because I qualify under their open source developers program, I just can't justify paying $10/month for it.
It saves a bit of time, but doesn't seem to make a difference on time to market of features, products, improvements or bug fixes.
In my experience, it's a quality of life improvement, but the things that dictate actual time to market is bottlenecked by things that aren't solved by copilot, such as overall design, decision making, requirements gathering, code structure/architecture, solution ideation, user acceptance, infrastructure setup, etc.
I think if it eventually could help with those other tasks, you'd see time to market gains, and that would start to make it really valuable.
"Our diagnosis is that individual developers do not pay for tools."
I think this is probably true. If you need a tool for your day job, your company ought to be paying for it. Some companies have slush funds for small purchases like books, but subscription costs for services would normally need to be approved. If you're a solo consultant then perhaps you'd pay for tools that make you more productive. But for personal projects the value-add would have to be pretty high to be paying another O($10-20) a month on top of other subscriptions.
The big group of "hobbyist" coders are students, and they get copilot for free via Github's very generous edu package (and so does anyone with an edu email address I think). The bigger problem is that this is a very expensive project. It's better suited to a big company with money to burn and deep pockets to give it away to junior devs who will evanglise for it at their new companies (e.g. students) for nothing. See Matlab.
The sheer volume of subscription services I've signed up for as the CTO for a startup is mind-boggling. $8 here, $19 there, $49 for something important, $99 for something essential.
Some tools are easily worth it, especially when you see what is charged for other (less valuable) tools.
1) I need to justify these expenses each for what value they bring, some things are nice to have but bring so little value on paper.
2) You can't just enable tools for some people, there's huge overlap and that overlap gets greater
I get that people need to be paid, but these things very quickly add up. I'm paying about 7-13% of peoples salaries already in these subscriptions, and I feel like a total dick for saying no to people or trying to consolidate these.
The weird thing is that 13% seems high. It is hard to imagine they are less than 13% more efficient with those tools.
It is weird that software engineers are the only engineer-types that are supposed to be able to do their job with just a computer and a built-in editor.
> It is weird that software engineers are the only engineer-types that are supposed to be able to do their job with just a computer and a built-in editor.
Not really. We aren't actually engineers. Someone appropriated the title and misused it, and now there's no putting that genie back in the bottle.
Engineering is expensive, and most software developers rightly default to a pragmatic craftsman's attitude. Build something people can use and iterate on it based on feedback.
When there aren't lives at stake, it's usually the right call.
Software development is the only field I can think of where the making of the tools of the trade is wholly encapsulated by the field itself. Maybe blacksmithing. In such an environment, it makes sense. We make our own tools, and for the most part the most powerful of those tools end up being given away for free. To other people who both use the tools, and have the capacity to improve them. Who then give them away for free.
It is not a coincidence that software development tooling is one of the only fields that has has been thoroughly eaten by open source. It's because the user-developer circle is complete. A mechanical engineer probably doesn't have the skillset to improve the CAD program they're running. A software developer probably has the skillset to improve VIM.
Ones I excluded for bring "not worth it" are Lens ($20/user/mo), Snyk ($139/user/month) and Postman ($36/user/month) - contrast those with Gitlabs pricing to understand the value trade-off.
I’d recommend anybody thinking about building a devtool to read Neil Davidson’s “Don’t roll the dice”. It’s a pretty old book, but Neil has also made it available for free now and the general lessons still hold true today.
Some IC developers will pay for tools, it’s very hard to have that happen at a price point that supports the scale required. So feature discriminate on the things their boss needs, and charge for that. And then the next set of features for their bosses’ boss, and so on until you’re selling into the C-suite.
When I tried kite over a year ago I was relatively unimpressed with it. Even though it ran as a plug-in to jet brains IDE it required a windows installed service and two separate executables running in the background (kite.exe, kited.exe), and that stuff continue to run after exiting my IDE which was unacceptable for me.
Kite may have been the first to market but copilot blew them out of the water in terms of overall functionality.
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 was.
For more expensive purchasing decisions, there was a longer purchasing/approval process. But the expense would have to be 5-6 figures per year before hitting this barrier.
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.
I think “company card” is the differentiating point here. I’m not sure how many IC devs have access to that. Which makes me think you don’t fall into the group that they’ve defined as IC.
I started getting purchasing authority around the senior level, when I also had some amount of hiring authority. Even if you don't have a company card, there's typically a process where you can get reimbursed for expenses.
If you are an IC reading this and have never tried to expense a tool you find valuable, give it a shot. You might end up surprised at how much management appreciates the ability to trade money for business value.
On the contrary, I find Github Copilot extremely helpful and saving me heaps of time. Yes, it's not writing the logic instead of me, but it acts like the best companion I could have in most of the cases.
I paid for intellij - damned near the entire architecture team where I worked had a copy, and the company sure as shit wasn't the one paying for it.
(I eventually stopped subscribing, in part because they were too slow distancing themselves from Russia, in part because of their movement away from open source with their newer tooling.)
Developers will pay for software, if the value proposition is there.
> in part because they were too slow distancing themselves from Russia
I'd cut them some slack here. They had to get their team out of there first—with the way Putin is running things, they sure as hell couldn't announce they were leaving Russia until everyone who was going to follow them was out of there.
On the day of the invasion they tweeted a statement condemning the attack, and within two weeks announced they were leaving Russia.
> Developers are somewhat reluctant to pay for tools but I think you can get them to pay for things that are worth it. I've been paying for code editors for years.
Especially when you don't market to developers in general, but freelancers/contractors specifically. It might be hard to sell to salaried developers (they'll buy because it's nicer to work with good tools), but it's easy to sell tooling to anyone who makes more money when they get more done.
With Copilot it's important to configure your editor so that it only generates completions when you ask for them. Then it can be very useful at times, especially when you're doing something you know is routine but you don't recall off-hand how to do (e.g. opening and writing to a file in append mode in a language you only use occasionally) Having it suggesting stuff every time you hit enter quickly gets annoying.
The tool just has to be very well integrated and easy to use. That's why copilot is seeing adoption, because Microsoft owns VSCode and has built a very simple integration of Copilot into VSCode.
That said, I'm not even sure VSCode or Copilot is lucrative, if it wasn't owned by Microsoft, could they both be sustainable businesses?
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.
Yeah, where it seems very good for me is just writing flask or fast api boilerplate, esp if I have a good function sig + doc string.
I kind of hoped that it would propose good tsx for my components (react+mui) but instead it’s basically useless. Maybe problem is that I chose “filter out exact code reproductions.”
I tried Kite and didn't even keep using the free trial or whatever the free tier was at the time. I don't think the issue is that developers won't pay for tools. Companies like Jetbrains are incredibly successful selling tools to developers. The issue for Kite is that Kite wasn't worth paying for.
Paying for copilot :) at least in go it’s great to write tests and sometimes some smaller functions :) totally worth paying for it, even from your own pocket if the company wouldn’t allow expensing it
If the company wouldn't pay for it then better think twice because you could get in hot water with legal. That's not a tool one's job or even company's business is worth risking over.
Copilot has a ton of still unresolved legal and compliance issues (copyright violation problems, sending proprietary code to Microsoft as you are writing it, etc.) and most larger businesses won't touch it with a 10 foot pole for that reason. There is even a class action lawsuit against Microsoft over Copilot already.
I pay out of pocket for a JetBrains license because it makes me a LOT more productive. I don't spend money on a lot of dev tools, but if it saves me non-trivial time, it's a no-brainer.
Yea.. i happily pay for several JetBrains tools and i'd love to pay for even more. I've got several problems that i don't want to spend time solving myself.
Frankly as a developer i've got more problems than i can count and if it involves a GUI i tend to prefer to pay for it. I love FOSS but UX is just not often a focus. I have better experience with paid products. Assuming the licensing isn't punishing.
Biggest one off the top of my head is in the category of developer productivity (which i pay a lot for already), and specifically it lets me use my editor of choice (Helix/Kakoune currently) while getting powerful new features.
Huge hurdle, obviously, but my thought was an expanded set of LSP features from JetBrains, disconnected from their IDEs. They spend quite a bit of time and money on developing DX but it's all inaccessible to those of us who prefer different editors.
I'd pay a lot for these sorts of features that go above the existing FOSS LSP, while retaining more integration to the FOSS tooling we've come to know and love (like editors or choice).
That's why I tried it twice. I've been hearing people say they liked it. But I haven't found it very helpful, and often distracting, so I ended up turning it off. I'll probably try again next year when the models are improved to see if I feel any differently then.
Yeah, I understand. I just see a lot of people on here who seem to be deliberately looking for reasons not to like Copilot.
You don't fit that stereotype, of course. So feel free to ignore the following.
Developer tools have learning curves. One doesn't simply open vim/emacs for the first time with a full understanding of how to use it (or why it's a good tool to use, even). Historically, we have had _no_ problem with the steepness of this curve. But, when it comes to Copilot, there's a lot of "tried it and it output an obvious bug! how did this make it past quality assurance?? such a liability!" Just very reactionary and all-that.
The difference between other Dev tools and GitHub is the probability of getting things wrong. Like when intellij types out boilerplate or a compiler generates code it's 100 percent correct and if it fails, it fails predictably. Copilot is impressive sometimes but there's no guarantee of correctness or failure mode. I cannot trust such tools for anything serious. If you're in the habit of copy / pasting code from the internet then I can see why it might help speed that up. But imo that too is dangerous and I avoid it unless absolutely necessary
I don’t see how that’s relevant to anything in my comment, but since you brought it up I assume you take both of those notions as a given - but they aren’t necessarily concerns of all programmers.
Tabnine, in emacs, with lsp mode gives you single line completions and predicts and fills out word by word in a very effective manner. It's an actual timesaver and worth the money (in emacs). The vscode experience is more problematic, but that's vscode's completions guis fault, not the tabnine server's.
I disagree, Github copilot makes me happy, helps a lot with guessing patterns in my own project base code, I just write the good function name and he guess what I want to do.
“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 component.
I guess what I’m saying is that I want to buy tools, but people are only renting. Personally I’m largely holding out hope this becomes someone’s open source passion project and I can truly own my tools.
Software developers are also more likely than most to be "free software people". I for one am excited to see Kite go open source; if it's truly open, including the underlying recommendation models and algorithms, I will be happy to use it and set up a monthly donation for whoever wants to keep working on it.
Exactly. Non-free software is always paying for a service. If you don't get the source (and the ability to use it) you don't get the software. The source code is the software... the binary is an merely way to access a small part of it.
> If it's truly open, including the underlying recommendation models and algorithms, I will be happy to use it and set up a monthly donation for whoever wants to keep working on it.
Knowing examples such as Hudson CI & co, that probably makes it "no one", at a statistical scale.
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”
I like what the other has said in under another comment — selling software to software engineers is like selling magic to magician. You are a magician, a very unfriendly use case to prioritize. It is reasonable for you to want what you want, but it would be suicide for the business to prioritize acquiring you as a customer.
Condolences to the Kite team. But, congratulations, too - you have some of the highest value engineering experience in the world. I'm sure you'll land somewhere great; try and take some time off if you can afford it!
Mulling over business models, and noticing the 'devs won't pay' narrative in the blog post, it's interesting to see the existing business models in AI; basically they seem to be:
* API-driven cloud calls (this is a way to get high value out of your existing cluster if you're AWS, MS, etc.)
* Platform play + possible eventual lock-in: OpenAI/Microsoft
* Subscription service for very specific needs (Grammarly, writing support)
I wonder if engineers would pay $9.99/month (or even $49.99/month) for a 'grammar checker for PRs' - essentially: "Avoid embarrassing bugs before you commit". That is, I wonder if Kite could have been successfully sold as the third tier - sub service for something very specific.
I guess if it's a good idea, someone could pull the Kite repos and launch it -- but my guess is there may be a market in there.
Devs almost always lack any kind of purchase authority. Any tool that appeals to devs needs to appeal to their management more, either showing some kind of cost savings over existing tools, increased dev productivity, or the new fangled "dev experience" where this tool, by shear awesomeness, will let devs put aside the low salary, process hell, and keep them employed.
I understand that's Kite's perspective (and yours -- "purchasing won't pay for this"), but devs are not paid meager salaries in general, and definitely might care about their code quality when it's put out in 'public' whether that be internal repos, or github.
Payscale estimates average engineering salary as having between $3,000 and $7,000 a month more in disposable income over writers -- and I would guess almost every professional writer pays for grammarly.
But, I agree that this is a new concept, and just spitballing -- right now, these sorts of linters and code formatting tools are mostly open source, so it would be some product marketing work to see if the market would actually pay.
> I understand that's Kite's perspective (and yours -- "purchasing won't pay for this"), but devs are not paid meager salaries in general
Perhaps an under-appreciated perspective – most of us don't come from families that were paid the sort of salaries we get; and consequently we are more likely to be irrationally stingy about money as a result of having grown up (relatively) poor. I know that $200/year is not a significant cost at my salary; but I do remember a time when that would have been totally out of reach for me.
And also there's the fairness aspect – do I want to be participating in a system where only rich devs can get access to good tools? Yes, I understand that the world is not fair and already works that way, but I should probably not perpetuate that system; and instead, make work pay for it.
Like everything in most companies, it's never about money, it's about control/power. It's inevitably someone's job to manage all the SaaS shit at a company, and damnit we just bought a JetBrains license why do you need Copilot?
If you don't have a massive platform (ie if you aren't Amazon or MS) the vertical end to end solution is much more easy to sell - ie sell the benefit directly.
"we were 10+ years too early to market, i.e. the tech is not ready yet."
"Our diagnosis is that individual developers do not pay for tools."
"We built the most-advanced AI for helping developers, but it fell short of the 10× improvement required to break through because today’s state of the art for ML on code is not good enough."
Sounds like you know why people didn't pay for it. If it truly did make people as productive as you claim, it would have sold like hot cross buns on a cold day.
Exactly, they started a decade earlier and got outdone despite the massive head start. Then again maybe without the big data they had no hope of succeeding, but they should've mentioned that specifically instead of giving a bunch of contradicting statements.
If they're claiming 18%, it was probably more like 5% to 10% and it's really hard to sell something that's 5% better (especially when the alternative is free/ do nothing).
There are different types of market timing. They're right about the tech not being ready, but others are because you found the right "moment." Wordle was a success because it got traction in a covid winter. The exact same experience was just as viable 10 years earlier, but people weren't looking for entertainment in the same way.
> developers began noticing something: Kite had quietly injected promotional content and data-tracking functionality into open-source apps the company previously had no affiliation with. The discoveries of those injections, and Kite’s initial refusal to roll them back, led to backlash from programmers who felt the company’s actions undermined the open-source community.
I was looking for such comment to understand why the GoodByeAds (which I use with NextDNS) contains a record for kite.com (which means I'll have to add an exception to access kite.com).
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.
Kite messed up privacy expectations one too many times by uploading everything in my home folder without consent. They were repeatedly shamed for this on HN and every time it seemed like they didn't understand why people were mad about consensual analytics.
The thesis that helping developers write code has value is flat wrong. We spend so much more time reading, reviewing, designing, arguing/bitching about code than we do writing it. Orders of magnitude more.
Any developer tooling company must understand this basic fact.
Indeed! Software development is not about writing syntax, but about "knowing what to write and where to put it".
Having a tool that rapidly creates setters, getters, or even common algorithms in function/method bodies is neat, crucial even. But also a problem that has mostly been solved for decades now.
The actual difficulty, where software devs spend (or should spend?) most time is indeed in what you say "reading, reviewing, designing, arguing". Where I'd like to add that the "arguing/bitching" is crucial if done with the right people (stakeholders, business, etc: creating a domain -or ubiquitous- language).
No AI can help me with that. And the current AIs make that worse. Rather than learning and applying ubiquitous language, rather than evolving a clean, maintainable architecture, it blurps a generic(ish) blurp of code. That often has no place where it was suggested, is inconsistent, breaks encapsulation or coupling and so on. If you blindly accept all the suggestions, the code often becomes worse fast; but you do write a lot of lines of code quickly. Whoever cares about that, though?
I've tried Kite once, and wasn't really impressed. For example, back when I tried it, it wouldn't offer any kind of autocompletion within a string. Even vim's built-in autocomplete tries to complete words for you there, based on other words you've used before.
Kite did sometimes offer some good suggestions in regular code, but it tried really hard to understand your code, and went belly-up when it didn't.
At that time, I tried some other ML-based autocompletion tool which wasn't specific to python, and which usually worked much better, except that it used far too much memory and caused regular crashes.
Maybe they improved kite since I tried it, or maybe "individuals don't pay for dev tools" isn't the whole story. Or maybe both.
Anyway, kudos for both trying and for open-sourcing the code at the end!
I disagree with their statement that individual developers do not pay for tools. I have paid for tools out of my own pocket on many occasions. However, being able to deliver code 18% faster isn't enough to fork out $9.99 a month. First of all it is relatively expensive. For that amount I can get a personal license for PyCharm. Secondly coding speed never tends to be a bottle neck for delivering a feature or a product on time. I can see why Engineering Managers are not willing to pay for this.
I do wish the Kite team all the best, and I hope they can re-use their skills in products that are commercially viable.
Most importantly, coding is the fun part of the job. This seems like trying to sell a DALL-E-esq product to a visual artist promising 18% faster deliverables. Even if it is true, who is going to be in a rush to give way in that aspect of the job and sell their manager on it to spend more time doing the less fun things?
On the other hand, create an AI that can stand in during pointless meetings and the blank checks will shower down.
This metric seems silly on its face. 10 bucks to get 18% more productivity out of a $10k per month developer? If this was indeed the case, everyone who employs software engineers would instantly pay this. Maybe they should have marketed more? Or maybe there are other problems with the technology (e.g., fears over copyright infringement?).
Yeah the problem is the "if" part. It may well be true but productivity is notoriously hard to measure and anyone making any claims about exact productivity increases is clearly pulling a number out of the air. People know this.
We have plenty of techniques that we know improve productivity (e.g. static types) but some people still don't believe it because it's really hard to prove productivity increases.
> I disagree with their statement that individual developers do not pay for tools.
They were a VC backed start-up and it was indeed go big or go home for them.
As they seem to have identified, enterprise sales is one way to go big. Timing is also crucial. Right now, by iterating relentlessly over a decade on just the models, OpenAI and Cohere have commoditized access to the AI itself via APIs: Perhaps a better go-to-market than Kite's which had to build both the AI (ex: OpenAI Codex) and the end-product (ex: GitHub Copilot).
Even though they had 8 years to execute, they had zero leverage on the kind of network effects and developer mindshare that GitHub has or access to bottomless funding like OpenAI. Hindsight is 20:20.
> You can see this in Github Copilot, which is built by Github in collaboration with Open AI. As of late 2022, Copilot shows a lot of promise but still has a long way to go.
This sounds like spite. Sure, copilot can be even better (what can't?) but it's already a great tool. It has a small learning curve (which is just getting comfortable with it) and then it can add a lot to your productivity. Of course, this is orthogonal to any copyright polemics out there.
"we were 10+ years too early to market, i.e. the tech is not ready yet."
"Our diagnosis is that individual developers do not pay for tools."
"We built the most-advanced AI for helping developers, but it fell short of the 10× improvement required to break through because today’s state of the art for ML on code is not good enough."
So basically, everyone's fault but their own. Got it.
Edit: Also I want to say, that WE DO pay for stuff if it brings us value. Out of my pocket I pay for JetBrains, Github, Temius, and the SublimeText 4.
> Our diagnosis is that individual developers do not pay for tools.
Throwing salt on the wound here but that’s just false. I mean, there’s copilot and it’s alternative that I can’t think of the name right now. more broadly there’s Jet brains ides, visual studio, Productivity apps, etc. look at product hunt or appsumo or popular show hns. Devs pay for tools, just not Kite.
Edit: I should clarify, enough devs pay for tools to make the market sustainable. Not all devs pay for tools.
Most devs don't pay for their tools. Because they are employees and they need their bosses to sign off on expenses. I know some free lancers that pay for some tools but way more that don't. So, it's a small market that sustains a handful of really nice tools. Jetbrains is one of the more successful tool vendors in this space. But their tools are really essential to many developers.
As a CTO, most of my budget goes to paid services that add clear value with a clear value proposition. The value proposition with developer tools is usually quite murky. It's all very subjective and preference based. So, something like kite is a hard sell.
It's remarkable that they attracted so much investment. But of course that put them under enormous pressure to meet what were probably highly unrealistic revenue goals as well. That team might have made them a nice acquihire target at best.
If you could actually prove it provided real benefits, it would still be worth it since you could know for sure that spending $5 on a tool will result in $10 extra earned. Sounds like people just didn't believe that there was that value being generated.
Open sourcing when you're shutting down is only marginally better to not releasing anything.
It means that you didn't believe in open source while you were in business, and are only doing so now to score some points with your customers. There's no guarantee that someone will step up and maintain the project for you.
I am glad they open-sourced their code. If you ever wanted to write an autocomplete plugin for SublimeText or VSCode or wondered how to implement a GitHub crawler in Go, their repo is very informative.
Sad to see, but happy they're open sourcing things.
I went ahead and filed an issue on kiteco-public[0] about their derived data because the readme states:
> By the way, we are happy to share any of our open-source-derived data. Our Github crawl is about 20 TB, but for the most part the intermediate and final pipeline outputs are pretty reasonably-sized. Although please let me know soon if you want anything because we will likely end up archiving all of this.
However, I have no idea if this is the right way to contact them
Kite rejected me for a position years ago which motivated me to go raise $1M from the NSF to research AI-based dev tools before I moved on to Microsoft.
They seemed like a really cool team, I wish them the best.
How did you go about that NSF fund raise? Was it a SBIR? Did you already know how to fundraise through SBIR or whatever vehicle you used? Were you funding just yourself or a team? What ended up happening to the thing you fundraised from NSF?
sorry 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.
> Then, our product failed to generate revenue. Our 500k developers would not pay to use it.
I don't pay for Kite (or any other proprietary developer tooling like Github) because one day your company can choose to shut down, change its terms, or raise my prices and I'd be left without recourse, while also being locked in to a proprietary workflow. Just like you did today, which validates my hesistation.
Kite should have been open source from the very beginning. I hope the team can take away this learning for their next startup. I applaud teams like GitLab who build entirely in the open--and, as a result, have highly successful products and businesses.
Now that it's open source, what's stopping you from integrating it into your workflow? Have you ever even tried it?
I don't think the being locked in a proprietary workflow bit is your real reason, because when you break it down - this doesn't make much sense. Fear of needing to switch workflows down the line outweighs the [potentially temporary if company dies] boost in productivity?
Of course, this assumes kite fits your workflow well and you find it delivers value (you don't cancel immediately)
Meta's language models, GH Pilot, real life car auto-pilot. When it fails, it fails big. And the "we were 10+ years early to market" is just a big lie that bought them plenty of VC money. Good for them.
At least partially over. It's one of those things though; when you first see what's possible with neural networks it does get your hopes up. When you later realize the limitations, it's hard to walk back your old claims. Even Elon Musk has to realize that FSD is never going to happen by now. Google with all their learning and training data, still can't correctly find and smudge license plates or faces correctly on Google maps. If that much processing power cannot correctly identify two classes of objects, what chance do these cars have to classify tons more objects + adapt how they steer based on that information in real time?
The internet was a hype cycle, which ended with the dot com bubble burst. But some of the companies that came out of the bubble came out strong. AI has had multiple hype cycles, like every washing machine with "fuzzy logic" in the 90s, they usually end, but they do usually leave us with more than we had. This AI hype cycle is ending now, and we have seen a lot of progress on image detection, video editing, etc. but the highest targets haven't been reached.
It's kind of the explore-exploit dichotomy. You have some new technology (internet), in the first few years you have exploration and all the low hanging fruit are implemented, then everybody just starts iterating on similar ideas, which lead to less and less gain. The Uber/AirBnb/Amazon for X pitches. If you hear those you're in the late phase of the hype cycle. Because Y for X just means it's not a really new idea and plenty of people have thought of those.
Similarly you have some new technology like fuzzy logic, then some people thought of some good applications. But because the hype train was running it was put everywhere where it didn't make sense.
Or deep learning which was the first to have useful image processing. Now most research is tuning some parameters, adding compute, and hoping for better results.
But in the end we'll be left with some technological advances, and maybe in ten or twenty years somebody has a new idea which beats deep learning in learning efficiency.
The Google Maps smudging point is an interesting one and definitely worth considering, but the incentives at play are very different. While I'm sure they want to be seen as making an effort, Google isn't rewarded in any way for achieving high accuracy in their smudging. It just has to be "good enough" to the point that they aren't getting in trouble for deliberately neglecting it. For this reason, I'd imagine the resources they devote to it are quite limited. It's not having billions poured into it like self-driving AI is--while I have no inside knowledge, I'd guess the budget is orders of magnitude less.
> I'd imagine the resources they devote to it are quite limited
That's a problem inherent to AI or neural networks. We cannot spend our way out of these problems; they are underlying to the technology itself. Nobody knows what "doesn't work" when a neural network does something unexpected. AI is not a technology we have invented, it's a technology we've copied from nature. Nobody knows anything about what really goes on, this is why we're not getting anywhere.
Google could spend their entire budget on that smudge-bot, and it still wouldn't get any better using AI; they would have to go back to regular image analysis to make any improvements at this point. Google has trained it to be so good at finding faces; it started smudging faces on billboards/ads/shop-windows, but when these are flagged as errors, then it starts showing regular faces in shop windows un-smudged. The problem is that we have no idea of what's going on, so all we can do is to add new layers to the neural network, or give it more training data, neither of which gives an accurate result typically, making it impossible to use for self driving cars etc.
Things I've payed for in the past that I no longer use:
- MS Visual C++
- Omicron Pascal
- Application Systems Modula-2
- Atari ST GFA BASIC 2.0
- Berkeley YACC and FLEX port to TOS/GEM
- ...
Overall, many dev tools are free nowadays, which creates an expectation, perhaps, that it should all be free (I disagree in principle, but of course it is nice to see this trend progressing).
I appreciate that Kite is posting a post mortem for others to learn, and I wish they had been able to find a niche where people pay for their work. I love software tools as a work product, but have been told by many experienced people it's not a good area for making money.
I don't think people have problem paying for tools that are genuinely useful for them, regardless of whether or not there are free tools around.
The problem with Kite seems that their engineered first ("This machine learning AI is so cool, what can we do with it?" "I am a VC, are you doing AI? TAKE MY $$$$!") and only after burning through millions started to look at how to actually make money out of it.
And discovered that:
a) Hobbyist/individual developers rarely want to pay yet another subscription (can't justify it if you aren't making money with it & even $10/month subscriptions do add up!)
b) Corporate developers don't have purchasing authority. Everything must get approved, by both accountants and legal/compliance. Expecting a large company to pay a huge monthly/annual subscription fee for what is essentially a better autocompleter? Good luck with that.
That "Oh but your developers will be 18% faster!" argument is BS. 90% of the corporate developer's time isn't spent on typing code but on debugging, design, maintenance and meetings. Kite (or Copilot) don't help with that.
c) What about copyright/compliance issues? This has been trained on Github repositories - i.e. the same as Github's Copilot. How do I know where does the completed code come from? What about licenses on that code? Can I filter only for permissive/non-contagious (i.e. non-GPL) licenses? What about my code/whatever I type? Does it get sent to your servers? That alone is a complete no-go for companies.
In other words, a classic case where one shouldn't ask whether something could be done but whether it should. Someone outside of their engineering bubble and with a bit of business acumen would have told them that. Or at least told them to do a market research first, before spending all that time and money.
But hey, they had a good ride for the VC's money and are winding it down in an organized manner, without leaving a ton of shattered lives and a mountain of debt behind. So that's a plus.
> We failed to build a business because our product did not monetize, and it took too long to figure that out.
This is the one-sentence summary about why the business failed, but it's kind of a strange way of putting it.
I am dead sure that there were plenty of advisers along the way who told the company's executives that its monetization plan was weak and unlikely to succeed. But everyone assumes that they'll be the exceptional case.
"It took too long to figure that out" makes it seem like the most likely scenario wasn't staring them in the face the whole time.
From one founder (of a much smaller startup) to another: respect for writing this. It probably wasn't easy but the fact that you took the time to do it and share learnings so that the next startup in the space can benefits speaks volumes about y'all.
It’s a bit weird to me that developers (myself included) are reluctant to pay for tools. When I first started out in the 90s, I spent significant amounts of money on developer tools: Zortech C/C++. Borland Pascal, Borland C/C++, Paradox for database work, not to mention the hundreds of dollars I spent on printed books. Now, the only things I’m spending money on are subscriptions to IntelliJ and CLion and infrequently books. I wonder how much this reluctance to spend money is holding back software development.
Sorry for the Kite team, but for other folks aspiring here, more optimism is in order: We pay for copilot for Graphistry staff because it works well. Similar story for Docker Desktop: It's new, yet people are already paying for it to the tune of 8 figures revenue per year. I bet similar is/will be happening with Copilot.
Credit to where credit is due. I worked in R&D here in a group tackling it for almost a decade ("program synthesis"), and while Copilot has a lot more to do, it solved so much of the usability & basic use case gap of what the R&D community had been attempting for years. Large language models & transformer models have been out for years, and the Github team executed well on adapting them.
(Separately: There _is_ an interesting question whether this space is VC-investable -- how likely will at least 1 startup here make it to 9-10 figures of revenue. But that's another story.)
Sourcegraph CEO here. I respect what you and your team built. It’s tough to build a brand new kind of product, and I heard from many people who loved Kite over the last several years.
I'm sorry, but the reason I didn't pay for Kite was that I moved to Tabnine which is free, and does a better job, with a simpler AI model... just scanning my local code provided better recommendations than Kite (and I never got any of the promised multi-line suggestions).
Even plain old Jedi was a decent competitor to Kite.
So you we're no beat by billion-dollar CoPilot I'm afraid...
I remember when Kite launched. The feedback on HN was that few people wanted all of their code sent to Kite’s servers. Copilot took all open source code instead and made it autocomplete into your IDE. It would be hard to sell to any company giving away their IP for some auto completion, but it’s easy to sell autocompleting from open source code.
> it fell short of the 10× improvement required to break through because today’s state of the art for ML on code is not good enough. You can see this in Github Copilot, which is built by Github in collaboration with Open AI. As of late 2022, Copilot has a number of issues preventing it from being widely adopted.
True, AI assisted coding does not deliver 10x. But as a user of another AI assistant, I feel that it gives me ~1.25x to ~2x improvement for the keyboard typing when I code. And that is respectable too :) AI for me currently allows me to tab complete some things that previously an IDE on its own was not able to.
> The largest issue is that state-of-the-art models don’t understand the structure of code, such as non-local context.
Depending on how local he's talking, this isn't really true of Copilot. In my experience it will use context all the way up to the top of the file, even in very long files. And at least the Rust version even seems to look at the imports—if you have a use declaration it will actually correctly build and use structs in other files regardless of whether you've yet used them in the current file.
Yes, this was precisely what I was referring to. In small-enough programs (e.g. one file) Copilot has all the context. The other extreme would be something like the Chromium codebase. Because of this, Copilot looks better in quick demos than real-world use. (Though of course it is very impressive and this tech will get there, hopefully very soon!)
But what I'm saying is that it does use imports, at least in Rust. I'm assuming that somehow behind the scenes they're concatenating the contents of the imports into the prompt.
I can imagine this is easier in a language like Rust that has a really strict module system, and to be fair the project that I've been using it on is a side project that isn't over 10,000 lines of code yet. If I were up to 30 imports per file I can imagine concatenating would become much less effective.
Does it seem to only understand imports of public libraries? If so, it's likely that, rather than understanding the contents of those libraries, it's learning from others' use of those library APIs. If not, it is likely just understanding the words in the API at a shallow depth.
No, it's imports from other files in my project. It's either using the import or the fact that I have another tab open.
There are definitely times where it produces a close approximation that's obviously just statistical, but there are other times where there's no question that it picked up something from a different source file that couldn't have possibly been in its training set.
I haven't yet decided if it's using imports or opened files in the editor, but it's definitely not just using the single file I have active.
It could be doing some "fine tuning" based on the repo. That would be cool! That said, what I meant when referring to 'understanding' the non-local nature of code was in a more principled way.
For example, if an object defined in another file has a function called `rename` that takes zero arguments, when calling it from another file Copilot will likely suggest arguments if there are variables like `old` and `new` near the cursor, even though `rename` actually doesn't take any, just because functions called `rename` typically take arguments. This behavior is in contrast to a tool like an IDE that can trace through the way non-local code references work.
I had a similar thought. I think in this instance, they mean something like a labeled/supervised training approach where the model is given not just the tokenized code, but also perhaps is grounded in the possible structure (indentation vs. semicolons, function-scope, etc.).
My understanding is that copilot is largely a self-supervised approach. They feed a massive body of (somewhat noisy) code into the model. The model really does learn a lot of structure on its own and this is a testament to deep learning on noisy datasets.
I'm guessing the "hooks" that they have already from IDE's, language-servers, etc. _are_ quite "structure-aware" - so they want the predicted structure as well as the code, so they can improve the typing experience beyond line-completion.
I think the estimation of 100 million for such a task is maybe too high? I don't know - it feels like you could actually get quite close to such a system by simply using thousands of custom prompt engineering tricks that prepend structure examples to the prompt?
Code automation seems like a poor substitute for effective abstractions in a language, but, having seen this game before many times, I think it’s the way we are headed. Writing code will become entirely idiomatic, like the pidgin language we’ve developed for searching google, and the actual source will be unintelligible and useless, probably JavaScript simply because there is the most data available for the AI to train on, relying entirely on the compiler for efficiency. The code sizes will be monstrous, as there will be no more effort put into maintaining modules, because the AI doesn’t need to organize things this way.
From an old programmer perspective, it doesn’t make much sense, but a new programmer will not want to learn the old way, which will be effectively obsolete from lack of updates. If there’s any value to be derived from it, perhaps it is demand for hardware that will run enormously-inefficient code. The way that now you see people doing full sorts to get the third-largest value just because it’s easier to write it that way, you will see code that also does analytics and builds a distributed hash table to accomplish the same task, just because more capability means more usage means more suggestions to carry along that code.
I think it was a mistake to think of computer programs as a linear text language, but I don’t see this turning back. At some point, the concept of programming a machine will merge entirely with the method of interacting with a machine, which is to say, communicating intent, and then I suppose we can relax into a very comfortable full-service 5-star extinction.
Kite made me a very good (for a startup) job offer a few years back. They had a very friendly and welcoming bunch of people, and even Adam, the founder, came off as a typical human being in conversation. Easily the best job I've ever turned down, even knowing that Copilot would eat their lunch a year or two later.
> First, we failed to deliver our vision of AI-assisted programming because we were 10+ years too early to market, i.e. the tech is not ready yet.
This seems to be very much the standard story for "AI"; not quite there yet. Given the history, it's, er, surprising that people are constantly surprised by this.
Netscape open-sourcing their code is what led to Firefox and an open Web, as a counterweight to closed source browsers. Safari took WebKit from Konqueror
Mind that they continued working on it and built Netscape versions on top of Mozilla/Phoenix/Firebird/Firefox. This people with knowledge of the code base and domain pushed it along.
It's always a shock to see startups like this get shutdown. I guess initially there's a lot of hype and excitement, almost like an inevitability that will lead to raising more and more funding until a business model is found. It's always two things that stop that from happening 1. Run out of money 2. The founders quit. To persevere through covid, war, etc is no easy feat, to do it when you started in 2014 and then see fresh faces on the scene in the AI space in 2022, much harder.
It's also demoralising to see an entire category form without you, especially when you were working tirelessly towards it early on. I've really learned this the hard way also. Good luck to the Kite team in their future endeavours.
"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."
Are there a lot of businesses where individual developer productivity, with a narrow definition of LOC per hour, is the bottleneck?
I've worked for 10 years as a web dev and the bottleneck is very often at the product management level (tickets not ready, goals changing, haven't got the credentials for the 3rd party API yet..) and a minority of the time it's my brain (yes sometimes I need to think before I write code). It's rarely how fast I can write a function. So if you make me 18% faster at something I do 1% of the time... good luck making money out of me
What that says to me is: we were absolutely not capable of developing the required technology, went to market anyway, and feel spite because someone else developed tech that could have made us successful 10 years ago.
Thank you for open sourcing your startup. I’m sorry it didn’t work out. I think you deserve a big congratulations for being the first to really go after this problem. It’s a correct problem — it’s a big market and the solution will come eventually — I’m just sorry it turned out to be too gnarly to solve for you right now! I would have loved for it to have worked out better.
I agree that Kite didn’t deliver the 10x. I was an early user and tried hard to use it but didn’t find the benefit compelling enough to drop into my workflows, but it was very exciting.
I’m sure I speak for all of HackerNews when I wish you the best for whatever is next for the team.
> Our diagnosis is that individual developers do not pay for tools.
I’m an individual developer and I pay for tools all the time. They just have to be of value to me. If developers weren’t paying for your tool, maybe look within.
Seeing a lot of comments trying to dispute the claim that "individual developers do not pay for tools". The claim does invite these kinds of disputes since it's so absolutist, but I do believe there is some truth to it, at least if we take it as a generalization (rather than a literal statement).
Anyone who's either worked at a developer tooling company or tried to sell to developers themselves (I personally did both, having worked at CircleCI in the past and now building my own developer tooling product at https://reflame.app, Show HN launch thread here: https://news.ycombinator.com/item?id=33134059) can probably back the observation that we individual developers are notoriously reluctant to open our wallets, even for products that we love and use daily, despite our high disposable income relative to professionals in other markets.
Gonna share a few of my own hypotheses for some of the contributing factors as comments below for discussion.
Would be fun to see folks share their own! Especially if you've seen successful strategies for how someone might be able to overcome these hurdles to selling products to individual developers at scale (a topic near and dear to my heart these days)!
Competition for developer tooling products is _fierce_, possibly more so than any other industry, precisely because we really seem to love spending our free time building slightly different versions of the tools we use that suit our preferences better, sometimes before we even try to Google if that slightly different version already exists.
Again, I'm totally guilty of this myself, since Reflame started as a side project initially to scratch my own itch, and I can't claim to have done an exhaustive search on the problem space before I started.
This results in a vicious cycle where every product, however innovative it might be at its inception, gets quickly commoditized by dozens of similar products immediately following any signs of traction, so they end up having to shift to competing on price eventually.
Combined with https://news.ycombinator.com/item?id=33691132 means any product that isn't available for free then eventually rots into obscurity due to the unfair distribution advantage of "free" in this market. Thus they are forced to offer a free version themselves and the cycle continues.
We get so many developer tooling products thrown at us, either for free or dirt cheap, that over the decades it's conditioned us to assign much less monetary value to developer tooling products compared to what a simple opportunity cost analysis would yield, given the high monetary value of our time.
I certainly suffered from this myself to a rather extreme degree in the past, having categorically refused to pay a single cent for anything I used to build side projects with, until I started to seriously think about pricing for my own product. Eventually I realized throwing money at almost any problem where it could buy me more free time should be a no-brainer considering how highly I value my free time.
Tangentially, I think there's an interesting analogue in here to what Steam did in the PC games market, but I digress...
Developers know much more than other professions about how much SaaS products cost to run in terms of infra (i.e. very little for most products), so are much more likely to anchor on infra costs when considering whether a price is reasonable during purchasing decision than basically any other group.
Most SaaS are priced completely independently of infra costs (or any other costs really), but we are much less likely to accept products priced with high margins on top of obviously low infra costs, even though that doesn't represent nearly the full cost of running a SaaS (which consists mostly of payroll due to how high our salaries typically are haha...).
We also like to justify this line of thinking by the argument that "well, I can build this myself in an afternoon" (significantly underestimating the real ongoing time investment required to build and maintain a SaaS product, even seemingly trivial ones) or "I can write some bash scripts and put this on the VPS that I'm already running anyways" (undervaluing our own time).
I completely agree with you but it's surprising that the biggest factors aren't being brought up.
Most people won't pay for a ton of small services since it adds up. There is a minimal threshold to pass to make online transactions financially reasonable, making the pricing models make little sense for most services. Given that most cheap services (ie. those at or below $5/mo) don't have large infrastructure costs, it's an even harder sell. Not to mention that sometimes people rather watch movies or television than get tools to make them more productive.
This is doubly compounded when you look at opportunity costs. With the amount of software that can be self hosted, the costs isn't just the comparison of having the tool or not or even other developer focused offerings, but instead having this tool (or access to it) versus any other tool that can be self-hosted (including those that might not exist yet).
Also, lets say we spend $5/mo, well for that we can host our own server which can easily be used for more than one purpose (with WireGuard now even the smallest VPS can be used to saturate most home links and bypass CGNAT easily). Increasing the monthly spending just increases the amount of opportunities.
This of course doesn't touch the elephant in the room which is privacy.
For the regular user privacy isn't a huge deal for these small services. For the average reasonable user that doesn't upload sensitive data, at worst it would be something like a personal photo being seen.
On the other hand as a software developers using these tools is a lot more complicated. Licensing, copyright, and possible work contracts start to matter. If the service interfaces with code (like Kite or GitHub Co-pilot) then you get into a some serious murkiness due to the fact that you don't really know what they are doing with it on their end. Even the things like telemetry and what type of data is being sent back matter in corporate environments.
It's unfortunate when companies fail and I hope I am not coming off as celebrating their misfortune but I love this trend of companies open sourcing their products when they are unable to continue with their existing business model. I feel like it gives their products a chance to continue a positive legacy.
I've recently noticed a couple of companies open sourcing their product upon discontinuing the company -- is this a new trend or has it happened for a long time and I am only just recently noticing it?
It is smart to wind this down. Elon says the biggest mistake engineers make is optimizing something that shouldn’t exist in the first place. AI suggested code is exactly the kind of problem that engineers would fall into this trap for. Its cool and exciting and very alluring. Lets no lose sight of the fact that most code being generated in front of a developer shouldn’t need a developer there in the first place. We should not even be sitting to code a lot of things we are tasked with doing today.
I would never willingly pay for AI coding tools. Why should I help improve a product that has a chance of putting myself or my fellow software developers out of work in the future?
> Then we grew our user base. We executed very well here, and grew our user base to 500,000 monthly-active developers, with almost zero marketing spend.
> Then, our product failed to generate revenue. Our 500k developers would not pay to use it.
Isn’t it better to work with a smaller number of users but more closely first. Otherwise you burn the chance to impress all of those users. Plus with 100 users you have a decent sample but you can also reasonably interview them all one on one.
Yeah having tried kite years ago, copilot absolutely destroys them in terms of helpful suggestions both at a line level and at a code block level. Its contextual awareness of surrounding code is also fantastic.
Now whether or not that's due to the fact that copilot had the financial resources to train a significantly superior ML model is another question, but throwing shade at copilot is a fairly transparent move.
>"First, we failed to deliver our vision of AI-assisted programming because we were 10+ years too early to market, i.e. the tech is not ready yet."
I highly doubt that you failed! You blazed a trail forward for people in the future to follow. Financial success is not the same thing as taking a super tough problem to solve and then making inroads solving or starting to solve the many sub-problems (and their sub-problems) that invariably show up as a result of taking that path.
>"Then we grew our user base. We executed very well here, and grew our user base to 500,000 monthly-active developers, with almost zero marketing spend."
That's extremely impressive in my book! (By comparison, I failed to get 2 users -- for one of the apps I built -- and that was with marketing spend! <g>)
>"Then, our product failed to generate revenue. Our 500k developers would not pay to use it."
You might mean that there may have been an issue with communicating the VALUE of your product such that users would "see" (magical word, "see" -- "percieve", "understand", "observe in a way that you do") the VALUE of it -- such that they would be willing to equally-and-oppositely exchange their money for that VALUE...
Finally:
I do not think that you failed, and you have no reason to apologize to your investors, customers, employees and others.
You pushed the envelope -- and you created great value for future generations who will no doubt benefit from your pioneering steps in this gargantuan undertaking.
Well done -- and I think more people should appreciate you for that!
I've used Kite, it simply wasn't as good as Copilot. I'm not sure why they say that Copilot still doesn't work well, it works well enough for me and I presume everyone else who pays for it.
That being said, glad to see a lack of Our Incredible Journey type language here and more of a true postmortem of their business and technical decisions. It is rare to see a company go into so much detail when shutting down.
It failed because they did it exactly in reverse of how it should have been done. First they assembled the team, then they outlined the product then marketing and then only then they realized nobody would pay for that. You're supposed to first sell your product and then build it! I wonder whether anyone raised this issue in the early stage...
> 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.
What sounds more plausible you:
- engineering managers hate free money
- it’s obvious to everyone that this statistic is bullshit
As a fellow failed startupper, this blog post reads like any other failed startup goodbye post.
Sure, your people were great but they didn't innovate enough to make an attractive product (granted, AI code autocompletion is hard - I doubt we'll get something I'd be happy to pay before we reach GAI and we'll be all out of a job by then).
Oh and the "It's not the tech fault which is amazing, it's just a sales pipeline issue!"
Look, I understand caring about your employees and I said the same BS when my company failed trying to shift all the blame on me and not on my team. When you are in a startup it's everyone's job to say "hey, btw, what we want to do will suck because the tech is not there".
If you see something raise it and try to pivot, or you'll be out of a job with worthless grades.ß in
I think they're spot on to say they were too early. But their analysis of the current state is pretty tainted by their personal situation.
Many people I know find copilot extremely helpful. I think tools like it are about to become extremely important to the productivity of everyday developers. I seriously doubt it will take $100M to develop. The company Kite might have needed $100M to get there, but I bet you a few smart people working evenings in their garages can get there too.
Also the "nobody pays for dev tools" line is pretty obviously a weak excuse. Github is a developer tool that was worth $7B+. The truth was they just didn't provide _enough_ value to get people to pay for it. That's clearly true, and goes along with their idea that they were too early. Not that the problem is impossible.
No opinions on the product itself as this is the first I’m hearing of it. But:
I am very impressed and happy to see the open-sourcing of their code like this. I often find myself thinking about how much human knowledge and effort disappears when a company shutters and all of their documents, code, etc go with them.
> Our diagnosis is that individual developers do not pay for tools.”
Sadly, I never heard of Kite until copilot came out. As someone who pays for tools, I would have considered it (have paid for JB for years, various atlassian tools, and other utilities/etc).
Value generation in software doesn't equal profit generation. Is it a flawed business model to pursue growth first and profit later? No, as long as there is a good plan to get that future profit. If the 500k developers weren't driving business spending decisions enough to pay for Kite, either it isn't particularly useful or it's a sign of the times. I'm guessing from the rest of the context it's the former, no one seems to be crying out that this is a great product that will be widely missed. This sort of failure is good and a good decision by the business leaders. It keeps our economy healthy, you want the real winners to win, and not every bet works out.
> Our diagnosis is that individual developers do not pay for tools.
Quite simply developers are not decision makers. Often engineering managers aren't even decision makers. I fully believe if you want to dominate in that area you need to target decision makers who force it upon their developers. How many of us have been told we're using X database or we're using X project management tool or even X virtualisation system? Management makes these decisions which is why if you go an AWS conference you'll find majority of the people there aren't techies but management and lots of the talks are aimed at management understanding the tech.
I've seen many other commenters lament the fact that "even though devs make a boatload of money, they don't want to pay for their tools".
This may be true.
But I think the biggest issue is that most developers are only developers "at work". And I've seen far too many people work with subpar tools (old, dingy PCs that would take ages to do anything). Management thinks this is fine, and that a 5 yo intel U laptop with 8 GB RAM is AOK for running heavy computations in 2022.
So, going out of their way to buy some "text editor" when vscode is free? Not gonna happen. Even if the devs themselves are convinced.
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!
"""Our diagnosis is that individual developers do not pay for tools."""
Not to sound overly mean but it might have been a good idea to start with testing this idea first/earlier. Additionally, it seems to me like they didn't do a great job at identifying their customer. It's probably not individual devs but rather the people they work for. So you're in a B2B business and need to sell it that way.
The meaner response would be that it seems like developers do not pay for YOUR tools. Seems like there are plenty of paying customers for copilot for example.
> First, we failed to deliver our vision of AI-assisted programming because we were 10+ years too early to market, i.e. the tech is not ready yet.
What?
You're supposed to create the technology, not wait for others to create it. That's why VCs give you money, isn't it?
> We built the most-advanced AI for helping developers at the time, but it fell short of the 10× improvement required to break through because the state of the art for ML on code is not good enough.
Aren't you supposed to advance the state of the art?
The key issue is that ml/dl is pure statistics - there is no intelligence or learning or conceptual awareness of space-time, so that technology can never do so many things people try to do with it.
Some ml/dl tools (think gpt3) seem to be able to answer questions that we previously thought you needed gintelligence for. I think the line between "pure statistics" and "intelligence" are much more blurry than they used to be, and might go away entirely.
Actually, I think the industry is finally realizing that there is no intelligence there, especially with gpt3 which can figure out with great precision what statistically comes next, but there is zero understanding of the space-time conceptual meaning for gpt3 in that answer - its not designed to do anything but figure out statistically what is most likely to come next.
> Another key piece of evidence, the failure of all FSD attempts trying to use ml/dl thinking its more than just statistics.
I would almost put FSD as a good example here. Yes, some attempts here are very naive and try to use ML as a magic black box tries to covers a long stretch of the system from vision to turning the steering wheel. However the best performers just utilize ML for small well-defined parts of the system and in a "statistics on steroids" way with most of the other parts utilizing much more traditional methods.
Some of the things GPT3 can achieve are very impressive, but once you work you work with it a little bit, you definitely feel that it just regurgitates the masses of text it has been trained on and tries to piece it together in the most cohesive ways. And for production usage, it (and similar models) have huge problems with halucination where it will confidently spit out "facts" that are just plain wrong.
That’s what many people do as well, I feel. Not joking.
That aside, copilot works well as a proactive search tool for idioms, templates, and boilerplate. It can also do things like build the invocation of a CLI tool, with arguments, from a comment line. To me, if nothing more, is the next step in the use of reference. I started with man, .hlp files and books… then progressively replaced them with Google because it was faster even if more noisy… now I use copilot first.
I pay for jetbrains and GitHub co-pilot from my pocket I find it totally worth it. I think they must have been hesitant in asking for money. Copilot was free for 3 months and then paid.
Kite was good, integrations were plentiful, sad to see them go!
I hope Tabnine learns from this and ups their game, I love what they are doing.
Not so sold on Github Copilot yet, and probably the observations of Kite are applicable to Github Copilot, but due to their deeper pockets they may survive long enough to make to the AI breakthrough needed to get this product/class of products flying!
Thank you for open sourcing your code. Thank you for your effort. 7 years is a long time to work on something, and I hope you all recover a bit from the previous campaign before moving on to your next things.
> It includes our data-driven Python type inference engine
I couldn't find which repository this lived in. I am very interested in it, as my team maintains a few open source static analysis and code generation tools. We'd be interested in trying this out.
> The largest issue is that state-of-the-art models don’t understand the structure of code, such as non-local context.
Copilot ended up being rarely helpful for me. But on the other hand, MS IntelliCode (I think it only works for C# in full Visual Studio) was a fantastic productivity tool that actually sped up writing code because it does understand the structure of C# and your codebase. Wish it was available for other languages and VSC
Maybe instead of blaming potential customers for not finding enough value for your product, you might need to start looking inward.
I gladly paid for my own personal license for R# that I kept across four jobs over 8 years. I only stopped paying for it because I no longer develop in C#.
I think if they open sourced Kite from the start rather than as they call it quits that they could've had a ton of free development done on their products by interested developers. Developers not paying for tools is simply not true. Developers do pay for good tools. Sublime text is one such tool many devs pay for and it's quite profitable and completely built and operated by a two person team.
I pay for Copilot. Integrates with my neovim and my Jetbrains IDEs. I love it. Great stuff honestly.
My favourite use is at the command line. It's great!
I pay for it myself and use it in all sorts of contexts.
EDIT: Actually, perhaps that is actually smart. If you want to find people who would pay for dev software you probably should target people who pay for dev software already. Jetbrains is better for paid plugins than VS Code by this logic.
Automating software is a really hard problem. I think I can imagine a possible roadmap to it, but it's so hard to explain it in under an hour, it would require several sequential new technologies, and some of it hinges on parts of information theory I don't know enough about, and statistical ML isn't part of the core.
I wonder if a better approach is to build and train the ML model to recognize the AST of the code in question rather than text. The workflow would be Build AST -> run ML to get an optimised solution render new code out from that optimised AST.
A lot of work I think and as is pointed out here devs wants their tooling for free.
I like folks here defending their buying strategy. It makes the point even more valid, as I read all of these, they are very few data points. Quantitative and Qualitative -wise, developer tools market are almost non-existence. Better to jump into overall software development process tools if you insist.
Two things are not providing for a bright future of IT:
- developers willing to use AI crutches instead of their own brains to write their code;
- developers unwilling to pay other developers while being paid themselves by companies whose profit models are often far removed from the honest craft of developing something wholesome.
I tried Tabnine and had mixed feelings. It can make sensible suggestions and save my time, but Tabnine forcing said suggestions to top priority means I’m spending time to press down key to find the obvious autocomplete. And this can’t be turned off.
Depending on your editor, this may/should be customisable. The tabnine client for Emacs (company-tabnine) is just another completion backend, and the order of completions presented is a just a variable in company-mode that can be set to any order you prefer[1].
2 years ago i try to register, not working.
Write some mail to support, no response.
Hello GitHub CoPilot. Have convinced myself and am also willing to pay for it. I can't understand Kites Argument, that their users did not want to pay.
Ahh, why Python ? Except for social networking website (which's harmful), like reddit, instagram, choosing Python is bad for the world. Use better tooling, better languages to spread the good sides computing instead.
A few people would pay, you have to start monetizing your product from day 1 if possible. This was my mistake as well, I had 6,5k users in the group, no money after 8 months. So I shut it down.
I was a relatively early Tabnine user and suggested this time two years ago that people were “sleeping” on AI code completion. [1]
I read about and tried evaluating Kite at the time and it seemed like it was in some kind of private invite stage. I remember thinking it must have been acquired and wasn’t taking new users. This must have been an incorrect take.
I’m surprised Tabnine is not mentioned in this thread at all, though because that was acquired and afaik is still operating.
Before copilot came along, Tabnine, not Kite, seemed like the ai took to beat.
I also remember a Python dev relations person from Jetbrains going on a podcast and clowning on AI code completion. That was in April of 2021. [2] A month later copilot dropped.
The very strange thing about that was Jetbrains described efforts to build an ML-based code completion plug-in in 2016! [3] It obviously failed to follow through on that.
I still think G Co pilot represents a threat to jetbrains IDEs overall. Even the packaged autocomplete can’t compete on basic stuff copilot does now.
I disagree with the idea that AI code completion is not good enough yet. I see that said all the time and yet it can masterfully fill in boiler plate today.
It can be way better, particularly in languages outside JavaScript and Python, but it’s usable now and maybe even profitable as a service if the business is not leveraged by VC capital.
If you listen to the September interview with Eddie Aftandilian of Github Copilot you would realize how early it still is for that product, as how to measure success in code completion is something still requiring behavioral patterns that are still being recorded.
Indeed. I find it very exciting when a product category dominated by proprietary products gets a FOSS alternative. I wasn't aware of the others, thanks!
I find co-pilot useful when I am working with a language I am not familiar with but I imagine that isn't the case for most developers working their day to days. I see ML and AI in dev as more of a code generation tool. Describe something large in a prompt, get a bunch of code. Then a dev can run through it like a code-review, making changes and tweaking it to suite the need of the client/business.
copilot might impact kite's future, it's hard to compete against microsoft.
copilot: "Get code suggestions in more than a dozen coding languages including Python, JavaScript, TypeScript, Go, and Ruby", how about c, c++ even lua here? if they cover c and c++ I can pay $10 per month right away.
I was truly wondering why is it developers don't want to pay. But now I think I got it: If they can implement something like the tool themselves, it is clear how much money they are saving by NOT buying it, and implementing something like that themselves.
When you just program you don't really know the value of the code you are creating, you get your salary and company gets the benefits of your code. But if your code makes it unnecessary to pay $100 for something, the value of what you are doing becomes clear, it is at least worth $100.
Hey if we're going to talk language, maybe you should just use 'Kife', it looks like Kite and means to steal. (Allegedly derived from Old English word 'kip', net says it's British slang, but I've heard it a few times in northeast US.
> take over (something) and use it for a different purpose.
You are misleading readers in order to promote your agenda. You clearly speak perfect English, so you know what hijack means. "take over (something) and use it for a different purpose." is not found as a definition of "hijack" in any dictionary. "Hijack" implies "unlawfully" or "without having a right to do so".
Of course, every word can be used in a slightly different meaning; for example, in software can (harmlessly) hijack an entity (circumventing the usual API for expediency or performance). Such broadened semantics is perfectly fine when there's no confusion about the meaning. Very clearly in the case of OP, there was a clear intention to imply "unlawful" or "without having a right", so this exception doesn't apply.
The sad thing is that I actually support your agenda. I just don't support promoting it through misleading statements.
> : to take or take control of (something) as if by hijacking
> often, specifically : to change the topic or focus of (something, such as a conversation) : REDIRECT
It wasn't my statement by the way, I just figure if you're going to nitpick you should at least be correct about the nit.
I know good developers pay for tools. Maybe the lesson for someone who wants to be best at what they do is do things 90% of people they are competing with wouldn't do.
You know there is no score board for software engineers right?
And you know that the company is supposed to buy this stuff and you can get fired for using unapproved tools that send code and probably violate copyright.
People pay for services around this technology. They pay not for the technology itself, cause there are many other provider. Nobody would use Docker or Vagrant, if they use the same pricing strategy as all competitors before. Red Hat Linux is free, but the company make money, but not directly with the core.
Nobody ever would buy a Android license, google has other strategies to make money.
The VCs are willingly fleeced - they aren't about companies generating revenue either. Hard to feel sorry for VCs when they're playing the same game Kite is - just hyping the market and flipping an asset, hoping the music doesn't stop before they get out.
Because the incident should be fresh and impactful enough to remember, from my point of view it almost reach levels as bad as Sourceforge adware injection in open source software installers.
For a recap for people who weren't in the industry or have short memory.
Kite took ownership of some popular code editor plugins and injected some adware/tracking code.
"While we built next-generation experiences for developers, our business failed in two important ways.
First, we failed to deliver our vision of AI-assisted programming because we were 10+ years too early to market, i.e. the tech is not ready yet.
We built the most-advanced AI for helping developers, but it fell short of the 10× improvement required to break through because today’s state of the art for ML on code is not good enough. You can see this in Github Copilot, which is built by Github in collaboration with Open AI. As of late 2022, Copilot has a number of issues preventing it from being widely adopted.
The largest issue is that state-of-the-art models don’t understand the structure of code, such as non-local context. We made some progress towards better models for code, but the problem is very engineering intensive. It may cost over $100 million to build a production-quality tool capable of synthesizing code reliably, and nobody has tried that quite yet.
Nonetheless, we could have built a successful business without 10×’ing developer productivity using AI, and we did not do that.
We failed to build a business because our product did not monetize, and it took too long to figure that out."
How many working hours, tons of materials will it take?
Could they be used on more relevant needs to humanity?
If so, why use them on a moonshot we will die before humanity achieves? Essentially approving burning up resources on unverifiable, perhaps unachievable outcomes?
We still fund a lot of agency to iterate on high minded potential as if future humans have an immutable obligation to carry on the work.
Secular norms and justifications are not sacrosanct. The dollar is a made up token of power.
While this maybe true for FAANG and other tech giants, it is unfortunately still a lot of money for most startups that are working their way to IPO.
Tbh even at tech giants that make tens of billions of dollars, a $100 million investment is likely a lot, I'm guessing this sort of investment will require sign-off by CEO or at least VP level along with a solid business plan.
I know this first hand, building a developer tool startup and failing to reach any level of revenue. In the end, the tech was bought out by a larger company to recover a fraction of our VC investment.
The challenge is that when you're building software for developers, they already know how it must work.
It's like trying to sell magic tricks to magicians. Sell magic to regular people, and you'll see some significant revenue.
I've used Kite before. It was ok. But I am a SWE. It's entirely possible that Kite would have seen major adoption if the push was towards non-technical folks trying to get their feet wet in software. Eg: Data scientists or business.
The reason why BI tools sell so well at the moment is that you have tons of C-level execs that like the appeal of a business-optimizing tool requiring little to none of any actual software development.
Let that be a lesson to everyone. You can't blow away developers. They're just too damn ~~smart~~ well-informed.
Edit: Another anecdote: A buddy of mine built a bespoke OCR and document indexing/search tool. He has ~60 paying clients (almost exclusively law-firms and banks) that primarily work with printed pages on paper. No Saas. No free tier. The client data resides on an on-premise Windows box, avoiding issues with sensitive data in the cloud etc.
He's a solo dev with support contracts and nets something like $1000/month from each client.
For your average lawyer/paralegal, the ability to locate and reference a single page from thousands of pages in under a second is magic. So they pay for it wholeheartedly.