RethinkDB: por que cerramos

La traducción del artículo fue publicada con permiso del autor.

Cuando anunciamos que RethinkDB estaba cerrando, prometí escribir una crítica póstuma. Me tomé un tiempo para repensar la experiencia, y ahora puedo decirlo claramente.

En el hilo de discusión de HN, las personas describieron muchas razones por las cuales RethinkDB falló, que van desde la perversión inexplicable de la naturaleza humana, las maquinaciones astutas de los vendedores de MongoDB y el fracaso para construir un equipo experimentado listo para ingresar al mercado, terminando con la falta de soporte para tipos numéricos de flotación de 64 bits. He resumido los comentarios sobre la lista de razones para el fracaso que se han sugerido.

Algunos de ellos tienen algo de verdad, pero son síntomas más probables que causas. Por ejemplo, la afirmación de que no hemos aprendido cómo obtener ganancias financieras es superficial. Esta declaración no ilumina las razones por las cuales no tuvimos éxito.

Mirando hacia atrás, concluyo que dos cosas salieron mal: elegimos un mercado difícil y optimizamos el producto de acuerdo con los criterios incorrectos de utilidad para el usuario. Cada uno de estos errores probablemente redujo el valor de RethinkDB en uno o dos órdenes de magnitud. Por lo tanto, si hiciéramos una de estas dos cosas correctamente, RethinkDB habría alcanzado el tamaño de MongoDB, y si nos hubiéramos dado cuenta de ambas omisiones, finalmente habríamos alcanzado el tamaño de Red Hat [1].

Mercado duro

Nuestro pensamiento fue aproximadamente como sigue. Las nuevas empresas no se crean sobre la base de las soluciones de Oracle, por lo que existe un nicho en el que es posible construir una empresa con una nueva infraestructura. El mercado de bases de datos es enorme. Si creamos un proyecto que capturará parte del mercado, llegaremos a la conclusión de que nos convertiremos en una empresa muy exitosa.

Desafortunadamente, no está entrando en el mercado en el que está pensando, está en el mercado donde lo llevan sus usuarios . Y nuestros usuarios tenían una visión clara de nosotros como una compañía de herramientas de código abierto, porque eso es lo que estamos haciendo. Lo que resultó ser muy triste para nosotros, porque el mercado de herramientas de código abierto es uno de los peores mercados en los que cualquiera podría encontrarse. Miles de personas usaron RethinkDB, en parte en el contexto del negocio, pero la mayoría quería pagar menos por el uso de por vida que por una taza de café de Starbucks (es decir, no querían pagar nada).

Esto no fue porque el producto fuera tan bueno que la gente no tuviera que pagar por el apoyo, o porque los programadores no controlaran el presupuesto o por el colapso del capitalismo. La respuesta es lo básico de la microeconomía. Los programadores adoran desarrollar herramientas de desarrollo, a menudo de forma gratuita. Y aunque hay una gran demanda, la oferta está muy por delante. El número de alternativas aumenta y los precios caen a cero.

Para saber cómo afecta esto a otras compañías, mire MongoDB (con un valor aproximado de $ 1.6 mil millones ~ 700 empleados) y Docker (con un valor aproximado de $ 1 mil millones ~ 300 empleados). Ambas compañías dominan absolutamente sus mercados. De acuerdo con dos reglas generalmente aceptadas, las compañías de software privadas en crecimiento se estiman en diez veces el ingreso anual, y el ingreso por empleado es de aproximadamente $ 200 mil / año. Lo que significa que los ingresos anuales de MongoDB son de aproximadamente $ 140- $ 160 millones, y los ingresos anuales de Docker son de aproximadamente $ 60- $ 100 millones.

Esto se ve bastante bien hasta que miramos a las empresas tecnológicas B2B que prevalecen en mercados que no son mercados de herramientas de desarrollo. Empresas como SalesForce, Palantir o Box (que enfrentan una dura competencia). Y de repente, MongoDB y Docker comienzan a verse pequeños.

Aunque estas son empresas extremadamente exitosas. Si las empresas relativamente establecidas con asociaciones, infraestructura de distribución y acceso a cuentas impresionantes enfrentan desafíos de crecimiento, ¿qué significa esto para una startup que está en una etapa de brotación?

Para nosotros, esto significó un embudo de ventas difícil de alcanzar. Si en un mercado B2B próspero, una startup necesita procesar cien leads para obtener diez oportunidades, obtener una venta, luego, para una startup que trabaje en herramientas de desarrollo, este número se multiplica por 10. Tiene acceso a muchas buenas perspectivas: muchas personas descargan su producto e interactúan. con usted, pero necesita romper la plaga de clientes potenciales para acercarse a la única venta.

