8 Punkte von baeba 3 시간 전 | 4 Kommentare | Auf WhatsApp teilen

Das Erfolgsgeheimnis des SQLite-Schöpfers über 26 Jahre hinweg ist, seine eigenen Werkzeuge selbst zu bauen, externe Beiträge auf ein Minimum zu beschränken und die Codequalität durch rigorose Tests aufrechtzuerhalten.
Das zeigt das Wesen von „Freiheit“, das im komplexen Open-Source-Ökosystem oft übersehen wird.


Inhaltsverzeichnis

  1. 26 Jahre Code-Reise von Richard Hipp, dem Schöpfer von SQLite


1. 26 Jahre Code-Reise von Richard Hipp, dem Schöpfer von SQLite

Der Schöpfer von SQLite, Richard Hipp, hat auf seiner 26-jährigen Entwicklungsreise folgende Philosophie in die Praxis umgesetzt.

  • Er entwickelt die Werkzeuge, die er braucht, selbst.
  • Er hält externe Code-Beiträge auf ein Minimum beschränkt.
  • Er sichert die Codequalität durch rigorose Tests.
  • Er reduziert externe Abhängigkeiten, um die Freiheit in der Entwicklung zu bewahren.

1.1. Die Entstehung von SQLite: Problemlösung, die auf einem Kriegsschiff begann

SQLite begann in einem Kriegsschiff-Projekt

  • SQLite entstand im Zusammenhang mit Vertragsarbeiten rund um das Kriegsschiff USS Oscar Austin.
  • Damals war Richard Hipp als Auftragnehmer von General Dynamics am Schiffsbauprojekt DDG-79 von Bath Iron Works beteiligt.
  • Bei der Entwicklung des Informationssystems für Schadenskontrolle des Schiffs traten Probleme auf.
  • Ein anderes Unternehmen hatte Millionen Dollar investiert, ohne ein brauchbares Ergebnis zu liefern.

Grenzen bestehender Datenbanksysteme

  • Richard Hipp entwickelte eine schnelle heuristikbasierte Software, um die Probleme des Schadenskontrollsystems zu lösen.
  • Allerdings gab es das Problem, dass die Software ebenfalls nicht funktionierte, wenn die verwendete Informix-Datenbank-Engine gestoppt wurde.
  • Die Software musste weiterlaufen, auch wenn der Systemadministrator die Datenbank-Engine abgeschaltet hatte.
  • Deshalb begann er über einen Ansatz nachzudenken, bei dem die Anwendung Daten direkt von der Festplatte liest, ohne einen separaten Datenbankprozess.
  • Da es damals schwer war, eine SQL-Datenbank-Engine zu finden, die diese Anforderungen erfüllte, musste er sie selbst entwickeln.

Im Selbststudium zur relationalen Datenbankforschung

  • Damals war Internetsuche noch nicht so verbreitet wie heute.
  • Richard Hipp suchte in der Bibliothek einer örtlichen Universität nach relevanten Materialien und studierte relationale Datenbanktechnik.
  • An MIT, Harvard, Berkeley und anderen Einrichtungen wurde damals aktiv zu relationalen Datenbanken geforscht.
  • Wegen geografischer Einschränkungen war es jedoch nicht leicht, an aktuelle Forschungsergebnisse zu gelangen.
  • Letztlich erforschte und implementierte er die benötigte Datenbanktechnik selbst.

1.2. Das Wachstum von SQLite und der kommerzielle Erfolg

Ein Projekt ohne Gewinnerzielungsabsicht

  • SQLite wurde von Anfang an nicht mit dem Ziel entwickelt, daraus Umsatz zu machen.
  • Die frühen Versionen wurden als freie Software veröffentlicht.
  • Zum Zeitpunkt der Entwicklung gab es keinen Plan, daraus ein Geschäft oder Einnahmen zu machen.

Der erste kommerzielle Vertrag mit Motorola

  • Einige Jahre nach der Veröffentlichung von SQLite meldete sich der Handyhersteller Motorola.
  • Motorola wollte SQLite in seinen Mobiltelefonen einsetzen.
  • Dadurch kam der erste kommerzielle Vertrag für SQLite zustande.
  • Der Vertrag war kein nutzungsabhängiges Lizenzmodell, sondern ein Festpreisvertrag.

