Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OSDC 2014 - Building Popular open source projects

OSDC 2014 - Building Popular open source projects

Yo-An Lin

April 11, 2014
Tweet

More Decks by Yo-An Lin

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. So you might ask

    View Slide

  4. “Is it important to make it popular?”

    View Slide

  5. “Yes!”

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. “Open source
    collaboration”

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 市場潛⼒力
    And find the market potential

    View Slide

  17. 獨特性
    Make it unique

    View Slide

  18. 爭議性
    Let people discuss

    View Slide

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

    View Slide

  20. You may focus on

    View Slide

  21. creativity / performance /
    simple interface / lightweight
    implementation / fun

    View Slide

  22. I started using GitHub
    since 2009

    View Slide

  23. for fun

    View Slide

  24. and wrote a lot of vim
    plugins, perl modules…

    View Slide

  25. Was really busy in the
    past few years

    View Slide

  26. Almost work from
    9 AM to 2 AM everyday

    View Slide

  27. holiday = working day

    View Slide

  28. Chinese cruel torture

    View Slide

  29. And we released a lot of
    open source projects
    from them

    View Slide

  30. From back-end to
    front-end

    View Slide

  31. phprew, pux, gutscript
    and so on…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 3. Unique

    View Slide

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

    View Slide

  39. 第⼀一
    印象
    First Impression

    View Slide

  40. SYNOPSIS

    View Slide

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

    View Slide

  42. Synopsis is important
    because…

    View Slide

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

    View Slide

  44. View Slide

  45. And of course, further
    development :)

    View Slide

  46. You firstly see the
    synopsis of the API,

    View Slide

  47. then read the tediously
    long description

    View Slide

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

    View Slide

  49. ⾔言簡
    意賅
    Easy to understand

    View Slide

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

    View Slide

  51. 友善
    授權
    License

    View Slide

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

    View Slide

  53. 簡易
    使⽤用
    Easy to use

    View Slide

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

    View Slide

  55. 多環境設置測試
    Test on different platforms

    View Slide

  56. 減少使⽤用者挫折感

    View Slide

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

    View Slide

  58. 傻⽠瓜都會⽤用建置步驟

    View Slide

  59. For Contributors

    View Slide

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

    View Slide

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

    View Slide

  62. 詳細
    確實
    Details

    View Slide

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

    View Slide

  64. 少數開發者才會去
    trace code

    View Slide

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

    View Slide

  66. 完整度的表現

    View Slide

  67. 可增加使⽤用意願

    View Slide

  68. 且可製造安全感的假象

    View Slide

  69. ⽼老⺩王
    賣⽠瓜
    Promote your project

    View Slide

  70. 善⽤用媒體

    View Slide

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

    View Slide

  72. 多管
    閒事
    Help others

    View Slide

  73. 如果很閒的話 :-p

    View Slide

  74. 上 Stack Overflow

    View Slide

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

    View Slide

  76. 打鐵
    趁熱

    View Slide

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

    View Slide

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

    View Slide

  79. Merged pull request
    makes people happy,

    View Slide

  80. and they might send
    new pull request later…

    View Slide

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

    View Slide

  82. ⽽而且不會回來

    View Slide

  83. If possible, try not to
    reject pull requests,

    View Slide

  84. Rejecting pull request
    will stop their motivation

    View Slide

  85. 盡量不要發好⼈人卡

    View Slide

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

    View Slide

  87. To prevent rejecting
    pull requests

    View Slide

  88. 或先收下 PR 來再修改

    View Slide

  89. Let them know: discuss
    before sending pull
    request

    View Slide

  90. 步步
    ⾼高陞

    View Slide

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

    View Slide

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

    View Slide

  93. 縮短釋出時程
    Release Fast

    View Slide

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

    View Slide

  95. 正向
    循環

    View Slide

  96. Be kind to others

    View Slide

  97. 尊重彼此
    Respect each other

    View Slide

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

    View Slide

  99. 彼此勉勵
    Encourage Each Other

    View Slide

  100. 列出貢獻者
    List Your Contributors in your README

    View Slide

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

    View Slide

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

    View Slide