RethinkDB: почему мы закрылись

Автор оригинала: Slava Akhmechet
  • Перевод
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] Кстати, распознать людей, компетентных в бизнесе, не имея хорошей деловой интуиции, так же сложно, как и распознать хороших инженеров, не имея интуиции в инженерии.
Поделиться публикацией

Комментарии 45

    +6
    Во время подготовки к участию в подкасте DevZen мы обсуждали эту статью. Я решил опубликовать ее перевод, чтобы больше людей могло ознакомиться с ней.

    По роду деятельности меня очень интересуют причины, по которым компании могут умирать :-).
      +4
      Первая половина статьи просто поражает. Описывается мышление натурально кодера или академика. «Правильность и единообразие» блин. Как с таким мышлением у них вообще получилось что-то запустить? С другой стороны, это внушает определенный оптимизм — даже если во главе компании стоят идеалистичные красноглазики типа нас с тобой, нам все равно могут отсыпать десяток лямов для прокорма по 200к в год других красноглазиков.
        0
        Придти на рынок БД, это очень долго и дорого. Достаточно вспомнить, что 10 лет назад Postgresql уступал MySql по объемам использования, хотя второй уже был куплен Oracle и оставался без развития.
        Люди выбирая, где и как хранить данные, хотят быть уверены, что через 2-3 года база данных не нагнется и поддержка не прекратится, тем более это именно те, кто может платить деньги. До этого, люди проверяют и естественно никто не будет платить деньги за проверку.
          0
          Разве? Если база данных решает хорошо конкретную задачу, то она пользуется спросом. Пример ClickHouse, Tarantool и куча коммерческих форков Postgres заточенных под конкретные нужды.
            +1
            Tarantool

            Если знаете, расскажите кто использует Tarantool, кроме mail.ru (собственно самих разработчиков)? Правда интересно узнать, а на оф. сайте не нашел такой информации.
              –1
              Всё там есть
                0
                Мда, хоть бы ссылку оставили. Это?
                  0
                  Ну, я не знаю. На самом видном месте tarantool.io/ru, нужно лишь прокрутить немного вниз.
                    +3
                    Да, нашел, спасибо. Просто страница так масштабируется, что не понял, что ее можно скроллить вниз.
                +1
                Из известных, Tarantool юзает Yota, например, но, только, для узкой задачи «сбоку».
                  0
                  Badoo, Avito, Мегафон, Yota, Билайн, Альфабанк, Qiwi, Аэрофлот и т.д.
                    0
                    Благодарю
                  +1
                  ClickHouse, Tarantool — просто волна хайпа, которая уже утихает и пользователи начинают видеть ограничения.
                  Что касается «форков заточенных под конкретные нужды»… вовсе не проблема сделать узкоспециализированную БД. Только вот работать с десятком БД и их интеграцией никто особо не хочет, все хотят одну (две) универсальную.
                    0
                    Хотеть не вредно, но что то не получается
                    0
                    она пользуется спросом.

                    Я бы сюда добавил ещё пункт: «если использование нестандартной базы данных можно добавить в резюме, то рациональные сотрудники могут попытаться максимизировать свою будущую заработную плату путём изучения нестандартных БД за счёт работодателя»

                      0
                      У нас это невозможно, потому что есть список разрешённых технологий, а когда не хватает, то нужно получать разрешение у архитектора. Если 3 вас такое возможно, то у вас бардак.
                        0
                        У нас это невозможно <...> нужно получать разрешение у архитектора.

                        Правильно говорить не "невозможно", а "затруднено" или "сложно"/"сложнее". Так как Вы сами только что написали, что это возможно, ну если получится убедить архитектора.


                        На деле тут много тонкостей. Если сам архитектор рационален и планирует сменить работу в течении года, то он может просто сам захотеть использовать новые технологии. Я думаю, вы же не на Коболе пишете, а на чем-то по новее. Значит, продвинуть получилось.


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


                        Кстати, у Вас статьи про Go. Видимо, для каких-то проектов Вы выбрали его, а не С. Значит, Вы поступили рационально и добавили строчку в резюме, вместо того, чтобы пользоваться проверенными временем технологиями.

                          0

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


                          вместо того, чтобы пользоваться проверенными временем технологиями.

                          Go входит в список допустимых технологий. И почему оно не проверенное?

                            0
                            Как ваш бизнес еще не загнулся

                            Какой "ваш бизнес"? Вы пытаетесь так аккуратно перейти на личности, чтобы проигнорировать аргументы про "эгоистичный рационализм"?


                            Go входит в список допустимых технологий.
                            Именно невозможно

                            Определитесь, пожалуйста, можно ли добавить новую технологию в "список допустимых технологий" или нет? Если да, то перестаньте говорить "невозможно". Если нет, то как туда добавили тот же популярный Go?


                            P. S> И только не говорите мне, что добавление языка Go в Ваше резюме лично Вам не выгодно.

                              +1
                              Вы пытаетесь так аккуратно перейти на личности, чтобы проигнорировать аргументы про "эгоистичный рационализм"?

                              Ни в коем случае. А вот вы пытаетесь подменять понятия. Вспомните с чего все началось:


                              Я бы сюда добавил ещё пункт: «если использование нестандартной базы данных можно добавить в резюме, то рациональные сотрудники могут попытаться максимизировать свою будущую заработную плату путём изучения нестандартных БД за счёт работодателя»

                              Определитесь, пожалуйста, можно ли добавить новую технологию в "список допустимых технологий" или нет?

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

                            0
                            >Еще раз: я говорил, что рациональный человек будет максимизировать свою прибыль, а не прибыль компании.

                            Пожалуйста, не используйте слово «рациональный» в значении «эгоистичный и глупый». Не говоря уже о том, что у двух рациональных людей могут быть противоположные цели или же противоположные способы их достижения.
                            0

                            Ха! Да архитектор первый же прыгает на каждый баззворд! Да и уболтать его обычно не проблема

                              0

                              Вспомни работу в НИЦ ЭТУ и то, какой геморрой протолкнуть свою БД в военных заказах.

                      +3
                      рынок инструментов с открытым исходным кодом — это один из худших рынков, на котором кто-либо может оказаться

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

                      Какая-то плохо скрываемая обида на опенсорс сквозит. Мол мы сделали хороший продукт, но вот пользователи у нас плохие оказались — платить не захотели.
                        +2
                        Мол мы сделали хороший продукт, но вот пользователи у нас плохие оказались — платить не захотели
                        Но ведь так и получилось? Сами пользователи не плохие, при этом, в целом это нормальная ситуация. Если взглянуть на тех, кто зарабатывает на опенсорсе, они оборачивают его в саппорт/платформу/дополнительные модули под закрытой лицензией.
                        В итоге в свободном доступе находится только какой-то кор, который сам по себе трудно монетизировать и который использовать неудобно и/или он существенно ограничен в своих возможностях. Ну и все, кого это не устраивает, вынуждены платить.
                          +1
                          Если взглянуть на тех, кто зарабатывает на опенсорсе, они оборачивают его в саппорт/платформу/дополнительные модули под закрытой лицензией.

                          Не совсем ясно, что мешало сделать так в случае RethinkDB? Из статьи я понял, что банально не успели, потому что писали код и думали, что монетизация придет сама собой как-то?
                            +1
                            писали код и думали, что монетизация придет сама собой как-то?
                            Не, у них вполне был план монетизации на облаке, но не успели, да:
                            Разработки трех больших проектов (RethinkDB, Horizon, и Horizon Cloud) с очень небольшой командой в конце концов настигли нас, и нам так и не удалось выпустить облачный сервис до того, как у нас кончились деньги
                        +3
                        Rethink была в свое время великолепной. Reql до сих пор выглядит очень мощным. Мы около пяти лет используем эту базу данных в продакшене на кластере из нескольких машин. В те годы выбор казался верным, монга не было такой вылизанной как сейчас. Поставили не на ту лошадь :)
                          +1
                          Стоит указать что это перевод поста от Jan 18, 2017. В настоящий момент проект живет и присоеденился к The Linux Foundation.
                            0
                            Я бы сказал, трепыхается. Последние релиз был в 2017. А жаль. Мы много лет использовали Rethinkdb.
                            0
                            Она умерла навсегда? На Гитхаб вроде-бы что-то движется… Забыть, или пользоваться и надеяться?
                              0
                              Если какая-то команда под крыло возьмёт, то может и будет двигаться. На текущий момент ключевые разработчики не занимаются проектом. Факт перехода под Linux Foundation ничего не дал, т.к. нету кор команды, чтоб двигать разработку.
                              0

                              Жаль конечно. Я её не использовал в проде, но выглядела бд интересно.


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


                              Разве что делать расширенную функциональность за деньги.

                                0
                                Мне кажется, за все эти консультации платные никто платить особо не будет

                                Есть же консалтинговые компании, которые этим занимаются.

                                  0
                                  Посмотрите на Postgres Pro
                                  — расширенная функциональность за деньги
                                  — платные консультации (и весьма толковые)
                                  — курсы
                                  — сертифицированные государственными органами версии для специализированного применения

                                  Прекрасно существуют.
                                    +1
                                    — сертифицированные государственными органами версии для специализированного применения
                                    вот это, в наших условиях, надо ставить на первое место.
                                    0

                                    Я так понимаю, на консультациях можно прожить если у тебя цель работать и получать как норм девелопер, а пацаны тут хотели нюхать килограммы кокса на яхтах.

                                      0
                                      Но ведь в этом и смысл бизнеса. Иначе можно было бы просто работать девелопером.
                                        0
                                        Рядовым разработчикам кокс бы не достался, а топам бы да. Есть же пример MySQL. Микаэль Видениус в 2008, при продаже Sun Microsystems, заработал 16,6 миллиона евро. Из недавнего Microsoft купила Citus Data, для развития PostgreSQL в Azure.
                                        0
                                        Мне кажется, за все эти консультации платные никто платить особо не будет — взаимодействуют ведь с по программисты, и они скорее самостоятельно попытаются загуглить и решить проблему, чем консультанта нанимать.

                                        Взаимодействуют менеджеры, которым нужно купить «решение», во многих западных компаниях важно, чтобы за решениям стояла какая-то компания, которая будет это решение поддерживать. Например, у нас Postgres живёт не сам по себе, а в виде EnterpriseDB. От обычного Postgres'а ничем особо не отличается, но позволяет скидывать все вопросы на консультантов, которые могут прийти 8/5, а свои DBA в это время способны только зайти на сервер и открыть конфиг, без понимания что там смотреть.
                                        +1
                                        Очень интересно было почитать статью с позиции людей, которые разработали продукт и который умер на их глазах. Несколько грустно это осознавать, но тем не менее.
                                        Поинты «правильно & удобно» выглядят достаточно хорошо, для меня, как для простого разработчика, но да, думаю, этого недостаточно для того, чтобы оставаться конкурентноспособным на рынке.
                                        Статья в принципе заставляет задуматься о том, почему я использую тот или иной продукт, созданный для разработчиков (например предпочитаю IntelliJ, а не бесплатные NetBeans/Eclipse), и каким образом функционирует рынок.
                                        Всё это заставляет пересмотреть свои взгляды на разработку, и переосмыслить почему один продукт становится сверхпопулярным, а другой — пожив какое-то время, умирает.
                                          0
                                          Впервые слышу о такой БД,
                                          из статьи так и не понял две вещи:
                                          1. Чем ваша бд лучше конкурентов и почему её следовало использовать;
                                          2. Какие задачи привели к созданию этой бд.
                                            0

                                            «Мы все делали по Фаулеру и называли переменные красивыми именами».

                                            0
                                            Не вешать нос, гардемарины. Судя по языку статьи вы там совсем прокисли, качественнее надо было делать
                                              0
                                              Прошло 10 лет с момента 1-го релиза, компания, стоявшая за это СУБД успела закрыться, а я услышал про неё в первый раз.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое