W , opisałem historię powstania Veliam oraz decyzję o jego dystrybucji w systemie SaaS. W tym artykule opowiem o tym, co zostało zrobione, aby produkt stał się nie lokalnym, a publicznym. O tym, jak rozpoczęliśmy dystrybucję i z jakimi problemami się spotkaliśmy.
Planowanie
Bieżąca część serwerowa dla użytkowników opierała się na systemie Linux. W niemal każdej organizacji znajdują się serwery Windows, czego nie można powiedzieć o Linuxie. Główną siłą Veliam jest zdalne łączenie się z serwerami i urządzeniami sieciowymi za NAT. Jednak ta funkcjonalność była bardzo ściśle powiązana z tym, że routerem musiał być koniecznie MikroTik. To zdecydowanie wielu by nie satysfakcjonowało. Na początku myślałem o dodaniu wsparcia dla routerów najbardziej popularnych producentów. Jednak zdawałem sobie sprawę, że to niekończący się wyścig z rozszerzeniem listy obsługiwanych firm. Co więcej, te, które już są obsługiwane, mogą mieć z modelu na model różny zestaw poleceń do zmiany reguł NAT. Jedynym rozwiązaniem tej sytuacji wydawał się VPN.
Ponieważ zdecydowaliśmy się na dystrybucję produktu, ale nie jako open source, nie mogliśmy do niego włączyć różnych bibliotek z otwartymi licencjami typu GPL. To w ogóle jest osobny temat; po podjęciu decyzji o sprzedaży produktu musieliśmy przemyśleć połowę bibliotek, ponieważ były one objęte licencją GPL. Kiedy pisaliśmy to dla siebie, było to w porządku. Ale do dystrybucji się nie nadaje. Pierwsze VPN, które przychodzi na myśl, to OpenVPN. Ale on jest na GPL. Była też opcja użycia japońskiego SoftEther VPN. Jego licencja pozwalała na włączenie go do naszego produktu. Po kilku dniach różnych testów, jak zintegrować go w taki sposób, aby użytkownik w ogóle niczego nie musiał konfigurować i nie musiał wiedzieć o SoftEther VPN, powstał prototyp. Wszystko było jak należy. Ale z jakiegoś powodu ta koncepcja wciąż nas niepokoiła i ostatecznie się od niej odstąpiliśmy. Oczywiście, zdecydowaliśmy się na to dopiero po wymyśleniu innej opcji. W końcu wszystko zrobiliśmy na zwykłych połączeniach TCP. Część połączeń działa przez koordynatora, część bezpośrednio za pomocą technologii Nat Hole Punching (NHP), która również była realizowana w Free Pascal. Muszę powiedzieć, że wcześniej w ogóle nie słyszałem o NHP. Nie przyszło mi do głowy, że można bezpośrednio połączyć dwa urządzenia sieciowe, które znajdują się za NAT. Przeczytałem temat, zrozumiałem zasady działania i zabrałem się do pisania. Zrealizowano zamysł; użytkownik łączy się jednym kliknięciem z odpowiednim urządzeniem za NAT przez RDP, SSH lub Winbox, bez wprowadzania haseł i konfiguracji VPN. A większość z tych połączeń przechodzi obok naszego koordynatora, co korzystnie wpływa na opóźnienie i koszty obsługi tych połączeń.
Migracja serwera z Linuxa na Windows
Było kilka problemów podczas przejścia na Windows. Pierwszy — wbudowany wmic w Windows nie pozwala na wykonywanie zapytań WQL. A w naszym systemie wszystko było już na nich oparte. Było też coś jeszcze, ale teraz nie pamiętam, dlaczego ostatecznie zrezygnowaliśmy z jego użycia. Możliwe, że różnice między wersjami Windows. A drugi problem — wielowątkowość. Nie znajdując dobrej zewnętrznej aplikacji z "dozwoloną" dla nas licencją, ponownie uruchomiłem IDE Lazarus. Napisałem potrzebne narzędzie. Na wejściu otrzymuję wymagany wykaz obiektów i jakie konkretne zapytania należy wykonać, a w odpowiedzi otrzymuję dane. I wszystko to w trybie wielowątkowym. Doskonale.
Po skonfigurowaniu pthreads dla PHP w Windows myślałem, że wszystko po prostu zacznie działać, ale się myliłem. Po pewnym czasie debugowania zrozumiałem, że pthreads wydaje się działać, ale w naszym systemie nie funkcjonował. Stało się jasne, że istnieje jakaś szczególna cecha działania pthreads w Windows. I tak właśnie było. Przeczytałem dokumentację i zobaczyłem, że dla Windows liczba wątków jest ograniczona, a jeśli dobrze pamiętam, to niejawnie. To stało się problemem. Ponieważ gdy zacząłem zmniejszać liczbę wątków, przy których aplikacja działała, praca była bardzo wolna. Znowu otworzyłem IDE i dodałem funkcjonalność do wielowątkowej pingu dla obiektów. No i przy okazji również skanowanie portów. Właściwie po tym, potrzeba używania pthreads dla PHP zniknęła i przestał być używany. Następnie do tej aplikacji dodano jeszcze kilka funkcji i działa ona do dzisiaj. Po tym zbudowano instalator dla Windows, który zawierał Apache, PHP, MariaDB, samo PHP oraz zestaw narzędzi do interakcji z systemem, napisanych w Free Pascal. Jeżeli chodzi o instalator, myślałem, że ten temat szybko rozwiążę, ponieważ to bardzo powszechne i potrzebne niemal w każdym oprogramowaniu. Albo niewłaściwie szukałem, albo coś innego. Ale ciągle natrafiałem na produkty, które były albo niewystarczająco elastyczne, albo drogie i przy tym też sztywne. Mimo to, znalazłem darmowy instalator, który pozwalał uwzględnić wszystkie wymagania. To InnoSetup. Piszę o tym tutaj, ponieważ musiałem poszukać, być może komuś zaoszczędzę czas.
Rezygnacja z wtyczki na rzecz własnego klienta
Wcześniej pisałem, że częścią kliencką była przeglądarka z „wtyczką”. Były czasy, kiedy to Chrome się aktualizował i układ się nieco psuł, to Windows się aktualizował i custom uri scheme znikały. Bardzo nie chciałem mieć tego rodzaju niespodzianek w publicznej wersji produktu. Przy tym, custom uri zaczynały znikać po każdej aktualizacji Windows. Microsoft po prostu usuwał wszystkie nie swoje gałęzie w odpowiedniej sekcji. Również Google Chrome teraz nie pozwala zapamiętać wyboru otwierania aplikacji z custom uri i zadaje to pytanie przy każdym kliknięciu na obiekt monitoringu. Generalnie potrzebna była normalna interakcja z lokalnym systemem użytkownika, co przeglądarka nie zapewniała. Najprostszą opcją w tej sytuacji wydaje się stworzenie własnej przeglądarki, jak wielu teraz robi przez Electron. Jednak wiele rzeczy było już napisanych w Free Pascal, w tym część serwerowa, dlatego zdecydowaliśmy się również zrealizować klienta w tym samym języku, zamiast rozmnażać zbiory. Tak powstał klient z Chromium na pokładzie. Po tym zaczął on nabierać różnych powiązań.
Wydanie
W końcu wybraliśmy nazwę dla systemu. Ciągle przeszukiwaliśmy różne opcje podczas przekształcania z lokalnej wersji na SaaS. Ponieważ pierwotnie planowaliśmy wejście nie tylko na rynek krajowy, głównym kryterium wyboru nazwy była dostępność nie zajętej lub niezbyt drogiej domeny w strefie ".com". Niektóre funkcje/moduły jeszcze nie zostały przeniesione z lokalnej wersji do Veliam, ale postanowiliśmy, że wypuścimy produkt z aktualną funkcjonalnością, a pozostałe elementy zrealizujemy już w aktualizacjach. W pierwszej wersji nie było HelpDesku, Veliam Connectora, nie można było zmieniać progów reakcji powiadomień i wiele innych. Kupiliśmy certyfikat podpisu kodu, podpisaliśmy część kliencką i serwerową. Napisaliśmy stronę produktu, rozpoczęliśmy procedury rejestracji oprogramowania, znaku towarowego itp. Generalnie jesteśmy gotowi do startu. Lekka euforia po wykonanej pracy i z tego, że być może ktoś korzysta z naszego produktu, chociaż w tej kwestii nie mieliśmy wątpliwości. I tu nagle stop. Partner powiedział, że bez powiadomień w komunikatorach nie możemy wyjść na rynek. Można obyć się bez wielu innych rzeczy, ale nie bez tego. Po krótkich sporach dodano integrację z Telegramem, która nam odpowiadała. Spośród wszystkich obecnych komunikatorów, to jedyny, który udostępnia swoje API za darmo i bez skomplikowanych procedur zgody. WhatsApp z kolei zachęca do kontaktowania się z dostawcami, którzy biorą niezłe pieniądze za korzystanie z ich usług, wszystkie nasze prośby o udostępnienie dostępu bez pośredników zostały zignorowane. A Viber… Nie wiem, kto teraz z tego korzysta, ponieważ spam i reklama są tam na poziomie szczytowym. Pod koniec grudnia, po serii testów wewnętrznych i testach wśród przyjaciół, otworzyliśmy rejestrację dla wszystkich i udostępniliśmy oprogramowanie do pobrania.
Początek rozpowszechnienia
Od samego początku wiedzieliśmy, że potrzebujemy niewielkiego strumienia użytkowników systemu, aby mogli oni testować produkt w trybie rzeczywistym i dać nam jakieś pierwsze opinie. Kilka zakupionych postów na VK przyniosło efekty. Pierwsze rejestracje zaczęły napływać.
Trzeba powiedzieć, że wejście na rynek bez znanego imienia i oferowanie funkcjonalności monitorowania bezagentowego, do którego trzeba wprowadzić konta swoich serwerów i stacji roboczych, jest bardzo trudne. Wiele osób się tym niepokoi. Od samego początku zdawaliśmy sobie sprawę, że będą z tym problemy i byliśmy na to przygotowani zarówno technicznie, jak i moralnie. Wszystkie połączenia zdalne, mimo że RDP i SSH są domyślnie szyfrowane, są dodatkowo szyfrowane przez naszego softu zgodnie z standardem AES. Wszystkie dane z lokalnych serwerów przesyłane są do chmury za pomocą HTTPS. Konta przechowywane są w postaci zaszyfrowanej. Klucze szyfrowania dla wszystkich podsystemów są indywidualne dla każdego klienta. Dla połączeń zdalnych używane są sesyjne klucze szyfrowania.
Wszystko, co możemy zrobić w tej sytuacji, aby ludzie czuli się spokojniej, to być maksymalnie otwartymi, pracować nad bezpieczeństwem i nieustannie odpowiadać na niepokojące ich pytania.
Dla wielu osób wygoda i funkcjonalność oprogramowania przeważają nad strachem, dlatego się rejestrują. Niektórzy w opublikowanych postach na VK pisali, że tego oprogramowania nie można używać, ponieważ zbiera hasła i w ogóle pochodzi od firmy bez nazwy. Należy powiedzieć, że takie zdanie nie było odosobnione. Wiele osób po prostu nie rozumie, że gdy instalują inny własnościowy soft na swoim serwerze, który działa jako usługa, ma pełne prawa w systemie i nie potrzebują konta, aby zrobić coś nielegalnego (oczywiste jest, że można zmienić użytkownika, z którego uruchamiana jest usługa, ale tutaj również można wprowadzić dowolne konto). W rzeczywistości obawy ludzi są zrozumiałe. Instalacja oprogramowania na serwerze jest czymś powszechnym, ale wprowadzanie danych konta jest już trochę przerażające i intymne, ponieważ połowa ludzi ma jedno hasło do wszystkich usług, a stworzenie oddzielnego konta nawet do testów jest leniwe. Jednak obecnie istnieje ogromna liczba usług, którym ludzie ufają w zakresie swoich danych logowania i nie tylko. I staramy się stać się jednymi z nich.
Wiele komentarzy sugerowało, że gdzieś to ukradliśmy. Trochę nas to zdziwiło. Cóż, to zdanie jednej osoby, ale takie komentarze pojawiały się w różnych publikacjach od różnych ludzi. Na początku nie wiedzieliśmy, jak na to zareagować. Czy smucić się tym, że niektórzy mają zdanie, że w Rosji nikt nie potrafi nic zrobić samodzielnie, a tylko ukraść, czy cieszyć się, że sądzono, iż coś można tylko ukraść.
Obecnie zakończyliśmy procedurę uzyskania certyfikatu EV Code Sign. Aby go uzyskać, trzeba przejść szereg kontroli i dostarczyć mnóstwo dokumentów dotyczących firmy, z których część musi być poświadczona przez prawnika. Uzyskanie certyfikatu EV Code Sign w warunkach pandemii to w ogóle osobny temat na artykuł. Procedura trwała miesiąc. I to był miesiąc pełen nie oczekiwania, ale ciągłych próśb o dodatkowe dokumenty. Może pandemia nie ma z tym związku, a wszystkim procedura trwała tak długo? Podzielcie się.
Niektórzy mówią, że nie będziemy korzystać, ponieważ nie mamy certyfikatu FSTEK. Muszę tłumaczyć, że nie możemy go uzyskać i nie będziemy, ponieważ aby uzyskać ten certyfikat, szyfrowanie musi być zgodne z GOST, a my planujemy rozpowszechnianie oprogramowania nie tylko w Rosji i używamy AES.
Wszystkie te komentarze wzbudzały pewną niepewność, czy to możliwe — promować produkt, w który trzeba wprowadzać konta, nie będąc jednocześnie na językach. Nawet biorąc pod uwagę, że wiedzieliśmy, że będą tacy, którzy odnoszą się do tego bardzo negatywnie. Po przekroczeniu liczby rejestracji tysiąc przestaliśmy o tym myśleć. Szczególnie po tym, jak oprócz negatywów tych, którzy nie próbowali produktu, zaczęły pojawiać się bardzo pozytywne opinie. Trzeba powiedzieć, że te pozytywne opinie są największym motywatorem do rozwoju produktu.
Dodanie funkcji zdalnego dostępu dla pracowników
Jednym z częstych zadań od klientów jest „dostarczenie Waniemu dostępu do jego komputera z domu”. Ustawialiśmy VPN na MikroTik i tworzyliśmy konta dla użytkowników. Ale to naprawdę problem. Użytkownicy nie są w stanie przeczytać instrukcji i postępować zgodnie z nią krok po kroku, aby połączyć się przez VPN. Różne wersje Windows. W jednej wersji Windows wszystko działa dobrze, a w innej potrzebny jest inny protokół. I w ogóle zawsze wiązało się to z ponowną konfiguracją sprzętu sieciowego, który pełnił rolę serwera VPN, a nie wszyscy pracownicy mieli do niego dostęp, co było niedogodne.
Mamy już zdalne połączenia z serwerami i sprzętem sieciowym. Dlaczego więc nie skorzystać z gotowego transportu i nie stworzyć osobnej, małej aplikacji, którą można po prostu dać użytkownikowi do połączenia? Chciałem, aby użytkownik nie musiał wprowadzać żadnych trudnych informacji. Po prostu jeden przycisk „połącz się”. Ale jak ta aplikacja miałaby wiedzieć, dokąd się połączyć, skoro ma tylko jeden przycisk? Był pomysł, aby zdalnie zbudować potrzebną aplikację na naszych serwerach. Administrator systemu naciska przycisk „pobierz skrót”, a do naszej chmury przesyłana jest komenda na zbudowanie indywidualnego binarka z zakodowaną informacją do połączenia z odpowiednim serwerem / komputerem przez RDP. W zasadzie można by to zrobić. Ale trwałoby to długo, administrator musiałby czekać, aż binarek zostanie skompilowany, a potem pobrany. Można by oczywiście dodać po prostu drugi plik z konfiguracją, ale to już są dwa pliki, a dla prostoty użytkownik potrzebuje jednego. Jeden plik, jeden przycisk i żadnych instalatorów. Po przeczytaniu trochę w Google doszedłem do wniosku, że jeśli na końcu skompilowanego „.exe” doda się jakąś informację, to nie ulega uszkodzeniu (no prawie). Można dodać nawet „Wojnę i pokój” i będzie działać jak wcześniej. Grzech z tego nie skorzystać. Teraz można po prostu w locie, prosto w kliencie, rozpakowywać aplikację, zwaną Veliam Connector, i po prostu dopisywać do niej na końcu potrzebne informacje do połączenia. A sama aplikacja wie, co z tym zrobić. Dlaczego w nawiasie napisałem „no prawie”? Ponieważ za tę wygodę trzeba zapłacić tym, że aplikacja traci swoją podpisaną kwalifikowanym podpisem. Ale na tym etapie uważamy, że to niewielka cena za taką wygodę.
Licencje modułów zewnętrznych
Wcześniej pisałem, że po podjęciu decyzji o udostępnieniu produktu dla wszystkich, a nie tylko dla własnych potrzeb, musiałem sporo się napracować i poszukać zamienników dla niektórych modułów, które nie pozwalały na włączenie ich w skład naszego produktu. Po wydaniu odkryłem niestety dość nieprzyjemną rzecz. W składzie Veliam Server, który był po stronie klienta, znajdowała się baza danych MariaDB, a jej licencja to GPL. Licencja GPL zakłada, że oprogramowanie musi być otwartym źródłem, a jeśli nasz produkt zawiera MariaDB, to również powinien być na tej samej licencji. Na szczęście celem tej licencji jest otwarte źródło, a nie ukaranie w sądzie tych, którzy przypadkowo się pomylili. Jeśli właściciel praw zgłasza zarzut, powiadamia naruszającego pisemnie i ten ma 30 dni na usunięcie naruszenia. Sami odkryliśmy błąd i nie otrzymaliśmy żadnych pism, więc od razu zaczęliśmy rozważać opcje rozwiązania problemu. Rozwiązanie okazało się oczywiste — przejście na SQLite. Ta baza danych nie ma żadnych ograniczeń licencyjnych. Większość nowoczesnych przeglądarek używa SQLite, a także wiele innych programów. W internecie znalazłem informację, że SQLite jest uważana za najpopularniejszą bazę danych na świecie, właśnie ze względu na przeglądarki, ale nie szukałem dowodów, więc to nie dokładna informacja. Zacząłem badać, co wiąże się z przejściem na SQLite.
To staje się już nietrywialnym zadaniem, gdy jest kilka setek serwerów z MariaDB i danymi w niej zainstalowanych u klientów. Niektóre funkcje MariaDB są niedostępne w SQLite. Na przykład w kodzie używane były zapytania typu
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Ta konstrukcja nie tylko wykonuje zapytanie z tabeli, ale również blokuje wskazane wiersze. Kilka innych konstrukcji też trzeba było przepisać. Poza tym, że należało przepisać wiele zapytań, trzeba było również wymyślić mechanizm, który podczas aktualizacji Veliam Server u klienta przeniesie wszystkie dane do nowej bazy danych i usunie starą. Ponadto transakcje w SQLite nie działały, co było realnym problemem. Jednak po przeczytaniu różnych źródeł w internecie, bez problemu znalazłem, że transakcje w SQLite można włączyć, przekazując prostą komendę przy połączeniu
PRAGMA journal_mode=WAL;W rezultacie zadanie zostało wykonane, a część serwerowa u klientów działa na SQLite. Nie zauważyliśmy żadnych zmian w działaniu systemu.
Nowy HelpDesk
Z wewnętrznej wersji na wersję SaaS należało przenieść system HelpDesk, wprowadzając pewne zmiany. Pierwsze, co chciałem zrobić, to integracja z domeną klienta w zakresie przezroczystej autoryzacji użytkowników w systemie. Obecnie użytkownik, aby wejść do HelpDesk i złożyć wniosek, po prostu klika na ikonę na pulpicie, a przeglądarka się otwiera. Użytkownik nie wprowadza żadnych danych logowania. Moduł Apache SSPI, który wchodzi w skład Veliam Server, automatycznie autoryzuje użytkownika przy użyciu konta domenowego. Aby złożyć wniosek w systemie, gdy użytkownik znajduje się poza siecią korporacyjną, klika przycisk, a na jego e-mail przychodzi link, za pomocą którego loguje się do systemu HelpDesk bez hasła. Jeśli użytkownik zostanie wyłączony lub usunięty w domenie, jego konto w HelpDesk również przestanie działać. W ten sposób administrator systemu nie musi samodzielnie monitorować kont zarówno w domenie, jak i w HelpDesk. Jeśli pracownik został zwolniony — wyłączył konto w domenie i to wszystko, nie wejdzie do systemu ani z sieci korporacyjnej, ani przez link. Aby ta integracja działała, administrator systemu musi stworzyć jedną GPO, która i .
Drugą rzeczą, którą uważamy za niezwykle ważną dla systemów HelpDesk, przynajmniej dla nas samych – jest możliwość jednego kliknięcia bezpośredniego połączenia z zgłaszającym. Co więcej, połączenia powinny działać, jeśli administrator systemu znajduje się w innej sieci. Dla outsourcingu jest to konieczność, a także często bardzo potrzebne dla etatowych administratorów systemu. Istnieje już kilka produktów, które doskonale radzą sobie z zadaniem zdalnych połączeń. Postanowiliśmy stworzyć dla nich integracje. Obecnie zrealizowaliśmy integrację z VNC, a w przyszłości planujemy dodać Radmin i TeamViewer. Używając naszego transportu sieciowego do zdalnych połączeń z infrastrukturą, zrobiliśmy tak, że VNC łączy się z zdalnymi stacjami roboczymi za NAT. To samo będzie dotyczyć Radmin. Teraz, aby połączyć się z użytkownikiem, wystarczy w samej zgłoszeniu nacisnąć przycisk „połącz z zgłaszającym”. Otwiera się klient VNC i łączy z zgłaszającym niezależnie od tego, czy jesteś w tej samej sieci, czy siedzisz w domu w kapciach. Wcześniej administrator systemu, za pomocą GPO, musi zainstalować wszystkim na stacjach roboczych VNC Server.
Obecnie sami przechodzimy na nowy HelpDesk i korzystamy z integracji z domeną i VNC. Jest to dla nas bardzo wygodne. Teraz nie musimy płacić za TeamViewer, którego używaliśmy przez ponad trzy lata do pracy naszej obsługi wsparcia.
Co planujemy robić dalej
Kiedy wprowadziliśmy nasz produkt, nie wprowadziliśmy żadnych płatnych planów, a po prostu ograniczyliśmy darmowy plan do 50 obiektów monitorowania. Pięćdziesiąt urządzeń sieciowych i serwerów powinno wystarczyć wszystkim, pomyśleliśmy. I wtedy zaczęły napływać prośby o zwiększenie limitu. Powiedzieć, że byliśmy nieco w szoku — to nic nie powiedzieć. Czyżby nasze oprogramowanie zainteresowało firmy, które mają taką liczbę serwerów? Bezpłatnie zwiększaliśmy limit dla tych, którzy składali takie prośby. Niektórzy z nas w odpowiedzi na ich zapytania pytali, dlaczego potrzebują tylu, czyżby mieli tak dużą liczbę serwerów i sprzętu sieciowego? Okazało się, że administratorzy systemów zaczęli używać systemu w sposób, którego w ogóle nie planowaliśmy. Wszystko okazało się proste — monitorowali naszym oprogramowaniem nie tylko serwery, ale także stacje robocze. Stąd wiele próśb o zwiększenie limitów. Obecnie wprowadziliśmy już płatne plany i limity można rozszerzać samodzielnie.
Serwery prawie zawsze pracują albo z pamięcią masową, albo z lokalnymi dyskami w macierzy RAID. I pierwotnie stworzyliśmy produkt dla nich. Monitorowanie SMART nie było ciekawe dla tego zadania. Jednak w związku z tym, że ludzie dostosowali oprogramowanie do monitorowania stacji roboczych, pojawiły się prośby o wdrożenie monitorowania SMART. Wkrótce to zrealizujemy.
Dzięki Veliam Connector, nie ma już potrzeby wdrażania serwera VPN w sieci korporacyjnej, ani tworzenia RDGW, ani po prostu przekazywania portów do odpowiednich maszyn do połączeń przez RDP. Wiele osób korzysta z naszego systemu tylko do tych zdalnych połączeń. Veliam Connector jest dostępny tylko dla systemu Windows, a niektórzy użytkownicy firm łączą się z domowych laptopów z MacOS do stacji roboczych lub terminali w sieci korporacyjnej. I w rezultacie administrator systemu musi z powodu kilku użytkowników wracać do kwestii przekazywania portów lub VPN. Dlatego teraz kończymy wersję Veliam Connector pod MacOS. Użytkownicy swojej ulubionej, jabłkowej technologii również będą mieli możliwość w jednym kliknięciu połączyć się z infrastrukturą korporacyjną.
Bardzo podoba mi się to, że mając dużą liczbę użytkowników systemu, nie muszę się głowić nad tym, czego potrzebują i co będzie dla nich wygodniejsze. Sami piszą swoje sugestie, więc jest wiele planów rozwoju na najbliższy czas.
Równolegle planujemy teraz zająć się tłumaczeniem systemu na język angielski i jego dystrybucją za granicą. Na razie nie wiemy, jak będziemy rozpowszechniać produkt poza naszym krajem, szukamy możliwości. Być może o tym później będzie osobny artykuł. Może ktoś z tych, którzy przeczytali ten artykuł, będzie w stanie zasugerować właściwy kierunek lub sam wie jak to zrobić i zaoferuje swoje usługi. Będziemy wdzięczni za pomoc.
Źródło: habr.com
