Amazon acquiert Fig
(archive.md)- L’équipe de Fig, qui développe des outils pour terminaux/shell, rejoint Amazon Web Services (AWS), et Amazon acquiert la technologie de Fig
- AWS considère l’IA générative comme une transition technologique majeure qui transforme la façon dont ses clients développent, et l’arrivée de Fig s’inscrit dans cette vision
- Les utilisateurs existants peuvent continuer à utiliser Fig et bénéficieront d’un support continu, tandis que les fonctionnalités payantes de Fig Team deviennent entièrement gratuites
- Les nouvelles inscriptions sont actuellement suspendues afin de se concentrer sur l’optimisation pour les clients existants et sur l’intégration avec AWS
- Les plans produits à venir n’ont pas encore été dévoilés, mais l’innovation pour les développeurs dans l’univers des terminaux/shell continue
Annonce de l’arrivée de Fig chez AWS
- L’équipe de Fig rejoint AWS et Amazon acquiert la technologie de Fig
- Fig et AWS partagent tous deux un intérêt commun pour l’amélioration des outils et services destinés aux développeurs
- En combinant l’expertise de Fig avec l’orientation long terme d’AWS et son historique de produits centrés sur le client, l’objectif est d’améliorer l’expérience développeur
- AWS considère l’IA générative comme une transition technologique majeure qui transforme la manière dont les clients construisent leurs produits
Changements apportés au produit Fig
- Les utilisateurs existants peuvent continuer à utiliser Fig et bénéficieront d’un support continu
- Toutes les fonctionnalités payantes de Fig Team deviennent totalement gratuites
- Les nouveaux utilisateurs ne peuvent actuellement pas s’inscrire au produit Fig
- Concentration sur l’optimisation du produit pour les clients existants
- Concentration sur le traitement des exigences identifiées pour intégrer Fig à AWS
- Un lien d’inscription permettant de recevoir des nouvelles des travaux avec AWS sera publié dans les prochaines semaines
Produits qu’Amazon + Fig proposeront
- Il n’y a pour l’instant aucune mise à jour à partager sur les plans futurs
- L’innovation pour les développeurs se poursuit dans l’univers des terminaux/shell
- D’autres annonces seront faites lorsque de nouvelles informations seront disponibles
Remerciements à la communauté
- Merci à la communauté pour son soutien constant
- Les réalisations des 3 dernières années représentent plusieurs centaines de milliers d’utilisateurs, 22k GitHub stars, 13k membres sur Discord, 400 contributeurs open source et 5 produits principaux
- L’équipe prévoit de continuer à innover avec la communauté
1 commentaires
Avis sur Hacker News
La formulation indiquant qu’ils bloquent les nouvelles inscriptions et s’occupent des exigences d’optimisation pour les clients existants et d’intégration avec AWS donne l’impression que le produit est en pratique mort, et qu’il pourrait ressortir un jour sous la forme d’un produit de marque Amazon hébergé sur AWS.
Je n’utiliserais jamais un produit avec un abonnement et plein de télémétrie greffés à un workflow central, mais ça doit être dommage pour les utilisateurs existants.
Si AWS l’avait acheté pour le produit, je ne vois pas pourquoi ils arrêteraient complètement le modèle économique existant pendant des mois, au lieu de le laisser tourner tel quel jusqu’à ce que ces « exigences » soient traitées.
Plusieurs entreprises ont essayé de transformer le terminal en logiciel en tant que service et ont échoué, donc je ne dois pas être le seul à ressentir ça.
« Il restait apparemment un composant de l’infrastructure informatique qui n’envoyait pas encore tout ce que vous faites dans le cloud et ne vous facturait pas de loyer mensuel… »
Quand ce genre d’entreprise dit « acquérir la technologie », c’est un peu comme dire que les révolutionnaires ont acquis la tête de Louis XVI.
Ça avait l’air sympa, mais je n’avais pas envie que Fig récupère toutes mes saisies.
La fonctionnalité est intéressante, mais l’idée de devoir utiliser une application de terminal entièrement nouvelle pour en profiter ne m’a jamais plu.
Peut-être que je deviens un dinosaure, mais ce n’est pas que je refuse d’essayer des choses nouvelles. Au contraire, après avoir utilisé pendant des années un seul véritable environnement de développement, je suis passé d’Emacs à VS Code, et je travaille désormais dans des environnements plus hétérogènes au lieu d’un environnement 100 % Mac.
Du coup, ce genre de client lourd propre à une plateforme ne me semble plus être la direction à suivre.
Tant que j’ai une machine *nix, en local ou via SSH, je peux disposer d’un environnement de développement familier et suffisant, et cela a fonctionné dans mes 8 derniers postes, au bureau ou à distance, quelles que soient les contraintes de sécurité, que j’aie un bureau ou non, ou seulement un portable 13 pouces. C’est le plus petit dénominateur commun.
À l’inverse, mes collègues actuels essaient de préserver en permanence leur environnement de workstation pour utiliser leur IDE en local, et ces dernières années on les a même forcés à changer deux fois d’IDE.
Ce n’est pas un discours issu de l’idéologie du logiciel libre. Personnellement, je ne m’en préoccupe pas vraiment, mais il se trouve parfois que les meilleurs outils sont des logiciels libres. J’utilise aussi un Mac et je peux gérer Linux quand il le faut.
La page d’accueil dit littéralement : « autocomplétion façon IDE pour votre terminal existant ».
Le cimetière des projets de terminaux « nouvelle génération » est déjà bien rempli, et aucun de ceux qui sont encore en vie ne semble s’imposer. Écrire une spécification ne résoudra pas ce problème, mais j’aimerais que ce qui finira par gagner en ait une.
Si vous avez besoin de rapports sur les scripts qu’un développeur exécute sur sa machine locale, cela signifie probablement que vous lui donnez trop d’accès à la production. Les garde-fous et le reporting devraient se trouver dans les processus CI/CD et dans la gestion du code source.
Des shells comme fish ou des plugins de shell gèrent déjà très bien l’autocomplétion, donc cette fonction n’est pas si utile.
Si vous avez besoin de gérer des variables d’environnement ou des dotfiles, vous devriez consacrer du temps à créer un véritable environnement de développement plutôt que d’ajouter un outil qui facilite de mauvaises pratiques.
La gestion des clés SSH peut être assurée très facilement de multiples façons, par exemple via la gestion de configuration ou les solutions intégrées des fournisseurs cloud. En plus, la plupart des équipes de développement donnent probablement déjà trop d’accès SSH.
Si vous devez faire souvent du SSH, c’est que votre application n’émet pas correctement ses logs ou que vos outils de développement local ne sont pas assez bons.
C’est allé vraiment vite. Le lancement de Fig sur Hacker News remontait au 25 mai 2021 : https://news.ycombinator.com/item?id=27277819
J’ai vu Brendan beaucoup parler de ce produit sur Twitter.
J’ai essayé Fig quelques jours il y a quelques mois, puis je l’ai supprimé parce qu’il causait plus de tracas qu’il n’aidait.
Je suis déjà surpris que ce soit devenu un produit viable, et encore plus qu’il ait réellement été acquis.
J’ai essayé plusieurs fois sur plusieurs machines : blocages, consommation mémoire absurde ou autres comportements aléatoires. C’est étonnant que ce soit allé aussi loin.
Je l’utilise depuis environ un an et j’espère que le produit restera disponible.
Le blog le dit pour l’instant, mais au début presque tout le monde dit ça.
Au cours des 6 dernières semaines, 57 nouveaux contributeurs ont créé 62 issues et 111 nouveaux contributeurs ont commenté. Comme indicateurs de communauté, c’est très sain, même si l’activité de code n’était pas très élevée, ce qui se comprend s’ils se concentraient sur la vente à AWS.
Source consultée : https://devboard.gitsense.com/withfig
Transparence : c’est un outil que j’ai créé.
J’aime ce produit et j’y ai contribué plusieurs fois, mais là j’ai des sentiments un peu mitigés.
Une chose qui me vient à l’esprit, c’est que la spécification d’autocomplétion est sous licence MIT, donc elle pourrait servir à réimplémenter un produit d’autocomplétion open source de base : https://github.com/withfig/autocomplete
Est-ce qu’il faut s’en réjouir ? J’espère que cela veut dire que le nombre croissant de commandes CLI d’AWS va toutes devenir, ou finir par devenir, compatibles avec Fig.
Elles commencent à dater sérieusement. Je me demande aussi ce qu’il adviendra du support hors AWS. Fig continuera-t-il à prendre parfaitement en charge tout ce qui se trouve dans %PATH% dans iTerm2 ?
Pour faire la promotion de mon projet, je travaille sur une idée similaire adaptée à l’ère des LLM : https://butterfi.sh
C’est bien plus basique que Fig, mais ça peut être utile si vous cherchez une alternative. Les retours sont les bienvenus.
Toutes les commandes ne sont pas en minuscules. Toute interaction avec un service externe devrait être effectuée intentionnellement par l’utilisateur, via une action séparée.
Ce serait sympa si le client exécuté en mode objectif pouvait interroger une API de moteur de recherche et faire aussi un peu de crawling. J’imagine bien aller chercher directement des informations dans les dernières issues GitHub ou la documentation AWS.
Je n’avais jamais entendu parler de Fig, à part le nom qui servait à l’ancêtre de Docker Compose.
Est-ce que c’est en gros très similaire à Atuin ?
https://github.com/atuinsh/atuin
Je n’ai jamais vraiment pensé que Fig ou Warp réussiraient.
Exiger un compte et un abonnement pour utiliser des outils CLI me semble absurde. Mais chez AWS, un compte est de toute façon indispensable, donc ils semblent avoir trouvé une solution.
Je leur souhaite aussi de réussir la suite.