[Перевод] RethinkDB: почему мы закрылись

Когда мы объявили, что RethinkDB закрывается, я пообещал написать критический анализ посмертно. Я взял некоторое время, чтобы переосмыслить полученный опыт, и сейчас могу его четко изложить.
В ветке обсуждений HN люди описывали множество причин, почему RethinkDB провалился, начиная от необъяснимой извращенности человеческой натуры, хитрых махинаций маркетологов MongoDB и неудачи построить опытную команду, готовую выйти на рынок, заканчивая отсутствием поддержки числовых типов размерностью больше 64-битного float. Я обобщил комментарии в списке причин провала, которые были предложены.

В некоторых из них есть доля правды, но они скорее представляют из себя симптомы, чем причины. Например, высказывание, что мы не научились получать финансовую выгоду, является поверхностным. Это утверждение не освещает причин, почему у нас не получилось.

Оглядываясь назад, делаю вывод, что две вещи пошли не так — мы выбрали жесткий рынок и оптимизировали продукт согласно неправильным критериям полезности для пользователя. Вероятно, каждая из этих ошибок снизила ценность RethinkDB на один-два порядка. Поэтому если бы мы правильно сделали одну из этих двух вещей, RethinkDB достиг бы размера MongoDB, и если бы мы осознали оба упущения, мы в конечном итоге достигли бы размеров Red Hat[1].

Жесткий рынок

Наше мышление было приблизительно следующим. Новые компании не строятся на основе решений от Oracle, поэтому есть ниша, в которой есть возможность построить компанию с новой инфраструктурой. Рынок баз данных огромен. Если мы создадим проект, который захватит часть рынка, мы придем к тому, что станем очень успешной компанией.

К сожалению, ты выходишь не на тот рынок, о котором думаешь — ты находишься на том рынке, куда тебя относят твои пользователи. А наши пользователи имели четкое представление о нас как о компании, занимающейся инструментами с открытым исходным кодом, потому что это именно этим мы и занимаемся. Что оказалось очень печальным для нас, потому что рынок инструментов с открытым исходным кодом — это один из худших рынков, на котором кто-либо может оказаться. Тысячи людей использовали RethinkDB, часть в контексте бизнеса, но большинство хотело платить за пожизненное использование меньше, чем за кружку кофе из Starbucks (то есть, не хотели платить совсем ничего).

Это не было из-за того, что продукт был настолько хорош, что людям не нужно было платить за поддержку, или потому что программисты не контролировали бюджет или из-за краха капитализма. Ответ в основах микроэкономики. Программисты любят разрабатывать инструменты для разработки, часто бесплатно. И пока есть большой спрос, предложение значительно опережает его. Количество альтернатив взвинчивается, и цены опускаются до нуля.

Чтобы узнать, как это отражается на других компаниях, посмотрим на MongoDB (стоимостью примерно $1.6 млрд.~700 сотрудников) и Docker (стоимостью примерно $1 млрд.~300 сотрудников). Обе компании абсолютно преобладают на своих рынках. Согласно двум общепринятым правилам, растущие частные компании, разрабатывающие ПО, оцениваются в размере десятикратного ежегодного дохода, и доход на одного сотрудника составляет примерно $200тыс./год. Что означает, что годовой доход MongoDB составляет примерно $140-$160 млн, и годовой доход Docker — около $60-$100млн.

Это выглядит довольно неплохо, пока не рассматриваем превалирующие B2B технические компании на рынках, которые не являются рынками инструментальных средства разработки. Такие компании, как SalesForce, Palantir или Box (которые сталкивается с жесткой конкуренцией). И внезапно MongoDB и Docker начинают выглядеть крошечными.

Хотя это крайне успешные компании. Если относительно утвердившиеся компании, имеющие партнерства, инфраструктуру распространения и доступ к внушительным счетам, сталкиваются с проблемами роста, что это означает для стартапа, находящегося в стадии прорастания?

Для нас это означало труднообрабатываемую воронку продаж. Если на благодатном B2B рынке стартапу нужно обрабатывать сто лидов, чтобы получить десять возможностей, получить одну продажу, то для стартапа, занимающегося инструментами разработки, это количество умножается на 10. У тебя есть доступ к множеству годных перспектив — много людей скачивают твой продукт и взаимодействуют с тобой, но тебе нужно прорваться через чумовое количество лидов, чтобы приблизиться к единственной продаже.

