open-source-marketing

开源项目营销

这项技能可帮助你以不尴尬的方式营销开源项目。内容涵盖 GitHub 优化、社区建设、贡献者体验、发布策略和可持续增长。

---

开始之前

先加载受众背景信息。 阅读 .agents/developer-audience-context.md，了解：

• 谁会使用这个项目（角色、技术栈、问题）
• 他们会在哪里发现工具（社区、社交平台、搜索）
• 有哪些替代方案（他们为什么会换用这个项目？）
• 他们如何评估开源软件（星标、活跃度、文档、社区）

如果背景信息文件不存在，请先运行 developer-audience-context 技能。

---

开源项目营销思维

哪些做法有效，哪些无效

有效	无效
公开构建过程	垃圾式宣传“看看我的项目”
解决实际问题	为找问题而构建解决方案
真诚地参与社区	交易式地互相关注和取消关注
优质文档和开发者体验	“代码会自我说明”
赞扬贡献者	独揽功劳
持续活跃	发布后就销声匿迹

增长公式

Growth = (Real value) × (Discoverability) × (First-use experience)

任何一个因素为零，增长就为零。

---

GitHub 优化

打造优秀的 README

README 就是你的着陆页。请对其进行优化。

结构：

# 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](CONTRIBUTING.md).

## License

[License type] - see [LICENSE](LICENSE)

README 检查清单

要素	重要性
清晰的名称	易记、易搜索、易拼写
一句话介绍	“一个面向 [受众] 的 [类型]，可以 [实现什么]”
徽章	社会认同、项目健康状况信号
视觉内容	GIF > 截图 > 无
快速开始	少于 5 行即可体验价值
为什么选择它？	与替代方案的差异
安装	覆盖所有平台，支持复制粘贴
示例	真实用例，而非刻意编造
文档链接	提供更多详情
贡献指南	欢迎社区参与

优化仓库

要素	最佳实践
描述	最多 100 个字符，包含丰富的关键词
主题	添加 5-10 个相关标签，提高可发现性
网站	链接到文档或着陆页
发布版本	使用语义化版本，并提供变更日志
Issues	为错误和功能请求提供模板
Discussions	启用讨论，方便社区问答
赞助	需要资金支持时启用

Issue 和 PR 模板

错误报告模板：

---
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.]

功能请求模板：

---
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.]

---

社区建设

社区交流空间

平台	最适合	设置工作量
GitHub Discussions	问答、公告	低
Discord	实时聊天、营造社区氛围	中
Slack	企业社区	中
论坛（Discourse）	异步、可搜索的讨论	高

从 GitHub Discussions 开始。活跃用户达到 50 人以上后再添加 Discord。

社区原则

原则	实施方式
及时响应	在 48 小时内回复 Issue（即使只是说“正在调查”）
赞扬贡献	公开感谢每一位贡献者
保持透明	分享路线图，解释决策
明确预期	清楚说明维护者的响应 SLA
欢迎新成员	使用“适合初次贡献”标签，并提供指导

贡献者漏斗

User → Star → Issue → PR → Regular Contributor → Maintainer

优化每个转化环节：

转化环节	改进方法
用户 → 星标	优秀的 README，清晰展现价值
星标 → Issue	清晰的 Issue 模板，友好的语气
Issue → PR	“适合初次贡献”标签、CONTRIBUTING.md
PR → 固定贡献者	快速评审，鼓励性的反馈
固定贡献者 → 维护者	信任、共同所有权

---

贡献者体验

CONTRIBUTING.md 必备内容

# 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” 策略

创建真正容易上手的问题：

好	不好
“为 X 函数添加 TypeScript 类型”	“重构整个代码库”
“修复 README 中的拼写错误”	“性能优化”
“为 Y 方法添加测试”	“调试间歇性 CI 故障”
“更新依赖 Z”	“实现 RFC 中的功能”

对于每个适合新手的问题：

• 说明背景及其重要性
• 链接相关代码文件
• 描述预期结果
• 表示愿意在评论中提供帮助

---

发布策略

发布前检查清单

