Zotero brauchte fünf Jahre statt fünf Minuten

The Slow Formation of Durable Software

Zum 20. Jubiläum von Zotero erzählt Dan Cohen, wie das preisgekrönte Literaturverwaltungsprogramm entstand. Statt schneller KI-Entwicklung setzten die Historiker am Roy Rosenzweig Center for History and New Media auf jahrelange Diskussionen und Prototypen wie Web Scrapbook und Scribe. Diese langsame Formung führte zu dauerhafter Software, die heute über 20 Millionen Menschen nutzen. Cohens persönlicher Rückblick zeigt, warum gemeinsames Denken wichtiger war als schnelles Coden.

Wenn es KI in den frühen 2000er Jahren gegeben hätte, hätten wir Zoteros Konzeption nicht beschleunigen können, weil wir nicht genau wussten, was wir wollten, und daher keine kohärenten Prompts für ein LLM hätten schreiben können.
  1. nickledave

    Für alle, die sich fragen:

    In diesem Beitrag geht es um Zotero.

    https://www.zotero.org/

    Wenn man nicht im akademischen Bereich tätig ist, kennt man Zotero vielleicht nicht.

    Es macht einfach Freude, es zu benutzen. Jede App sollte so sein.

    Ich lese alles darin, auch Bücher, die ich gerade jetzt von https://teachyourselfcs.com/ durchgehe.

    Es macht auch einen großartigen Job dabei, Schnappschüsse von Beiträgen zu machen. Ich benutze es ständig, um Beiträge von HackerNews zu speichern, damit ich sie markieren kann.

    Und es synchronisiert sich automatisch über alle Geräte hinweg und lässt mich viel zu viele Dateien im Web speichern, wie der ADD-Messie, der ich bin, ohne ins Schwitzen zu geraten.

    Kurz gesagt, diese Software funktioniert einfach, und sie funktioniert gut.

    Wenn also jemand hinter Zotero darüber spricht, wie man Software entwickelt, höre ich zu.

    Und es ist ein unterhaltsamer Beitrag mit etwas Geschichte. Du solltest diesen Beitrag in Zotero speichern und ihn dann lesen.

  2. adamddev1

    > Aber diese langsame Entstehung führte zu Software, die dauerhaft statt flüchtig war, mit einem starken Fundament, auf dem aufgebaut werden konnte.

    Man sagt, agentische Entwicklung sei großartig, weil man so viel so schnell produzieren kann. Aber das bedeutet nicht, dass irgendetwas davon wirklich gut und zuverlässig sein wird.

    Die Dinge, die wirklich tiefgründig und solide sind, werden exponentiell mehr genutzt, was die linearen Kosten zusätzlicher Entwicklungszeit (asymptotisch) in der Kosten-Nutzen-Gleichung unbedeutend macht.

  3. _fw

    Als jemand, der für die Nutzergewinnung und das Wachstum eines Unternehmens in Bezug auf Kunden und Umsatz verantwortlich ist, ist dies ein SEHR wichtiger Punkt:

    > „… wir hätten Zoteros Konzeption nicht beschleunigen können, weil wir nicht genau wussten, was wir wollten, und daher keine kohärenten Prompts für ein LLM hätten schreiben können.“

    Ein überraschend großer Anteil von Softwareprodukten, vielleicht sogar Unternehmen heute, sind Lösungen auf der Suche nach einem Problem.

    Manchmal ist das in Ordnung, aber nur manchmal. Und eine Lösung auf der Suche nach einem Problem zu sein, erfordert, dass man so ziemlich alles /andere/ perfekt macht, wenn man Erfolg haben will.

    Die Tatsache, dass Zotero darauf geachtet hat, was die Leute wollten, und es ihnen gegeben hat, und marktorientiert war, ist nachweislich ein großer Teil ihres Erfolgs.

    Es ist VIEL einfacher, etwas zu machen, das die Leute wollen, als sie dazu zu bringen, etwas zu wollen, das man gemacht hat.

  4. kstenerud

    > Wenn KI in den frühen 2000ern existiert hätte, hätten wir Zoteros Konzeption nicht beschleunigen können, weil wir nicht genau wussten, was wir wollten, und daher keine kohärenten Prompts für ein LLM hätten schreiben können. Stattdessen brauchte es viel Zeit und Zusammenarbeit, um eine klare Vision dafür zu entwickeln, was Zotero sein sollte.

    KI schließt das nicht aus. Tatsächlich kann sie helfen, Teile davon zu beschleunigen.

    Er beschreibt den typischen Lebenszyklus eines großen Projekts:

    - Die Landschaft untersuchen

    - Nutzerforschung (wie sie bestehende Software nutzen, was ihre Frustrationen sind, usw.)

    - Brainstorming

    - Erste Ideen und Prototypen

    - Verfeinerung, Nutzerfeedback

    - Die Vision und das High-Level-Prozessdesign festigen

    - Technologien auswählen

    - Design & Architektur

    - Phasen planen

    - Phasen bauen, dann mit Nutzern testen

    LLMs sind großartig in der Forschung und großartig bei Prototypen. Sobald man sein Design hat, sind sie auch gut im Programmieren. Sie sind auch gut darin, Nutzerfeedback zu destillieren.

  5. olafmol

    In den Niederlanden haben wir dieses Sprichwort: „Ohne Reibung, kein Glanz“

Mehr von diesem Tag

2026-10-08