Minęło dziesięć dni odkąd zdecydowałem się opublikować kod jako source-available. Najwyższy czas usiąść i spisać, co się przez ten czas wydarzyło - zarówno w projekcie, jak i w mojej głowie.

Co to w ogóle jest Devset?

Zanim przejdę do refleksji - krótko, o czym mówimy. Devset to local-first aplikacja do testowania systemów event-driven opartych o Kafkę i RabbitMQ. Zamiast pisać kolejne skrypty wysyłające testowe wiadomości albo klikać po terminalach z paczkami JSON-a, dostajesz wizualny flow builder na canvasie przeciągasz etapy, łączysz je, konfigurujesz payloady i headery w UI, a potem odpalasz cały przepływ i widzisz każdą wiadomość od źródła do dostarczenia.

Kluczowe założenia:

• Local-first - nic nie wychodzi z twojej maszyny, łączy się bezpośrednio z lokalnym brokerem
• Wizualnie, nie YAML-em - flow builder zamiast skryptów
• Function Studio - budowanie payloadów field-by-field, bez ręcznego klepania JSON-ów
• Dla developerów i nie-developerów - ktoś z biznesu też może odpalić testowy event
• Community Edition to pełen produkt - wszystkie kluczowe moduły, bez płatnego tieru

Instalacja to docker compose up i tyle. Strona: devset.io, kod: github.com/devset-io/devset-ce (licencja FSL-1.1-Apache-2.0).

To tyle wstępu - wracam do tego, co się działo przez ostatnie 10 dni.

Emocje opadły (prawie)

Pierwsze dni to był czysty stres. Strach przed pokazaniem światu, co tak naprawdę mam pod maską. Ile „makaronu" zostało w kodzie, ile rozwiązań było pisanych „na szybko, później poprawię"? Po dziesięciu dniach mogę powiedzieć, że ten lęk w dużej mierze opadł. Nie zniknął całkowicie, wciąż gdzieś z tyłu głowy siedzi myśl, że ktoś zaraz wytknie mi coś oczywistego ale już nie paraliżuje.

Kod, który piszesz „dla siebie", a kod, który wystawiasz publicznie, to dwa różne światy. Nawet jeśli to ten sam plik.

To chyba naturalna część procesu.

GitHub po prostu daje radę

GitHub dla publicznych repozytoriów jest super. Funkcje, które dostajesz za darmo, robią robotę. Na początku nie zdawałem sobie sprawy, ile rzeczy odpala się automatycznie po przełączeniu repo na public.

Kilka konkretów, które zwróciły moją uwagę najbardziej:

Dependabot: sprawdzanie zależności w czasie rzeczywistym. Widzę na bieżąco, co w projekcie ma znane podatności (CVE), co wymaga aktualizacji, gdzie jest potencjalny problem. Nie raz na kwartał przy ręcznym audycie, tylko codziennie, automatycznie. Dodatkowo sam tworzy pull requesty z propozycją aktualizacji — klikasz, mergujesz, gotowe.

CodeQL: statyczna analiza kodu pod kątem bezpieczeństwa. Narzędzie wyłapuje wzorce, które mogą być problematyczne: SQL injection, XSS, niebezpieczne deserializacje, hardcoded credentials. Dla samotnego developera bez zespołu security to bardzo pomocne. Nie zastąpi pełnego audytu, ale wyłapuje większość typowych błędów zanim trafią do kogokolwiek innego.

Secret scanning Jeśli przypadkiem wrzucisz token API, klucz prywatny albo connection string do repo, GitHub od razu to wykrywa i — w przypadku znanych providerów — informuje samego providera, żeby unieważnił token. Dodatkowa siatka bezpieczeństwa, której nawet nie musisz konfigurować.

Darmowe minuty GitHub Actions dla public repo. Bez limitu. CI/CD, build, test, deploy, code scanning — wszystko, co odpalam jako workflow, kosztuje zero. To zmienia podejście: nie myślisz „czy to się opłaca uruchomić w pipelinie", tylko po prostu dorzucasz kolejny krok.

Zakładka Security w repo. Przegląd wszystkiego w jednym miejscu — otwarte advisories, vulnerable dependencies, secret leaks, wyniki code scanningu. Zamiast grzebać w logach z trzech narzędzi, masz jeden widok.

Suma tych rzeczy oznacza, że jako solo developer mam infrastrukturę bezpieczeństwa, która jeszcze kilka lat temu w wielu firmach była luksusem. W zamian za to, że kod jest publicznie dostępny — uczciwa wymiana.

GitHub Actions i decyzja o monorepo

Zdecydowałem się trzymać wszystko w jednym repozytorium — backend, frontend i landing page razem. Wiem, że to kontrowersyjna decyzja i nie każdemu by się to spodobało, ale dla projektu tej wielkości po prostu ma sens. Mniej kontekstów do przełączania, jeden punkt prawdy.

Wymagało to trochę zabawy z GitHub Actions, żeby pipeline działał sensownie dla każdej z części osobno. Dwa wieczory — i naprawdę dwa wieczory, bo myślałem, że to będzie tygodniowa walka — wystarczyły, żeby zapanować nad konfiguracją.

Co teraz? Dokumentacja, ale z prawdziwego zdarzenia

Następny krok to dokumentacja — i nie chcę, żeby była to tylko ściana tekstu. W planach mam dorzucić krótkie filmiki i gify, które pokażą krok po kroku, jak dokładnie działa devset. Co się dzieje po uruchomieniu, jak wygląda interfejs, jak skonfigurować typowe scenariusze.

Trzydziestosekundowy gif pokazujący „wpisz to, kliknij tu, dostajesz to" potrafi zastąpić pół README.

Tekst zostanie tam, gdzie musi być (instalacja, konfiguracja, referencje), ale wszędzie, gdzie da się pokazać zamiast opisywać — pokażę.

Równolegle łatam drobne błędy, które wyszły dopiero przy świeżym spojrzeniu po publikacji. Klasyka. I zastanawiam się nad kierunkiem — w którą stronę pójść, żeby dotrzeć do szerszej grupy. Jeszcze nie mam odpowiedzi. Najpierw dokumentacja, potem myślenie o promocji.

Statystyki — w okolicach zera, ale to początek

Wersja 1.0 portalu ma na ten moment około 30 pobrań. Nie mam pojęcia, ile z tego to realni ludzie, a ile boty skanujące rejestry. Ale 30 to 30 — liczba większa od zera, a od czegoś trzeba zacząć.

• Pobrania wersji 1.0: ~30 (ludzie czy boty?)
• Gwiazdki na repo: 1 (moja własna 😉)
• Dni od publikacji: 10

Mam też jedną gwiazdkę na repozytorium. Co prawda swoją własną — ale liczy się.

Podsumowanie

Dziesięć dni to za mało, żeby wyciągać daleko idące wnioski. Ale wystarczająco, żeby stwierdzić, że decyzja o publikacji kodu była dobra. Stres opadł, narzędzia wokół są świetne, projekt zaczyna żyć własnym życiem — nawet jeśli to życie jest na razie bardzo skromne.

Wracam do pisania dokumentacji i nagrywania pierwszych gifów. Do następnego wpisu — może wtedy będzie więcej niż jedna gwiazdka.