Open source: nasz kod w Proxmox VE, ILSpy i 69 innych projektach
Poprawki, które opiekunowie cudzych projektów przejrzeli i włączyli do swojego kodu, i narzędzia, które piszemy u siebie. Każdy projekt ma osobną stronę z opisem tego, co zmieniliśmy, i linkiem do każdej zmiany.
Największe projekty z naszymi zmianami71 projektów, 147 przyjętych zmian
Kontrybucje według technologii
Poprawiamy biblioteki w językach, w których sami piszemy. Strona każdej technologii pokazuje nasze projekty, fragment kodu z jednego z nich i wszystkie kontrybucje w tym języku.
PHP
20 projektów, 36 przyjętych zmianC# i .NET
8 projektów, 17 przyjętych zmianRust
8 projektów, 12 przyjętych zmianTypeScript, React i Node
6 projektów, 30 przyjętych zmianPython
5 projektów, 6 przyjętych zmian
Opisy zmian w Nowinkach technicznych
Przy wybranych zmianach piszemy, co nie działało, co poprawiliśmy i jak to sprawdziliśmy, z kodem i linkiem do pull requesta.
Dlaczego poprawiamy błędy u autorów bibliotek
Błąd w bibliotece da się obejść na trzy sposoby, a każdy kosztuje inaczej w czasie. Wybieramy trzeci: do czasu wydania wersji z poprawką projekt działa na przypiętej wersji z łatką, a potem wraca na oficjalną.
Obejście w kodzie projektu
- Na start
- Działa od razu: dodatkowe sprawdzenie przed wywołaniem biblioteki.
- Przy kolejnych wersjach
- Zostaje kod, który istnieje tylko z powodu błędu biblioteki. Gdy biblioteka sama go naprawi, obejście zostaje jako martwy kod, którego nikt nie odważy się usunąć.
Własna kopia biblioteki
- Na start
- Poprawka siedzi tam, gdzie powinna: we własnej kopii biblioteki albo w łatce nakładanej na zainstalowany pakiet.
- Przy kolejnych wersjach
- Przy każdej aktualizacji łatkę trzeba nałożyć ponownie i sprawdzić, a poprawka bezpieczeństwa dociera dopiero wtedy, gdy ktoś ręcznie przeniesie zmiany.
Poprawka u autorów biblioteki
- Na start
- Najwolniej: test odtwarzający błąd, kod w stylu projektu i review, które bywa kwestią dni albo tygodni.
- Przy kolejnych wersjach
- Poprawkę utrzymują autorzy, przechodzi przez ich testy przy każdej wersji i trafia do wszystkich użytkowników, a projekt wraca na oficjalną wersję bez lokalnych zmian.
Nasze projekty
Vulp, Gyred i Plazer piszemy od podstaw u siebie. Każdy ma w portfolio stronę z ekranami i opisem tego, jak działa.
Vulp
Wszystkie nasze repozytoria z jednego terminala.
Vulp to nasze wewnętrzne narzędzie w terminalu: jeden ekran pokazuje stan wszystkich repozytoriów, zbiorczy sync podciąga i wypycha zmiany naraz, a projekty, zadania, pull requesty i statystyki siedzą pod skrótami klawiszowymi. Napisane w Ruście, żeby chodziło od ręki.
- Stan wszystkich repozytoriów na jednym ekranie
- Zbiorczy sync wielu repo naraz
- Projekty, zadania i pull requesty pod ręką
- Statystyki commitów i aktywności
Gyred
Panel sterowania dla agentów AI, które pracują same.
Gyred trzyma flotę agentów w ryzach: przestrzenie robocze oddzielają projekty, reguły mówią, co agentowi wolno, a pętle mają prawdziwy warunek stopu zamiast kręcenia się w kółko. Leasy pilnują, żeby dwóch agentów nie rzuciło się na to samo zadanie - jeden bierze, reszta czeka.
- Przestrzenie robocze na osobne projekty
- Reguły, które ograniczają, co agent może zrobić
- Pętle z prawdziwym warunkiem stopu
- Leasy blokujące dublowanie zadań
Plazer
Komunikator, który nie wie, o czym rozmawiasz.
Wiadomości, serwery z kanałami, rozmowy głosowe i profile w jednej lekkiej aplikacji. Rozmowy prywatne, grupy i prywatne kanały szyfruje Twoje urządzenie, kod jest otwarty, a serwer dla swojej społeczności postawisz sam.
- Szyfrowanie na urządzeniu: rozmowy prywatne, grupy i prywatne kanały
- Serwery z kanałami, rolami i rozmowami głosowymi
- Konto bez e-maila i numeru telefonu
- Natywna aplikacja na komputer, telefon i do przeglądarki
Jak dokładamy naszą cegiełkę?
Nasz udział w otwartym kodzie nie ma jednej formy. Robimy to na cztery różne sposoby - każdy karmi pozostałe.
Usługi indywidualne
Piszemy oprogramowanie na zamówienie: strony, panele, sklepy i aplikacje. Klient dostaje kod na własność i pełną historię commitów, a nie zamkniętą czarną skrzynkę. Wiele wzorców i narzędzi, które tu wypracujemy, wraca potem do naszych otwartych projektów.
Prowadzenie projektów OSS
Utrzymujemy własne otwarte projekty - jak vulp - z prawdziwym repo, wydaniami i dbałością o jakość. To nie porzucone eksperymenty: pilnujemy zgłoszeń, piszemy dokumentację i rozwijamy je, bo używamy ich codziennie sami. Kto chce, może wejść, przeczytać kod i zbudować na nim swoje.
Kontrybucje do cudzego kodu
Kiedy w bibliotece, której używamy, znajdziemy błąd albo brakującą funkcję, nie łatamy tego po cichu u siebie - odsyłamy poprawkę do źródła. Zgłaszamy issue, otwieramy pull requesty i pomagamy utrzymać przy życiu narzędzia, na których stoi też nasza praca. To najzwyklejsza uczciwość wobec ekosystemu, z którego korzystamy.
Gotowe platformy SaaS
Część naszych projektów wyrasta w pełne platformy SaaS, na których ktoś może po prostu założyć konto i pracować. Rdzeń tych platform często dzieli kod z otwartymi narzędziami, więc rozwój jednego napędza drugie. Zamiast wymyślać wszystko od zera przy każdym zleceniu, mamy sprawdzone fundamenty, które sami zbudowaliśmy i rozumiemy do końca.
Nie stoimy w miejscu
Nie chwalimy się jednym dobrym miesiącem. Po lewej liczby z całej naszej historii w otwartym kodzie, po prawej wykres aktywności z ostatnich 90 dni - gęsty i bez długich przerw, bo open source to u nas codzienny nawyk.
25 000+
commitów od 2020
6 mln+
linii kodu
630 000+
gwiazdek OSS
70+
projektów OSS z wkładem
198 mln+
znaków kodu
Aktywność, ostatnie 90 dni
Lip
Sie
Wrz
Paź
45 aktywnych dnimniejwięcej
Co budujemy w otwartym kodzie
Otwarty kod to u nas nie jeden typ projektu. Od narzędzi w terminalu, przez platformy i aplikacje, po emulatory i biblioteki.
01Narzędzia deweloperskie
Narzędzia w terminalu, które sami odpalamy każdego dnia i które oszczędzają nam godzin klikania. Sztandarowym przykładem jest vulp - z jednego okna terminala zarządza wieloma repozytoriami naraz, synchronizuje je, otwiera pull requesty i zbiera statystyki. Do tego pilnuje guardraili, żeby nic nie trafiło do kodu w złym stanie. Budujemy je najpierw dla siebie, więc muszą być szybkie i niezawodne.
02Platformy i panele
Kompletne panele sterowania i platformy, które spinają wiele ruchomych części w jeden czytelny pulpit. Takim projektem jest Gyred - prowadzi całą flotę agentów AI z jednego miejsca, pokazuje ich stan i pozwala nimi sterować w czasie rzeczywistym. Podobnie budujemy panele hostingowe i klienckie, w których wszystko ważne jest pod ręką. Chodzi o to, żeby złożoną infrastrukturę dało się ogarnąć jednym spojrzeniem.
03Komunikatory i aplikacje
Aplikacje pisane od zera, w których jeden kod obsługuje web, pulpit i telefon naraz. Flagowym przykładem jest Plazer - komunikator z rozmowami na żywo i szyfrowaniem end-to-end, więc treść wiadomości zostaje między rozmówcami. Zamiast składać gotowe klocki, budujemy takie aplikacje warstwa po warstwie i panujemy nad każdym detalem. Dzięki temu działają tak samo dobrze na każdym ekranie.
04Emulatory i silniki
Schodzimy do najniższych warstw, tam gdzie liczy się każdy takt zegara. Piszemy emulatory CPU testowane bit w bit - od CHIP-8 po Game Boya - tak żeby zachowywały się dokładnie jak oryginalny układ. Do tego dochodzą silniki gier i renderery budowane od podstaw, bez gotowych bibliotek do rysowania. To najbardziej wymagająca część tego, co robimy, i najwięcej się przy niej uczymy.
05Biblioteki i mikroframeworki
Małe, dobrze przetestowane biblioteki i mikroframeworki, które robią jedną rzecz i robią ją porządnie. Budujemy je wyłącznie o standardową bibliotekę języka, bez ciężkich zależności ciągnących za sobą pół internetu. Dzięki temu są lekkie, łatwe do wczytania w cudzy projekt i przewidywalne w utrzymaniu. Każdą z nich pokrywamy testami, zanim uznamy ją za gotową.
06Boty i automatyzacje
Boty Discorda, proxy webhooków i skrypty operacyjne, które przejmują nudną, powtarzalną robotę. Odciążają zespół i same pilnują infrastruktury, reagując zanim ktokolwiek zdąży zauważyć problem. Zamiast klikać ręcznie po panelach, opisujemy raz, co ma się dziać automatycznie, i zostawiamy to maszynie. Dzięki nim mamy więcej czasu na rzeczy, których nie da się zautomatyzować.
Narzędzia deweloperskie
Pytania o open source
Zobacz, jak piszemy - w otwartym kodzie
Cały nasz open source jest publiczny: repozytoria, historia commitów, wydania. Zajrzyj, przeczytaj kod, sklonuj go i zbuduj na nim swoje.
Zobacz kod na git.vulcode.com