Building Popular Open Source Projects - COSCUP 2018

Why is building popular open source project important? This talk introduces the tips and tricks of building open source projects.

Transcript

1. Building popular open source projects 林林佑安 / Yo-An Lin / @c9s Tips & Tricks
2. So you might ask
3. “Is it important to make it popular?”
4. “Yes!”
5. 群聚效應 “群聚效應(Critical mass) 是⼀一個社會動⼒力力學的名詞， ⽤用來來描述在⼀一個社會系統裡，某件事情的存在已達⾄至 ⼀一個⾜足夠的動量量，使它能夠⾃自我維持，並為往後的成 長提供動⼒力力。”
6. 若若有⼀一個⼈人停下來來抬頭往天望，沒有⼈人會理理會他，其他 路路過的⼈人會照舊繼續他們要做的事情。如果有三個⼈人停 了了下來來抬頭望天，可能會有多幾個⼈人會停下來來看看他們 在做甚麼，但很快⼜又會去繼續他們原來來的事。但假若若當 街上抬頭向天望的群眾增加⾄至 5 到 7 ⼈人，這時，其他⼈人 可能亦會好奇地加入，看看他們到底在做甚麼。 http://zh.wikipedia.org/wiki/群聚效應
7. 也就是: 當某專案符合某個獨特的市場需求 ， ⽽而且能夠受到注⽬目 ， 不斷被群眾提起，⾃自然就能吸引更更多的開發者重視，並 且加入開發/⽀支援/貢獻。 有了了動能，就算專案擁有者沒有持續開發，也可以讓專 案持續前進
8. 開源之道 Allison Randal @ OSDC TW 2012 http://pugs.blogs.com/pugs/2012/04/%E9%96%8B%E6%BA%90%E4%B9%8B%E9%81%93.html http://allisonrandal.com/2012/04/15/open-source-enlightenment/
9. “Open Source Collaboration”
10. 前提是要有女朋友
11. 前提是你的專案要有⼈人 願意參參與
12. 如果你想要有更更多⼈人願 意參參與 If you want more people join in
13. 你必須把 open source 專案視為銷售產品 You need to treat your project as a product
14. –McCarthy “4P: Product, Price, Place, Promotion”
15. –Robert Lauterborn “4C: Customer needs and wants, Cost to the customer, Convenience, Communication”
16. 市場潛⼒力力 Find the market potential
17. 獨特性 Make it unique
18. 爭議性 Let people discuss
19. Different Targets
20. creativity / performance / simple interface / lightweight / fun / invention
21. 專案 名稱 The name of a project should be easy to remember
22. 1. Short name node.js, three.js, gearman, apache, nginx, jQuery, bootstrap, gem, rails and so on…
23. If you need to combine different words, don't combine more than 3 words
24. 2. Pronounceable Project name should be easily pronounced and spelled.
25. Worcestershire
26. 3. Unique
27. 4. Combining words or making up new words entirely YouTube, Facebook, Myspace, GitHub
28. 第⼀一 印象 First Impression
29. SYNOPSIS
30. Which I learned from CPAN - an aged, fantastic site.
31. Synopsis is important because…
32. It may include a workable example to help others run a basic program
34. And of course, further development :)
35. You firstly see the synopsis of the API,
36. then read the tediously long description
37. 先看對⽅方條件好不好 再看是否進⼀一步交往
38. ⾔言簡 意賅 Easy to understand
39. • Describe what’s the project doing, and what’s the problem this project trying to solve. • Details & mechanism later. • Design & implementation doc for advanced users.
40. 友善 授權 License
41. http://inspire.twgg.org/internet/trends/item/74-comparison-of-five-kinds-of-standard-open-source-license-bsd- apache-gpl-lgpl-mit.html 五種開源授權規範的比較 • MIT License • BSD License • Apache License • LGPL License • GPL License
42. 簡易易 使⽤用 Easy to use
43. “設置到使⽤用” 非常重要 From Setup to Use
44. 多環境設置測試 Test on different platforms
45. 減少使⽤用者挫折感
46. 幫助使⽤用者”快速”建立環 境
47. 傻瓜都會⽤用建置步驟
48. For Contributors
49. “簡易易”有效的開發環境 建置步驟
50. 使⽤用良好的套件⼯工具避 免 dependency failure
51. 錯誤 排除 Debugging
52. Trouble Shooting Guide
53. List All The Problems that Your Users Might Encounter.
54. 詳細 確實 Details
55. 多數開發者還是依賴⽂文 件開發
56. 少數開發者才會去 trace code
57. 詳細的⽂文件對加入專案 的會很有幫助
58. 完整度的表現
59. 可增加使⽤用意願
60. 且可製造安全感的假象
61. 老王 賣瓜 Promote your project
62. 善⽤用媒體
63. • Mailing List • Google Group • IRC • Twitter • Facebook • Hacker News • 善⽤用 Mail Signature
64. 多管 閒事 Help others
65. 如果很閒的話 :-p
66. 上 Stack Overflow
67. “嘿 何不嘗試看看某 xxx 專案，也許符合你的需求。”
68. 打鐵 趁熱
69. “Hey, I fixed ….” “Hey, I added a new feature for …” “What if ….., can we make it?”
70. If you don’t reply them, you might lost these contributors.
71. Merged pull request makes people happy,
72. and they might send new pull request later…
73. 也就是: 如果你忘了了他們 貢獻者也會把你忘了了
74. ⽽而且不會回來來
75. If possible, try not to reject pull requests,
76. Rejecting pull request will stop their motivation
77. 盡量量不要發好⼈人卡
78. Help them improve the pull request and get the pull request merged.
79. To prevent rejecting pull requests
80. 或先收下 PR 來來再修改
81. Let them know: discuss before sending pull request
82. 步步 ⾼高陞
83. 版本號不⽤用錢 Bumping minor / patch version number doesn’t cost
84. 不該擔⼼心版本號跳太快 You should not worry about bumping the numbers
85. 語意化版本號 Semantic Versioning
86. 盡可能縮⼩小釋出版本 Release Small
87. 縮短釋出時程 Release Fast
88. 讓被合併的功能能儘快 在新版本釋出並使⽤用 Release Merged Features ASAP, of course you should test them
89. 正向 循環
90. Be kind to others
91. 尊重彼此 Respect each other
92. 避免“讀他媽的⽂文件” No RTFM
93. 彼此勉勉勵 Encourage Each Other
94. 列列出貢獻者 List Your Contributors in your README
95. –Field of Dreams “If you build it, they will come.”
96. Thank you c9s @ twitter / github / plurk