Este proceso tiene las desastrosas consecuencias del dominó. El equipo está desmoralizado, se hace difícil atraer inversiones y contratar a los mejores profesionales. A su vez, esto limita sus propios recursos, por lo que se hace imposible invertir significativamente en un producto o distribución. La dinámica de conducción es una cuestión de vida o muerte para las nuevas empresas, y las dificultades de distribución en las primeras etapas casi siempre lo condenan a una muerte segura.

Criterios de utilidad incorrectos

Bueno, el mercado es malo, pero otras compañías involucradas en herramientas de desarrollo todavía venden en grandes volúmenes. ¿Por qué no repensar DB?

Aunque no pudimos hacer nada con la dinámica del mercado (aparte de hacer otra cosa), las decisiones sobre los productos dependían completamente de nosotros. Queríamos crear un producto elegante, confiable y hermoso, por lo que nos optimizamos para las siguientes métricas.

• Corrección Dimos garantías muy altas y las cumplimos estrictamente .
• La simplicidad de la interfaz. Asumimos la mayoría de las dificultades de implementación para no complicar la vida de los desarrolladores.
• Uniformidad Hicimos todo, desde el lenguaje de consulta, los controladores del cliente, la configuración del clúster, la documentación, hasta el texto publicitario en la portada lo más uniforme posible.

Si parece familiar, tomamos estas cualidades del trabajo; peor es mejor . Resultó que la corrección, la simplicidad de la interfaz y la secuencia son criterios de utilidad incorrectos para la mayoría de los usuarios. La mayoría de los usuarios querían estas tres opciones:

• Puntualidad. Querían que el producto realmente funcionara cuando lo necesitaran, no tres años después.
• Velocidad tangible La gente quería que RethinkDB fuera rápido bajo las cargas que los usuarios realmente daban, y no solo bajo las ofertas que están cerca de la "realidad". Por ejemplo, escriben scripts rápidos para medir cuánto se tarda en insertar diez mil documentos sin leerlos. MongoDB dominó estas cargas magníficamente mientras luchamos en una batalla de entrenamiento de mercado ya perdida.
• Casos de uso. Teníamos la intención de hacer un buen sistema de base de datos, pero los usuarios querían una buena forma de hacer X (por ejemplo, una buena forma de guardar documentos JSON desde hapi, una buena forma de guardar y analizar registros, una buena forma de crear informes, etc.).

Esto no significa que no intentamos comenzar rápidamente, hacer que RethinkDB sea rápido y construir un ecosistema a su alrededor para facilitar el trabajo útil. Lo hicimos Pero el software correcto, simple y consistente lleva mucho tiempo. Esto causó nuestro retraso en el mercado por tres años.

En el momento en que sentimos que RethinkDB era satisfactorio, teníamos la confianza suficiente para recomendar su uso en la producción, casi todos preguntaron "¿qué tan diferente es RethinkDB de MongoDB"? Trabajamos arduamente para explicar por qué la corrección, la simplicidad y la sistémica / compatibilidad son tan importantes, pero al final, estos factores no fueron criterios de utilidad que fueran importantes para la mayoría de los usuarios.

Para ser honesto, duele. Realmente duele. Esto fue incomprensible para nosotros, por qué las personas eligieron un sistema que apenas hace lo que debería hacer (almacenar datos), bloquea el núcleo, está disperso por errores, funciona como un nodo que deja de funcionar cuando se segmenta, tiene un sistema de segmentación que apenas funciona. El hecho de que esta sea una de las características clave del producto no garantiza un funcionamiento correcto y arroja una mezcla de interfaces en las que no hay una visión sistemática o uniforme.

Cada vez que MongoDB lanzó un lanzamiento y la gente los felicitó por las mejoras, sentí una oleada de indignación. Dijeron que arreglarían el BKL, pero de hecho bajaron el nivel de detalle de la base de datos a la colección. Agregaron más operaciones, pero en lugar de una interfaz modular que se combina con el sistema, simplemente arruinaron los comandos únicos. Tendrían una mejor segmentación, pero era obvio que no querían o ni siquiera podían dar garantías elementales sobre la consistencia de los datos.

