This sounds a lot like the product is dead, and may emerge again at some point as an AWS hosted, Amazon branded product...
I'd never use a subscription + telemetry laden product like this in my core workflow, but sucks for the current users I guess.
If AWS bought it for the product, what reason would there ever be to stop the current business model entirely rather than leaving it on its current trajectory for a few months, untill said "needs" are addressed?
Just tell us if you just wanted the employees, just wanted some rights, wanted to integrate their product for your use, or just wanted to kill something off. I'm sick of reading the same new release for every acquisition knowing it's bullshit.
If it was just acquihire there probably wouldn’t have a big blog post tying it to AWS. Just negative publicity for acquirer when they could shut down quietly.
It never happens.
If $BIGCO had any intent to keep the product along, you'd be reading the post on $BIGCO's blog, not $FAILEDSTARTUP's blog.
That’s a good point.
But what reason is there to disable new registrations?
I'd assume the same thing is going to happen here.
I worked at AWS from 2010 to 2014 after also getting acqui-hired (AWS SDK for PHP, fka CloudFusion).
That’s an easy one: if it’s burning money like crazy on its current hosting, but only because of rents extracted by one of their competitors, not for any inherent OpEx-intensity; and that therefore Amazon expects it to be profitable when moved to live rent-free on their hosting.
Several companies have tried to SaaSify the terminal and failed, so I suspect I am not alone here.
"We've noticed that there's a component of the computing infrastructure that isn't sending everything you do to the cloud and charging monthly rent..."
Fig is a great product.
Idk though, this doesn't seem useful enough to me as an individual that I'd bother looking into it. Maybe for a team or company.
That's a euphemism. These companies "acquire technology" in the same sense that revolutionaries acquired Louis XVI's head.
Having something with autocomplete that works seamlessly with their services seems like a better idea than a plain prompt if you're going to use their shell. Hopefully they do something sensible and customer-centric with the telemetry stuff, that seemed to be the big drawback for many.
I am fully expecting that I'll have to go back to zsh-autosuggestions once the current iteration is fully wound down.
My favorite 'acquihire' story is when Oracle bought out MySQL and the creator forked it and made MariaDB.
when Oracle bought out MySQL and the creator forked it and made MariaDB
Not quite.Wiki tells me: https://en.wikipedia.org/wiki/MySQL#History
Sun Microsystems acquired MySQL AB (the company) in 2008.
Oracle acquired Sun Microsystems in 2010.
The day Oracle announced the purchase of Sun, Michael "Monty" Widenius forked MySQL, launching MariaDB, and took a swath of MySQL developers with him.2. You could provide a list of FOSS solutions to replace Fig.io, even better write a tutorial on how to install and setup those solutions.
Saving an hour of engineering time spent fiddling with your CLI config every year makes this a good value for a business.
I've heard a lot of good things about Raycast. I'm very tempted to jump ship from Alfred. Still hanging on.
I adore and appreciate Alfred, it was one of the first applications I would install on a new Mac. However, Raycast is a very well polished product and has been a great add-on to the daily arsenal.
The ones I love the most are Keepass, Bitrise, and the fact that you can just press enter to join the Google Meet call attached to the next upcoming meeting.
That's possibly the most inefficient way of saying "AWS bought Fig" but I guess it makes some people happier to frame it that way
In any event, I'll pass on "the CLI with a subscription that sends telemetry".
Paying hard earned dollars every month for a terminal is something so out of the realm of the possible for me I'm honestly baffled to see this has any customers...
Often that kind of language is employed when the actual transaction was structured as an asset sale coupled with en-masse hiring of the team, rather than a true acquisition of the company as a complete entity, which is not an unusual scenario when a company is in distress.
Any venture funded product has a sword of Damocles over its head. After acquisition the company product is much less likely to be shut down in the long run (unless it’s Google).
With Google, everything has a huge chance of being shutdown, unless its Gmail or Search, but in both of those cases they will also continue to get worse over time.
This sounds like a win for users.
I may be becoming a dinosaur, but it's not that I'm not willing to try new things. On the contrary, after many years of being rigid about having one true development environment, I've moved away from Emacs to VS Code, and work from more heterogeneous environments instead of being 100% Mac. So these platform-specific thick client apps no longer feel like the way to go.
And this isn't coming from some FOSS ideology. I don't personally care about any of that, but the best tools are sometimes FOSS. I've got a Mac and can deal with Linux as needed.
There's a whole graveyard out there of "next-gen" terminal projects, and none of those still alive seems to be gaining dominance. I don't think writing down a spec would help this, but it would be great if whatever emerged victorious had one.
If you need reporting on the scripts your developers are running on their local machines, that probably means they have too much access to live environments. Guardrails and reporting should be in your CI/CD process and your source control.
Shells like fish or shell plug-ins already handle autocomplete nicely, so that feature isn’t that useful.
If you need env/dotfile management you probably need to spend time making a proper development environment rather than shimmying in a tool to make doing the wrong thing easier.
SSH key management is so trivially accomplished by numerous methods like configuration management or built-in solutions offered by cloud providers. Plus, most development teams almost certainly give out too much SSH access as it stands.
If you need to SSH regularly that means your application isn’t shipping logs and your local development tooling isn’t good enough.
I'm a super confused soul, and currently I use all of them:
- Emacs (for clojure / lisps / big projects).
- NeoVim (for when I want to work in the shell, smaller scripts/playground, ssh).
- VScode (js / ts / frontend / figma / etc).
I've made both my vim and emacs keybindings / features almost identical, so there is limited context switching there.
I feel very slow in VSCode, I don't even have one of my most common task optimised in VSCode yet: grepping something and quickly moving to that buffer.
I was using both before but the upcoming annual payment reminded me that its over
It's much more bare-bones than Fig but perhaps useful if you're looking for an alternative! Send me feedback!
This is a dangerous assumption. Not all commands are lowercase. Interaction with an external service should be a deliberate, discrete action on the user's part.
FWIW, from my understanding llama.cpp is pretty easy to integrate and is reasonably fast for being API agnostic. Ollama embeds it, for example. No pressure, just pointing it out :)
The product was nice, but their business plan made zero sense to me, so I decided to not continue the process.
2. IMHO: Be in the wrong place at the wrong time. I've never heard a happy story about Amazon that didn't involve a metric ton of Kool-Aid.
Beyond that, actual GH Copilot does a damn good job of crafting any CLI command that you can describe.
Their servers have been overwhelmed by Hacker News traffic presumably.
Fig has been a godsend for acting as glue for one-off bash scripts that are added to repos.
They seem to have built a decent community, so I can see it continuing, provided the core/all code for Fig is open source. In the last 6 weeks, 57 new contributors took the time to create 62 issues and 111 new contributors took the time to comment. These are very heathy community metrics, but there hasn't been a lot of code activity, which would make sense if they were focused on the sale to AWS.
Source for my insights from https://devboard.gitsense.com/withfig
Full Disclosure: This is my tool
What you are looking at seems to be a repository of autocompletion specs and some server to publish them.
Wait for the “Our amazing journey” post where Amazon is just going to shut their product down
It would make no sense for AWS to treat this as ongoing concern. They are probably going to integrate it with their other products - Cloud 9 , the AWS CLI, CloudShell etc.
Then you, in act of desperation, sell out and sell your users...
The issue is, people are already super skeptical when these startups start asking for things, this just makes them even harder to get users to trust you as a emerging company or product with data and usage.
but it is true that this is a rare devtools startup acquisition by amazon. i cant think of many here (cloud9 was the last one i know, and that was 2016) but that could be due to my ignorance.
Have seen Brendan talk a lot about it on Twitter.
Is this effectively very similar to Atuin?
good luck to them on what comes next.
The dropdown for autocomplete is far from necessary but a nice addition. Helping with completing commands that I don't use often but know the basics of like "aws s3 cp" is nice. But because of that I could just never justify spending money on it.
Hopefully it isn't abandoned, but maybe this will also mean they don't have to try to find artificial reasons (or bloat) to convince people to pay and can just focus on the core offering.
The telemetry part didn't bug me that much, but the product itself was cool, reminds me of warp.dev
Congratz on the acquisition.
One of the most annoying thing is to learn about an interesting project by the post were they announce that they are aquihired, or even worse, closing down because of lack of interest.
Congrats to the team on the sale! Sadly, seems like it’s dead now. Happy they got paid :)