Slayer zaczyna jako otwarty warsztat badawczy: publikujemy metody, pomiary i część artefaktów tak, by społeczność mogła je weryfikować i rozwijać. Otwartość dotyczy standardu pracy badawczej, nie deklaracji nonprofit. Slayer może w przyszłości działać jako organizacja komercyjna, jeśli będzie to najlepszy sposób finansowania compute, utrzymania zespołu i wdrażania polskich modeli w praktyce.
Kacper Wikieł jest inicjatorem, autorem kierunku i osobą odpowiedzialną za początkową strukturę projektu: zakres badań, standard publikacji, ton marki, priorytety techniczne i decyzje o tym, co trafia do oficjalnego Slayera.
Kontrybucje są mile widziane, ale oficjalna linia projektu musi pozostać spójna: dobry smak, twardy pomiar, jawny koszt i brak benchmaxxingu. Wkład społeczności nie wyklucza przyszłej struktury for-profit.
Początkowy model organizacyjny Slayera to BDFL, czyli Benevolent Dictator For Life — model znany z wczesnej historii Pythona. W praktyce oznacza to, że Kacper Wikieł ma ostatnie słowo w sprawach kierunku, jakości, publikacji, nazwy, marki i konfliktów decyzyjnych.
To nie jest zamknięcie projektu. To mechanizm utrzymania spójności, dopóki Slayer nie ma dojrzałego governance, stałych maintainerów i jasnych procesów rozstrzygania sporów.
Obecnie Kacper Wikieł posiada 100% projektu. To stan startowy, nie docelowy — w miarę jak Slayer dojrzewa, własność będzie się otwierać dla osób, które realnie go budują.
Przewidujemy, że ścieżka core membera będzie wiązać się z vested equity (udziałami nabywanymi w czasie, za dowożoną pracę i odpowiedzialność). Pojawią się też prawdopodobnie inwestorzy — finansowanie compute i zespołu wymaga kapitału. Szczegóły (struktura spółki, vesting, cap table) domkniemy, gdy będą realne, i opiszemy je tutaj — bez obietnic bez pokrycia.
Każdy może eksperymentować, forkować i proponować zmiany. Oficjalny Slayer zachowuje jednak jedną linię decyzyjną i jedną odpowiedzialność redakcyjną.
Decyzje techniczne zapadają na podstawie artefaktów: kodu, danych, pomiarów, kosztu, replikowalności i jakości odpowiedzi. Sama opinia nie wystarcza.
Realni kontrybutorzy mają wpływ na plan działania i priorytety. Wpływ rośnie z odpowiedzialnością za dowożone rzeczy, a nie z deklaracjami.
Jeśli dyskusja nie prowadzi do decyzji, BDFL domyka temat. Celem jest ruch projektu, nie nieskończona debata.
Gdy projekt będzie miał stabilnych maintainerów, regularnych kontrybutorów i większą powierzchnię odpowiedzialności, struktura może przejść w bardziej formalny model. Do tego czasu obowiązuje BDFL.
Jeśli chcesz dołożyć kod, dane, ewaluację albo compute, wejście jest otwarte. Jeśli chcesz zmienić kierunek projektu, przynieś dowód.