Pero con el tiempo, aprendí a apreciar la sabiduría de la multitud. MongoDB convirtió a los desarrolladores comunes en héroes cuando la gente lo necesitaba , no años después. Esto hizo que el almacén de datos fuera rápido y permitió a las personas entregar productos rápidamente. Y con el tiempo, MongoDB ha crecido. Uno por uno, solucionaron problemas de arquitectura, y ahora es un gran producto. Puede que no sea tan guapo como nos gustaría, pero hace su trabajo y lo hace bien.

Cuando se hizo evidente a mediados de 2014 que no podíamos competir, trabajamos duro para ser diferentes de MongoDB. Encontramos una forma muy elegante de agregar notificaciones en tiempo real , con la esperanza de que esto permitiría a los desarrolladores crear una generación de aplicaciones que antes no podían hacer. Pero eso no fue suficiente. Inesperadamente para nosotros, nos convertimos en competidores con Meteor y Firebase, compañías que se dedicaron a resolver problemas apremiantes, que ni siquiera se discutirán durante varios años. Y nuevamente estuvimos tres años detrás del mercado, nuevamente descubrimos que no podíamos competir.

¿Qué hay de la nube?

Varias personas sugirieron que necesitábamos hacer un servicio en la nube. De hecho, teníamos uno de esos proyectos en desarrollo, por lo que este es un tema interesante que me gustaría tratar.

El problema obvio con una pequeña empresa que desarrolla un servicio en la nube es que tiene un modo de falla común: el desenfoque. Es difícil desarrollar, distribuir y operar un servicio en la nube multiinquilino. Todo esto requiere una experiencia y recursos extraordinarios, por lo que si realmente ingresas en este camino, es posible que administres dos startups a la vez. Pero nos enfrentamos a la amenaza de la existencia, y nuestras opciones de acción se estaban agotando rápidamente, por lo que le dimos a esta idea la oportunidad de disparar. Supongamos por el momento que pudiéramos impulsar esta idea.

Nuestro razonamiento fue el siguiente. Una propuesta de base de datos podría significar una de tres cosas: hosting administrado, una base de datos como servicio (DBaaS) o una plataforma avanzada como servicio (PaaS). Volvamos al análisis de marketing escrito en la rodilla, donde usamos el parámetro $ 200 mil / empleado en ingresos anuales, la misma regla que usamos anteriormente:

	Hospedaje administrado	DBaaS	PaaS
Empresa	Compose.io, mLab	Faunadb	Parse, Firebase, Meteor
Empleados	~ 30	~ 30	~ 30
Ingresos	<$ 10 millones	<$ 10 millones	<$ 10 millones

Estos mercados son pequeños, incluso más pequeños que el mercado de la base de datos. ¿Quizás deberías haber preferido uno de ellos al otro?

El alojamiento administrado básicamente consiste en mantener una base de datos de AWS para las personas. Una alternativa al uso de estos servicios es crear su propia base de datos de AWS. Es un dolor, pero no es tan difícil. Por lo tanto, existe una restricción severa sobre cómo evaluar los servicios de alojamiento administrado. Dado que Compose.io y mLab ofrecen MongoDB, que tiene un orden de magnitud más clientes que RethinkDB, asumimos que la oferta de hosting administrado no tendría mucho efecto.

Una base de datos como servicio es una versión más compleja del alojamiento administrado, por ejemplo, un servicio DBaaS separa completamente la administración del host del usuario. Simplemente realiza solicitudes y el sistema las procesa. Simplemente no sabes nada sobre cuántos nodos se ejecutan bajo el capó. Este negocio no es muy simple: en parte porque las compañías DBaaS tienen que competir con gigantes (como DynamoDB y DocumentDB) y en parte porque los clientes no están inclinados a transferir completamente la administración de datos a las nuevas empresas, mientras que hay muchas otras opciones y alternativas ( ¿ Conoces a alguien que usa los servicios DBaaS desde una startup?) Entonces, la propuesta para DBaaS se queda atrás.

La última opción era desarrollar una plataforma avanzada como servicio. Pensamos que era un área prometedora, porque teníamos una gran ventaja técnica. Firebase y Meteor tuvieron que construir una lógica de aplicación en tiempo real sobre MongoDB, lo que limita significativamente las capacidades de consulta en tiempo real y el rendimiento en el nivel correcto. Por otro lado, podríamos controlar la pila hasta el final, por lo que podríamos ofrecer beneficios significativos que no estaban disponibles para Firebase y Meteor.