Это процесс имеет катастрофические последствия домино. Команда деморализована, становится сложно привлечь инвестиции и нанять лучших профи. В свою очередь, это ограничивает собственные ресурсы, поэтому становится невозможным существенно вложиться в продукт или распространение. Динамика движения это вопрос жизни и смерти для стартапов, и трудности распространения еще на ранних этапах почти всегда обрекают тебя на верную смерть.

Неправильные критерии полезности

Ну хорошо, рынок плох, но другие компании, занимающиеся инструментами средств разработки, все равно продают в больших объемах. Почему не RethinkDB?

Хотя мы ничего не могли сделать с динамикой рынка (кроме того, чтобы заняться чем-то другим), решения по продуктам полностью зависели от нас. Мы хотели построить элегантный, надежный и красивый продукт, поэтому мы оптимизировались под следующие метрики.

• Правильность. Мы давали очень высокие гарантии и выполняли их неукоснительно.
• Простота интерфейса. Мы взяли на себя большинство трудностей реализации, чтобы не усложнять жизнь разработчикам.
• Единообразие. Мы делали все, начиная от языка запросов, клиентских драйверов, конфигурации кластера, документации, до рекламного текста на обложке как можно более единообразным.

Если это кажется знакомыми, мы взяли эти качества из работы хуже это лучше. Оказалось, что корректность, простота интерфейса, и последовательность являются неправильными критериями полезности для большинства пользователей. Большинство пользователей хотели вместо этого эти три опции:

• Своевременность. Они хотели, чтоб продукт действительно функционировал, когда он им был нужен, не три года спустя.
• Ощутимая скорость. Люди хотели, чтобы RethinkDB был быстрым под теми нагрузками, которые пользователи фактически давали, а не только под предлагаемыми, которые приближены к «реальности». Например, они пишут быстрые скрипты, чтобы замерить, сколько нужно, чтобы вставить десять тысяч документов без чтения. MongoDB освоил эти нагрузки превосходно, пока мы боролись в уже проигранном бою обучения рынка.
• Варианты использования. Мы намеревались сделать хорошую систему базы данных, но пользователи хотели хороший способ сделать X (например, хороший способ сохранять JSON документы из hapi, хороший способ сохранять и анализировать логи, хороший способ создавать отчеты и т.д.).

Это не значит, что мы не старались запускаться быстро, сделать RethinkDB быстрым и выстроить экосистему вокруг него, чтобы делать полезную работу легко. Мы это делали. Но правильное, простое и единообразное программное обеспечение требует много времени. Это обусловило наше отставание от рынка на три года.

К тому времени, как мы почувствовали, что RethinkDB удовлетворяет поставленным требованиям, мы были достаточно уверены, чтобы рекомендовать использовать его в производстве, почти каждый спрашивал «насколько RethinkDB отличается от MongoDB»? Мы упорно работали над тем, чтобы объяснить, почему правильность, простота и системность/совместимость так важны, но в конце концов эти факторы не были критериями полезности, которые имели значение для большинства пользователей.

Если быть честным, это больно. Очень больно. Это было непостижимо для нас, почему люди выбирали систему, которая едва ли делает вещь, которую она должна делать (хранить данные), блокирует ядро, разбрасывается ошибками, функционирует как один узел, который перестает работать при сегментировании, имеет едва работающую систему сегментирования, несмотря на то, что это одна из ключевых фишек продукта, не гарантирует корректную работу и вываливает мешанину интерфейсов, в которых нет системности или единства видения.

Каждый раз, когда MongoDB выкатывал релиз и люди поздравляли их с улучшениями, я чувствовал прилив негодования. Они сказали, что исправят BKL, но на самом деле они опустили уровень глубины детализации от базы данных до коллекции. Они добавили больше операций, но вместо модульного интерфейса который сочетался бы с системой, они просто прикрутили разовые команды. Им бы улучшить сегментирование, но было очевидно, что они не хотели или не могли дать даже элементарные гарантии о согласованности данных.

Но со временем я научился ценить мудрость толпы. MongoDB превратили обычных разработчиков в героев, когда людям это было нужно, не годы спустя. Это сделало хранилище данных быстрым и позволило людям быстро поставлять продукты. И со временем, MongoDB вырос. Одна за другой, они исправили проблемы с архитектурой, и теперь это отличный продукт. Может, он не такой красивый, как нам хотелось бы, но он делает свою работу и делает ее хорошо.

