Krótka odpowiedź
- Zacznij od samego repozytorium: README, które odpowiada na pytania co, po co i jak zacząć, licencja, do 20 tematów GitHub i obraz podglądu społecznościowego.
- Potem idź tam, gdzie twoi użytkownicy już rozmawiają: na forum, czat albo subreddit twojego języka lub frameworka, a na Show HN wtedy, gdy da się projekt uruchomić bez rejestracji.
- Poproś opiekunów jednej lub dwóch pasujących list awesome o dodanie, zgodnie z zasadami zgłoszeń każdej z tych list.
- Dodaj stronę internetową lub wersję hostowaną do kilku katalogów i platform startowych i wydawaj kolejne wersje. Regularna aktywność stale przyciąga nowych odwiedzających.
Mapa dystrybucji dla open source
Odkrywanie projektów open source ma cztery warstwy. Każda opiera się na poprzedniej: post w społeczności kieruje ludzi do twojego repozytorium, więc to repozytorium musi ich najpierw przekonać.
- 1 · RepozytoriumTo, co każdy odwiedzający widzi najpierw.
- README
- Licencja
- Tematy
- Podgląd społecznościowy
- Wydania
- 2 · Odkrywanie na GitHubieJak ludzie znajdują cię wewnątrz GitHuba.
- Strony tematów
- Wyszukiwarka GitHub
- Explore
- Gwiazdki i listy
- 3 · SpołecznościTam, gdzie twoi użytkownicy już rozmawiają.
- Show HN
- Fora i czaty ekosystemu
- Subreddity
- Odpowiedzi na pytania (Q&A)
- 4 · Kuratorowane i katalogowaneMiejsca, które stale do ciebie odsyłają.
- Listy awesome
- Rejestry pakietów
- Katalogi
- Newslettery
Zbuduj swój czterotygodniowy plan
Odpowiedz na osiem pytań i wklej swoje tematy. Kreator sprawdza tematy pod kątem zasad GitHub i przypisuje każdy kanał do tygodnia, z oznaczeniem „gotowe” albo z tym, co trzeba najpierw poprawić. Wszystko działa w twojej przeglądarce; nic nie jest wysyłane ani zapisywane.
Spraw, by repozytorium dało się znaleźć
Każdy kanał z tej strony kończy się na stronie twojego repozytorium. Dokumentacja GitHub wymienia, na co README powinno odpowiadać; tabela zamienia to w konkretną treść pierwszego ekranu.
| Element | Czego potrzebuje odwiedzający | Co działa |
|---|---|---|
| Co robi | W kilka sekund ocenić, czy pasuje do jego problemu | Jedno zdanie pod tytułem, słowami, których szukaliby twoi użytkownicy |
| Dlaczego jest przydatny | Powód, by wybrać go zamiast oczywistej alternatywy | Jedna konkretna różnica albo krótkie porównanie |
| Jak zacząć | Pierwszy sukces w ciągu kilku minut | Jedno polecenie instalacji i jeden minimalny przykład, który działa po wklejeniu |
| Pokaż, jak działa | Dowód przed instalacją | Zrzut ekranu, GIF albo nagranie terminala blisko początku |
| Gdzie szukać pomocy | Pewność, że nie zostanie sam | Podlinkuj Issues, Discussions albo czat; napisz, co gdzie zgłaszać |
| Kto go utrzymuje | Pewność, że projekt żyje | Maintainerzy, niedawne wydanie, przewodnik dla kontrybutorów |
Tematy: do 20 drzwi do wyszukiwarki GitHub
- Łącz cztery rodzaje, które proponuje GitHub: cel (cli, static-site-generator), dziedzina (accessibility), społeczność (hacktoberfest) i język (rust).
- Używaj tematów, które ludzie naprawdę przeglądają. Otwórz github.com/topics/ i sprawdź, czy dany temat ma już repozytoria.
- GitHub sam też proponuje tematy dla publicznych repozytoriów. Przyjmij te, które pasują, a resztę odrzuć.
Podgląd społecznościowy
Bez obrazu udostępniony link pokazuje podstawowe dane repozytorium i twój awatar. Wyraźny obraz 1280 × 640 z nazwą projektu i jednym zdaniem o jego celu sprawia, że każde udostępnienie jest rozpoznawalne. Przed wgraniem sprawdź rozmiar i format w darmowym narzędziu do sprawdzania rozmiarów obrazów. Sprawdź grafiki do premiery pod kątem wymagań platform →
| Zasada | Oficjalne brzmienie | Co to dla ciebie znaczy |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Traktuj README jak swoją stronę docelową: pierwszy ekran decyduje, czy ludzie zostaną. |
| Rozmiar README | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | Długie README są ucinane. Szczegółową dokumentację referencyjną przenieś do docs i podlinkuj. |
| Rodzaje tematów | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Wybieraj tematy z obszarów celu, dziedziny, społeczności i języka, a nie dziesięć wariantów jednego słowa. |
| Format tematów | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | Walidator w kreatorze planu stosuje dokładnie te trzy zasady. |
| Podgląd społecznościowy | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | Przygotuj plik PNG lub JPG 1280 × 640 o rozmiarze poniżej 1 MB. |
| Profil społeczności | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | Otwórz Insights → Community Standards w swoim repozytorium i dodaj to, czego brakuje. |
Listy awesome: dwie różne drogi
Listy awesome to kuratorowane zbiory na GitHubie, po jednym na temat. Często cytowane zasady, takie jak 30 dni i cztery recenzje, dotyczą jednego konkretnego przypadku. Wiedz, którą drogą idziesz.
Droga A: twój projekt trafia na listę tematyczną
To typowy przypadek dla biblioteki, narzędzia lub aplikacji. Znajdź jedną lub dwie aktywne listy dla swojego tematu, przeczytaj plik zgłoszeń (contributing) tej listy i zaproponuj jedną linię w jej formacie. Listy różnią się tym, co przyjmują, więc obowiązuje ich własny przewodnik. Opiekuna przekonuje twoje README, licencja i niedawna aktywność.
Droga B: twoja kuratorowana lista trafia do meta-listy awesome
Tylko jeśli sam prowadzisz listę. Wtedy obowiązuje ścisły szablon meta-listy: co najmniej 30 dni od powstania, recenzja 4 innych otwartych pull requestów, uruchomienie awesome-lint, licencja Creative Commons, tematy awesome i awesome-list oraz tytuł w formie „Add Name of List”.
| Zasada | Oficjalne brzmienie | Co to dla ciebie znaczy |
|---|---|---|
| Dodawanie do listy | If you have something awesome to contribute to an awesome list, this is how you do it. | Każda lista opisuje własną drogę. Przeczytaj przewodnik zgłoszeń tej konkretnej listy, a nie ogólny. |
| Wiek listy | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Tylko dla list, które chcą trafić do meta-listy awesome: odczekaj 30 dni od pierwszego prawdziwego commita. |
| Recenzje | Just commenting “looks good” or simply marking the pull request as approved does not count! | Zgłaszający do meta-listy muszą zrecenzować co najmniej 4 inne otwarte pull requesty, z prawdziwym feedbackiem. |
| AI | Fully AI-generated pull requests are not accepted. | Napisz pull request samodzielnie. W całości wygenerowany zostanie zamknięty. |
| Licencja | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Lista potrzebuje licencji Creative Commons, zalecana CC0. Licencje na kod się nie liczą. |
| Jakość | Only has awesome items. Awesome lists are curations of the best, not everything. | Listy zawierają to, co najlepsze, a nie wszystko. Wpuszcza cię twoje README i twoja aktywność. |
Cytujemy zasady według stanu z daty sprawdzenia; opiekunowie je aktualizują. LaunchRepo nie otwiera za ciebie pull requestów ani nie kontaktuje się z opiekunami list.
Społeczności, które chętnie widzą projekty
Open source ma tu przewagę: wiele społeczności programistów chętnie widzi działający projekt, o ile rozwiązuje prawdziwy problem, a ty zostajesz, by odpowiadać na pytania.
| Kanał | Najlepiej pasuje do | Pierwszy krok |
|---|---|---|
| Show HN (Hacker News) | Narzędzi, które można od razu uruchomić | Opublikuj raz, zostań w wątku, odpowiedz na każde pytanie |
| Forum lub czat twojego ekosystemu | Bibliotek i wtyczek dla jednego języka lub frameworka | Przeczytaj zasady prezentowania projektów, potem pokaż przykład użycia, a nie slogan |
| Pasujący subreddit | Projektów z wyraźną grupą odbiorców na Reddicie | Najpierw sprawdź zasady autopromocji danego subreddita |
| Odpowiedzi na pytania (Q&A) | Projektów, które rozwiązują powracające pytanie | Odpowiedz na pytanie w pełni; wspomnij o projekcie tam, gdzie naprawdę pomaga |
| Tygodniowe newslettery twojego ekosystemu | Wydań, za którymi stoi historia | Wyślij redakcji krótką wiadomość z linkiem do wydania |
| Meetupy i wystąpienia na konferencjach | Projektów, z których płynie lekcja | Zacznij od lokalnego meetupu twojego języka |
W naszym publicznym zbiorze danych postów Show HN, które linkowały do repozytorium kodu między wrześniem 2025 a sierpniem 2026 (łącznie: 15 859), mediana wyniosła 2 pkt, a 9,5% osiągnęło 10 lub więcej punktów. Jeden post to początek, a nie plan.
Jak przeprowadzić premierę projektu na Show HN →Promuj swój SaaS na Reddicie bez łamania zasad →
| Zasada | Oficjalne brzmienie | Co to dla ciebie znaczy |
|---|---|---|
| Co pasuje | Show HN is for something you've made that other people can play with. | Coś, co ludzie mogą uruchomić, a nie ogłoszenie czy landing page. |
| Treść | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Publikuj projekt, w który włożyłeś prawdziwą pracę i o którym potrafisz rozmawiać. |
| Bariery | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Publiczne repozytorium z jednym poleceniem instalacji to idealny Show HN. |
| Głosy | Please don't ask friends to upvote or comment. That's not ok on HN. | Udostępniaj link bez prośby o głosy. Niech praca mówi sama za siebie. |
| Wybór miejsc | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Wybierz kilka społeczności, w których projekt rozwiązuje prawdziwy problem. |
| Reputacja | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Najpierw pomagaj w innych projektach. Ludzie to zauważają i zaglądają do twojego. |
Katalogi i platformy startowe
Gdy masz stronę internetową, stronę z dokumentacją lub wersję hostowaną, kilka katalogów staje się stałym dodatkowym źródłem odwiedzających i linków. Trzy, które dobrze pasują do open source:
- AlternativeTo: gdy twój projekt jest darmową alternatywą dla znanego oprogramowania.
- SourceForge: hostuje projekty open source z plikami do pobrania przez ścieżkę Create a Project, oddzielną od katalogu oprogramowania biznesowego.
- Product Hunt: dla projektów z dopracowanym interfejsem i dniem premiery, w którym możesz być obecny.
Wybieraj platformy według dopasowania do odbiorców i sprawdzaj aktualne zasady każdej z nich; wpis to drzwi, a nie gwarancja użytkowników. Wpisz swoje narzędzie tam, gdzie programiści naprawdę szukają. →
Czego nie robić
- Kupione lub wymieniane gwiazdki
- Zasady GitHub zabraniają manipulowania rankingami, a badania pokazują, że kupione gwiazdki pomagają tylko na krótko. Szczegóły wraz z naszym własnym pomiarem: Gwiazdki na GitHub zdobyte prawdziwą użytecznością →
- Proszenie znajomych o głosy
- Hacker News mówi to wprost: to nie jest w porządku. Głosy grupy znajomych nie mówią ci też nic o prawdziwym zainteresowaniu.
- Ten sam post wszędzie
- Skopiowane ogłoszenia w wielu społecznościach jednego dnia wyglądają jak spam. Wybierz kilka miejsc i pisz osobno dla każdego.
- Premiera przed README
- Uwaga jest krótka. Popraw pierwszy ekran repozytorium, zanim wyjdzie jakikolwiek post.
Gdzie pasuje LaunchRepo
LaunchRepo zajmuje się warstwą katalogów i platform startowych: twój agent kodujący przygotowuje i zgłasza stronę twojego projektu do dużego katalogu serwisów, a tracker odróżnia wpis opublikowany od oczekującego.
Posty w społecznościach, prośby do list awesome i rozmowy zostają po twojej stronie, bo najlepiej działają twoim własnym głosem. LaunchRepo oszczędza godziny, które zajęłyby formularze, żebyś mógł spędzić je właśnie tam.
Źródła
Wszystkie zasady przeczytaliśmy 1 października 2026 i cytujemy je słowo w słowo po angielsku. Kopie tekstów przechowujemy razem z naszymi dowodami.
Najczęściej zadawane pytania
- Jak promować projekt open source?
- Zacznij od repozytorium: README, które odpowiada na pytania co, po co i jak zacząć, licencja, tematy i obraz podglądu. Potem pokaż projekt w społeczności swojego ekosystemu i na Show HN, gdy da się go wypróbować bez rejestracji, zgłoś się do jednej lub dwóch pasujących list awesome i regularnie wydawaj nowe wersje.
- Jak dodać projekt do listy awesome?
- Otwórz listę, przeczytaj jej plik zgłoszeń (contributing) i zaproponuj jeden wpis w jej formacie. Ścisłe zasady (30 dni, cztery recenzje, awesome-lint) dotyczą tylko zgłaszania własnej kuratorowanej listy do meta-listy awesome.
- Ile tematów GitHub dodać?
- GitHub pozwala na maksymalnie 20. Użyj tych, które opisują cel, dziedzinę, społeczność i język, zapisanych małymi literami, cyframi i łącznikami, każdy po 50 znaków lub mniej.
- Czy Show HN to dobre miejsce dla open source?
- Tak, jeśli ludzie mogą od razu uruchomić projekt, a ty możesz zostać i odpowiadać na pytania. Show HN wymaga czegoś, co da się wypróbować, bez barier w postaci rejestracji i bez proszenia znajomych o głosy.
- Czy kupić gwiazdki GitHub, żeby wyglądać poważniej?
- Nie. Acceptable Use Policies GitHub zabraniają manipulowania rankingami, np. automatycznego dawania gwiazdek, a duże badanie wykazało, że kupione gwiazdki pomagają tylko na krótko i szkodzą w dłuższej perspektywie.
- Czy LaunchRepo publikuje za mnie w społecznościach?
- Nie. LaunchRepo daje twojemu agentowi playbooki do zgłoszeń strony twojego projektu do katalogów i platform startowych. Posty w społecznościach i prośby do list awesome pozostają osobiste.
Niech twój agent zajmie się katalogami
Jeden zakup, twój agent kodujący, każdy produkt, który zbudujesz: twój agent kodujący korzysta z LaunchRepo, by zgłosić stronę twojego projektu do katalogów i platform startowych, a ty w tym czasie rozmawiasz z użytkownikami.
Zobacz cennik