Por lo tanto, desarrollamos Horizon y comenzamos a trabajar en Horizon Cloud, con el cual los usuarios tendrían la oportunidad de implementar y escalar aplicaciones RethinkDB / Horizon. El desarrollo de tres grandes proyectos (RethinkDB, Horizon y Horizon Cloud) con un equipo muy pequeño finalmente nos superó, y aún no pudimos lanzar un servicio en la nube antes de que se nos acabara el dinero. Sin embargo, respeto al equipo de desarrollo. Estaban muy, muy cerca.

Meta preguntas

Hay otro nivel de análisis de las causas raíz que podemos señalar. ¿Por qué elegimos un mal mercado y optimizamos el producto de acuerdo con las métricas incorrectas?

Cuando era niño, quería hacer mi propia radio. Hice una caja de madera contrachapada, arrojé algunos restos metálicos desde el interior y conecté la caja al cable de alimentación. Tenía libros sobre electrónica en casa, pero me pareció que no los necesitaba, tenía una fe inquebrantable de poder hacerlo yo mismo. Al final, construí un receptor que funciona, pero me llevó varios años finalmente comprender que necesitaba aprender los conceptos básicos de la electrónica.

RethinkDB temprano fue un poco así. No teníamos intuición para los productos y los mercados, por lo que simplemente nos impulsó la idea de construir una empresa, sin comprender realmente lo que estábamos haciendo. Además, teníamos una increíble actitud optimista . Del mismo modo que los médicos saben que los obsequios de las compañías farmacéuticas tienen un efecto de adicción en otros médicos, pero todavía creen que no se ven afectados por este efecto, pensamos que no teníamos leyes económicas y un componente matemático para hacer negocios. Y, por supuesto, al final, las matemáticas nos derribaron.

¿Podríamos hacer algo para evitar estos errores? No más de lo que podría hacer de niño con esa radio. No nos dimos cuenta de que éramos incompetentes, y tomó años para que esta incompetencia se volviera consciente.

Varias personas notaron que podríamos mejorar nuestra situación si construimos un equipo experimentado listo para ingresar al mercado. Esto es 100% cierto, pero el tiempo para nuestro desarrollo personal no estuvo de acuerdo con las necesidades de la empresa. Inicialmente, no sabíamos que necesitábamos conocimiento experto y experiencia para ingresar al mercado, por lo que no nos esforzamos por incluir esto en la lista necesaria de cosas para formar un equipo. Cuando desarrollamos un tipo de pensamiento que se correspondía bien con la realidad, estábamos atrapados en un mercado difícil lleno de competidores dignos y un producto que tenía tres años de retraso. Para entonces, incluso el mejor equipo amigable con el mercado del mundo no podría salvarnos.

Adios Pensamientos

Muchas personas están indignadas por el mercado de herramientas para desarrolladores. A los desarrolladores les gusta hacer herramientas para desarrolladores, por lo que realmente quieren que las empresas que hacen herramientas para que los desarrolladores prosperen.

No quisiera omitir este mercado en absoluto, en parte porque no quiero generalizar sobre la base de una experiencia, y en parte porque no me gusta decir "es imposible hacerlo" y en parte porque hay bastantes excepciones. GitHub, MongoDB y Docker han creado empresas impresionantes. Parece que a GitLab y Unity también les va bien.

Si realmente tiene la intención de establecer una empresa de desarrollo de herramientas, proceda con precaución. El mercado está lleno de buenas alternativas. Las expectativas de los usuarios son altas y los precios bajos. Considere cuidadosamente el precio que ofrece al cliente. Recuerde: el deseo de que el mundo sea así, lo quiere, no lo hace así.

En 2009, hablamos sobre la idea original de RethinkDB (aún no teníamos software) de una audiencia de inversores en el día de demostración de YCombinator. Terminamos el informe de diapositivas con tres puntos clave. “Si solo puedes recordar tres cosas sobre RethinkDB”, dijimos, “recuerda estas”. Funcionó. La gente no recordaba nada del discurso, pero recordaban tres puntos al final.

Terminaré con tres puntos clave que vale la pena recordar. Si algo vale la pena recordar de este artículo, entonces vale la pena recordar esto:

• Elija un mercado grande, pero hágalo para usuarios específicos.
• Aprende a reconocer los talentos que te faltan, luego trabaja para formar parte del equipo.
• Lea The Economist sin falta. Te hará mejor más rápido.

[1] No leas muchos de estos números. Di una estimación muy aproximada, pero aún tenía que dar una idea general del costo de estos errores.

[2] , , , , , , .