Zusammenarbeit mit AOL

  • Danach schloss auch America Online (AOL) einen Vertrag, um SQLite in CD-ROM-Paketen zu integrieren.
  • Auch dieser Vertrag wurde zu einem Festpreis abgeschlossen.
  • Richard Hipp bewertete die Vertragssumme im Rückblick als relativ günstig im Verhältnis zum Wert von SQLite.

Symbian OS entscheidet sich für SQLite

  • Symbian OS, das unter anderem auf Mobiltelefonen von Nokia eingesetzt wurde, führte einen Blindtest zur Auswahl einer Datenbank-Engine durch.
  • Insgesamt wurden 10 Datenbank-Engines bewertet.
  • Im Ergebnis wurde SQLite ausgewählt.
  • Dabei wurde die Frage aufgeworfen, dass SQLite zu stark von einem einzelnen Hauptentwickler abhänge.
  • Es wurde vorgeschlagen, ein Konsortium zu bilden, um den sogenannten bus factor zu erhöhen.

bus factor
Eine Kennzahl dafür, ob ein Projekt weiterbestehen kann, wenn einige zentrale Personen plötzlich nicht mehr arbeitsfähig sind.
Ein bus factor von 1 bedeutet, dass das Projekt schwer aufrechterhalten werden kann, wenn ein einziger Kernentwickler ausfällt.

Gründung eines Konsortiums und Entwicklung in Vollzeit

  • Mitchell Baker von Mozilla beriet bei der Gründung des Konsortiums.
  • Auf dieser Grundlage wurde das SQLite-Konsortium gegründet.
  • Nach der Gründung des Konsortiums arbeitete Richard Hipp hauptberuflich an der Entwicklung von SQLite.
  • Mit mehreren Angestellten entstand eine kleine, aber nachhaltige Entwicklungsorganisation.

Langfristiger Support bis 2050

  • 2010 wollte Airbus SQLite in der Avionik des A350-Projekts einsetzen.
  • Airbus fragte an, ob SQLite langfristig gepflegt und unterstützt werden könne.
  • Mit Blick auf eine Lebensdauer des Flugzeugrumpfs von rund 40 Jahren sagte Hipp langfristigen Support zu.
  • Diese Zusage war weniger eine rechtliche Verpflichtung als vielmehr ein langfristiges Ziel des SQLite-Projekts.
  • Derzeit setzt Richard Hipp sein persönliches Ziel für das Ende des Supports von SQLite auf 2050.
  • Das Ziel basiert auf der Idee, Code länger zu pflegen als die erwartete Lebensdauer der Daten – gewissermaßen „50 Jahre zusätzlich für data-first code“.

1.3. Lizenz, Open-Source-Philosophie und die Entwicklung eigener Werkzeuge

Die Entstehung der „Gebets“-Lizenz

  • SQLite Version 1 war von der GDBM-Bibliothek abhängig.
  • Da GDBM unter der GPL lizenziert war, stand auch SQLite zwangsläufig unter dem Einfluss der GPL.
  • Später entwickelte Hipp ein eigenes speicherbasiertes Backend auf Basis von B-Bäumen, um Range Queries zu unterstützen.
  • Mit dem Wegfall externer Bibliotheksabhängigkeiten konnte die Lizenz frei gewählt werden.

Die Wahl der Public Domain

  • Damals waren vor allem die MIT- und Berkeley-Lizenzen weithin bekannt.
  • Statt eine Lizenz mit komplexen juristischen Klauseln zu verwenden, veröffentlichte Richard Hipp SQLite als Public Domain.
  • Später stellte sich heraus, dass das Konzept der Public Domain nicht in allen Ländern gleich anerkannt wird.
  • Dennoch wird die Veröffentlichungspolitik von SQLite faktisch ähnlich wie eine Open-Source-Lizenz verstanden.

Die Formulierung des „Gebets“

Im Header des SQLite-Quellcodes wurde statt üblicher juristischer Formeln ein Text aufgenommen, der eher einem Segen oder Gebet ähnelt.

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

Da SQLite zu einer der am weitesten verbreiteten Softwarebibliotheken der Welt wurde, steht auch diese Formulierung heute symbolisch für die besondere Lizenzphilosophie von SQLite.