任务	完成？
README 已润色	☐
快速入门可正常使用	☐
文档已准备好	☐
3 个以上示例/演示	☐
测试通过	☐
已选择许可证	☐
CONTRIBUTING.md	☐
问题模板	☐
社交预览图	☐
5-10 个 GitHub 主题	☐

发布日行动指南

时间安排：

时间	行动
前一天	最后检查 README，准备好所有帖子
发布当天早晨	发布 HN 帖子（最佳时间：PT 时间上午 6-8 点，周二至周四）
+1 小时	发布 Twitter 串帖
+2 小时	在相关 subreddit 发布 Reddit 帖子
全天	回复所有评论和问题
当天结束时	感谢所有人，分享数据

各平台专属策略

Hacker News：

• 标题：描述清晰，不夸大其词（“Show HN：X——面向 Z 的 Y”）
• 首条评论：解释动机和技术决策
• 几小时内保持在线并回复
• 不要请求别人点赞（会立刻适得其反）

Reddit：

• 找到 2-3 个相关 subreddit（不要只选 r/programming）
• 先阅读规则
• 以社区成员的身份参与，而非营销人员
• 分享真正有用的背景信息

Twitter/X：

• 串帖格式：问题 → 解决方案 → 演示 → 链接
• 添加 GIF/视频
• 标记相关账号（框架作者等）
• 分享公开构建项目的历程

Dev.to / Hashnode：

• 撰写一篇“我为什么构建这个”文章
• 兼顾技术深度和个人故事
• 从你的博客交叉发布

发布后

时间	重点
第 1 周	回复所有反馈，修复错误
第 2 周	博客文章：“我从发布中学到了什么”
第 3 周	开始定期更新，发布新功能
第 1 个月	建设社区，完善贡献者文档
持续进行	保持稳定的社区参与度，定期发布

---

可持续增长

增长策略

策略	投入	影响	时间线
针对 SEO 优化的文档	中	高	3-6 个月
集成教程	中	高	1-2 个月
会议演讲	高	中	3-6 个月
对比内容	低	中	1-2 个月
客座博客文章	中	中	1-2 个月
新闻简报推荐	低	低-中	2-4 周
Twitter 活跃度	中	中	持续进行

开源软件的内容策略

内容类型	目的
“我们为什么构建 X”	讲述发布故事和动机
“X 与 Y、Z 的比较”	吸引对比搜索流量
“从 Y 迁移到 X”	转化竞争对手的用户
“X + [热门工具]”	吸引集成相关搜索流量
“[公司]如何使用 X”	提供社会认同和真实用例
“X 性能基准测试”	建立技术公信力

避免倦怠

风险	缓解措施
问题过多	明确响应 SLA 预期
功能需求	公开路线图和 RFC 流程
单人维护	主动招募共同维护者
随时待命的压力	安排固定的“答疑时间”，而非 24/7 全天候在线
负面反馈	制定行为准则并进行管理

---

重要指标

虚荣指标与价值指标

虚荣指标	价值指标
Stars	活跃问题 + PR
Fork	回访的贡献者
下载量	每周活跃用户
Twitter 关注者	社区参与度

跟踪哪些指标

指标	查看位置
Stars 随时间的变化	GitHub Insights、Star History
克隆次数	GitHub Traffic
引荐来源	GitHub Traffic
npm 下载量	npm-stat.com
社区规模	Discord/Slack 成员数
贡献者人数	GitHub Insights
问题响应时间	手动跟踪

---

工具

工具	用途
Octolens	监控项目在 GitHub、HN、Reddit、Twitter 和 Stack Overflow 上的提及。跟踪竞品项目。寻找提出问题的贡献者。
Star History	跟踪 Stars 随时间的增长
npm-stat	下载统计
GitHub Traffic	浏览量、克隆次数、引荐来源
Shield.io	动态徽章
All Contributors	认可所有贡献者
Probot	自动化 GitHub 工作流

---

相关技能

• developer-audience-context — 了解用户是谁
• community-building — 建立 Discord/Slack 社区
• devrel-content — 创建配套内容
• developer-advocacy — 会议演讲、播客
• hacker-news-strategy — 在 HN 上发布并参与互动