Open Source Marketing
When to Use
Use this skill when you need when the user wants to market an open source project authentically. Trigger phrases include "open source marketing," "OSS marketing," "GitHub marketing," "promote my library," "grow stars," "launch open source," "open source growth," or "contributor marketing.".
This skill helps you market open source projects without being cringe. Covers GitHub optimization, community building, contributor experience, launch strategies, and sustainable growth.
Before You Start
Load your audience context first. Read .agents/developer-audience-context.md to understand:
- Who would use this project (role, tech stack, problem)
- Where they discover tools (communities, social, search)
- What alternatives exist (why would they switch?)
- How they evaluate OSS (stars, activity, docs, community)
If the context file doesn't exist, run the developer-audience-context skill first.
The OSS Marketing Mindset
What Works vs. What Doesn't
| Works |
Doesn't Work |
| Building in public |
Spamming "check out my project" |
| Solving real problems |
Building solutions seeking problems |
| Genuine community engagement |
Transactional follows/unfollows |
| Great docs and DX |
"The code is self-documenting" |
| Celebrating contributors |
Taking sole credit |
| Consistent presence |
Launch and disappear |
The Growth Equation
Growth = (Real value) × (Discoverability) × (First-use experience)
If any factor is zero, growth is zero.
GitHub Optimization
README Excellence
Your README is your landing page. Optimize it.
Structure:
# Project Name
[One-line description that explains what it does]
[Badges: build status, version, license, downloads]
[Screenshot or GIF showing it in action]
## Why [Project Name]?
- ✅ [Benefit 1 - specific, not fluffy]
- ✅ [Benefit 2]
- ✅ [Benefit 3]
## Quick Start
\`\`\`bash
npm install project-name
\`\`\`
\`\`\`javascript
// 5 lines that show immediate value
\`\`\`
## Installation
[Detailed installation for all platforms]
## Usage
[Core usage patterns with examples]
## Documentation
[Link to full docs]
## Contributing
We love contributions! See [CONTRIBUTING.md](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/open-source-marketing/CONTRIBUTING.md).
## License
[License type] - see [LICENSE](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/open-source-marketing/LICENSE)
README Checklist
| Element |
Why It Matters |
| Clear name |
Memorable, searchable, spellable |
| One-liner |
"A [type] for [audience] that [does what]" |
| Badges |
Social proof, health signals |
| Visual |
GIF > Screenshot > Nothing |
| Quick start |
<5 lines to first value |
| Why this? |
Differentiation from alternatives |
| Installation |
All platforms, copy-paste |
| Examples |
Real use cases, not contrived |
| Docs link |
More detail available |
| Contributing |
Community welcome |
Repository Optimization
| Element |
Best Practice |
| Description |
100 chars max, keyword-rich |
| Topics |
5-10 relevant tags for discoverability |
| Website |
Link to docs or landing page |
| Releases |
Semantic versioning, changelogs |
| Issues |
Templates for bugs/features |
| Discussions |
Enable for community Q&A |
| Sponsors |
Enable if you want funding |
Issue & PR Templates
Bug report template:
---
name: Bug Report
about: Report a bug to help us improve
---
## Bug Description
[Clear description]
## Steps to Reproduce
1.
2.
3.
## Expected Behavior
[What should happen]
## Actual Behavior
[What actually happens]
## Environment
- OS:
- Node version:
- Package version:
## Additional Context
[Screenshots, logs, etc.]
Feature request template:
---
name: Feature Request
about: Suggest an idea for this project
---
## Problem
[What problem does this solve?]
## Proposed Solution
[How would you like it to work?]
## Alternatives Considered
[Other approaches you've thought about]
## Additional Context
[Examples, mockups, etc.]
Community Building
Community Spaces
| Platform |
Best For |
Setup Effort |
| GitHub Discussions |
Q&A, announcements |
Low |
| Discord |
Real-time chat, community feel |
Medium |
| Slack |
Enterprise communities |
Medium |
| Forum (Discourse) |
Async, searchable discussions |
High |
Start with GitHub Discussions. Add Discord when you have 50+ active users.
Community Principles
| Principle |
Implementation |
| Be responsive |
Respond to issues within 48 hours (even if just "looking into it") |
| Celebrate contributions |
Thank every contributor publicly |
| Be transparent |
Share roadmap, explain decisions |
| Set expectations |
Clear SLA for maintainer response |
| Welcome newcomers |
"good first issue" labels, mentorship |
Contributor Funnel
User → Star → Issue → PR → Regular Contributor → Maintainer
Optimize each transition:
| Transition |
How to Improve |
| User → Star |
Great README, visible value |
| Star → Issue |
Clear issue templates, welcoming tone |
| Issue → PR |
"good first issue" labels, CONTRIBUTING.md |
| PR → Regular |
Quick review, encouraging feedback |
| Regular → Maintainer |
Trust, shared ownership |
Contributor Experience
CONTRIBUTING.md Essentials
# Contributing to [Project]
First off, thanks for considering contributing! ❤️
## Quick Start
1. Fork the repo
2. Clone your fork
3. Install dependencies: `npm install`
4. Create a branch: `git checkout -b my-feature`
5. Make your changes
6. Run tests: `npm test`
7. Commit: `git commit -m "Add my feature"`
8. Push: `git push origin my-feature`
9. Open a Pull Request
## Development Setup
[Detailed setup instructions]
## Code Style
- We use [Prettier/ESLint config]
- Run `npm run lint` before committing
- [Other conventions]
## Commit Messages
We follow [Conventional Commits](https://conventionalcommits.org/):
- `feat: add new feature`
- `fix: resolve bug`
- `docs: update readme`
- `chore: update dependencies`
## Pull Request Process
1. Update docs if needed
2. Add tests for new features
3. Ensure CI passes
4. Get one approval
## Good First Issues
Look for issues labeled `good first issue` — these are great starting points!
## Questions?
Open a Discussion or reach out on Discord.
"Good First Issue" Strategy
Create genuinely approachable issues:
| Good |
Not Good |
| "Add TypeScript types for X function" |
"Refactor the entire codebase" |
| "Fix typo in README" |
"Performance optimization" |
| "Add test for Y method" |
"Debug intermittent CI failure" |
| "Update dependency Z" |
"Implement feature from RFC" |
For each good first issue:
- Explain context and why it matters
- Link to relevant code files
- Describe expected outcome
- Offer to help in comments
Launch Strategies
Pre-Launch Checklist
| Task |
Done? |
| README polished |
☐ |
| Quick start works |
☐ |
| Docs exist |
☐ |
| 3+ examples/demos |
☐ |
| Tests passing |
☐ |
| License chosen |
☐ |
| CONTRIBUTING.md |
☐ |
| Issue templates |
☐ |
| Social preview image |
☐ |
| 5-10 GitHub topics |
☐ |
Launch Day Playbook
Timeline:
| Time |
Action |
| Day before |
Final README review, prep all posts |
| Launch morning |
HN post (best: 6-8am PT, Tuesday-Thursday) |
| +1 hour |
Twitter thread |
| +2 hours |
Reddit post to relevant subreddits |
| Throughout day |
Respond to all comments/questions |
| End of day |
Thank everyone, share metrics |
Platform-Specific Tactics
Hacker News:
- Title: Descriptive, no hype ("Show HN: X — a Y for Z")
- First comment: Explain motivation, tech decisions
- Be available to respond for hours
- Don't ask for upvotes (instant death)
Reddit:
- Find 2-3 relevant subreddits (not just r/programming)
- Read the rules first
- Be a community member, not a marketer
- Share genuinely useful context
Twitter/X:
- Thread format: Problem → Solution → Demo → Link
- Include GIF/video
- Tag relevant accounts (framework authors, etc.)
- Share builds-in-public journey
Dev.to / Hashnode:
- Write a "Why I Built This" article
- Technical depth, personal story
- Cross-post from your blog
Post-Launch
| Week |
Focus |
| Week 1 |
Respond to all feedback, fix bugs |
| Week 2 |
Blog post: "What I learned from launch" |
| Week 3 |
Start regular updates, ship new feature |
| Month 1 |
Community building, contributor docs |
| Ongoing |
Consistent presence, regular releases |
Sustainable Growth
Growth Tactics
| Tactic |
Effort |
Impact |
Timeline |
| SEO-optimized docs |
Medium |
High |
3-6 months |
| Integration tutorials |
Medium |
High |
1-2 months |
| Conference talks |
High |
Medium |
3-6 months |
| Comparison content |
Low |
Medium |
1-2 months |
| Guest blog posts |
Medium |
Medium |
1-2 months |
| Newsletter features |
Low |
Low-Medium |
2-4 weeks |
| Twitter presence |
Medium |
Medium |
Ongoing |
Content Strategy for OSS
| Content Type |
Purpose |
| "Why we built X" |
Launch story, motivation |
| "X vs Y vs Z" |
Capture comparison searches |
| "Migrating from Y to X" |
Convert competitor users |
| "X + [Popular Tool]" |
Capture integration searches |
| "How We Use X at [Company]" |
Social proof, real use case |
| "X Performance Benchmarks" |
Technical credibility |
Avoiding Burnout
| Risk |
Mitigation |
| Overwhelming issues |
Set response SLA expectations |
| Feature demands |
Public roadmap, RFC process |
| Solo maintenance |
Actively recruit co-maintainers |
| Always-on pressure |
Scheduled "office hours" vs. 24/7 |
| Negative feedback |
Code of conduct, moderation |
Metrics That Matter
Vanity vs. Value
| Vanity Metric |
Value Metric |
| Stars |
Active issues + PRs |
| Forks |
Returned contributors |
| Downloads |
Weekly active users |
| Twitter followers |
Community engagement |
What to Track
| Metric |
Where to Find It |
| Stars over time |
GitHub Insights, Star History |
| Clones |
GitHub Traffic |
| Referrers |
GitHub Traffic |
| npm downloads |
npm-stat.com |
| Community size |
Discord/Slack member count |
| Contributor count |
GitHub Insights |
| Issue response time |
Manual tracking |
Tools
| Tool |
Use Case |
| Octolens |
Monitor mentions of your project across GitHub, HN, Reddit, Twitter, and Stack Overflow. Track competitor projects. Find contributors asking questions. |
| Star History |
Track star growth over time |
| npm-stat |
Download statistics |
| GitHub Traffic |
Views, clones, referrers |
| Shield.io |
Dynamic badges |
| All Contributors |
Recognize all contributors |
| Probot |
Automate GitHub workflows |
Related Skills
developer-audience-context — Know who your users are
community-building — Build Discord/Slack community
devrel-content — Create supporting content
developer-advocacy — Conference talks, podcasts
hacker-news-strategy — Launch and engage on HN
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
1---2name: open-source-marketing3description: When the user wants to market an open source project authentically. Trigger phrases include "open source marketing," "OSS marketing," "GitHub marketing," "promote my library," "grow stars," "launch open source," "open source growth," or "contributor marketing."4license: MIT5---6
7# Open Source Marketing
8## When to Use
9
10Use this skill when you need when the user wants to market an open source project authentically. Trigger phrases include "open source marketing," "OSS marketing," "GitHub marketing," "promote my library," "grow stars," "launch open source," "open source growth," or "contributor marketing.".
11
12
13This skill helps you market open source projects without being cringe. Covers GitHub optimization, community building, contributor experience, launch strategies, and sustainable growth.
14
15---
16
17## Before You Start
18
19**Load your audience context first.** Read `.agents/developer-audience-context.md` to understand:
20
21- Who would use this project (role, tech stack, problem)
22- Where they discover tools (communities, social, search)
23- What alternatives exist (why would they switch?)
24- How they evaluate OSS (stars, activity, docs, community)
25
26If the context file doesn't exist, run the `developer-audience-context` skill first.
27
28---
29
30## The OSS Marketing Mindset
31
32### What Works vs. What Doesn't
33
34| Works | Doesn't Work |
35|-------|--------------|
36| Building in public | Spamming "check out my project" |
37| Solving real problems | Building solutions seeking problems |
38| Genuine community engagement | Transactional follows/unfollows |
39| Great docs and DX | "The code is self-documenting" |
40| Celebrating contributors | Taking sole credit |
41| Consistent presence | Launch and disappear |
42
43### The Growth Equation
44
45```
46Growth = (Real value) × (Discoverability) × (First-use experience)
47```
48
49If any factor is zero, growth is zero.
50
51---
52
53## GitHub Optimization
54
55### README Excellence
56
57Your README is your landing page. Optimize it.
58
59**Structure:**
60
61```markdown
62# Project Name
63
64[One-line description that explains what it does]
65
66[Badges: build status, version, license, downloads]
67
68[Screenshot or GIF showing it in action]
69
70## Why [Project Name]?
71
72- ✅ [Benefit 1 - specific, not fluffy]
73- ✅ [Benefit 2]
74- ✅ [Benefit 3]
75
76## Quick Start
77
78\`\`\`bash
79npm install project-name
80\`\`\`
81
82\`\`\`javascript
83// 5 lines that show immediate value
84\`\`\`
85
86## Installation
87
88[Detailed installation for all platforms]
89
90## Usage
91
92[Core usage patterns with examples]
93
94## Documentation
95
96[Link to full docs]
97
98## Contributing
99
100We love contributions! See [CONTRIBUTING.md](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/open-source-marketing/CONTRIBUTING.md).
101
102## License
103
104[License type] - see [LICENSE](https://github.com/jonathimer/devmarketing-skills/tree/main/skills/open-source-marketing/LICENSE)
105```
106
107### README Checklist
108
109| Element | Why It Matters |
110|---------|---------------|
111| **Clear name** | Memorable, searchable, spellable |
112| **One-liner** | "A [type] for [audience] that [does what]" |
113| **Badges** | Social proof, health signals |
114| **Visual** | GIF > Screenshot > Nothing |
115| **Quick start** | <5 lines to first value |
116| **Why this?** | Differentiation from alternatives |
117| **Installation** | All platforms, copy-paste |
118| **Examples** | Real use cases, not contrived |
119| **Docs link** | More detail available |
120| **Contributing** | Community welcome |
121
122### Repository Optimization
123
124| Element | Best Practice |
125|---------|--------------|
126| **Description** | 100 chars max, keyword-rich |
127| **Topics** | 5-10 relevant tags for discoverability |
128| **Website** | Link to docs or landing page |
129| **Releases** | Semantic versioning, changelogs |
130| **Issues** | Templates for bugs/features |
131| **Discussions** | Enable for community Q&A |
132| **Sponsors** | Enable if you want funding |
133
134### Issue & PR Templates
135
136**Bug report template:**
137
138```markdown
139---
140name: Bug Report
141about: Report a bug to help us improve
142---
143
144## Bug Description
145[Clear description]
146
147## Steps to Reproduce
1481.
1492.
1503.
151
152## Expected Behavior
153[What should happen]
154
155## Actual Behavior
156[What actually happens]
157
158## Environment
159- OS:
160- Node version:
161- Package version:
162
163## Additional Context
164[Screenshots, logs, etc.]
165```
166
167**Feature request template:**
168
169```markdown
170---
171name: Feature Request
172about: Suggest an idea for this project
173---
174
175## Problem
176[What problem does this solve?]
177
178## Proposed Solution
179[How would you like it to work?]
180
181## Alternatives Considered
182[Other approaches you've thought about]
183
184## Additional Context
185[Examples, mockups, etc.]
186```
187
188---
189
190## Community Building
191
192### Community Spaces
193
194| Platform | Best For | Setup Effort |
195|----------|----------|--------------|
196| **GitHub Discussions** | Q&A, announcements | Low |
197| **Discord** | Real-time chat, community feel | Medium |
198| **Slack** | Enterprise communities | Medium |
199| **Forum (Discourse)** | Async, searchable discussions | High |
200
201Start with GitHub Discussions. Add Discord when you have 50+ active users.
202
203### Community Principles
204
205| Principle | Implementation |
206|-----------|----------------|
207| **Be responsive** | Respond to issues within 48 hours (even if just "looking into it") |
208| **Celebrate contributions** | Thank every contributor publicly |
209| **Be transparent** | Share roadmap, explain decisions |
210| **Set expectations** | Clear SLA for maintainer response |
211| **Welcome newcomers** | "good first issue" labels, mentorship |
212
213### Contributor Funnel
214
215```
216User → Star → Issue → PR → Regular Contributor → Maintainer
217```
218
219Optimize each transition:
220
221| Transition | How to Improve |
222|------------|----------------|
223| User → Star | Great README, visible value |
224| Star → Issue | Clear issue templates, welcoming tone |
225| Issue → PR | "good first issue" labels, CONTRIBUTING.md |
226| PR → Regular | Quick review, encouraging feedback |
227| Regular → Maintainer | Trust, shared ownership |
228
229---
230
231## Contributor Experience
232
233### CONTRIBUTING.md Essentials
234
235```markdown
236# Contributing to [Project]
237
238First off, thanks for considering contributing! ❤️
239
240## Quick Start
241
2421. Fork the repo
2432. Clone your fork
2443. Install dependencies: `npm install`
2454. Create a branch: `git checkout -b my-feature`
2465. Make your changes
2476. Run tests: `npm test`
2487. Commit: `git commit -m "Add my feature"`
2498. Push: `git push origin my-feature`
2509. Open a Pull Request
251
252## Development Setup
253
254[Detailed setup instructions]
255
256## Code Style
257
258- We use [Prettier/ESLint config]
259- Run `npm run lint` before committing
260- [Other conventions]
261
262## Commit Messages
263
264We follow [Conventional Commits](https://conventionalcommits.org/):
265- `feat: add new feature`
266- `fix: resolve bug`
267- `docs: update readme`
268- `chore: update dependencies`
269
270## Pull Request Process
271
2721. Update docs if needed
2732. Add tests for new features
2743. Ensure CI passes
2754. Get one approval
276
277## Good First Issues
278
279Look for issues labeled `good first issue` — these are great starting points!
280
281## Questions?
282
283Open a Discussion or reach out on Discord.
284```
285
286### "Good First Issue" Strategy
287
288Create genuinely approachable issues:
289
290| Good | Not Good |
291|------|----------|
292| "Add TypeScript types for X function" | "Refactor the entire codebase" |
293| "Fix typo in README" | "Performance optimization" |
294| "Add test for Y method" | "Debug intermittent CI failure" |
295| "Update dependency Z" | "Implement feature from RFC" |
296
297For each good first issue:
298- Explain context and why it matters
299- Link to relevant code files
300- Describe expected outcome
301- Offer to help in comments
302
303---
304
305## Launch Strategies
306
307### Pre-Launch Checklist
308
309| Task | Done? |
310|------|-------|
311| README polished | ☐ |
312| Quick start works | ☐ |
313| Docs exist | ☐ |
314| 3+ examples/demos | ☐ |
315| Tests passing | ☐ |
316| License chosen | ☐ |
317| CONTRIBUTING.md | ☐ |
318| Issue templates | ☐ |
319| Social preview image | ☐ |
320| 5-10 GitHub topics | ☐ |
321
322### Launch Day Playbook
323
324**Timeline:**
325
326| Time | Action |
327|------|--------|
328| **Day before** | Final README review, prep all posts |
329| **Launch morning** | HN post (best: 6-8am PT, Tuesday-Thursday) |
330| **+1 hour** | Twitter thread |
331| **+2 hours** | Reddit post to relevant subreddits |
332| **Throughout day** | Respond to all comments/questions |
333| **End of day** | Thank everyone, share metrics |
334
335### Platform-Specific Tactics
336
337**Hacker News:**
338- Title: Descriptive, no hype ("Show HN: X — a Y for Z")
339- First comment: Explain motivation, tech decisions
340- Be available to respond for hours
341- Don't ask for upvotes (instant death)
342
343**Reddit:**
344- Find 2-3 relevant subreddits (not just r/programming)
345- Read the rules first
346- Be a community member, not a marketer
347- Share genuinely useful context
348
349**Twitter/X:**
350- Thread format: Problem → Solution → Demo → Link
351- Include GIF/video
352- Tag relevant accounts (framework authors, etc.)
353- Share builds-in-public journey
354
355**Dev.to / Hashnode:**
356- Write a "Why I Built This" article
357- Technical depth, personal story
358- Cross-post from your blog
359
360### Post-Launch
361
362| Week | Focus |
363|------|-------|
364| **Week 1** | Respond to all feedback, fix bugs |
365| **Week 2** | Blog post: "What I learned from launch" |
366| **Week 3** | Start regular updates, ship new feature |
367| **Month 1** | Community building, contributor docs |
368| **Ongoing** | Consistent presence, regular releases |
369
370---
371
372## Sustainable Growth
373
374### Growth Tactics
375
376| Tactic | Effort | Impact | Timeline |
377|--------|--------|--------|----------|
378| **SEO-optimized docs** | Medium | High | 3-6 months |
379| **Integration tutorials** | Medium | High | 1-2 months |
380| **Conference talks** | High | Medium | 3-6 months |
381| **Comparison content** | Low | Medium | 1-2 months |
382| **Guest blog posts** | Medium | Medium | 1-2 months |
383| **Newsletter features** | Low | Low-Medium | 2-4 weeks |
384| **Twitter presence** | Medium | Medium | Ongoing |
385
386### Content Strategy for OSS
387
388| Content Type | Purpose |
389|--------------|---------|
390| **"Why we built X"** | Launch story, motivation |
391| **"X vs Y vs Z"** | Capture comparison searches |
392| **"Migrating from Y to X"** | Convert competitor users |
393| **"X + [Popular Tool]"** | Capture integration searches |
394| **"How We Use X at [Company]"** | Social proof, real use case |
395| **"X Performance Benchmarks"** | Technical credibility |
396
397### Avoiding Burnout
398
399| Risk | Mitigation |
400|------|------------|
401| **Overwhelming issues** | Set response SLA expectations |
402| **Feature demands** | Public roadmap, RFC process |
403| **Solo maintenance** | Actively recruit co-maintainers |
404| **Always-on pressure** | Scheduled "office hours" vs. 24/7 |
405| **Negative feedback** | Code of conduct, moderation |
406
407---
408
409## Metrics That Matter
410
411### Vanity vs. Value
412
413| Vanity Metric | Value Metric |
414|---------------|--------------|
415| Stars | Active issues + PRs |
416| Forks | Returned contributors |
417| Downloads | Weekly active users |
418| Twitter followers | Community engagement |
419
420### What to Track
421
422| Metric | Where to Find It |
423|--------|------------------|
424| **Stars over time** | GitHub Insights, Star History |
425| **Clones** | GitHub Traffic |
426| **Referrers** | GitHub Traffic |
427| **npm downloads** | npm-stat.com |
428| **Community size** | Discord/Slack member count |
429| **Contributor count** | GitHub Insights |
430| **Issue response time** | Manual tracking |
431
432---
433
434## Tools
435
436| Tool | Use Case |
437|------|----------|
438| **[Octolens](https://octolens.com)** | Monitor mentions of your project across GitHub, HN, Reddit, Twitter, and Stack Overflow. Track competitor projects. Find contributors asking questions. |
439| **Star History** | Track star growth over time |
440| **npm-stat** | Download statistics |
441| **GitHub Traffic** | Views, clones, referrers |
442| **Shield.io** | Dynamic badges |
443| **All Contributors** | Recognize all contributors |
444| **Probot** | Automate GitHub workflows |
445
446---
447
448## Related Skills
449
450- `developer-audience-context` — Know who your users are
451- `community-building` — Build Discord/Slack community
452- `devrel-content` — Create supporting content
453- `developer-advocacy` — Conference talks, podcasts
454- `hacker-news-strategy` — Launch and engage on HN
455
456## Limitations
457
458- Use this skill only when the task clearly matches its upstream source and local project context.
459- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
460- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.