Ein Entwicklungsmodell mit minimalen externen Beiträgen

  • SQLite nimmt nicht aktiv Pull Requests an wie ein typisches Open-Source-Projekt.
  • Externe Beiträge werden minimiert, während das Kernteam den Code selbst schreibt und verwaltet.
  • Richard Hipp vergleicht Pull Requests mit einem „free puppy“.
  • Denn auch wenn der Hund kostenlos ist, folgen daraus Verantwortung für Pflege und Betreuung – genauso bringt externer Code langfristige Pflichten mit sich, etwa:
    • Code-Wartung
    • Tests
    • Dokumentation
    • Fehlerbehebungen
    • Kompatibilitätsmanagement für andere Plattformen
    • langfristige technische Verantwortung
  • Diese Begrenzung externer Beiträge ist einer der Gründe, warum SQLite über mehr als 26 Jahre hinweg eine konsistente Qualität und Richtung bewahren konnte.

Beispiele für selbst entwickelte Werkzeuge

Fossil
  • Fossil ist ein eigens entwickeltes Versionskontrollsystem zur Verwaltung des SQLite-Projekts.
  • Es entstand ungefähr zur gleichen Zeit wie Git.
  • Neben der Quellcodeverwaltung bietet es integriert auch folgende Funktionen:
    • Versionskontrolle
    • Issue-Tracking
    • Wiki
    • Forum
    • Web-Interface
  • Fossil selbst basiert auf SQLite.
  • Daher fungiert Fossil auch als praktische Beta-Test-Plattform für SQLite.
  • Bei der Entwicklung und dem Betrieb von Fossil konnten Probleme in SQLite aus Sicht von Anwendungsentwicklern erkannt und verbessert werden.
  • Richard Hipp hält Git für gut geeignet für große verteilte Projekte wie den Linux-Kernel, während Fossil für kleinere Projekte wie SQLite besser passe.
Lemon
  • Lemon ist ein Werkzeug zur Erzeugung des SQL-Parsers von SQLite.
  • Statt Yacc oder Bison zu verwenden, wurde es eigens entwickelt.
  • Weil es ein eigenes Werkzeug ist, ließ sich die Parser-Generierung frei an die Anforderungen von SQLite anpassen und verbessern.

Eigene Werkzeuge und die Philosophie der Freiheit

  • Für Richard Hipp ist die Entwicklung eigener Werkzeuge nicht bloß eine technische Vorliebe.
  • Die Werkzeuge, die man braucht, selbst zu bauen, versteht er als eine Form der Selbstfürsorge.
  • Wer externe Abhängigkeiten reduziert, wird weniger von Entscheidungen anderer Projekte oder Unternehmen beeinflusst.
  • Diese Unabhängigkeit erweitert aus seiner Sicht unmittelbar die Freiheit von Entwicklern.
  • Zugleich empfindet er Belastung und Sorge angesichts der Tatsache, dass SQLite in zahllosen Systemen weltweit als kritische Abhängigkeit eingesetzt wird.

1.4. Konsequentes Testen und Softwareentwicklung im Zeitalter der AI

Tests als Kern des Erfolgs von SQLite

  • Einer der wichtigsten Gründe, warum SQLite über lange Zeit stabil bleiben konnte, sind extrem gründliche Tests.
  • Das SQLite-Team prüft nicht nur, ob Funktionen grundsätzlich laufen, sondern verifiziert auch verschiedenste Ausnahmefälle und Plattformen.
  • Tests haben einen so hohen Stellenwert, dass es deutlich mehr Testcode als eigentlichen Produktcode gibt.

Anwendung des DO-178B-Standards

  • Das SQLite-Team übernahm für seine Tests Ansätze aus DO-178B, dem Standard für die Entwicklung von Flugzeugsoftware.
  • Dadurch wurde die Testabdeckung systematisch erhöht.
  • Nachdem in der frühen Android-Entwicklung ein Testabdeckungsniveau auf DO-178B-Niveau erreicht worden war, gingen Bug-Reports fast vollständig zurück.
  • Diese Erfahrung zeigte, dass gründliche Tests die tatsächliche Softwarestabilität direkt verbessern.

