AmazonがFigを買収
(archive.md)- ターミナル／シェル向け開発者ツールを手がけてきたFigチームが**Amazon Web Services（AWS）**に加わり、AmazonがFigの技術を買収
- AWSは生成AIを、顧客の開発方法を変える重要な技術的転換と捉えており、Figの参加をこのビジョンの一部として進める
- 既存ユーザーは引き続きFigを利用でき、継続的なサポートを受けられる。有料のFig Team機能は全面的に無料化
- 新規登録は現在停止しており、既存顧客向けの最適化とAWS統合作業に注力
- 今後の製品計画はまだ未公開だが、ターミナル／シェル領域で開発者向けのイノベーションを継続
FigのAWS参加を発表
- FigチームがAWSに加わり、AmazonがFigの技術を買収
- FigとAWSはいずれも、開発者ツールとサービスの改善に関心を共有
- AWSの長期志向と顧客中心の製品提供実績にFigの専門性を組み合わせ、開発者体験の向上を推進
- AWSは生成AIを、顧客のビルド方法を変える重要な技術的転換と認識
Fig製品の変更点
- 既存ユーザーは引き続きFigを利用でき、継続的なサポートを提供
- すべての有料Fig Team機能を完全無料化
- 新規ユーザーは現在、Fig製品に登録不可
- 既存顧客向けの製品最適化に注力
- FigをAWSと統合するために特定された要件への対応に注力
- AWSとの取り組みに関する最新情報を受け取れる登録リンクを、今後数週間以内に公開予定
Amazon + Figが提供する製品
- 現時点で今後の計画について共有できるアップデートはなし
- ターミナル／シェル領域で開発者向けのイノベーションを継続中
- 追加情報があり次第、引き続き告知予定
コミュニティへの感謝
- コミュニティの継続的な支援に感謝
- 過去3年間の成果として、数十万人のユーザー、22k GitHub stars、13k人のDiscordメンバー、400人のオープンソース貢献者、5つの中核製品を保有
- 今後もコミュニティとともにイノベーションを続ける計画
1件のコメント
Hacker News のコメント
新規登録を止め、既存顧客向けの最適化と AWS 統合要件に対応するという文言は、製品が事実上死んでいて、いつか AWS ホスティングの Amazon ブランド製品として再登場する可能性がある、という意味に聞こえる
中核的なワークフローにサブスクリプションとテレメトリが大量に付いた製品は絶対に使わないが、既存ユーザーにとっては残念なことだと思う
AWS が製品目当てで買ったのなら、その「要件」が処理されるまでの数か月間、既存のビジネスモデルをそのまま回さず完全に止める理由が分からない
複数の会社がターミナルをサービス型ソフトウェアにしようとして失敗しているので、そう感じているのは自分だけではないはず
「コンピューティングインフラの中に、まだあなたのやることすべてをクラウドへ送らず、月額料金も取らない構成要素がありましたので……」
こういう会社が「技術を買収する」というのは、革命家たちが ルイ16世の首を手に入れたと言うのに近い
かっこよくは見えたが、Fig に自分の入力をすべて持っていかれるのは気が進まなかった
機能は良いが、それを使うために まったく新しいターミナルアプリを使わなければならないという考えは、ずっと気に入らなかった
自分が恐竜になりつつあるだけかもしれないが、新しいものを試そうとしないわけではない。むしろ何年も一つの本物の開発環境にこだわった後、Emacs から VS Code に移ったし、100% Mac 環境ではなく、より異質な環境で働くようになった
だから、こういうプラットフォーム別の厚いクライアントアプリは、もはや進むべき方向には感じられない
ローカルでも SSH 越しでも、*nix マシンさえあれば慣れた十分な開発環境を持てたし、オフィスでもリモートでも、セキュリティ上の制約がどうであれ、机があろうとなかろうと、13インチノートだけであろうと、過去8つの職場でずっと通用した。これが最小公倍数だ
一方、今の同僚たちはローカルで IDE を使うためにワークステーション環境を守り続けようとしており、ここ数年で IDE も2回変更を強いられている
これは自由ソフトウェアの理念から出た話ではない。個人的にはそういうことは気にしないが、最高のツールが時に自由ソフトウェアであるだけだ。Mac も使うし、必要なら Linux も扱える
ホームページに文字どおり「既存のターミナル向けの IDE スタイルの自動補完」と書いてある
「次世代」ターミナルプロジェクトの墓場はすでに多く、まだ生きているものの中で支配的な地位を得ているものもなさそうだ。仕様を書くことでこの問題が解決するわけではないが、最終的に勝つ何かには仕様があるとよい
開発者がローカルマシンで実行するスクリプトについてレポートが必要なら、おそらく本番環境へのアクセス権を与えすぎているという意味だ。安全策とレポートは CI/CD プロセスとソース管理にあるべきだ
fish のようなシェルやシェルプラグインがすでに自動補完をうまく処理しているので、その機能もそれほど有用ではない
環境変数や dotfile の管理が必要なら、間違ったことをやりやすくするツールを差し込むより、きちんとした開発環境を作ることに時間を使うべきだ
SSH キー管理は構成管理やクラウドプロバイダーの組み込みソリューションなど、多数の方法で非常に簡単に処理できる。さらに、ほとんどの開発チームはすでに SSH アクセスを与えすぎている可能性が高い
SSH を頻繁にしなければならないなら、アプリケーションがログを適切に出していないか、ローカル開発ツールが十分によくないということだ
本当に速かった。Fig の Hacker News でのローンチは2021年5月25日だった: https://news.ycombinator.com/item?id=27277819
Brendan が Twitter でこの製品の話をたくさんしているのを見た
数か月前に Fig を数日使ってみたが、助けになるより 厄介ごとの方が多かったので削除した
これが実行可能な製品になったことにも驚くし、実際に買収されたことにはさらに衝撃を受けている
複数のマシンで何度か試したが、マシンが固まったり、メモリをとんでもなく食ったり、そのほかランダムな挙動を見せたりした。これがどこかまで行き着いたというのが驚きだ
約1年ほど使ってきており、製品が残り続けることを願っている
ブログには今そう書かれているが、最初はほとんど誰もがそう言うものだ
過去6週間で新規コントリビューター57人が Issue を62件作り、新規コントリビューター111人がコメントしている。コミュニティ指標としては非常に健全だが、コード活動は多くなかった。AWS への売却に集中していたなら納得できる
参照した出典: https://devboard.gitsense.com/withfig
完全開示: これは自分が作ったツールだ
この製品は好きで何度か貢献もしたが、今は少し複雑な気持ちだ
一つ思い浮かぶのは、自動補完仕様が MIT ライセンスなので、基本的なオープンソースの自動補完製品を再実装するのに使えそうだという点: https://github.com/withfig/autocomplete
祝うべきことなのか？ AWS のますます増えている CLI コマンドが、これで全部 Fig になる、あるいはそうなっていくという意味ならいいのだが
かなり古びてきている。AWS 以外のサポートがどうなるのかも気になる。Fig は iTerm2 で %PATH% 内にあるものを何でも引き続き見事にサポートするのだろうか？
自分のプロジェクトを宣伝すると、LLM 時代に合わせた似たアイデアを作っている: https://butterfi.sh
Fig よりずっと基本的なレベルだが、代替を探しているなら役に立つかもしれない。フィードバックを送ってくれるとうれしい
すべてのコマンドが小文字なわけではない。外部サービスとのやり取りは、ユーザーが意図的に、別の操作として行うべきだ
目標モードで実行されるクライアントが検索エンジン API を呼び出し、少しクローリングもできると素晴らしそうだ。最新の GitHub Issue や AWS ドキュメントから直接情報を取ってくる様子を想像してしまう
Docker Compose の前身に使われていた名前以外では、Fig は初めて聞いた
これは実質的に Atuin とかなり似たものなのか？
https://github.com/atuinsh/atuin
Fig や Warp が成功するとはまったく思っていなかった
CLI ツールを使うのにアカウントとサブスクリプションを要求するというのは、あり得ないように聞こえる。しかし AWS ではどうせアカウントが必須なので、解決策を見つけたように見える
次のステップもうまくいくことを願っている