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