Neue Bugs durch Fuzzing entdecken

  • Später kam die Technik des profile-guided fuzzing auf.
  • Beim Fuzzing werden zufällige oder veränderte Daten in ein Programm eingespeist, um unerwartete Fehler zu finden.
  • Durch Fuzzing wurden neue Arten von Bugs entdeckt, die selbst mit Tests auf DO-178C-Niveau schwer zu finden waren.
  • Das zeigt, dass selbst hohe Testabdeckung nicht alle Fehler aufdecken kann.

Bugs, die AI entdeckt

  • In jüngerer Zeit gibt es auch Fälle, in denen AI zur Suche nach Bugs oder zum Schreiben von Bug-Reports eingesetzt wird.
  • Auch beim SQLite-Projekt gingen Bug-Reports ein, bei denen vermutet wurde, dass sie von AI erzeugt wurden.
  • AI könnte zu einem neuen Werkzeug der Softwareverifikation werden, das bestehende Tests und Fuzzing ergänzt.

Richard Hipps Einschätzung zu AI

  • Richard Hipp sagt, seine Meinung zu AI könne sich täglich ändern.
  • Aktuell nutzt er AI als sehr nützliches Werkzeug.
  • Er erzählte von einer Erfahrung, bei der er ChatGPT Fragen zu SQLite-Code stellte und AI ihm in etwa so antwortete:

„Natürlich wissen Sie das auch, aber …“

  • Er beschrieb es als etwas unheimlich, dass AI über den von ihm selbst geschriebenen Code sprach, als wüsste sie mehr darüber als er.
  • AI ist nützlich, um Informationen zu durchsuchen und Ideen zu bekommen.
  • Sie ist jedoch nicht immer korrekt und kann falsche Informationen in sehr überzeugender Form liefern.
  • Von AI erzeugter Code funktionierte mitunter auf einem Betriebssystem, auf einem anderen jedoch nicht, was zu Kompatibilitätsproblemen führte.
  • Deshalb müssen auch von AI erzeugte Ergebnisse von Menschen direkt überprüft und korrigiert werden.

Ratschläge für junge Entwickler

  • Richard Hipp begrüßt Versuche, SQLite zu forken und eine bessere Datenbank zu bauen.
  • Er betont jedoch, dass dafür auf dem Niveau von SQLite folgende Faktoren nötig sind:
    • mehr als 25 Jahre kontinuierliche Entwicklung
    • hartnäckige Hingabe an ein einziges Thema
    • langfristige Tests und Verbesserungen
    • fortlaufende Beobachtung der Nutzeranforderungen
    • Erfahrung, die sich durch wiederholtes Scheitern ansammelt
  • Hervorragende Software entsteht nicht in kurzer Zeit.
  • Zwar könnte AI die Softwareentwicklung grundlegend verändern, doch wie genau diese Zukunft aussehen wird, lasse sich schwer vorhersagen.

1.5. Die Nachhaltigkeit von SQLite und die menschliche Seite

Warum es 26 Jahre lang weitergehen konnte

  • Richard Hipp erklärt den Erfolg von SQLite eher mit göttlicher Vorsehung und Glück als mit seinen eigenen Fähigkeiten.
  • Er sagt, er halte sich nicht für einen außergewöhnlich guten Programmierer.
  • Dennoch hätten folgende Eigenschaften zur Entwicklung von SQLite beigetragen:
    • eine beharrliche Haltung, an der eigenen Arbeitsweise festzuhalten
    • die Bereitschaft, gängige Annahmen infrage zu stellen
    • die Gewohnheit, benötigte Werkzeuge selbst zu bauen
    • die Neigung, sich langfristig auf ein Problem zu konzentrieren
    • die Haltung, den Entwicklungsprozess selbst zu genießen
  • Beim Entwickeln von SQLite sei vor allem der ständige Prozess wichtig gewesen, darüber nachzudenken, wie man es noch besser machen könne.

Die Vorteile eines kleinen Teams

  • Richard Hipp sagt, dass er nicht besonders gut darin sei, mit vielen Menschen umzugehen oder politische Beziehungen innerhalb von Organisationen zu managen.
  • Wegen dieser Persönlichkeit hat er das SQLite-Entwicklungsteam klein gehalten.
  • Im Ergebnis habe die kleine Teamstruktur der konsistenten Ausrichtung und schnellen Entscheidungsfindung von SQLite geholfen.
  • Er räumt ein, dass ihm die Fähigkeit fehle, wie Linus Torvalds im Linux-Umfeld Beziehungen zu zahllosen Entwicklern zu koordinieren.

