El creador de SQLite, Richard Hipp, habla de Turso, la IA y 26 años de código [YouTube]
(youtube.com)El creador de SQLite explica que la clave de su éxito durante 26 años ha sido crear sus propias herramientas, minimizar las contribuciones externas y mantener la calidad del código mediante pruebas exhaustivas.
Esto muestra la esencia misma de la "libertad", algo que a menudo se pasa por alto en los complejos ecosistemas de código abierto.
Índice
-
El recorrido de 26 años de código de Richard Hipp, creador de SQLite
- 1.1. El nacimiento de SQLite: resolver un problema que empezó en un buque de guerra
- 1.2. El crecimiento de SQLite y su éxito comercial
- 1.3. Licencias, filosofía open source y desarrollo de herramientas propias
- 1.4. Pruebas exhaustivas y desarrollo de software en la era de la IA
- 1.5. La sostenibilidad de SQLite y su lado humano
1. El recorrido de 26 años de código de Richard Hipp, creador de SQLite
El creador de SQLite, Richard Hipp, ha puesto en práctica durante 26 años de desarrollo de código una filosofía basada en lo siguiente:
- Desarrollar él mismo las herramientas que necesita.
- Minimizar las contribuciones de código externas.
- Mantener la calidad del código mediante pruebas exhaustivas.
- Reducir las dependencias externas para asegurar libertad en el desarrollo.
1.1. El nacimiento de SQLite: resolver un problema que empezó en un buque de guerra
SQLite nació en un proyecto naval
- SQLite comenzó a partir de un trabajo bajo contrato relacionado con el buque de guerra USS Oscar Austin.
- En ese momento, Richard Hipp trabajaba como contratista de General Dynamics en el proyecto de construcción del buque DDG-79 en Bath Iron Works.
- Surgieron problemas en el desarrollo del sistema de información para control de daños del buque.
- Otra empresa había invertido millones de dólares, pero no había logrado entregar un resultado funcional.
Las limitaciones de los sistemas de bases de datos existentes
- Para resolver los problemas del sistema de control de daños, Richard Hipp desarrolló rápidamente software basado en heurísticas.
- Sin embargo, si se detenía el motor de base de datos Informix usado para almacenar los datos, el software también dejaba de funcionar.
- El software tenía que seguir funcionando incluso cuando el administrador del sistema detuviera el motor de base de datos.
- Eso lo llevó a pensar en una forma en la que la aplicación leyera directamente los datos del disco sin un proceso de base de datos separado.
- En ese momento era difícil encontrar un motor de base de datos SQL que cumpliera con esos requisitos, así que tuvo que desarrollarlo él mismo.
Estudio autodidacta de bases de datos relacionales
- En ese entonces, las búsquedas por internet no eran tan comunes como hoy.
- Richard Hipp investigó la tecnología de bases de datos relacionales buscando material en la biblioteca de una universidad local.
- En ese tiempo, en lugares como MIT, Harvard y Berkeley se investigaban activamente las bases de datos relacionales.
- Pero por limitaciones geográficas, no podía acceder fácilmente a la información más reciente.
- Al final, terminó estudiando e implementando por su cuenta la tecnología de base de datos que necesitaba.
1.2. El crecimiento de SQLite y su éxito comercial
Un proyecto que no empezó con fines de lucro
- SQLite no fue desarrollado originalmente con el objetivo de monetizarlo.
- Las primeras versiones se publicaron como software gratuito.
- En ese momento no existía un plan para hacer negocio ni generar ingresos con él.
El primer contrato comercial con Motorola
- Años después de publicar SQLite, recibió una llamada del fabricante de teléfonos móviles Motorola.
- Motorola quería incorporar SQLite en sus teléfonos.
- Eso llevó al primer contrato comercial de SQLite.
- El acuerdo no se hizo con un esquema de licencias por uso, sino con un precio fijo.
Colaboración con AOL
- Después, America Online (AOL) también firmó un contrato para incluir SQLite en un paquete en CD-ROM.
- Ese contrato también se hizo con un precio fijo.
- Richard Hipp consideró que el monto de ese contrato fue relativamente bajo en comparación con el valor de SQLite.
Symbian OS eligió SQLite
- Symbian OS, usado en teléfonos de Nokia y otras marcas, realizó una prueba a ciegas para elegir un motor de base de datos.
- En total se evaluaron 10 motores de base de datos.
- Como resultado, SQLite fue el seleccionado.
- En ese proceso surgió la preocupación de que SQLite dependiera demasiado de un solo desarrollador clave.
- Se le sugirió formar un consorcio para aumentar el llamado bus factor.
Bus factor
Es una métrica que indica si un proyecto puede mantenerse cuando varias personas clave dejan de poder trabajar repentinamente en él.
Un bus factor de 1 significa que, si falta un solo desarrollador clave, mantener el proyecto puede volverse difícil.
Fundación del consorcio y desarrollo a tiempo completo
- Mitchell Baker, de Mozilla, le dio consejo sobre cómo crear un consorcio.
- A partir de eso se fundó el consorcio de SQLite.
- Después de la creación del consorcio, Richard Hipp pasó a dedicarse a tiempo completo al desarrollo de SQLite.
- Al contratar a varias personas, logró operar una organización de desarrollo pequeña pero sostenible.
Plan de soporte a largo plazo hasta 2050
- En 2010, Airbus quería usar SQLite en la aviónica del proyecto del avión A350.
- Airbus preguntó si SQLite podría mantenerse y recibir soporte durante un largo período.
- Considerando que la vida útil del fuselaje de un avión ronda los 40 años, se prometió soporte a largo plazo.
- Esa promesa no era tanto una obligación legal como una meta de largo plazo del proyecto SQLite.
- Actualmente, Richard Hipp se ha fijado 2050 como su meta personal para dejar de dar soporte a SQLite.
- Lo define como una forma de sumarle 50 años al enfoque de "código primero para los datos", es decir, mantener el código más tiempo del que se espera que vivan los datos.
1.3. Licencias, filosofía open source y desarrollo de herramientas propias
El nacimiento de la licencia de la “oración”
- SQLite versión 1 dependía de la biblioteca GDBM.
- Como GDBM usaba licencia GPL, SQLite también quedaba inevitablemente afectado por la GPL.
- Después, para soportar consultas por rango, desarrolló un backend de almacenamiento propio basado en B-tree.
- Al eliminar la dependencia de bibliotecas externas, pudo elegir libremente la licencia.
La elección del dominio público
- En ese momento, las licencias más conocidas eran la MIT y la Berkeley.
- En vez de usar una licencia con cláusulas legales complejas, Richard Hipp publicó SQLite como Public Domain.
- Más tarde descubrió que el concepto de dominio público no se reconoce de la misma forma en todos los países.
- Aun así, la política de publicación de SQLite terminó siendo aceptada de una manera similar a una licencia open source.
El texto de la “oración”
En el encabezado del código fuente de SQLite se incluyó, en lugar de un texto legal convencional, una frase más parecida a una bendición o una oración.
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.
A medida que SQLite se convirtió en una de las bibliotecas de software más usadas del mundo, este texto también pasó a simbolizar su filosofía única de licenciamiento.
Un estilo de desarrollo que minimiza las contribuciones externas
- SQLite no recibe pull requests de forma activa como un proyecto open source típico.
- Mantiene un modelo en el que se minimizan las contribuciones externas y el equipo principal escribe y administra directamente el código.
- Richard Hipp compara los pull requests con un “cachorro gratis”.
- Así como recibir un cachorro gratis implica después responsabilidades de cuidado y mantenimiento, aceptar código externo también trae responsabilidades de largo plazo como las siguientes:
- Mantenimiento del código
- Pruebas
- Documentación
- Corrección de errores
- Gestión de compatibilidad con otras plataformas
- Responsabilidad técnica a largo plazo
- Restringir las contribuciones externas ha sido uno de los factores que permitieron a SQLite mantener una calidad y una dirección consistentes durante más de 26 años.
Casos de desarrollo de herramientas propias
Fossil
- Fossil es un sistema de control de versiones propio creado para gestionar el proyecto SQLite.
- Fue desarrollado en una época parecida a la de Git.
- Además de administrar código fuente, integra de forma unificada las siguientes funciones:
- Control de versiones
- Seguimiento de issues
- Wiki
- Foro
- Interfaz web
- Fossil en sí mismo está construido sobre SQLite.
- Por eso, Fossil también funciona como una plataforma de beta testing real para SQLite.
- Al desarrollar y operar Fossil, pudieron detectar y mejorar problemas de SQLite desde la perspectiva de un desarrollador de aplicaciones.
- Richard Hipp considera que Git es adecuado para proyectos distribuidos de gran escala como el kernel de Linux, mientras que Fossil encaja mejor en proyectos pequeños como SQLite.
Lemon
- Lemon es una herramienta desarrollada para generar el parser SQL de SQLite.
- En vez de usar Yacc o Bison, decidió crearla por cuenta propia.
- Al ser una herramienta propia, pudo mejorar libremente la forma de generar parsers según las necesidades de SQLite.
Herramientas propias y la filosofía de la libertad
- Para Richard Hipp, desarrollar herramientas propias no es solo una preferencia técnica.
- Considera que crear por sí mismo las herramientas que necesita es una forma de cuidarse a sí mismo.
- Reducir dependencias externas hace que uno se vea menos afectado por decisiones de otros proyectos o empresas.
- Piensa que esa independencia amplía la libertad del desarrollador.
- Aun así, también siente peso y preocupación por el hecho de que SQLite sea una dependencia crítica en tantos sistemas del mundo.
1.4. Pruebas exhaustivas y desarrollo de software en la era de la IA
Las pruebas, clave del éxito de SQLite
- Uno de los factores más importantes para que SQLite haya mantenido su estabilidad durante tanto tiempo ha sido un nivel extremadamente riguroso de pruebas.
- El equipo de SQLite no se limita a comprobar si una función funciona, sino que valida muchos escenarios excepcionales y múltiples plataformas.
- Las pruebas son tan importantes que la cantidad de código de testing supera ampliamente la del código del producto real.
Aplicación del estándar DO-178B
- El equipo de SQLite aplicó a sus pruebas el enfoque del estándar de desarrollo de software aeronáutico DO-178B.
- Gracias a eso, aumentó de manera sistemática la cobertura de testing.
- En las primeras etapas del desarrollo de Android, tras alcanzar un nivel de cobertura comparable al de DO-178B, casi desaparecieron los reportes de bugs.
- Esa experiencia confirmó que las pruebas exhaustivas tienen un impacto directo en la mejora real de la estabilidad del software.
Descubrimiento de nuevos bugs mediante fuzzing
- Más adelante apareció la técnica de profile-guided fuzzing.
- El fuzzing consiste en introducir al programa datos aleatorios o modificados para encontrar errores inesperados.
- Gracias al fuzzing se descubrieron nuevos tipos de bugs que eran difíciles de encontrar incluso con pruebas de nivel DO-178C.
- Eso demuestra que una cobertura alta de testing por sí sola no basta para encontrar todos los errores.
Bugs detectados por IA
- Recientemente también han surgido casos en los que se usa IA para buscar bugs o redactar reportes de errores.
- El proyecto SQLite incluso ha recibido reportes de bugs que parecían haber sido generados por IA.
- La IA puede convertirse en una nueva herramienta de verificación de software que complemente las pruebas y el fuzzing existentes.
La opinión de Richard Hipp sobre la IA
- Richard Hipp dice que su opinión sobre la IA puede cambiar todos los días.
- Actualmente la usa como una herramienta muy útil.
- Contó que, al hacerle preguntas a ChatGPT sobre código de SQLite, obtuvo respuestas de la IA formuladas de una manera como esta:
“Por supuesto, tú también lo sabes, pero…”
- Explicó que le dio un poco de escalofrío ver a la IA hablar como si conociera mejor que él el código que él mismo escribió.
- La IA es útil para explorar información y obtener ideas.
- Sin embargo, no siempre es correcta y puede entregar información equivocada con una expresión muy convincente.
- También hubo casos en los que código generado por IA funcionaba en un sistema operativo, pero no en otro, causando problemas de compatibilidad.
- Por eso, incluso los resultados producidos por IA deben ser revisados y corregidos directamente por personas.
Consejo para desarrolladores jóvenes
- Richard Hipp dice que da la bienvenida a los intentos de hacer un fork de SQLite para crear una base de datos mejor.
- Pero subraya que, para llegar al nivel de SQLite, se necesitan los siguientes elementos:
- Más de 25 años de desarrollo continuo
- Dedicación obsesiva a un solo tema
- Años de pruebas y mejoras
- Observación constante de las necesidades de los usuarios
- Experiencia acumulada a partir de fracasos repetidos
- El gran software no se construye en poco tiempo.
- Considera que la IA podría cambiar profundamente la forma de desarrollar software, pero que no es fácil predecir cómo será ese futuro.
1.5. La sostenibilidad de SQLite y su lado humano
Por qué pudo sostenerse durante 26 años
- Richard Hipp explica el éxito de SQLite no tanto por su propia capacidad, sino por la providencia divina y la buena suerte.
- Dice que no se considera un programador especialmente brillante.
- Pero analiza que ciertos rasgos suyos sí ayudaron al desarrollo de SQLite:
- Mantener obstinadamente su propia manera de hacer las cosas
- Cuestionar las ideas convencionales
- Tener el hábito de crear sus propias herramientas
- La tendencia a concentrarse en un solo problema durante mucho tiempo
- Disfrutar el propio proceso de desarrollo
- Dice que, al desarrollar SQLite, lo importante fue el proceso mismo de pensar constantemente cómo hacerlo mejor.
Las ventajas de un equipo pequeño
- Richard Hipp dice que no es especialmente hábil para convivir con mucha gente ni para manejar relaciones políticas dentro de una organización.
- Por esa personalidad, ha mantenido pequeño al equipo de desarrollo de SQLite.
- Como resultado, considera que una estructura de equipo pequeño ayudó a mantener una dirección consistente y una toma de decisiones rápida en SQLite.
- Reconoce que no tiene la capacidad de coordinar relaciones con muchísimos desarrolladores como lo hace Linus Torvalds en Linux.
Manejar la empresa junto con su esposa Ginger
- Richard Hipp dirige la empresa junto con su esposa, Ginger.
- Los dos mantienen una dinámica flexible, incluso intercambiando cargos según la situación.
- Ginger es música y además tiene habilidad para ayudar a otros músicos que tienen dificultades con problemas informáticos.
- Richard Hipp cuenta que Ginger es más conocida que él en la comunidad local.
El lado humano del desarrollo de software
- Richard Hipp no ve el software solo como un conjunto de código o tecnología.
- Subraya que elementos humanos como las emociones de los desarrolladores, las relaciones de colaboración, la obsesión, el fracaso y la sensación de logro son importantes en el desarrollo de software.
- El software es un resultado complejo y abstracto, pero detrás de él existen las historias de las personas que lo hicieron posible.
Libro recomendado: 《The Soul of a New Machine》
- Richard Hipp recomienda 《The Soul of a New Machine》 como un libro que ayuda a entender el lado humano del desarrollo de software y de computadoras.
- El libro no se limita a explicar tecnología informática.
- También aborda elementos como los siguientes en el proceso de crear una nueva computadora:
- La pasión de los desarrolladores
- Conflictos dentro de la organización
- Desafíos técnicos
- Fracaso y frustración
- Colaboración y competencia
- Emociones en el proceso creativo
- Subraya que es importante tener la capacidad de comprender profundamente tecnologías complejas y, al mismo tiempo, transmitirlas como historias humanas.
Conclusión
La razón por la que SQLite ha podido mantenerse con éxito durante más de 26 años no se explica solo por su excelencia técnica.
Los factores clave de su éxito pueden resumirse así:
- Desarrolló directamente la tecnología necesaria para resolver problemas reales.
- Redujo dependencias externas y mantuvo el control del proyecto.
- Dio más importancia a la responsabilidad de mantenimiento a largo plazo que a las contribuciones externas.
- Creó por sí mismo herramientas como Fossil y Lemon.
- Aplicó pruebas exhaustivas al nivel del software aeronáutico.
- Aprovechó la IA y nuevas técnicas de desarrollo sin confiar ciegamente en sus resultados.
- Operó el proyecto sobre la base de un equipo pequeño y relaciones humanas cercanas.
- Se sumergió de forma obsesiva en un solo tema durante muchísimo tiempo.
La lección central que muestra el caso de SQLite es que la libertad no es la ausencia total de restricciones, sino la capacidad de asumir responsabilidad y tener control directo sobre las herramientas y el código que uno usa.
La forma de desarrollar de SQLite —reducir dependencias externas, crear las herramientas necesarias por cuenta propia y verificar todo rigurosamente— es un ejemplo importante de lo que significa construir software sostenible incluso en una era de IA que cambia rápidamente.
4 comentarios
El Do-178 de la RTCA es una guía lo suficientemente corta como para que de verdad sea posible leerla y aplicarla. Se usa ampliamente en la industria aeronáutica.
https://studylib.net/doc/27132454/rtca-do-178b
"Más de 25 años de desarrollo continuo" de verdad es increíble...
Está genial... hasta parece una película.
Qué mentalidad tan genial.