> 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...
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.
Can NOT this tool say to my employer - How many times I compile my code in a day ?
When I get a compilation error - how quickly it gets to compiling state again ?
Was the compilation error a trivial mistake ?
How much time is spent between each commands ?
How productive I am keying in command one after another ?
Also can NOT Fig figure out current apps Im running on my machine ?
What is the current app in foreground ?
How long I run each app ?
When I log off ?
How many times I log off ?
It is getting interesting! Can anybody help with more usecases.
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.
There are other ways to support developers thru honest tooling (eg IntelliJ).
That would be a completely useless metric.
Also, don't you have a daily build pipeline anyways?
Maybe the founders sold this as a way to get dev telemetry data + a subscription.
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.
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.
Not really, in the bay area engineers make $150K-500K/year (closer to the $150K end for startups) and office space costs upwards of $200K-300K/year.
Here's one: you wasted a perfect opportunity to feast on that sweet investor's money.
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.
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.
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?
What about when that is no longer your call (e.g. the VC's want returns, you sell to Facebook, etc.)? Is there anything in place to protect us then?
> We plan to monetize in the short term by offering autocomplete for internal CLI tools and scripts.
I'd love to hear more about this. Sounds like the GHE model?
No, No, and no. matter fact, it earned itself a forever no. thx have a crap product launch.
You can start by allowing to download the app without asking for email.
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.
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.
Canonical already does this.
* No sign in/email required
* Works offline
* No subscription
* Updates for 3 years included in price
* Perpetual license for older versions
* License per user, unlimited devices and operating systems, including home/work devices
* License is just a matter of copying a file
* No telemetry/phoning home without explicit opt-in
* No DRM/copy protection
* No root access required
* Works on Linux
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.
If it is worthwhile and not freely available, I will certainly pay. There are some great IDEs and tools that fit into this category.
>> We know now that free doesn't really work.
I suppose it depends on your needs, but I find using free tools such as zsh, vim, tmux, linux, and many others very valuable to me.
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?
[1] https://en.wikipedia.org/wiki/Bash_(Unix_shell)#cite_note-60
There's so many great projects for bash and zsh add-ons like fzf.
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 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.
Our macOS approach might not work everywhere.
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.
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.
> 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?
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
Why do I even want a shared terminal?
#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.
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.
#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).
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.
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.
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 really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.
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?
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.
Then why on earth did you go out of the way to implement this in JavaScript instead?
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].
[1]
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?
Care to share more about this? Which terminals are you planning to support?
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.
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.
- 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).
Those scripts are usually supplied by the CLI tool itself. For example for terraform: https://www.terraform.io/docs/cli/commands/index.html#shell-...
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>”
I am amazed that a CLI tool isn't made for Linux
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).