# The open source promotion cheat sheet: a checklist for getting your project noticed > This repository is a documentation checklist rather than a piece of software, laid out in three parts: prepare the project so visitors can use it, spread the word across social and specialised platforms, and keep the users you attract. It is maintained by Zenika's open source team, translated into fifteen languages, and published as both a web page and a PDF. **zenika-open-source/promote-open-source-project** — 📄 How to promote my open source project? - Repository: https://github.com/zenika-open-source/promote-open-source-project - Stars: 863 · Forks: 87 - Language: Unknown - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/zenika-open-source-promote-open-source-project ## What this repository is, and what kind of artifact it is This is a cheat sheet. The README describes it as summarizing important steps you should follow to promote your open source project in the best conditions, and the interactive property is that you can click items to expand and get more information from a topic. The structure is three numbered sections. Preparation step comes first, then spreading the word about your hard works, then keeping your users. Each item is a collapsible block with a title and a short piece of advice underneath, which makes the document work both as something to read in one sitting and as something to return to when you are about to do one specific thing. The distribution is worth noting because it says something about the project. There are fifteen README files, one per language: Arabic, English, Catalan, German, Spanish, Persian, French, Bahasa Indonesia, Italian, Japanese, Portuguese, Russian, Sinhala, Turkish, Simplified Chinese and Traditional Chinese. The README asks whether a language is missing and invites contributions, pointing at a CONTRIBUTING.md. There is also a PDF version of the cheat sheet in the repository, and an image logo at the top. The repository belongs to the zenika-open-source organisation and is maintained under the MIT licence, with a CODE_OF_CONDUCT.md and a .all-contributorsrc. The project topics describe it as a cheat-sheet about open source promotion, social medias and visitors, with hacktoberfest among them. What it is not is a framework or a tool. There is no code to run, no configuration to set, and no measurement. It is a document, and it is worth judging it as one. ## Preparation: the things that decide whether a visitor installs The first section has seven items, and the order is not accidental. Each one removes a reason for a visitor to leave. Maturity comes first. Your project must be stable enough with the minimum viable features in order to hook users. The cheat sheet's own framing, that it summarises steps to promote a project in the best conditions, implies the promotion is pointless without something to promote. Then the name. Choose a name that users can easily remember. This is the cheapest item on the list to act on and the one most often skipped, since a project usually gets named by its author rather than chosen for recall. The README gets its own item, described as the first thing your visitors will see, with the instruction to make it simple, pretty and easy to read, and a link to a curated list of good READMEs. Then highlighting your strengths, identifying them and making sure visitors see them first. A demo is the fifth item. Visitors will want to quickly understand the purpose of your project, how it works and how to use it, and providing a demo is the best way to satisfy them. The document suggests two forms, an animated GIF demonstrating how the project works, or a link to a live demo. Ease of installation follows, with a blunt warning: you will probably lose visitors if your project is not user-friendly. And documentation gets the longest entry of the seven. Creating good documentation is probably the most important step, with the advice that a small documentation can live in the README and anything larger should probably be hosted on a separate website, pointing at vuepress as an example of a tool for the job. ## Distribution: the platform list, and the rules around it The second section is the part people usually want, and it is organised around where to post rather than what to say. Trust comes first. Most visitors will check how many stars the project has before considering using it, and a minimum amount of stars makes a project more trustable than one with zero stars. The advice that follows is to ask people you know to support the project before making a public announcement, which is a specific and slightly awkward tactic that most people skip. The platform list is long: Twitter, LinkedIn, Facebook, Reddit, Dev.to, Lobsters, Hacker News, Product Hunt, Beta page and Human Coders. The framing is to tell the world about your awesome work and publish on social media and other specialised platforms. Then three channels that are not social posts. Write articles about your project, with the purpose being the technical stack you used, how it works or the problems you encountered, posted to platforms such as Medium and Dev.to. Present the project at conferences and meetups. And record and publish videos presenting the project and how it works, which the sheet says is not an easy exercise but is probably the most efficient way to make your project famous. Two timing rules close the section. Don't publish during holiday periods or weekends, because the best time to publish on social networks is usually mid-week. And don't spam platforms with your promotion: don't publish twice on the same platform, because it will be considered spam and might cause bad publicity for your project. The platform list is the weakest part of the document, for reasons that have nothing to do with the authors. It is a fixed list, and platforms in this space change faster than checklists do. Lobsters and Hacker News behave nothing like Facebook, and the sheet gives one set of rules for all ten. ## Keeping users: releases, issue hygiene and the contributor pipeline The third section is the one most projects skip, and it is the largest. It covers what happens after the announcement. Releases come first: maintain and improve your project with new releases and generate changelogs. That is what makes the announcement about a project rather than about a repository. Issue handling is second, and the emphasis is on responsiveness rather than on closing things. Do not let issues stay open without a single response, and be nice with people that took the time to open issues. The instruction to respond even when the answer is no is the part that matters, because an unanswered issue is what a prospective contributor sees when they check whether the maintainer cares. The third item is the contributor pipeline, and it is the most concrete advice in the document. A healthy project is a project with a community and contributors. To get one, let your users know that you need help by tagging issues with contribution welcome or good first issue labels, with a link to the GitHub documentation on labels. That single mechanism does more work than it appears. Labelled issues are a public queue that a new contributor can find without asking, and the good first issue label in particular turns a vague offer of help into a specific first task. The cheat sheet does not mention automation, but the labels are what a repository's own issue templates and starter workflows are built around. The fourth item is rewarding contributors, with the suggestion that some projects give gifts and that if you cannot afford that, do a public post on Twitter or another platform about the contribution, mentioning the author, with a link to an example of public thanks. The recommended structural fix is to open a Contributors section in your README, and the examples given are the contributors section in the vuepress README and a highlighted contributors section in the Rythm.js README. ## Limits: a document, not a strategy The limits here are the limits of the form rather than gaps in the content. The first is that there is no measurement. Nothing in the checklist tells you how to know whether a promotion worked, what a good conversion from a social post to a star looks like, or which channel is worth your time for your particular project. You can follow every item and still not know whether it worked. The second is that the advice is about presence rather than about fit. The platform list treats Twitter and Hacker News as entries in one list, but they have different audiences, different formats and different rules about what gets submitted. A project aimed at graphics engineers and a project aimed at Python library users have different channels, and the document does not help you work out which. The third is the star count item, which is the advice most likely to have decayed. Treating stars as a trust signal was reasonable when a star was a rough proxy for how many people had evaluated a project. It is weaker now, and the advice to ask people you know to support the project is closer to a description of how the metric gets gamed than a recommendation. The fourth is the framing of the whole thing. Every item is about getting attention, and the third section is about keeping the users you attracted. There is no item about whether the project should exist, whether the scope is right, or whether the maintenance burden is sustainable, which are the questions that decide whether a project is worth promoting at all. The fifth is that the document is advice with no mechanism attached. It tells you to write articles and record videos without suggesting how to scope them, and it treats a conference talk as a reasonable step for someone who has never given one. And there is no indication of how much of this is worth doing for a project with a hundred users rather than a project with ten thousand. ## This checklist against the platform's own guides and against asking other maintainers Two comparisons make the choice clearer. The first is against the individual platforms' own guidance. Each of Twitter, Reddit, Hacker News and Lobsters publishes rules about what counts as promotion, and those rules are enforced by moderators who can remove a post or ban an account. The cheat sheet's general advice to publish on several platforms and not twice on the same one sits alongside those rules without mentioning them, so following the sheet does not guarantee a post survives moderation. The more useful material is the platform-specific guidance, which is also the part that changes when the platforms change. The second comparison is against asking other maintainers. Every maintainer of a project in your field has already worked out which channels work for them, and the answer is specific to their audience and their field. A conversation costs an email and gives you the shortlist that took them years to assemble. That is where the checklist's real value sits, and it is a value that has nothing to do with the specific items. The reason to read a document like this before your first launch is that it changes what you check. The preparation section is a pre-flight list, and the distribution section is a checklist to run through so that you do not forget a step in the excitement of announcing something. Both of those uses survive the staleness of the platform list. The section that benefits most from external input is the third, because keeping users is where project governance lives, and where the advice of people who have run communities is worth more than any checklist. ## Conclusion Adopt this checklist if you have just published a library and want a structured pass over the things that decide whether a visitor installs it, whether they trust it and whether they come back. Do not treat it as a growth strategy, because it contains no advice about measuring impact or about timing beyond not publishing on weekends. Verify first that the platform list still reflects where developers in your field actually are, that the practices around star counts still hold, and that you are prepared for the ongoing work the third section asks for, which is larger than the effort of publishing. ## FAQ ### What are the three stages of the open source promotion cheat sheet? The document is organised as a preparation step, spreading the word about your hard works, and keeping your users. The preparation stage covers maturity, naming, the README, highlighting strengths, providing a demo, easy installation and documentation. The distribution stage covers trust, social and specialised platforms, articles, conferences, videos, timing and not spamming. The third stage covers releases, issue handling, inviting contributors and rewarding them. ### In which languages is the promotion cheat sheet available? The repository ships fifteen README files: Arabic, English, Catalan, German, Spanish, Persian, French, Bahasa Indonesia, Italian, Japanese, Portuguese, Russian, Sinhala, Turkish, Simplified Chinese and Traditional Chinese. There is also a PDF version of the cheat sheet in the repository. ### What does the cheat sheet say about getting people to contribute? It says a healthy project is a project with a community and contributors, and that you should let your users know you need help by tagging some issues with contribution welcome or good first issue labels. For rewarding contributors it suggests giving gifts where possible, otherwise a public post or a Contributors section in the README. ## Sources - [Issues](https://github.com/zenika-open-source/promote-open-source-project/issues) - [License: MIT](https://github.com/zenika-open-source/promote-open-source-project/blob/main/LICENSE) - [README](https://github.com/zenika-open-source/promote-open-source-project/blob/main/README.md) - [zenika-open-source/promote-open-source-project on GitHub](https://github.com/zenika-open-source/promote-open-source-project) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zenika-open-source-promote-open-source-project