Amazon übernimmt Fig

 (archive.md)
1 Punkte von GN⁺ 2023-08-29 | 1 Kommentare | Auf WhatsApp teilen
  • Das Fig-Team, das Entwickler-Tools für Terminal/Shell entwickelt hat, schließt sich Amazon Web Services (AWS) an, und Amazon übernimmt die Technologie von Fig
  • AWS sieht Generative AI als einen zentralen technologischen Wandel, der die Art verändert, wie Kunden entwickeln, und betrachtet den Zusammenschluss mit Fig als Teil dieser Vision
  • Bestehende Nutzer können Fig weiterhin verwenden und erhalten fortlaufenden Support; kostenpflichtige Fig Team-Funktionen werden vollständig kostenlos
  • Neuanmeldungen sind derzeit ausgesetzt; der Fokus liegt auf der Optimierung für bestehende Kunden und der AWS-Integration
  • Künftige Produktpläne wurden noch nicht bekannt gegeben, aber im Bereich Terminal/Shell will man weiter Innovationen für Entwickler vorantreiben

Ankündigung des AWS-Beitritts von Fig

  • Das Fig-Team schließt sich AWS an, und Amazon übernimmt die Technologie von Fig
  • Sowohl Fig als auch AWS teilen das Interesse, Entwickler-Tools und -Services zu verbessern
  • Durch die Verbindung der langfristigen Ausrichtung von AWS und der Erfolgsbilanz bei kundenorientierten Produkten mit der Expertise von Fig soll die Developer Experience verbessert werden
  • AWS betrachtet Generative AI als einen wesentlichen technologischen Wandel, der die Art verändert, wie Kunden entwickeln

Änderungen am Fig-Produkt

  • Bestehende Nutzer können Fig weiterhin verwenden und erhalten fortlaufenden Support
  • Alle kostenpflichtigen Fig Team-Funktionen werden vollständig kostenlos
  • Neue Nutzer können sich derzeit nicht für das Fig-Produkt anmelden
    • Der Fokus liegt auf der Optimierung des Produkts für bestehende Kunden
    • Der Fokus liegt auf der Bearbeitung der identifizierten Anforderungen, um Fig in AWS zu integrieren
  • Ein Anmeldelink, um in den kommenden Wochen Neuigkeiten zur Zusammenarbeit mit AWS zu erhalten, soll veröffentlicht werden

Produkte von Amazon + Fig

  • Derzeit gibt es keine Updates zu künftigen Plänen, die geteilt werden können
  • Im Bereich Terminal/Shell wird weiter an Innovationen für Entwickler gearbeitet
  • Weitere Neuigkeiten sollen bekannt gegeben werden, sobald es sie gibt

Dank an die Community

  • Dank für die anhaltende Unterstützung der Community
  • Zu den Erfolgen der vergangenen 3 Jahre zählen mehrere Hunderttausend Nutzer, 22k GitHub stars, 13k Discord-Mitglieder, 400 Open-Source-Mitwirkende und 5 Kernprodukte
  • Auch in Zukunft will man gemeinsam mit der Community weiter Innovationen vorantreiben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-29
