Slide 1

Slide 1 text

Building popular open source projects 林佑安 / Yo-An Lin / @c9s Tips & Tricks

Slide 2

Slide 2 text

• 林佑安 Yo-An Lin (c9s) • GitHub: @c9s • Golang / PHP / JavaScript / Perl

Slide 3

Slide 3 text

So you might ask

Slide 4

Slide 4 text

“Is it important to make it popular?”

Slide 5

Slide 5 text

“Yes!”

Slide 6

Slide 6 text

群聚效應 “群聚效應(Critical mass) 是⼀一個社會動⼒力學的名詞, ⽤用來描述在⼀一個社會系統裡,某件事情的存在已達⾄至 ⼀一個⾜足夠的動量,使它能夠⾃自我維持,並為往後的成 ⻑⾧長提供動⼒力。”

Slide 7

Slide 7 text

若有⼀一個⼈人停下來抬頭往天望,沒有⼈人會理會他,其他 路過的⼈人會照舊繼續他們要做的事情。如果有三個⼈人停 了下來抬頭望天,可能會有多幾個⼈人會停下來看看他們 在做甚麼,但很快⼜又會去繼續他們原來的事。但假若當 街上抬頭向天望的群眾增加⾄至 5 到 7 ⼈人,這時,其他⼈人 可能亦會好奇地加⼊入,看看他們到底在做甚麼。 http://zh.wikipedia.org/wiki/群聚效應

Slide 8

Slide 8 text

也就是: 當某專案符合某個獨特的市場需求,⽽而且能夠受到注⺫⽬目, 不斷被群眾提起,⾃自然就能吸引更多的開發者重視,並 且加⼊入開發/⽀支援/貢獻。 有了動能,就算專案擁有者沒有持續開發,也可以讓專 案持續前進

Slide 9

Slide 9 text

開源之道 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/

Slide 10

Slide 10 text

“Open source collaboration”

Slide 11

Slide 11 text

前提是你的專案要有⼈人 願意參與

Slide 12

Slide 12 text

如果你想要有更多⼈人願 意參與 If you want more people join in

Slide 13

Slide 13 text

你必須把 open source 專案視為銷售產品 You need to treat your project as a product

Slide 14

Slide 14 text

–McCarthy “4P: Product, Price, Place, Promotion”

Slide 15

Slide 15 text

–Robert Lauterborn “4C: Customer needs and wants, Cost to the customer, Convenience, Communication”

Slide 16

Slide 16 text

市場潛⼒力 And find the market potential

Slide 17

Slide 17 text

獨特性 Make it unique

Slide 18

Slide 18 text

爭議性 Let people discuss

Slide 19

Slide 19 text

甚⾄至可嘗試負⾯面⾏行銷

Slide 20

Slide 20 text

You may focus on

Slide 21

Slide 21 text

creativity / performance / simple interface / lightweight implementation / fun

Slide 22

Slide 22 text

I started using GitHub since 2009

Slide 23

Slide 23 text

for fun

Slide 24

Slide 24 text

and wrote a lot of vim plugins, perl modules…

Slide 25

Slide 25 text

Was really busy in the past few years

Slide 26

Slide 26 text

Almost work from 9 AM to 2 AM everyday

Slide 27

Slide 27 text

holiday = working day

Slide 28

Slide 28 text

Chinese cruel torture

Slide 29

Slide 29 text

And we released a lot of open source projects from them

Slide 30

Slide 30 text

From back-end to front-end

Slide 31

Slide 31 text

phprew, pux, gutscript and so on…

Slide 32

Slide 32 text

My public contribution calendar was almost like this, 2013 and private repositories are not included.

Slide 33

Slide 33 text

Here is what I’ve learned. And which should be helpful for small projects to start.

Slide 34

Slide 34 text

專案 名稱 The name of a project should be easy to remember

Slide 35

Slide 35 text

1. Short name node.js, three.js, gearman, apache, nginx, jQuery, bootstrap, gem, rails and so on…

Slide 36

Slide 36 text

2. Pronounceable You don’t want a project named “hjkdvbjkGUI” or something

Slide 37

Slide 37 text

3. Unique

Slide 38

Slide 38 text

4. Combining words or making up new words entirely YouTube, Facebook, Myspace, GitHub

Slide 39

Slide 39 text

第⼀一 印象 First Impression

Slide 40

Slide 40 text

SYNOPSIS

Slide 41

Slide 41 text

Which I learned from CPAN - an aged, fantastic site.

