Cześć!

Kiedyś dosyć popularny był żart:

• Co filozof słyszy w pracy najczęściej?
• Poproszę Big Maca z Colą i podwójne frytki.

Podobny suchar można by było opowiedzieć o programiście Open Source, gdyby nie to, że jest programistą i swoją “pracę” w Open Source robi po godzinach. Swego czasu często otrzymywałem pytania - ile dostaję za pracę w Marten. Pytający zwykle był zaskoczony, że jest to praca za dziękuję. No prawie, jakiś czas temu dałem możliwość wsparcia mojej działalności na GitHub Sponsors (https://github.com/sponsors/oskardudycz/). Mam aktualnie pięciu wspaniałych wspierających, dzięki nim mogę sobie kupić co miesiąc Whiskey. No ale umówmy się - kredytu na mieszkanie tym nie spłacę.

No dobrze, ale są przecież projekty Open Source, które na siebie zarabiają. EventStoreDB jest takim projektem. Postanowiłem, że dam Wam trochę “insiderskich” informacji na ten temat.

Model biznesowy EventStoreDB nie jest aktualnie specjalnie odkrywczy. Pokrywa się on z tym, jak większość projektówy Open Source’owych sobie z tym radzi.

Support

Jest to obecnie główne źródło dochodu. Jest on podzielony na kilka progów (https://www.eventstore.com/support#support-plans) głównie w zależności od tego jak szybka ma być uzyskana odpowiedź/rozwiązanie problemu. Dodatkowo płacący dostają dostęp do narzędzi takich jak rozbudowane bardziej UI, narzędzie konsolowe do zarządzania Event Store (np. łatwiejsze backupowanie). To co tutaj jest ważne do podkreślenia to to, że nie jest to licencja na oprogramowanie. Każdy może sobie używać EventStoreDB komercyjnie bez konieczności płacenia. Dopiero jak chce mieć wsparcie to może za to zapłacić.

Nie jest to w pełni typowe podejście w Open Source. To o czym nalęzy pamiętać, że Open Source wcale nie znaczy, że użycie produkcyjne może być darmowe. Warto patrzeć na licencję, bo samo Open Source znaczy tylko (i aż), że ma się pełen wgląd do kodów źródłowych. Nie zawsze to znaczy jednak, że same oprogramowanie można używać za darmo. Warto pamiętać o tym rozróżnie niu FOSS (Free Open Source Software) jest to oprogramowanie darmowe - OSS (Open Source Software) nie musi tego oznaczać.

No ale wracając do supportu. To co mnie zaskoczyło jest obecność Supportu na spotkaniach programistycznych. Codzienne spotkanie zaczyna się zawsze od przeglądu zgłoszeń. Sprawdzane są te, które muszą mieć od razu odpowiedź, ewentualnie te, które muszą mieć jakąś głębszą analizę od zespołu programistycznego. Na początku byłem zaskoczony, ale potem mi się spodobało to, że faktycznie support pracuje ściśle i blisko z programistami. Dodatkowo oczywiście są “zmianówki” na siedzenie na supporcie w zespole programistycznym.

Czy support jest dobrym źródłem dochodu? Przyzwoitym. Czy skalowalnym? Względnie. Wiadomo, jedni klienci zgłaszają więcej, drudzy mniej i jakoś to się bilansuje. O ile produkty jest stabilny i nie ma w nim dużo bugów, to nie powinno to destabilizować pracy zespołu programistycznego.

Consulting/Szkolenia

Event Store oferuje też consulting i szkolenia z Event Sourcing. Szkolenia są zarówno otwarte (https://training.eventstore.com/w/eu/upcoming/) jak i zamknięte. Klient może zgłosić się i dostarczyć dopasowane do jego potrzeb szkolenie (forma, materiał, itd.). Może też zamówić wsparcie i konsultacje w rozwiązaniu konkretnego problemu.

W Event Store ta forma jest jako marginalne źródło przychodu. W sensie te rzeczy nie są robione głównie po to by na tym zarabiać, ale raczej, żeby dać konkretnemu klientowi wsparcie jakie potrzebuje. Dlaczego? Bo taka forma się nie skaluje. Do szkoleń trzeba się przygotować (szczególnie tych zamkniętych, itd.). Same warsztay consulting też polega na skupieniu przez kilka dni na konkretnym kliencie. To jest jak najbardziej dobre, ale ta wiedza zostaje tylko u jednego klienta. Dodatkowo, żeby więcej na szkoleniach zarabiać to by trzeba było zatrudnić więcej konsultantów. Niektóre firmy w tą idą, ale tutaj nie chodzi o sprzedawanie konsultingu tylko o rozwój produktu.

Dlatego priorytetem dla m.in. mojej pracy jest przygotowanie wystarczająco dobrego materiału (dokumentacja, blogi, sample, itd.), żeby dać odpowedź i wsparcie większej liczbie klientów.

Do tego samego doszli chłopaki z Identity Server zakładając firmę Duende. Fajnie o tym opowiedzieli w podcast DotnetRocks https://dotnetrocks.com/?show=1722 (druga połowa).

Cloud

Ostatnio głośna była historia “wojenki” między Elastic a AWS (do poczytania https://github.com/oskardudycz/ArchitectureWeekly#elasticsearch-licence-change). Wcześniej podobne chwile przeżywał Redis. TLDR - dostawcy Cloud (AWS, Microsoft, Google, itd.) korzystają z nierestrykcyjnych licencji produktów FOSS i oferują je jako płatne usługi. MongoDB odniosło jednak sukces w tej nierównej walce. Oferują oni zarządzaną przez nich usługę chmurową. Umożliwiają odpalenie tej usługi na wszystkich trzech najpopularniejszych chmurach. Dzięki temu klient może zmniejszyć koszty obsługi (nie zatrudniać tylu swoich adminów) jak i zostawić zarządzanie takimi drażliwymi tematami jak backupy, bezpieczeństwo producentom bazy danych. Fakt, że można to zainstalować na wybranej chmurze ułatwia integrację z usługami. Czy w pewnym momencie dostawcy chmurowi nie wymyślą swojej alternatywy, która i tak zje produkt? Ciężko powiedzieć. Fakt, że zarabiają pośrednio, może ich zniechęcić do stawiania wysokiego priorytetu na robienie własnych alternatyw. De facto MongoDB jest re-sellerem chmur na których instalują ją klienci. AWS wymyśliło swoją alternatywę - DocumentDB (https://aws.amazon.com/documentdb/), ale MongoDB i tak sobie radzi, więc jest nadzieja.

…jest nadzieja dla EventStoreDB, bo właśnie taki sam model został tutaj obrany. Cloud już działa (https://developers.eventstore.com/cloud/intro/), klienci już używają go na produkcji. Póki co jest to produkt nowy, więc jest jego jeszcze mały udział w budżecie firmy. Docelowo jednak ma zostać głównym modelem. Dlaczego? Bo jest najbardziej skalowalny. Zarówno finansowo, jak i pod względem liczby osób potrzebnych do obsługi jak i też obciążenia zespołu programistycznego. Jeżeli Event Store sam może konfigurować serwery to (w teorii) będzie to robił lepiej niż klienci. W każdym razie powinno być mniej klasycznych i podstawowych błędów popełnianych przy konfiguracji. Dzięki czemu zespół programistyczny będzie mniej obciążony supportem z dziwnymi Edge Case. Diagnostyka też będzie łatwiejsza (ze względu na ujednolicony dostęp do logów, metryk itd.).

Taka w każdym razie jest idea.

Co o tym sądzisz? Jeśli ta tematyka Cię zainteresowała. Chcesz więcej takich “insiderskich” maili - daj znać!

Pozdrawiam Oskar

p.s. kolejny tydzień kolejny wpis na blogu. Tym razem zdradzam, że bazy relacyjne działają na zasadzie Event Sourcingu - https://event-driven.io/en/relational_databases_are_event_stores/. p.s.2 Zachęcam też, do kolejnego wydania Architecture Weekly https://github.com/oskardudycz/ArchitectureWeekly#8th-february-2021. Jest tam m.in. link do dawno nie widzianego na konferencjach Grega Younga i repo z beczką z JavaScript (zdaje się, że tego nigdy mało).