Когда в середине 2014 года стало ясно, что мы не можем конкурировать, мы упорно работали над тем, чтобы отличаться от MongoDB. Мы нашли очень элегантный способ добавить уведомления в реальном времени, надеясь, что это позволит разработчикам создать поколение приложений, которые они не могли делать раньше. Но этого не было достаточно. Неожиданно для себя мы оказались конкурентами с Meteor и Firebase, компаниями, которые посвящали себя решению насущных проблем, о которых еще несколько лет не будет даже речи. И снова мы отставали на три года от рынка, снова мы обнаружили, что не способны конкурировать.

Что насчет облака?

Несколько человек предположили, что нам нужно было сделать облачный сервис. У нас на самом деле было один такой проект в разработке, поэтому это интересная тема, которую я хотел бы охватить.

Очевидной проблемой маленькой компании, разрабатывающей облачный сервис, является то, что у нее включается распространенный провальный режим — расфокусировка. Разрабатывать, распространять и обеспечивать функционирование мультиарендного облачного сервиса сложно. Все это требует неординарного опыта и ресурсов, поэтому если ты действительно вступаешь на эту дорожку, можно обнаружить, что ты управляешь сразу двумя стартапами. Но мы были перед угрозой существования, и у нас быстро заканчивались варианты действий, поэтому мы дали и этой идее шанс выстрелить. Давайте на момент предположим, что у нас бы получилось протолкнуть эту идею.

Наши рассуждения заключались в следующем. Предложение по базе данных могло означать одну из трех вещей: управляемый хостинг, база данных как услуга (DBaaS), или расширенная платформа как услуга (PaaS). Вернемся к тому маркетинговому анализу, написанному на коленке, где мы использовали параметр $200тыс./сотрудника в годовой выручке, то самое правило, которое мы использовали ранее:

	Управляемый хостинг	DBaaS	PaaS
Компания	Compose.io, mLab	FaunaDB	Parse, Firebase, Meteor
Сотрудники	~30	~30	~30
Доход	< $10M	< $10M	< $10M

Эти рынки малы, даже меньше, чем сам рынок баз данных. Может, стоило предпочесть один из них другим?

Управляемый хостинг в основном заключается в ведении базы данных на AWS за людей. Альтернативой использованию этих сервисов является создание базы данных на AWS самостоятельно. Это боль, но это не настолько сложно. Поэтому есть жесткое ограничение, как оценивать услуги управляемого хостинга. Учитывая то, что Compose.io и mLab предлагают MongoDB, который имеет на порядок больше клиентов, чем RethinkDB, мы предположили, что предложение управляемого хостинга не окажет особенного эффекта.

База данных как услуга — это более сложная версия управляемого хостинга, например, DBaaS сервис полностью отделяет управление узлами от пользователя. Ты просто делаешь запросы, и система обрабатывает их. Ты просто не знаешь ничего о том, сколько узлов запускается под капотом. Этот бизнес очень не прост: частично потому что DBaaS компаниям приходится конкурировать с гигантами (такими, как DynamoDB и DocumentDB) и частично потому что, клиенты не расположены к полной передаче управления данными стартапу в то время, как есть столько много других вариантов и альтернатив (а вы знаете кого-то, кто пользуется услугами DBaaS от стартапа?) Итак, предложение по DBaaS осталось позади.

Последним вариантом было разработать расширенную платформу как сервис. Мы думали, что это было многообещающее направление, потому что в нем у нас было огромное техническое преимущество. Firebase и Meteor пришлось выстроить прикладную логику в реальном времени поверх MongoDB, что существенно ограничивает возможности запросов в реальном времени и производительность на нужном уровне. С другой стороны, мы могли контролировать стэк на всем пути, поэтому мы могли предложить значительные преимущества, которые были не доступны Firebase и Meteor.

Поэтому мы разработали Horizon и начали работать на Horizon Cloud, с помощью которого у пользователей появилась бы возможность развертывать и масштабировать приложения RethinkDB/Horizon. Разработки трех больших проектов (RethinkDB, Horizon, и Horizon Cloud) с очень небольшой командой в конце концов настигли нас, и нам так и не удалось выпустить облачный сервис до того, как у нас кончились деньги. Тем не менее, респект команде разработчиков. Они были очень, очень близки.

Мета вопросы

Есть еще один уровень анализа основных причин, который мы можем отметить. Почему мы выбрали плохой рынок и оптимизировали продукт по неправильным метрикам?

Когда я был ребенком, хотел сделать собственное радио. Я сделал коробку из фанеры, выбросил изнутри какой-то металлический мусор и соединил коробку с шнуром питания. У меня дома были книги по электронике, но мне казалось, что они мне не нужны, у меня была непоколебимая вера, что я могу сделать это сам. В конце концов я построил работающий приемник, но мне потребовалось несколько лет, чтоб наконец понять, что мне нужно выучить основы электроники.

Ранний RethinkDB был немного таким. У нас не было интуиции на продукты и рынки, поэтому мы просто были движимы идеей построить компанию, не понимая на самом деле, что мы делаем. Более того, у нас был невероятный оптимистический настрой. Так же как врачи знают, что подарки от фармацевтических компаний обладают эффектом пристрастия на других врачей, но они все равно верят, что они не подвержены этому эффекту, так и мы думали, что нам ни по чем экономические законы и математическая составляющая ведения бизнеса. И, конечно, в конечном итоге математика и подкосила нас.

Могли ли мы сделать что-то, чтобы избежать этих ошибок? Не больше, чем я мог сделать в детстве с тем радио. Мы не осознавали, что были некомпетентны, и это заняло годы, чтобы эта некомпетентность стала осознанной.

Несколько человек отметили, что мы могли бы улучшить свое положение, если бы построили опытную команду, готовую выйти на рынок. Это 100% правда, но время на наше личное развитие никак не согласовывалось с нуждами компании. Первоначально мы не знали, что нам нужны были экспертные знания и опыт выхода на рынок, поэтому мы не стремились к тому, чтобы включить это в необходимый список вещей для формирования команды. К тому времени, как мы выработали тип мышления, который хорошо соотносился с реальностью, мы оказались на мели на жестком рынке, полном достойных конкурентов и продуктом, который отставал на три года. К тому времени, даже самая лучшая приспособленная к рынку команда в мире не смогла бы спасти нас.

Мысли на прощание

Многие люди возмущаются по поводу рынка инструментов для разработчиков. Разработчики любят делать инструменты для разработчиков, поэтому они очень хотят, чтоб компании, делающие инструменты для разработчиков, процветали.

Не хотел бы опустить этот рынок совсем — частично потому что не хочу обобщать исходя из одного опыта, и частично потому что не люблю говорить «это невозможно сделать» и частично потому что есть довольно много исключений. GitHub, MongoDB, и Docker создали внушительные компании. У GitLab и Unity, кажется, дела тоже идут хорошо.

Если вы действительно намереваетесь основать компанию по разработке инструментов, действуйте осторожно. Рынок полон хорошими альтернативами. Ожидания пользователей высоки, а цены низки. Тщательно обдумайте цену, которую вы предлагаете клиенту. Помните — желание, чтоб мир был таким, вам хочется, не делает его таким.

В 2009 мы рассказывали о первоначальной идее RethinkDB (у нас еще не было ПО) аудитории инвесторов на демонстрационном дне YCombinator. Мы закончили доклад со слайдами тремя ключевыми пунктами. «Если вы сможете запомнить только три вещи о RethinkDB», — мы сказали, «запомните эти». Это сработало. Люди не запомнили ничего из выступления, но они запомнили три пункта в конце.

Закончу тремя ключевыми моментами, которые стоит помнить. Если что и стоит запомнить из этой статьи, то стоит запомнить вот это:

• Выберите большой рынок, но делайте для конкретных пользователей.
• Учитесь распознавать таланты, которых у вас не хватает, потом пашите, чтоб заполучить их в команду.
• Читайте The Economist в обязательном порядке. Это сделает вас лучше быстрее.

[1] Не вчитывайтесь слишком в эти цифры. Я дал совсем приблизительную оценку, но все же должен был дать общее представление о стоимости этих ошибок.

[2] Кстати, распознать людей, компетентных в бизнесе, не имея хорошей деловой интуиции, так же сложно, как и распознать хороших инженеров, не имея интуиции в инженерии.

Let's block ads! (Why?)