Unternehmensführung mit seiner Frau Ginger

  • Richard Hipp führt das Unternehmen gemeinsam mit seiner Frau Ginger.
  • Die beiden pflegen eine flexible Teamarbeit und tauschen je nach Situation sogar ihre Rollen.
  • Ginger ist Musikerin und hilft anderen Musikern kompetent bei Computerproblemen.
  • Richard Hipp erzählt, dass Ginger in ihrer lokalen Gemeinschaft bekannter sei als er.

Die menschliche Seite der Softwareentwicklung

  • Richard Hipp betrachtet Software nicht nur als Ansammlung von Code oder Technik.
  • Er betont, dass menschliche Elemente wie Gefühle von Entwicklern, Zusammenarbeit, Besessenheit, Scheitern und Erfolgserlebnisse für Softwareentwicklung wichtig sind.
  • Software ist zwar ein komplexes und abstraktes Ergebnis, doch dahinter stehen immer die Geschichten der Menschen, die sie geschaffen haben.

Buchempfehlung: 《The Soul of a New Machine》

  • Richard Hipp empfiehlt 《The Soul of a New Machine》 als Buch, um die menschliche Seite von Software- und Computerentwicklung zu verstehen.
  • Das Buch erklärt nicht einfach nur Computertechnik.
  • Es behandelt unter anderem folgende Aspekte, die beim Bau eines neuen Computers sichtbar werden:
    • die Leidenschaft der Entwickler
    • Konflikte innerhalb von Organisationen
    • technische Herausforderungen
    • Scheitern und Frustration
    • Zusammenarbeit und Konkurrenz
    • Emotionen im schöpferischen Prozess
  • Er betont, wie wichtig die Fähigkeit ist, komplexe Technik tief zu verstehen und zugleich als menschliche Geschichte zu vermitteln.

Fazit

Dass SQLite über mehr als 26 Jahre erfolgreich gepflegt werden konnte, liegt nicht allein an hervorragender Technik.

Die wichtigsten Erfolgsfaktoren lassen sich so zusammenfassen.

  1. Die für reale Probleme nötige Technik wurde selbst entwickelt.
  2. Externe Abhängigkeiten wurden reduziert und die Kontrolle über das Projekt behalten.
  3. Langfristige Wartungsverantwortung wurde höher gewichtet als externe Beiträge.
  4. Benötigte Werkzeuge wie Fossil und Lemon wurden selbst gebaut.
  5. Es wurden rigorose Tests auf dem Niveau von Flugzeugsoftware angewendet.
  6. AI und neue Entwicklungstechniken wurden genutzt, ohne den Ergebnissen blind zu vertrauen.
  7. Das Projekt wurde auf Basis eines kleinen Teams und menschlicher Beziehungen betrieben.
  8. Es gab eine langfristige, hartnäckige Fokussierung auf ein einziges Thema.

Der Kern, den das Beispiel SQLite zeigt, ist: Freiheit ist nicht ein Zustand ohne jede Einschränkung, sondern ein Zustand, in dem man für die eigenen Werkzeuge und den eigenen Code selbst Verantwortung und Kontrolle übernehmen kann.

Der Entwicklungsansatz von SQLite – externe Abhängigkeiten zu reduzieren, nötige Werkzeuge selbst zu bauen und alles rigoros zu verifizieren – ist auch im sich schnell wandelnden Zeitalter der AI ein wichtiges Beispiel dafür, was nachhaltige Softwareentwicklung bedeutet.

4 Kommentare

 
regentag 1 시간 전

RTCAs Do-178 ist tatsächlich ein so kurzes Regelwerk, dass man es realistisch lesen und anwenden kann. Es wird in der Luftfahrtbranche breit eingesetzt.

https://studylib.net/doc/27132454/rtca-do-178b

 
hmmhmmhm 2 시간 전

„Mehr als 25 Jahre kontinuierliche Entwicklung“ ist wirklich beeindruckend...

 
cnaa97 2 시간 전

Großartig … fast wie ein Film.

 
toida 3 시간 전

Die Einstellung ist wirklich großartig.