Nice website, but I wouldn't switch to this from Fish/Zsh on account of:
1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.
2. Less trust in you as a YC startup. What if you fail? What if you sell out?
3. Requirement of email.
4. Telemetry and privacy concerns raised by others.
5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).
> 2. Less trust in you as a YC startup. What if you fail? What if you sell out?
> 3. Requirement of email.
> 4. Telemetry and privacy concerns raised by others.
Dovetailing on these...
Like why is a CLI tool VC backed? Is the business model just selling our data? Is the VC backing for another product and the CLI tool is just a PR thing?
> Investors: We've raised several million dollars from amazing VCs like General Catalyst and Kleiner Perkins, and angels like Jason Warner, Adam Gross, Olivier Pomel, Scott Belsky, Will Gaybrick and a handful of other impressive dev tool founders and executives.
The fact that a CLI tool raised millions of dollars while also being basically powered by open-source contributions is also kind of a wtf moment to me, but what do I know.
There has to be some grand vision behind this, presumably large-scale data capture. At the end of the day, the terminal is is to the dev what Google is to the internet user: the point of entry where many journeys begin, with dozens or hundreds of interactions every day. And while devs are a niche market compared to Google's userbase, they are a lucrative and strategic one nonetheless.
Casting aside the environment of low-interest rates and massive inflow of investment in startups, how does a product like this otherwise raise several millions? The pitch sounds like something that a competent indie dev studio could sell on the Mac App Store...
Yes, but when you’re Googling, you’re searching for public information.
When you’re using the terminal, you’re mostly manipulating your own data, often in ways that would reveal sensitive information if your terminal history was leaked.
Any attempt to collect data from users’ terminal interactions is indistinguishable from keylogging.
They could rationalize it as only capturing the commands and not the arguments, or something. (If that's indeed the long-term plan. No clue; for all I know data collection isn't intended as the business strategy whatsoever.)
Your employer's group policy controls, management agents, etc. that control access to their internal network can (and are) already telling them all of that information. They're basically rootkits that run anything they want on computers that access their network. Usually they just distribute certs, keys, etc. or remotely wipe a lost/stolen machine, but the capability is there to do anything.
I think you misunderstand how tools like this sell, the enterprise offering will be fully supported integration of tools that are enterprisey (Cisco gear, Netapp, Fortinet, Xen, VMware, Veeam) and a hosted offering so teams can collaborate on scripts and snippets á la postman.
I saw the first few commands of the video on their site and I'm like "wait Wtf a visual representation of what hitting tab-tab does already? That can't be it"
But yes that's basically it. You have _all_ of this already and all it needs is for whatever tool you have to provide the "completion" definition file. The graphical nature of this makes it _less_ useful (as others have pointed out w/ regards to no Linux support). How this would sell to enterprise I do not get.
Kudos to them for getting funding for this tho. I wish I had the guts to take something that already exists better and free and ask for someone to pay me money to try and sell it to other people instead.
It strikes me as a pretty disgusting waste of "millions of dollars" to develop a Mac-exclusive app that does the same thing that your shell does, but slower.
I mean they’re trying to be JetBrains but for Bash so it makes total sense to me why it would be a many many millions of dollars effort.
I think people forget that IDEs (which is essentially what this is) are a stupid amount of work. Then you have
to add the rest of the business: sales, leadership, support, hr, ops. I mean a 25 person company $200k average total comp is 5mil annual burned cash just on salary.
> The fact that a CLI tool raised millions of dollars while also being basically powered by open-source contributions is also kind of a wtf moment to me, but what do I know.
There's probably more money than people know what to do with. So they might be investing in completely crazy ideas hoping that the founders figure it out along the way.
It's about 6(ish) years old and went through various states of reinvention before I landed on the current design and it's been my primary shell for the last 4 years now.
> Is the VC backing for another product and the CLI tool is just a PR thing?
Autocomplete is our first product. The bigger vision that Fig can enable an ecosystem of terminal extensions. Here are some early prototypes we built [0] and here is the discussion from when we were posted on HN last summer [1].
> Is the business model just selling our data?
We will never sell data. That just isn't the business we want to build - Brendan and I like hacking on the terminal because it's interesting and we get to solve our own problems.
We've been lucky enough to find investors, most of whom have an engineering background, who understand how important the terminal and believe there is a lot of room for improvement.
Obviously, we would like Fig to become a sustainable business. We plan to monetize in the short term by offering autocomplete for internal CLI tools and scripts. Longer term, we think that there is a lot of stuff that developers do in the browser that make more sense in the terminal. Fig's autocomplete product is powered by an API that lets anyone build graphical extensions that are connected to the terminal.
> We will never sell data. That just isn't the business we want to build
These are just words from strangers on the internet. You're offering a free and auto-updating app. You don't give me a contract guaranteeing anything. Most terms of use/privacy policies have a clause stating it can be updated without notice and when you do have actual policies on your site I'm sure they will be similar.
At any point you can decide that actually, you do want to share my data, or share access to it through one of your products. Maybe you won't call it "selling" (the same way Zuckerberg can tell Congress that Facebook doesn't sell anyone's data).
Maybe you don't decide to share my data, but Fig gets acquired and the new management decides to. Maybe an attacker gains access to the data and shares it. Maybe an attacker compromises an update, turning all Fig instances into keyloggers, and paired with the required email addresses uses it to compromise other data.
No offense, but the only way I'll believe a company will "never sell data" is if it never collects any in the first place. Even if I have ultimate trust in the current founders, what happens if/when you're acquired or the investors install different management?
Great. Looking forward to the Terminal App Store and learning why my company should pay you for the arcane knowledge of where bash_completion.d scripts go. Let me guess, a lot of emoji involved?
You are aware any shop with a modicum of competence is already doing what Fig does, right? Usually on a central or bastion server? What kind of TAM did you put in the pitch deck? People who can’t read man pages or pull apart an RPM to see how, for example, git’s completions work?
You’re probably going to price shell autocompletion per seat and you expect people to not think VC has jumped the shark? What’s your exit?
> Like why is a CLI tool VC backed? Is the business model just selling our data?
Agreed. Take a look at Nabu Casa, the developers of Home Assistant and Home Assistant Cloud. They are 100% self-funded by their revenue from HA Cloud and the hardware they sell.
Because of this, I don't have to worry about investors demanding a return on investment by any means necessary and potentially generating revenue from users' private data.
CLI is a relatively "pristine" environment, where a lot of people's time is spent and nothing competes for our attention (or data as was pointed out). Any business model that could plausibly exploit this environment for financial gain would be an easy sell to investors.
I don't know anything about this product's intentions, but it's easy to imagine the possibilities once you start getting permission to pop something up in someone's terminal window.
Well, it’s even easier to imagine that they will start charging money for it. If it makes life easier for developers they can easily charge 20 bucks a month for it.
You summarized my exact feelings about it, especially #1, 4, and 5. I get the feeling that the team hasn't done their homework on potential users and existing solutions.
Unless something external changes the incentives in the market you aren’t gonna see bits in a box return as a business model any time soon. ARR is the only metric that matters to get you funding, it’s way more expensive to support multiple versions than something evergreen, and you can’t really do per-user unlimited device licensing without a login. You can fake it with per user keys but then someone has to have a login to manage them still and your key is now essentially just a login where self-service password resets can’t be done. Why bother when companies clamor for SSO about a billion times more than they ask for anonymous user accounts?
I'm on the same boat, although I have an additional requirement that disqualifies Sublime Text: I want the software to be source-available. Not necessarily FLOSS, but I want to know that if push comes to shove I can hack the code and recompile the software.
I don't want to have to rely on the devs if I want to tweak something that's not meant to be configurable, or if I need to run the software on some unsupported configuration and it breaks.
Yeah this project totally completely baffled me. "Autocomplete for the Terminal". What?? Bash has had fully programmable auto-completion for over 20 years [1] -- and that's just one comparitively bare-bones shell, out of dozens that are all free forever and not spyware.
Watching their demo didn't help either. At most the behavior seems an incremental improvement over what Bash ships with in most distros, and it's not even clearly better than that (IMO worse, I prefer the trailing slash or color-coding that Bash uses to distinguish file/dir properties vs icons). Joke: Is the "perceived need" really just because macOS's default Bash distro has these features disabled?
Right: Assuming good faith, this project seems completely backwards.
But if their real product is the telemetry that also ships with it, and they've identified that many newbie developers have a hard time seeing through marketing pages directed at developers (eg like "webscale" stuff from mongodb circa 2010), then it, unfortunately, makes more sense.
I agree with all of your points and I probably would never use this product. That being said regarding Linux support, given the fact that Fig effectively needs to hook into your terminal emulator and your shell to drive a custom overlay, it seems like it would be a huge headache to add support for Linux given how heterogeneous the terminal setups can be on the platform. Imagine having to support urxvt running zsh on X11 and the gnome terminal running bash on Wayland or xterm running tcsh or...
I think on Linux it would make more sense to directly modify one of the many existing terminal emulators to add this functionality or you'll have to severely limit the supported configurations.
Thanks for your insight here! We are still deciding the exact implementation, but completely agree - Linux is a challenge due to the heterogeneity of distros, window managers, compositors, etc.
Point 2 is how I feel these days. It's hard to trust any low-level (installable) dev tools supported by VCs. Personally, that hard to trust is also moving up the stack, maybe more so because of the increased attacks on the software supply chain vendors (i.e. CodeCov, SolarWinds)
I agree, and since it's VC backed it also feels like this is going to end up as SaaS for your terminal.
I would honestly feel less skeptical if this was a Show HN and the founders had just organically launched an app that did autocomplete and asked for some money to buy a license. I'd put that along side similar attempts like Xiki.
VC-backed changes it though, it feels different. It'll start with a subscription model and if this requires elevated privileges to run as what could essentially be a keylogger, it won't be long before the privacy promise goes away and the marketing team takes hold.
> maybe more so because of the increased attacks on the software supply chain vendors
I'm intrigued by this but not 100% sure I follow. Is the implication that VC-backed startups are more likely to suffer from a supply-chain attack, or just more general reluctance to incorporate any new tech into the stack as it increases the attack surface area?
I'm personally reducing this surface area with clients in light of recent attacks.
Personally, something like this w.r.t. VC means that incentives will diverge and they lose touch with what it means to be a dev tool.
w.r.t. supply chain, it's probably more of a correlation (related to) that they will eventually have the large companies as enterprise customers who are the real target. Also, once making money becomes the primary driver, other important tasks are deprioritized. I've seen both the tools and their correct usage go to the wayside.
Most abstractly I think the misaligned incentives is what happens. I'm not convinced that VCs get dev tools and don't ruin them.
> Personally, something like this w.r.t. VC means that incentives will diverge and they lose touch with what it means to be a dev tool.
> Most abstractly I think the misaligned incentives is what happens. I'm not convinced that VCs get dev tools and don't ruin them.
I'd love to hear a little more about your thoughts here. We've committed to making autocomplete free for individuals. In your opinion, what else can dev tool companies like ours do to make you feel more comfortable?
To start with, remove network related code. There is no reason for a autocomplete language to need to fetch a file or send telemetry. A telemetry setting is insufficient
ITerm has had security issues, yes, but that is besides the point.
With this product, are their collaboration features secure? Are their servers which support that secure? You are installing a tool which phones home on each command
#1 I do not agree with. This is a great idea for a tool, and I am willing to pay for it. This is an extension to my terminal and a useful adjunct to my shell, not a replacement for either.
#5, maybe but that's fine. Lots of things are Mac-only or Linux-only. It's a proof of concept. Moreover they appear to be working on some kind of standard specification for completion meta-data, which other tools can start to adopt and use if it turns out to be a useful spec.
#2-4, it's open source (at least it looks like it's open source from the website). If the startup sells out, the project can be forked.
I have found "it's open source" to be a real-life meaningless response to "I prefer tools that I am likely able to have a significant amount of autonomous control over in the future."
The software market has very effectively figured out how to make things "open source" in name only (offhand, Canvas is the one that's killing me these days), and unfortunately now all such claims must be taken with a huge grain of salt.
#1 That's fair. Each to their own. For me I wouldn't be willing to pay even £1 a year for it.
#2-4 Firstly, just because it can be forked is not to say that it will. It's not easy to maintain a whole project in your spare time. Also, this may be a moot point since the completion engine is supposedly proprietary (as per another commenter).
Point #4 is particularly salient since it seems like telemetry information for a CLI-based tool which monitors the user's keystrokes doesn't provide the user any advantages.
We started with macOS because I have a background in Swift development. Linux is definitely not an after thought to us!
As for the telemetry concerns, I totally get that. We've tried to strike a balance and it seems like we've got it wrong. This will be fixed in the next update.
Just to clarify, the text you type into the terminal NEVER leaves your device. Fig does not store or collect this information.
We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app. We also send which completion spec (eg. git, npm or cd) was used to generate the suggestions to know which commands to prioritize.
>We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app
And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal.
If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea.
And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is reallyreally bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.
+1 for this. I don't wanna be rude, but dataops isn't a joke: I'm not going to put my security into the hands of someone who already made egregious security oversights an integral part of their product.
A distinction without difference, in my opinion. And it doesn't change the fact that anything other than 0% telemetry without full, complete disclosure and permission from the user is not good.
> generate the suggestions to know which commands to prioritize
What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration.
Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline.
What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?
I don't know if that's a fair reading of the functionality. It seems likely your mistakenly pasted password will generate an autocomplete and the (mis-)matched "spec" command will be sent as the telemetry, e.g., pasting "gi)#(RCS23!_)(U" into your terminal might result in "git" telemetry, not the password itself.
It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.
The current implementation of Fig is a native macOS app (Swift/ObjC) that exposes an API to access terminal specific information - edit buffer, working directory, current process, etc. On every platform we support, we'll implement this natively.
As Fig grows, we want to enable an ecosystem of UI extensions for the terminal that are built to go cross platform. Using web technology here made sense since we can leverage built-in webviews for rendering or bundle a lightweight implementation like Tauri[0].
I don't understand this response, so let me rephrase my question.
This page https://fig.io/docs/getting-started says that Node.js and NPM is required to use Fig. I presumed this meant that Fig was written in JavaScript, but you're saying it's native. Then why is Node required? If you're using web views for UI, wouldn't those web views on each respective platform already have their own JS engines?
> 1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.
It does have the features I want, although not enough to convince me to switch right now. cli can be painful if you are working on commands you are not familiar with. IMHO, this is a better interface than the ones in Fish/Zsh, that provides richer information regarding command choices, hence can be a huge improvement for discoverability.
Imagine that you are not familiar with AWS EC2 and want to spin up an instance to play with. If you do that via awscli, first you need to run a bunch of `--help` commands to find the correct subcommands(`aws ec2`, and then `aws ec2 run-instances`), after that, there are 40+ flags for `run-instances`, some are mandatory, some are optional. If you do that from the web console, there's a very friendly wizard with several pages breaking down by networking, storage, OS...etc, intuitive and easy to understand.
Speaking of, how did you generate the specs for the AWS cli and everything else? I wouldn't have thought that info is nicely laid out and documented somewhere.
As soon as I saw the title I anticipated the Dropbox conversation!
I’m guessing people like me who use the shell as a means to an end. Honestly most of the time I’m using git bash “coz it’s there” and hate typing in commands. I actively avoid it. I installed LENS for kubernetes to avoid it.
I’d rather write a script in an IDE and run that than be working at the command line. Because then I can treat it like code, review before running and it’s repeatable.
I really get the benefits of this tool but I won’t use it because I prefer to avoid excessive command line use - preferring GUI and scripts BUT I do get why it is useful if I have to do interactive command line sessions
Often the argument is simply test vs prod. So I can run it on my machine but also run it from Travis ci.
Any connections or secrets would be in the environment. For local I’d create another script to set them up and call the first script. Why? So the secrets don’t end up in the repo by mistake.
which oh-my-zsh plugins do you use that can do this? Is there an all-encompassing one or do you need to download tons of different ones like a docker plugin, git plugin, etc
I’ve been using grml’s zsh config [1] for years. It’s one file, I’ve never installed a single plugin, and it’s been doing a lot. Couple of examples:
- When I auto-complete a path, the shell prints all options and I can navigate between them with either tab or arrow keys
- For many tools, like git, auto-completion shows an annotated list of possible options/subcommands (and again, you can navigate them with tab or arrow keys)
- If I type something like chmod 644 and then start auto-completing the filename, the suggestions exclude every file that is already 644.
Also, there is a format to add auto-complete information for more tools. I’ve never actively used it, though, and I don’t know if it’s been adopted by any other shell/tool. I don’t even know if it’s specific to zsh or to grml’s config or to something else entirely. It has just stayed out of my way, while greatly facilitating my shell usage.
As a last point, none of these examples have been added recently. They have all been there for years.
This is not to pick on fig, but rather to show what zsh has been doing all along (and I suppose other shells like fish, too, but I’ve never tried).
Can you suggest some tools which auto suggest like Fig and work with zsh? The built in auto complete in zsh works nicely, but how do I get the drop down of all options?
Since switching to it from the default shell of Mac OS terminal (zsh I think) I have found it immensely productive. Some of the things it does seem Magic like auto completing uncommitted files when I say “git add <tab>”
You need no tool at all as you can do I reverse search in any shell with ^R. If you want to do it with a better UX you can use fzf. If you want the suggestions you can use zsh-autosuggestions or fish shell. Setting them up is straightforward. And if you want an example config for Zsh you can look mine. Zinit, the package manager, automatically load/install the plugins when loading the shell.
4 is a killer for me. I like the idea, I'd probably like the tool, but no way I'm installing a thing that sends out everything (or substantial part of) I type into CLI to the external server. Too much risk. I am ready to trust they mean well and make the maximum effort to make it work securely, but it's just not something I'd ever feel comfortable with.
>5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).
Absurd? I'm definitely more confident that Fish/Zsh will stay free forever without changing their incentives, licensing and pricing than a YC-backed startup whose primary goal is to make money.
I generally try to avoid startups and either go for established companies (business offers are more likely to stay there and work as expected) or small bootstrapped business (cheap, more likely to stay true to their roots, do one thing well without breaking everything in the future).
Startups are good for free trials as they have VC money to spend or finished deals (purchase once, consume once, forget about them).
1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.
2. Less trust in you as a YC startup. What if you fail? What if you sell out?
3. Requirement of email.
4. Telemetry and privacy concerns raised by others.
5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).