Slide 42

Slide 42 text

Synopsis is important because…

Slide 43

Slide 43 text

It may include a workable example to help others run a basic program

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

And of course, further development :)

Slide 46

Slide 46 text

You firstly see the synopsis of the API,

Slide 47

Slide 47 text

then read the tediously long description

Slide 48

Slide 48 text

先看對⽅方正不正 再看是否進⼀一步交往

Slide 49

Slide 49 text

⾔言簡 意賅 Easy to understand

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

友善 授權 License

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

簡易 使⽤用 Easy to use

Slide 54

Slide 54 text

“設置到使⽤用” ⾮非常重要 From Setup to Use

Slide 55

Slide 55 text

多環境設置測試 Test on different platforms

Slide 56

Slide 56 text

減少使⽤用者挫折感

Slide 57

Slide 57 text

幫助使⽤用者”快速”建⽴立環 境

Slide 58

Slide 58 text

傻⽠瓜都會⽤用建置步驟

Slide 59

Slide 59 text

For Contributors

Slide 60

Slide 60 text

“簡易”有效的開發環境 建置步驟

Slide 61

Slide 61 text

使⽤用良好的套件⼯工具避 免 dependency failure

Slide 62

Slide 62 text

詳細 確實 Details

Slide 63

Slide 63 text

多數開發者還是依賴⽂文 件開發

Slide 64

Slide 64 text

少數開發者才會去 trace code

Slide 65

Slide 65 text

詳細的⽂文件對加⼊入專案 的會很有幫助

Slide 66

Slide 66 text

完整度的表現

Slide 67

Slide 67 text

可增加使⽤用意願

Slide 68

Slide 68 text

且可製造安全感的假象

Slide 69

Slide 69 text

⽼老⺩王 賣⽠瓜 Promote your project

Slide 70

Slide 70 text

善⽤用媒體

Slide 71

Slide 71 text

• Mailing List • Google Group • IRC • Twitter • Facebook • Hacker News • 善⽤用 Mail Signature

Slide 72

Slide 72 text

多管 閒事 Help others

Slide 73

Slide 73 text

如果很閒的話 :-p

Slide 74

Slide 74 text

上 Stack Overflow

Slide 75

Slide 75 text

“嘿 何不嘗試看看某 xxx 專案,也許符合你的需求。”

Slide 76

Slide 76 text

打鐵 趁熱

Slide 77

Slide 77 text

“Hey, I fixed ….” “Hey, I added a new feature for …” “What if ….., can we make it?”

Slide 78

Slide 78 text

If you don’t reply them, you might lost these contributors.

Slide 79

Slide 79 text

Merged pull request makes people happy,

Slide 80

Slide 80 text

and they might send new pull request later…

Slide 81

Slide 81 text

也就是: 如果你忘了他們 貢獻者也會把你忘了

Slide 82

Slide 82 text

⽽而且不會回來

Slide 83

Slide 83 text

If possible, try not to reject pull requests,

Slide 84

Slide 84 text

Rejecting pull request will stop their motivation

Slide 85

Slide 85 text

盡量不要發好⼈人卡

Slide 86

Slide 86 text

Help them improve the pull request and get the pull request merged.

Slide 87

Slide 87 text

To prevent rejecting pull requests

Slide 88

Slide 88 text

或先收下 PR 來再修改

Slide 89

Slide 89 text

Let them know: discuss before sending pull request

Slide 90

Slide 90 text

步步 ⾼高陞

Slide 91

Slide 91 text

版本號不⽤用錢 Bumping minor / patch version number doesn’t cost

Slide 92

Slide 92 text

盡可能縮⼩小釋出版本 Release Small

Slide 93

Slide 93 text

縮短釋出時程 Release Fast

Slide 94

Slide 94 text

讓被合併的功能能儘快 在新版本釋出並使⽤用 Release Merged Features ASAP, of course you should test them

Slide 95

Slide 95 text

正向 循環

Slide 96

Slide 96 text

Be kind to others

Slide 97

Slide 97 text

尊重彼此 Respect each other

Slide 98

Slide 98 text

避免“讀他媽的⽂文件” No RTFM

Slide 99

Slide 99 text

彼此勉勵 Encourage Each Other

Slide 100

Slide 100 text

列出貢獻者 List Your Contributors in your README

Slide 101

Slide 101 text

–Field of Dreams “If you build it, they will come.”

Slide 102

Slide 102 text

Thank you c9s @ twitter / github / plurk (Next talk: gutscript)