diff --git "a/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md" "b/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md"
index bb02dfff0f90b18b151a1b4150780aa9a42fb776..ef14972496063fecdf29db8a7c0a0d1d99e6ce3c 100644
--- "a/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md"
+++ "b/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md"
@@ -1 +1,54 @@
-> 两种方式各需要进行什么准备工作？各有什么优劣？
\ No newline at end of file
+## 个人维护开源项目
+
+选择个人维护一个开源项目是进入开源世界的不错选择。
+
+开始的方法也非常简单 - 以个人的特长、经验和兴趣来创建一个项目并在开源平台（比如gitee）与大家分享。
+
+通过开源平台提供的工具就可以很有效的与用户进行沟通。包括创建 issue，review Pull Request (PR)，简单的任务管理，发布版本，创建wiki等。
+
+在与用户的交流过程中可以不断积累经验，改进项目，进而回馈用户。
+
+选择自己维护有很多有利的地方，例如：
+
+- 项目的路线图可以按照自己的想法演进
+- 更好的根据自己时间和精力控制项目的时间表和进度
+- 在方案决策上，自己有绝对的决定权
+
+但是往往限制于自身的精力、经验、工作生活的变动等因素影响到项目的进度和质量。
+
+## 建设开源项目社区
+
+开源社区所涉及的范畴要比个人维护要广的多。发起者一般是由一个组织 (organization)、一个公司或者公司与组织的联盟等。
+
+若干志同道合的个人可以成立开源组织，以协作的方式建立项目社区。开源组织成熟后，可以吸纳其他开源组织或者公司加入，从而扩大自己的影响力。
+
+社区围绕着一个共同的目标，借用组织或公司的人力财力，将一个或者若干个项目向前推进。
+
+社区针对项目的投入不光体现在对项目功能的开发和 bug 修正，更是从更高的层面来提升项目的影响力、路线图、沟通协作和质量保证等。具体来说：
+
+项目的影响力主要体现在使用者的质量和数量。社区可以通过吸收战略同盟会员等手段吸引在该领域有影响力的公司加入社区，并将该开源项目应用到公司的产品中，从而大大提升项目的实用性，扩展应用实例。继而提升项目的成熟度，吸引更多的会员加入，不断滚雪球，将优势扩大，甚至形成“垄断”。
+
+借助与业内厂商或者产业联盟沟通协作的优势，社区项目的路线图会更加贴近市场，有着非常强的针对性，符合市场愿景。
+
+社区的沟通协作会更加规范。用户的参与贡献方式会被更加正式的说明和要求，甚至签订 CLA (Contributor License Agreement)，从而帮助项目使用者很好的规避一些风险 (如许可证、著作权、专利等）。用户提出的 issue 由团队在规定的时间内按照优先级予以处理。定期组织会议，培训或者线下活动等。。
+
+因为社区项目一般都是将实际产品应用作为目标，所以质量保证上有着更加高的要求。CI 或 CD 成为社区项目的必选项。针对测试投入大量的人力物力（比如租用测试服务器或者云服务器）。
+
+除此之外，社区运行的主要项目一般会有更多的配套项目进行支持，比如上 test suite、 API 兼容性测试工具、脚本工具等。
+
+在与业内其他相关系统的集成方面，社区也会更加积极的推进，将集成方案和 demo 推到对方仓库或者维护在本项目仓库。
+
+综上所属，社区项目是以开源为基础，协作为框架，应用为目的的高效运作团体。所以社区内部的管理上也会更加规范。
+
+尽管社区的组织形式不尽相同，但是一般都会有核心决策团体或者管理委员会来从技术和项目管理的角度履行管理者的权力。甚至有些社区组织结构非常接近于公司的产品开发，从而保证其协同效率。
+
+
+## 个人维护 vs 建设社区
+
+从上面的描述中可以看出，个人维护更加适合初期学习开源项目维护的朋友，积累沟通协作的经验，深入理解开源文化和开源世界。
+
+对于小的项目而言，个人维护可以快速决策，减少沟通成本，进而提升效率。但是在项目推广上无法借助社区的优势，影响力提升较慢。
+
+反观以社区的方式维护项目，其更适合于一个成熟的团队 - 拥有丰富的开源管理经验，对特定的领域有清晰的愿景。
+
+作为个人开发者，可以从个人维护项目开始，借助开源平台认识结交一群志同道合的朋友，形成一个强有力的团队，进而建设社区，将自己的理想变成现实。
\ No newline at end of file