Hacker-News-Kommentare

  • Die Formulierung, dass man Neuanmeldungen stoppt und sich um die Optimierung für Bestandskunden sowie Anforderungen rund um die AWS-Integration kümmert, klingt so, als sei das Produkt faktisch tot und könnte irgendwann als AWS-gehostetes Produkt unter Amazon-Marke wieder auftauchen.
    Ein Produkt, das zentrale Workflows mit einem Haufen Abos und Telemetrie versieht, würde ich niemals nutzen, aber für bestehende Nutzer dürfte das schade sein.

    • Der ganze Beitrag las sich wie „Acqui-hire“, ohne zugeben zu können, dass es ein Acqui-hire ist, und der Anmeldestopp bestätigt diesen Eindruck.
      Wenn AWS wegen des Produkts gekauft hat, sehe ich keinen Grund, warum man das bisherige Geschäftsmodell nicht einfach ein paar Monate weiterlaufen lässt, bis diese „Anforderungen“ erledigt sind, statt es komplett anzuhalten.
    • Schon aus einfachen Gründen von Sicherheit und Datenschutz würde ich wohl nie ein Terminal mit Cloud-Synchronisierung oder Cloud-Anbindung nutzen; dazu kommt, dass man bei einem Ausfall als Entwickler oder Admin praktisch handlungsunfähig ist.
      Mehrere Firmen haben versucht, das Terminal zu Software as a Service zu machen, und sind gescheitert, also bin ich mit diesem Gefühl vermutlich nicht allein.
      „Uns ist aufgefallen, dass es in der Computing-Infrastruktur noch eine Komponente gibt, die nicht alles, was Sie tun, in die Cloud schickt und dafür auch keine Monatsmiete verlangt …“
    • „Amazon has acquired Fig's technology!“ ist ein Euphemismus.
      Wenn solche Unternehmen „Technologie übernehmen“, ist das ungefähr so, als hätten Revolutionäre den Kopf Ludwigs XVI. erworben.
    • Telemetrie war genau der Grund, warum ich Fig nie ausprobiert habe.
      Es sah zwar cool aus, aber mir war nicht wohl dabei, dass Fig alle meine Eingaben bekommt.
    • Sie haben einen Zeitplan von ein paar Wochen genannt, also werden wir wohl bald sehen, was passiert.

  • Die Funktionen sind gut, aber die Vorstellung, dafür eine komplett neue Terminal-App nutzen zu müssen, hat mir nie gefallen.
    Vielleicht werde ich zum Dinosaurier, aber es ist nicht so, dass ich nichts Neues ausprobieren will. Im Gegenteil: Nach Jahren mit nur einer echten Entwicklungsumgebung bin ich von Emacs zu VS Code gewechselt und arbeite inzwischen in deutlich heterogeneren Umgebungen statt zu 100 % auf dem Mac.
    Deshalb fühlen sich solche plattformspezifischen, schwergewichtigen Client-Apps für mich nicht mehr wie die Richtung an, in die es gehen sollte.

    • Bei Vim und sehr ausgereiften Kommandozeilen-Tools zu bleiben, hat mir im Gegenteil Flexibilität gegeben.
      Ob lokal oder per SSH: Solange es eine *nix-Maschine gibt, hatte ich eine vertraute und ausreichende Entwicklungsumgebung, und das hat in meinen letzten acht Jobs funktioniert – im Büro oder remote, mit welchen Sicherheitsvorgaben auch immer, mit oder ohne eigenen Schreibtisch, selbst nur mit einem 13-Zoll-Laptop. Das ist der kleinste gemeinsame Nenner.
      Meine aktuellen Kollegen versuchen dagegen, ihre Workstation-Umgebung ständig zu bewahren, um lokal eine IDE zu nutzen, und wurden in den letzten Jahren sogar zweimal gezwungen, die IDE zu wechseln.
      Das ist kein Argument aus der Ideologie Freier Software heraus. Mir persönlich ist das nicht wichtig, aber die besten Werkzeuge sind eben manchmal Freie Software. Ich nutze auch Macs und komme bei Bedarf mit Linux zurecht.
    • Man braucht kein neues Terminal.
      Auf der Homepage steht wörtlich „IDE-style autocomplete for your existing terminal“.
    • Ehrlich gesagt ist es meiner Meinung nach Zeit, über die Ära hinauszukommen, in der wir Fernschreiber nachahmen, aber das, was danach kommt, sollte auf offenen Standards beruhen und konkurrierende Implementierungen haben.
      Der Friedhof der „Next-Generation“-Terminalprojekte ist schon groß, und von den noch lebenden scheint keines eine dominante Stellung zu erreichen. Eine Spezifikation aufzuschreiben löst dieses Problem nicht, aber was am Ende gewinnt, sollte hoffentlich eine Spezifikation haben.
    • Vielleicht denkst du an Warp (https://www.warp.dev/).
    • Was sich an diesem Produkt seltsam anfühlt: Es dringt in einen Bereich ein, in dem es bereits viele gut funktionierende Tools gibt, und scheint dabei schlechte lokale Entwicklungs- und Deployment-Praktiken zu verfestigen.
      Wenn man Berichte darüber braucht, welche Skripte Entwickler auf ihren lokalen Maschinen ausführen, bedeutet das wahrscheinlich, dass man ihnen zu viele Zugriffsrechte auf Produktionsumgebungen gibt. Schutzmechanismen und Reporting gehören in CI/CD-Prozesse und in die Quellcodeverwaltung.
      Shells wie fish oder Shell-Plugins erledigen Autovervollständigung bereits gut, daher ist auch diese Funktion nicht besonders nützlich.
      Wenn man Umgebungsvariablen oder Dotfiles verwalten muss, sollte man Zeit in eine saubere Entwicklungsumgebung investieren, statt ein Tool einzuschieben, das falsche Dinge bequemer macht.
      SSH-Key-Management lässt sich auf sehr viele Arten sehr einfach lösen, etwa über Konfigurationsmanagement oder integrierte Lösungen der Cloud-Anbieter. Außerdem geben die meisten Entwicklungsteams wahrscheinlich ohnehin schon zu viel SSH-Zugriff.
      Wenn man häufig SSH nutzen muss, heißt das, dass die Anwendung ihre Logs nicht ordentlich ausgibt oder dass die lokalen Entwicklungstools nicht gut genug sind.

  • Das ging wirklich schnell. Der Hacker-News-Launch von Fig war am 25. Mai 2021: https://news.ycombinator.com/item?id=27277819
    Ich habe gesehen, dass Brendan auf Twitter viel über dieses Produkt gesprochen hat.

  • Ich habe Fig vor ein paar Monaten ein paar Tage lang ausprobiert und es wieder gelöscht, weil es mehr Ärger als Hilfe war.
    Schon dass daraus ein tragfähiges Produkt wurde, überrascht mich; dass es tatsächlich übernommen wurde, ist noch erstaunlicher.

    • Gleiche Erfahrung.
      Ich habe es auf mehreren Maschinen ein paar Mal versucht, und die Maschinen froren ein, fraßen absurd viel Speicher oder zeigten anderes zufälliges Verhalten. Erstaunlich, dass es so weit gekommen ist.

  • Ich nutze es seit ungefähr einem Jahr und hoffe, dass das Produkt erhalten bleibt.
    Im Blog steht es im Moment so, aber das sagen am Anfang natürlich fast alle.

    • Es scheint eine ziemlich gute Community aufgebaut zu haben; wenn der Kerncode von Fig oder der gesamte Code Open Source wäre, könnte es wohl weiterleben.
      In den letzten sechs Wochen haben 57 neue Beitragende 62 Issues erstellt, und 111 neue Beitragende haben Kommentare geschrieben. Als Community-Kennzahlen ist das sehr gesund, auch wenn es nicht viel Code-Aktivität gab; wenn sie auf den Verkauf an AWS fokussiert waren, ergibt das Sinn.
      Herangezogene Quelle: https://devboard.gitsense.com/withfig
      Vollständige Offenlegung: Das ist ein Tool, das ich gebaut habe.

  • Ich mag dieses Produkt und habe auch ein paar Beiträge dazu geleistet, aber im Moment habe ich gemischte Gefühle.
    Ein Gedanke ist, dass die Autocomplete-Spezifikation unter MIT-Lizenz steht und man sie nutzen könnte, um ein grundlegendes Open-Source-Autocomplete-Produkt neu zu implementieren: https://github.com/withfig/autocomplete

  • Ist das ein Grund zum Gratulieren? Ich hoffe, dass das bedeutet, dass die immer zahlreicheren CLI-Befehle von AWS nun alle zu Fig werden oder in diese Richtung gehen.
    Sie wirken ziemlich in die Jahre gekommen. Ich frage mich auch, was mit der Unterstützung außerhalb von AWS passiert. Wird Fig in iTerm2 weiterhin alles im %PATH% hervorragend unterstützen?

    • Er freut sich nicht, weil es gut für die Nutzer ist, sondern weil es gut für ihn selbst ist.

  • Um mein eigenes Projekt zu bewerben: Ich baue eine ähnliche Idee für das LLM-Zeitalter: https://butterfi.sh
    Es ist deutlich grundlegender als Fig, könnte aber nützlich sein, wenn ihr eine Alternative sucht. Feedback wäre willkommen.

    • „Innerhalb der Butterfish Shell muss man einen Befehl nur mit einem Großbuchstaben beginnen, um einen ChatGPT-Prompt zu senden“ ist eine gefährliche Annahme.
      Nicht alle Befehle sind kleingeschrieben. Interaktionen mit externen Diensten sollten vom Nutzer bewusst und durch eine separate Aktion ausgelöst werden.
    • Das gefällt mir ziemlich gut.
      Es wäre cool, wenn der im Zielmodus laufende Client eine Suchmaschinen-API anfragen und auch etwas Crawling durchführen könnte. Ich stelle mir vor, wie er Informationen direkt aus aktuellen GitHub-Issues oder der AWS-Dokumentation holt.
    • Ich frage mich, ob das in irgendeiner Weise mit der fish-Shell zu tun hat oder einfach ein sehr unglücklicher Name ist.
    • Ich frage mich, ob du vorhast, Unterstützung für lokale Modelle hinzuzufügen.

  • Abgesehen von dem Namen, der für den Vorläufer von Docker Compose verwendet wurde, habe ich von Fig noch nie gehört.
    Ist das im Grunde etwas sehr Ähnliches wie Atuin?
    https://github.com/atuinsh/atuin

  • Ich hätte nie gedacht, dass Fig oder Warp Erfolg haben würden.
    Für die Nutzung von CLI-Tools ein Konto und ein Abo zu verlangen, klingt absurd. Bei AWS braucht man aber ohnehin ein Konto, also scheinen sie eine Lösung gefunden zu haben.
    Ich hoffe, dass auch der nächste Schritt gut läuft.