|
GitHuber.infoチームによる制作 序文 いつから始まったのかは分かりませんが、GitHubは今やトレンドになっています。星を2つもつけずに出かけるのは、もはや恥ずかしいくらいです。GitHuber.infoのおかげで、私たちはGitHubの膨大なデータにアクセスできました。@PythonEnthusiastsの提案を受け、GitHubにおける中国人開発者の現状をより具体的に理解していただくため、自らデータをスクレイピングして分析し、レポートを作成することにしました。 現在、GitHubには1,000万人以上の登録ユーザーがいます。正確性を確保するため、全ユーザーの個人情報をスクレイピングし、中国の開発者および中国の組織、そしてアメリカの開発者およびアメリカの組織をすべて除外しました。そして、それらのユーザーが公開しているプロジェクト情報をすべてスクレイピングして分析を行いました。 このレポートは3つのパートに分かれており、第1部は中国の開発者の現状、第2部は中国とアメリカの開発者の比較、第3部は国内の優れたオープンソースプロジェクトの作者へのインタビューです。 前半では、中国の開発者を個人情報、プロジェクト情報、組織情報の3つの側面から統計的に分析しました。データ量が膨大だったため、グラフを見やすくするために、類似区間を結合しました。 第 2 部では、個人情報、プロジェクト情報、組織情報の観点から中国とアメリカの開発者を比較し、私たちとアメリカの開発者の類似点と相違点を皆様に理解していただくことを目的としています。 第三部では、国内の優れたオープンソースプロジェクトの開発者にインタビューを行いました。様々なタイプのプロジェクトを意図的に選び、オープンソースプロジェクトの様々な発展の軌跡を紹介することで、あらゆるタイプの開発者が恩恵を受けられるようにしました。現在、国内のオープンソース環境はまだ発展段階にあり、探求すべき点が数多く残されています。このインタビューが、オープンソースについてより深く考えるきっかけになれば幸いです。 このようなレポートを作成するのは初めてで、時間と機材の制約もあり、当初想定していた内容やプレゼンテーション効果を全て実現することはできませんでした。しかし、タイトルの通り、今後もこのようなレポートを作り続けていきます。失敗は数え切れないほどあります。一つくらいならまだしも、一つくらいならまだしも、もし成功したら？もし皆様に価値を提供できたら？やりたいことは何でも挑戦すべきです。 これはバージョン1.0です。皆様からのフィードバックをもとに、今後もコンテンツの改善とアップデートを続けていきます。皆様からの様々なご意見・ご提案を心よりお待ちしております。WeChat、Weibo、メール、ウェブサイトなど、お好きな方法でご提供ください。いただいたご意見はすべて記録いたします。 GitHuber.infoチームのLuan Junqing氏とXia Tianhan氏には、本レポートへの多大な貢献に深く感謝いたします。インタビューにご協力いただいた著者の皆様には、多忙なスケジュールの中、時間を割いて私たちの質問攻めに辛抱強く答えていただき、感謝いたします。アドバイザーの皆様には、多くの有益なご提案をいただき、感謝いたします。視聴者の皆様も、必ずしも発言してくださっているわけではありませんが、それでも私たちに計り知れないモチベーションを与えてくれました。データマイニングにご協力いただいたHe Bin氏にも感謝いたします。そして最後に、本レポートを読んでくださった皆様にも感謝いたします。レポート自体には価値がありませんが、皆様の温かいご支援のおかげで、レポートは活力を得て輝きを放っています。本当にありがとうございました！ 梁潔 2015年1月29日 中国の開発業者データ統計 個人情報 上と下の2つのグラフは、中国地域のプログラマーの活動ピーク時間を示しています。右側の凡例はGitHub上の様々なイベントを示しており、最も高い灰色はPush、次に高いオレンジ色はWatchを表しています。土曜日の活動が最も低く、日曜日の活動は金曜日よりも高いことがわかります。1日の活動ピークは朝、夕方、深夜の3回で、深夜が最も高くなっており、多くのプログラマーが夜型であることが分かります。 polyrabbit は 129 の言語を使用しています。これは、彼のプロジェクト polyglot に、さまざまな言語のコード スニペットを収集したプログラミング言語のコーパスが含まれているためです。 プロジェクトにはサードパーティのライブラリが含まれる場合があるため、カウントされる言語数は実際に使用される言語数よりも若干多くなります。それでも、複数の言語に精通している人はたくさんいます。 GitHub APIから取得したデータはバイト単位であるため、行数ではなくバイト数を使用しました。また、行数よりもバイト数の方が正確であると考えています。 ほとんどの開発者のコード総量は10万バイトから100万バイトの範囲に集中していることがわかります。ご自身のコード量がどの範囲に該当するかは、こちらで確認できます。 フォークするかしないかの違いは甚大です。フォークを削除すると、基本的にフォークの数は桁違いに減り、人々がフォークをどれほど好んでいるかが分かります。私たちの理解では、フォークとはプロジェクトにコードを提供したいという意思を意味します。フォローするだけであれば、スターを付けるだけで十分です。また、プロジェクトをフォークすると、自分のプロジェクトの閲覧が妨げられることもあります。 最も多くのフォークを持つ友人は、8,000以上のプロジェクトを持っています。自分のプロジェクトリストを開くのはどんな感じか想像しにくいかもしれませんが、ぜひご自身で試してみてください。 開発者の大多数はフォロワー数が10人未満で、1,000人以上のフォロワーを持つ開発者は極めて稀です。相互フォローだけではせいぜい第3層までしか到達できないことが判明しました。第4層に到達するには優れたオープンソースプロジェクトが必要ですが、GitHubはコードが自ら語る場です。 スター数統計によると、ほとんどの開発者は500個未満のスターしか獲得していません。スターはブックマークリストのようなもので、スターが多すぎると使い勝手が悪くなる可能性があります。Oh My Starのような優れたスター管理ツールがいくつか登場しており、スターの価値を最大限に高めるのに役立ちます。 彼らをフォローする価値は何でしょうか？専門家が日々何をしているのかを知ることができるようです。しかし、プログラマー向けのソーシャルプラットフォームとしては、GitHubはインタラクションが多すぎて、Weiboほどユーザーフレンドリーではありません。GitHubのAPIを使ってモバイル版を実装するのは良い選択肢でしょう。 プロジェクト情報 ほとんどのプロジェクトのコードサイズは10,000～100,000バイト程度です。これは、フロントエンドプロジェクトが一般的に短く簡潔であるという事実と関係している可能性があります。後ほど、各言語のプロジェクトのコードサイズの分布を分析し、各言語の複雑さを確認します。 ブランチに関して言えば、ほとんどのプロジェクトは3つ未満のブランチしか持っていません。これは、ほとんどのプロジェクトがまだ完全に個別の開発段階にあり、標準化されたブランチが必要な段階に達していないことを反映しています。プロジェクトが拡大するにつれて、ブランチ管理は重要な要素となってきます。 PRとIssueの分布は驚くべきものではありません。プロジェクトの90%にはPRもIssueもほとんどありません。Li Chengyin氏へのインタビューでもこの問題について議論しました。オープンソースプロジェクトにとってフィードバックは非常に重要です。PRを提出できない場合でも、Issueを提出することでプロジェクトの改善に貢献できます。
組織情報 組織の全体的な分布傾向はプロジェクトと似ていますが、各種統計の割合はプロジェクトよりもわずかに低い傾向にあります。論理的に考えると、組織内のプロジェクトはより多くのメンバーを引き付け、PRやIssueのパフォーマンスが向上するはずです。一方、中国の組織は現在、その潜在能力を十分に発揮しておらず、オープンソースプロジェクトの発展に大きく貢献していません。現在、中国の優れたオープンソースプロジェクトは主にオフラインのチームコラボレーションに依存しており、米国のオープンソースプロジェクトのクラウドソーシングモデルに遅れをとっています。
#p# 中国とアメリカの開発者の比較 個人的な比較 画像の左側の凡例に記載されている言語の順序（上から下へ）は、言語のランキングを表しています。円グラフの時計回りの方向も、言語のランキングを表しています。 JavaScriptとCSSが大きな優位性を持っていることは明らかで、合わせてランキングの約3分の1を占めています。中国と米国の間の最大の違いはJavaとRubyにあり、そのランキングはほぼ完全に対称的です。中国で非常に人気のある言語であるJavaが上位にランクインしているのは当然のことですが、同じく人気のある言語であるPHPは、米国での使用率よりも低いランクインにとどまっています。中国のPHP愛好家は、オープンソースにそれほど熱心ではないようです。 右側は、中国と米国の個人統計の比較を示しています。1つ目と3つ目のグラフでは、中国と米国の分布は非常に似ています。2つ目と4つ目のグラフでは、若干の違いが見られます。最初の区間では、中国の割合が米国よりも小さくなっていますが、他の区間では、中国の割合が米国よりも大きくなっています。 最初のセグメントは非アクティブユーザーを示しており、米国では中国よりも非アクティブユーザーの割合が高いことがわかります。2番目のセグメント以降はアクティブユーザーを示しており、中国のアクティブユーザーの割合が米国を上回っています。 このような状況の主な原因は、米国の開発者数が非常に多いことです。中国の開発者は約6万7000人ですが、米国の開発者は約36万人です。このような状況下では、米国の方が非アクティブユーザーの割合が高いのは当然のことです。量の増加は往々にして質の低下につながります。総数が同程度になった場合でも、割合の面で依然としてトップの地位を維持できると期待しています。 プロジェクト比較 左側は、中国と米国のプロジェクト統計の比較を示しています。ご覧のとおり、3つのグラフの比較結果は非常に似ています。最初の区間では中国の割合が米国を上回っていますが、他の区間では中国の割合が米国よりもはるかに小さいことがよくあります。 後続のグラフの比較結果から、米国における進行中のプロジェクト数は中国を上回っていることがわかります。2番目の期間から見ると、米国のプロジェクト数の割合は中国の3倍に達し、絶対数は中国の10倍以上であることがわかります。 全体的に見ると、個人情報の面では米国は中国よりわずかに劣っていますが、プロジェクトの比較では中国より強く、米国のアクティブユーザーの活動レベルは実際には中国よりもはるかに高いことがわかります。 コード量の比較は非常にユニークです。当社の統計によると、中国には約22万件のプロジェクトがあるのに対し、米国には約100万件のプロジェクトがあります。これは、米国のコードの大部分が第2および第3の区間に集中しており、その量は中国よりもはるかに多いことを意味します。 拠点数で言えば、米国と中国はほぼ同等です。しかし、後者の地域に拠点が集中しているのが現状です。先ほども申し上げたように、量の増加は往々にして質の低下につながります。こうした観点から、当社は現状、量と質の両面で劣勢にあり、更なる発展が求められています。 組織の比較 組織構造の面では、中国はやや劣勢です。中国では2,500の組織、米国では約25,000の組織について統計を取っていますが、米国は中国の10倍の組織数を有しています。従業員数は中国の4倍ですが、組織数は10倍を誇り、組織指標も中国を上回っています。これは、米国の組織構造全体が非常に強固であることを示しています。 平均値の比較 #p# 国内の優れたオープンソースプロジェクトの作者へのインタビュー Eチャート G: 自己紹介をお願いします。 Lin Feng：Lin Fengは、Open Source Chinaでは@Kener-林峰、GitHubでは@kener、Weiboでは@Kener-林峰として知られています。BaiduのCommercial Front-end General Technology Groupで、シニアフロントエンド開発エンジニア兼データビジュアライゼーション部門の責任者を務めています。デザインとプログラミングを得意とし、ZRenderとEChartsの作者でもあります。現在は、データビジュアライゼーションの研究に注力しています。 G: ECharts とその応用シナリオについて簡単に紹介していただけますか? Lin Feng：データ可視化製品は数多く存在しますが、EChartsは再利用可能なビジネスデータ可視化のニーズに応えるという位置付けで、HighchartsやFusionChartsといった既存製品と同等の地位にあります。もちろん、これらは成熟した商用有料製品ですが、私たちは無料・オープンソースとして提供しているため、まだ開発段階にあり、完成度という点では大きな差があります。しかし、控えめに言っても、EChartsの高度なパーソナライゼーションとインタラクティブ性は、多くの面で業界をリードしています。ドラッグ＆ドロップによる再計算や大規模散布図は国家特許を取得しており、データビュー、値範囲ローミング、サブマップモードなどはいずれも業界初かつ独自の機能です。適用シナリオは非常に幅広く、様々な業界のニーズに対応しています。インターネット業界では、レポートシステム、運用保守システム、ウェブサイトの表示など、データ可視化のニーズがあるあらゆる用途に活用できることは言うまでもありません。メディアでは近年、データジャーナリズムへの注目が高まっており、Caixin Mediaはその先駆者として、データジャーナリズムの可視化ツールとしてEChartsをいち早く活用した企業の一つです。実際、マーケティングやディスプレイ広告、企業ブランドプロモーション、営業収益の報告・分析など、あらゆる分野で様々な活用シーンが広がっています。ビッグデータの過大評価の有無に関わらず、データは多くの企業にとって最も価値のある資産の一つとなっており、データが存在する限り、その需要は確実に高まっていくでしょう。 G: ECharts を開発するというアイデアは、どのようにして最初に思いついたのですか? リン・フェン：百度に入社した時、私は会社にとって極めて重要な製品、Phoenix Nestシステムを担当することになりました。2年以上の努力を経て、私は初心者からベテランへと成長し、Phoenix Nestのフロントエンドの技術リーダーとなりました。日々、あらゆる種類のデータに接し、データの価値と力を理解し始めました。それは2012年末のことでした。「ビッグデータ」という言葉が生まれたばかりで、データビジュアライゼーションは（少なくとも中国では）まだ広く知られていませんでした。スティーブ・ジョブズがiシリーズでのFlashの実行を禁止し、HTML5が急速に普及し始めた頃でした。Phoenix Nestシステムのデータレポートを視覚化するためのソリューション、Phoenix Nestシステムのユーザーエクスペリエンスモニタリングデータを視覚化するためのソリューションなどを見つける必要がありました。プログラミング、デザイン、そしてデータの組み合わせはまさに私にぴったりだと感じ、データビジュアライゼーションの研究へと進みました。 Baiduのフロントエンド開発のリーダーであるErikが復帰した後、彼は商用フロントエンドの総合技術グループを結成し、データ可視化の方向性を具体的に策定しました。そのため、私はPhoenix Nestの技術リーダーから自然と現在の職務へと移行し、その後、非常に深い穴（EChartsの機能設計）を掘り下げることになりました。その後1年間、チームと共にこの穴を少しずつ埋めていく作業に取り組みました。 G: EChartsは中国で最高のオープンソースプロジェクトにまで成長しました。EChartsがどのようにして今日の地位を築いたのか、皆さんとても興味を持っているのではないでしょうか。その過程と、最も印象に残った出来事についてお話しいただけますか？ リン・フェン：最高だとは言いたくありません。ただ、自分が興味を持ち、会社と業界にとって価値のあることに熱心に取り組んできただけです。EChartsは19ヶ月目になります。毎日EChartsのスター数を確認し、100個ごとに記録しています。今ではすっかり生活の一部になっています。リーダーたちが私たちに信頼を寄せ、チームメンバーのほとんどが自由に働けるようにしてくださったことに感謝しています。監視を気にする必要はなく、交流会に出かけたり、視野を広げるために展示会を訪れたりすることもできます。気が向いたら、一日中カフェで過ごすこともできます。信頼によって得られるこの自由は、労働時間や効率を低下させることはありません。チームメンバーは、いつでもどこでも（レストラン、地下鉄、空港、病院など）働くことに慣れていると思います。重要なのは、誰もが自発的に働く意欲を持っていることです。おそらくこれが、EChartsの多くの独創的な機能の背後にある理由でしょう。夜更かしして、同僚たちの傑作がチャットに突然現れた回数は数え切れないほどです（お互いを褒めたりお世辞を言ったりする言葉はとっくに尽きています）。そして、突然ひらめきが湧き、夜中に起きてプログラミングに取り組んだ回数も忘れてしまいました。プログラミングは創造的な取り組みであり、言うまでもなく芸術でもあります。心から楽しめず、9時から5時までの仕事としてしか考えていないなら、クリエイティブにはなれません。 EChartsの歩みを共に歩んでくださった皆様に心から感謝いたします。Shen Yi、Zu Ming、Dong Rui、Su Shuang、Hong Qi、Yang Ji、Ding Ding、Huang Yue、Tong Bing、Tai Yun、Zhou Yang、Shi Wei、Hu Yao、De Cheng兄さん、Li Zhanゼネラルマネージャー、Zhi Minゼネラルマネージャー、Chen Wei先生、そしてもちろん、皆様。思い出に残る出来事はすべて皆様のおかげです。ECharts 1.1.0を発表したWeiboの投稿は、私たちが初めて500回以上リツイートされた投稿となりました（幸いなことに逮捕はされませんでした）。バージョン1.3以降、私たちは「可視化分野の新星」として称賛され、主要な主流技術メディアに掲載され、その年の中国で最も注目されたオープンソースプロジェクトのトップ10にランクインしました。バージョン1.4以降、EChartsは既に3つの異なるプログラミング言語で提供されており、「なぜEChartsなのか」というプレゼンテーションは、R言語やデータベースに関するカンファレンスで取り上げられました。ECharts 2.0のリリース前夜、社内の様々なスクリーンに「EChartsよりも優れたチャートが間もなく登場します」という宣伝ポスターを掲示し、多くの支持を得ました。ささやかながらも嬉しい驚きでしたが、ECharts 2.0のリリースは、ビッグデータ関連のほぼすべての主要なWeChat公式アカウントの見出しを飾ることになりました。これは私たちにとって大きな挑戦であり、予想をはるかに超えるものでした。2014年6月30日には、EChartsの誕生1周年記念パーティーを開催し、象徴的な小さなクジラのキャラクターをお披露目しました。ECharts 2.0の後、私たちのチームはEChartsをベースにしたアプリケーション「Baidu Tushuo」を公開テスト用にリリースしました。北京、上海、広州、杭州、武漢、ハルビン、西安など、様々なイベントや企業で数え切れないほどのプレゼンテーションを行ってきました。アメリカの同僚たちに私たちの素晴らしさを見せるため、この小さなクジラをシリコンバレーに連れて行ったことさえあります。私たちは広州に行き、翌日のプレゼンテーションの準備で徹夜し、正式にTushuoをリリースしました。嬉しいことに、このイベントは翌日の広州日報の見出しを飾りました。EChartsバージョン2.1.8の公式英語ウェブサイトがついに公開され、私たちの国際展開の始まりとなりました。私たちは、GitHub Explorerのデータ可視化セクションに選ばれた、中国初にして現在唯一のオープンソースプロジェクトとなりました。そのわずか2か月後、Jaroslav BencがDatamatic EChartsエディション（チャートの英語版）をリリースし、私たちに計り知れないプレッシャーをかけてきました。あの外国人プログラマー（敬意を込めて）は、本当にすごいですね！ GitHubのトレンドリストへのログイン、スターが5000を超えたこと、Baiduとの共同プロジェクトの立ち上げ、ナレッジグラフ、ワールドカップなど、思い出は鮮やかです。思い出に残る瞬間がたくさんあります。いつもそばにいてくれてありがとう。 G: ECharts は現在どのような問題に直面していますか? また、今後の開発計画は何ですか? Lin Feng: 私たち自身のプロジェクトのアップグレードとメンテナンスにおいて、最大の問題はメインモジュールのコードサイズと機能の結合です。これをさらに細分化し、より細かい粒度に分割し、動的かつオンデマンドでアセンブルできる機能を提供する必要があります。 プロジェクトに取り組んでいる開発者には、より詳細でユーザーフレンドリーなドキュメントとヘルプが必要です。チュートリアルの作成を始めようと思っています（半年ほど前から計画していたのですが…）。 チャートリーダー向けには、モバイルデバイスへの最適化、見た目の改善、大規模データセットでのパフォーマンス向上などが含まれます。ECharts 2.2はすでにモバイルデバイスへの大幅な最適化が行われており、ECharts-m（EChartsモバイル版）もまもなくリリースされます。今しばらくはご期待ください。さらに楽しくなるEChartsを、もうすぐお見せします。 G: EChartsの開発には多くの困難があったと思いますが、どのように乗り越えたのでしょうか？ Lin Feng：未完了のタスクリストは必ず存在します。これはEChartsを書き始めた頃からずっと言っていることです。以前はこのタスクリストをクリアできるかどうか確信が持てませんでしたが、今は完全に確信しています -_-。 チームであれ個人であれ、能力と時間は常に限られています。できること、すべきことはたくさんあります。できる限り多くのニーズとフィードバックを集め、また集めるべきですが、真のニーズと疑似ニーズ、あるいは不合理なニーズを区別することを学ぶ必要があります。ユーザーに左右されることなく、シンプルに物事を進め、自分のペースを維持することを学びましょう。 もう一つの問題は、多くの人がBaiduの製品を見ると、品質に関わらず「Googleが作っているものは何でもBaiduが作っている」と、すぐに怒り狂ってしまうことです。そしてさらに、「これは明らかに[製品名]の模倣品で、[製品名]よりはるかに劣っている」などと、さらに侮辱を加えます。最初は、Baiduとの違いや独自の機能について丁寧に説明しました。しかし、彼らは相変わらず些細なことにこだわり続け、うまく動作しないとドキュメントのせいにし、期待に応えられなければバグだと主張しました。後になって、彼らの要求に応えるために時間を無駄にするのは全く無意味だと気づきました。自分の仕事に集中し、我慢して、放っておけばいいのです。自分の仕事をきちんとやり遂げれば、彼らは徐々に黙っていくでしょう。本当にEChartsが必要なら、最終的には自分で解決策を見つけるか、ドキュメントの書き方がまずいと周りに尋ねるでしょう。 一部の人々を無視していたかもしれませんが、後になって気づいたのは、自分がすべきことにエネルギーを集中させることが、より多くの人々に責任を負っているということだったのです。ズーミングの言葉を借りれば、これは「私たちの指先にある責任」なのです。 G: EChartsの開発モデルについて簡単に説明していただけますか？例えば、趣味として始まり、最終的に企業の支援を受けるようになったのでしょうか？それとも、最初から企業によって支援・運営されていたのでしょうか？もし他の開発者がこのモデルに倣いたいと考えている場合、どのようなアドバイスをされますか？ リン・フェン：EChartsの起源については、ご自身で調べてみてください。私はとても幸運でした。EChartsは私自身が興味を持っていただけでなく、会社のニーズでもありました。多くの優秀なリーダーがいて、私のやりたいことを何でもやらせてくれました。そして、事業が拡大するにつれて、彼らは私を支え、助けてくれました。 プロジェクトを成功させる上で最も重要なのはチームの力です。同じ志を持ち、才能あるパートナーを見つけて共に働く必要があります。EChartsチームは、部門横断型のバーチャル組織です。百度のFEスタッフ全員からメンバーを採用しています。チーム結成時に、私は「忙しい、あるいは時間がないなら、一時的にチームを離れてください。いつでも戻ってきてください」というルールを決めました。最初の数ヶ月は2週間ごとにメンバーを入れ替え、様々なメンバーが入れ替わりました。しかし、6ヶ月後にはチームはほぼ安定し、ディンディンの言葉を借りれば、私たちは小さな家族になったのです。 G: 最後に、オープンソースについてお話しましょう。一般的なプログラマーにとって、オープンソースの意義とは何だとお考えですか？オープンソースとGitHubという言葉は誰もが耳にしたことがあるでしょうが、壮大な理論のように、実際には両者を組み合わせるのは難しい場合が多いです。プログラマーはGitHubをどのように活用すべきだとお考えですか？ Lin Fengさんの投稿はとても有意義で、私も勉強になります！トッププログラマーのコードを見るのは喜びです。真似から理解、そして自分のプログラムへの統合まで、それが成長です。私の周りの多くのトッププログラマーは、GitHubを遊び場やおもちゃ屋のように扱っています。これは子供っぽいという意味ではなく、プレイヤーとしての姿勢を持ち、楽しみを楽しむということです。いじくり回すことを学びましょう。GitHubには数え切れないほどの素晴らしいプロジェクトがあります。ぜひ積極的に手を動かし、実験し、これらのオープンソースコミュニティに貢献してみてください。最初は、問題への参加、フィードバックの提供、ドキュメントの誤字脱字の修正だけでも意味があります。そして、自分のアイデアを出し合い、他の人の問題解決を支援しましょう。コードに貢献し始めると、オープンソースが自分にとってどれほど重要かが理解できるかもしれません。 G：2014年、中国では多くの優れたオープンソースプロジェクトが誕生しました。その多くは企業が関与しているようです。これは、大企業のプログラマーが中核的な貢献者となっている海外の優れたオープンソースプロジェクトと似ています。企業はオープンソースプロジェクトにおいてどのような役割を果たしていると思いますか？現在の中国の環境において、企業はどのようにして成功するオープンソースプロジェクトを構築できるのでしょうか？ Lin Feng：会社にとって、オープンソース化は貢献者であると同時に受益者でもあります。会社は、自社の事業に関係のないプロジェクトや、理由もなく利用することすらできないプロジェクトを立ち上げることはありません。優れたプロジェクトは、より多くの注目、フィードバック、そしてコード貢献を引き付けることができます。もしプロジェクトをオープンソース化することで、プロジェクトの発展が促進されるのであれば、それは会社自身のプロジェクトニーズにとって意義深いだけでなく、特定の分野（Android、Linux、jQuery、Bootstrapなど）における技術的リーダーシップを確立することにもつながり、それは間違いなく会社にとって素晴らしいことです。 企業がオープンソースプロジェクトを運営できるかどうかは、その企業の状況やコアバリューによって異なるため、一概には言えません。ただ、企業内でオープンソースプロジェクトに取り組む場合、重要なのはプロジェクト自体が企業に価値をもたらすかどうかです。短期的価値と長期的な価値の両方が実現できれば理想的です。 追伸：私たちはまだ成功には程遠く、成功談を共有する時期ではありません。 シンクJS G: 自己紹介をお願いします。 Li Chengyin: Li Chengyinと申します。7年ほど働いています。以前はBaiduで働いていましたが、現在は360にいます。今後のことはまだ分かりません。以前はバックエンド開発に携わっていましたが、今はフロントエンド開発とNode.jsが中心です。私がやりたいこと、そして取り組んできたのは、エンジニアリング、ツール、そしてプロセスの最適化です。チームの開発効率を向上させたいと思っています。 G: ThinkJS を開発した理由は何ですか? Li Chengyin: Expressを使っていた時、フレームワークの機能が限られており、特定のビジネスニーズに迅速に対応できないと感じました。さらに、Node.js独自の非同期構文は書きやすく使いにくいと感じました。以前ThinkPHPを使っていたこともあり、Promiseを使った同様のNode.jsフレームワークを開発したいと考えていました。 G: ThinkJS はどのようにして生まれたのですか? Li Chengyin: 当初は趣味として開発を進めており、最初からプロジェクトとして取り組むつもりはありませんでした。2014年4月、社内外問わず多くの方がThinkJSを利用しており、真のニーズがあることが分かりました。そこで開発を進め、正式な部門プロジェクトとして位置付けることにしました。そして2014年9月22日にバージョン1.0が正式リリースされ、ThinkJSは正式な開発プロジェクトとなりました。バージョン1.0以前は主に私の個人的なアイデアを実装していましたが、正式な部門プロジェクトとして、部門はより多くの時間と人材を投入し、プルリクエストのマージも検討するようになりました。 G: ThinkJS がオープンソースのアプローチを採用することにしたのはなぜですか? Li Chengyin：実際、企業は現在、企業秘密に関係のないあらゆるもののオープンソース化を奨励しています。フロントエンド開発では、コードを隠蔽することはできないので、オープンソース化して、より良い考え方で受け入れるべきではないでしょうか？これが、GitHubに多くのフロントエンドプロジェクトが存在する理由です。ThinkJSはバックエンドフレームワークですが、私たちもそのような考え方を持っていたので、最初からオープンソース化するのは自然な流れでした。 G: オープンソースは ThinkJS に何をもたらしましたか? Li Chengyin：オープンソースはより多くのユーザーを呼び込むことができ、社内では発見できない問題やニーズをより多く発見し、プロジェクトの発展に貢献します。さらに、オープンソースプロジェクトはチームとメンテナー自身にも大きなメリットをもたらします。オープンソースプロジェクトでは、技術面以外にも、ドキュメントの作成やユーザーとのコミュニケーションなど、多くの作業があります。これらの作業を通して、多くの重要なスキルが養われ、開発者自身の長期的な成長に大きく貢献し、後に大規模なプロジェクトに取り組む際にも大きな力を発揮します。 ドキュメントを書くのも嫌いです。一度書いてしまうと、コードが変更されるたびに更新しなければならないからです。しかし、多くのユーザーはドキュメントだけを読み、コードを読むことはありません。そのため、ドキュメントの質は、プロジェクトの始めやすさや使いやすさに直接影響します。 G: ThinkJS はプロモーションなど会社から何か支援を受けているのでしょうか? Li Chengyin: ThinkJS は実際には企業ではなく、部門としてオープンソース化されています。この利点は、より自由度が高く、企業との結びつきが弱いことです。これはプロジェクトの開発にとって良いことです。プロジェクトが企業と非常に密接に結びついている場合、プロジェクトリーダーが退職すると継続できなくなる可能性があります。企業からのサポートが多少減る可能性はありますが、コミュニティからのサポートが中心となるため、長期的にはプロジェクトの発展にとってより有益です。 G: ThinkJS はどのようにして個人プロジェクトから正式な部門プロジェクトになったのでしょうか? 李承銀：主な理由は2つあります。まず、当時既にThinkJSを使っている人が何人かいて、このプロジェクトの効果を実感できたことです。また、Node.jsの人気が高まっていたこともあり、このプロジェクトは将来性が非常に高いと感じたため、正式な部門プロジェクトとなりました。これは実に自然な流れでした。個人的な興味から始まったプロジェクトでも、実際に使ってみて皆に認められ、大きな可能性を秘めているのであれば、部門としても認められる可能性は高いでしょう。 相对来说，产品型的项目更容易得到认可，因为产品类型的项目更容易看到效果，技术类型的项目有时候很难统计使用情况，有些公司并不会公开他们使用的技术。不过总体来说，只要一个项目能体现出它自己的价值，就很容易变成部门的项目。 G：你觉得国内的开源现状如何呢？ 李成银：目前国内的开源项目基本上都是团队内部在开发，即使是非常成功的项目PR 也非常非常少，所以目前来说国内的开源环境仍然不够活跃不够开放。一个项目出来会被很多人骂，不过关键就是别人骂了我们我们还不知道，也就无法改进。我们觉得骂本身不是坏事，说明用户还是需要你的项目的，只是项目不够好而已。但是关键是骂也要去Issue 里骂，这样我们才能看到。总体来说国内的开源环境已经比之前要好了，Issue 多起来了，PR 也有一些，不过目前来说还不够成熟，不能像国外的项目一样能够通过PR 完成很多功能。 其实也不能怪大家，国内和国外的工作情况就不一样。国外大家把编程当兴趣来做，工作也没有国内这么忙，所以有更多的时间和兴趣投入开源项目中。国内经常加班，压力很大，大家对于开源的热情就不高，更多的是把开源项目当做一个宝库，遇到问题的时候去找现成的解决办法，而不是参与其中。 此外，大家更喜欢用国外开源项目还有一个原因，就是国外的项目更加稳定，不太容易出现项目无人维护的情况。国内的开源项目有时候开发者会放弃并停止更新，这样依赖这些项目构建的项目就会很难处理，而国外的开源项目即使维护者停止更新，他也会找到其他人继续维护，比如前段时间的Express，这就让用户很有安全感。 Cocos2d-x G：请简单介绍一下你自己吧。 林顺：林顺，Cocos2d-x 的联合创始人，从小喜欢玩游戏，暴雪粉，星际死忠粉，最近爱上风暴英雄，喜欢不受打扰写代码，喜欢数码电子。 G：Cocos2d-x 大家应该都听过了，说实话我第一次听到它的时候还以为是国外的开源项目，后来知道是国人开发的时候非常惊讶。虽然Cocos2d-x 在国内已经非常有名，不过对于大多数没有接触过游戏的开发者来说可能不太了解，你能介绍一下Cocos2d-x 以及由它延伸出的整条产品线吗？ 林顺：Cocos2d-x 是专业的跨平台移动游戏引擎，采用MIT 协议，从2010 年7 月提交第一行代码到GitHub 就是完全开源免费的，目前在全球超过25% 的市场份额，而在中国这一份额超过70%，全球超过40 万的开发者正使用该引擎开发游戏。X 代表着Cross，为开发者提供了跨平台支持，采用C++ 语言编写一次游戏逻辑即可编译到iOS、Android 以及更多手机平台上运行，并且运行性能是最高效的。2012 年初Google 赞助Cocos2d-x 团队创建了Cocos2d-html5 分支，并在Zynga 的帮助下完成了JSB（JavaScript Binding）产品的开发，实现了JS 脚本游戏一次开发，不仅能跨原来Cocos2d-x 支持的所有平台，还能发布到Web。 目前Cocos2d-x 的工具链已经覆盖了游戏从新建项目一直到游戏SDK 接入、打包发布的全过程，集成开发工具Cocos Studio 支持快速原型构建和验证，调试脚本代码和应用打包使用Cocos Code IDE，AnySDK 高效快速接入海量渠道。此外，Cocos 社区还有Cocos Play 和Cocos Runtime 来实现游戏的点击即玩效果，提升游戏转化率。2015 年3D 和3D 编辑器将是Cocos2d-x 的发展重点，秉承最高效，体积最小的优势，提供更强大的3D 功能，支持用户使用Cocos2d-x 的3D 版本做出优秀的3D 游戏作品。 G：Cocos2d-x 应该从诞生开始就是由公司在运作的项目吧，最初公司为什么选择做游戏引擎，又是如何决定把它开源的呢？ 林顺：Cocos2d-x 从最开始就是完全开源、免费，当时Cocos2d-x 项目的目标是为我和王哲所在的操作系统公司提供游戏内容。一个新操作系统，全新的生态，没有很好的游戏内容，一点都不高大上，而是高处不胜寒，所以我们开发Cocos2d-x 这个跨平台的开发工具，让开发者可以快速的将游戏发布到iOS 的同时，能快速、低成本的发布到Android，最后顺手一编，将游戏内容也导入我们的操作系统，实现零落差同步导入最优秀的游戏内容。 G：目前在国外已经有一套很成熟的公司参与开源甚至主导开源的模式，但是在国内这还是一个比较新的概念。开源本身的不确定性和公司需要的可控性应该是矛盾的，触控科技是如何处理这个矛盾呢？ 林顺：开源引擎在不确定性和可控性上并没有很大的矛盾，目标都是提高效率，降低成本，更好的为商业游戏开发服务。 开源游戏引擎的好处是可以从社区获得最直接的需求，接地气，推动产品往正确的方向快速发展；社区的代码贡献者也能共同分享他们的成果，从而加速产品升级。Cocos2d-x 的发展离不开触控科技《捕鱼达人》系列游戏的推动，《捕鱼达人1》基于Cocos2d-x v1.0，引擎所有技术上的坑是捕鱼游戏最先趟平的，国内各种奇葩机型的适配和性能优化，也都是基于捕鱼达人进行验证。 G：Cocos2d-x 整条产品线发展到现在的规模和知名度，你觉得开源在其中起到了什么作用呢？ 林顺：开源在里面有决定性的作用，首先开源社区的需求驱动模式，为我们提供了最好的需求参考，其次，来自全世界超过300 位的优秀工程师在为引擎贡献代码，这是一笔无法估算的财富，如果不是因为开源模式，我相信没有哪家公司能让这么多的优秀工程师在为同一个项目贡献代码。最后，开源免费的模式，让更多人能从中受益，他们的口口相传才造就了今天Cocos2d-x 的口碑和用户基础。 G：什么事都是有利有弊，你觉得公司主导的开源项目相比个人或者社区主导的开源项目利在哪里，弊又在哪里呢？ 林顺：有公司或者资本提供支持的开源项目，相对于个人或者没有资本支持的开源项目的优势：有更多的资源投入，对开源项目的后期发展至关重要，允许有更多专职的研发人员，产品的迭代周期和质量也能得到很好的控制，提供更加持续长久的维护，可以让开源产品走的更高、更远。至于弊端，那就得看对开源项目的态度，如果本着服务行业，推动行业升级，用开放的心态来做开源项目，并不会存在着什么弊端，全世界范围内也并不乏有各个公司支持的开源项目。当时我们的操作系统公司做的不好了，引擎项目发展的却是很好，愿意投资我们的有好几家，但是最后还是觉得陈昊芝思路很开放，能坚持不把一个开源的项目做成闭源商业项目，最终和他一起做，一路走来，也发现我们当初的选择是最正确的。 G：如果其他公司也想走开源路线，有什么话想对他们说吗？ 林顺：非常欢迎一起加入开源路线，开源项目不论是对个人和对公司，能学习到很多宝贵的知识，社区里汇集的智慧是巨大的宝贵的，国外资深程序员教你两招，你就能发现原来代码还能这么写，框架还能这么设计优雅。另外，和社区做好互动，有效采集用户需求和反馈，是推动开源项目往正确方向发展的关键，也是产品化和易用化的捷径。 G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用GitHub 呢？ 林顺：参与开源项目对于程序员来讲是一种高效、快速学习成长的方法，不仅如此，如果你是一个技术爱好者，参与开源项目你有可能找到自己的兴趣，擅长结合点。当然，如果能找到和商业的结合点，进而从事自己喜欢的工作，那就更爽了，这点是很难得的。 一般有秩序的开源社区都提供很好的知识和经验交流平台，深入参与到开源项目中，对个人的技术成长和视野会有很大的帮助。 GitHub 在全球的火爆程度无需多表，提供非常高效的项目开发协作机制，是了解开源项目运作机制的很好入口。在GitHub 上，开发人员可以随时与全世界的人共享代码，也允许接受来自全球不同地方的人贡献各种idea，代码片段，也是社区交流的基础，越来越多的开源项目迁移到GitHub 上。最后，欢迎各位加入Cocos2d-x 开源项目社区，成为我们社区的一份子，实现自己的游戏梦想。 ペン G：请简单介绍一下你自己吧。 小鱼：大家都叫我小鱼，在大部分需要ID 的网站叫一般用sofish。法学院毕业后，就一直写代码。 G：你做过很多开源项目，我们就聊聊Star 最多Pen 吧。Markdown 相关的项目非常多，不过Pen 这样的项目我确实是第一次见到。简单介绍一下Pen 的用途吧。 小鱼：Pen 是一个支持Markdown 的可视化（实时编译）编辑器。 写Pen 是因为当时觉得百姓网用户发贴的体验应该更好一点，刚好GitHub 当时有一个ZenPen 的项目很火，准备用。不过这货代码耦合度太高，CSS / JS 也分不开，还不能自定义功能。觉得非常鸡肋，无奈就只能自己写。目标就是编辑的时候与发布结果一样，真正的WYSIWYG，并支持自定义功能，CSS / JS 也好分开。而刚好Markdown 的一些语法比较简洁，就直接支持了。当时上了Trending，GitHub 的员工给提了一个非常给力的PR，支持显示Markdown。 不过后来觉得太麻烦，没集成在产品上，也就一直没更新。直到Teambition 在用，严清同学贡献了很多代码，也解决了很多隐藏的Bug。 G：最初是如何想到要做Pen 这么一个项目呢？做得过程中有什么有意思或者让你印象深刻的事情呢？和我们分享一下吧。 小鱼：像上面说的，直接原因是工作需要。我的大部分开源项目，除了Typo.css，直接原因都是想把工作中一些功能抽象成模块，顺路就开源了。像最早的AliceUI 是已经大面积用在了支付宝上，才开源的。要说印象深刻，我觉得开源的项目一定要用在某个产品上，特别是商业项目，才能变的真正好用，因为无论是开源还是闭源都需要保证质量的动力，而工作就是动力之一。任何没真正用在商业产品上的开源项目，都是要慎用的，也称不上好。 G：Pen 是如何获得这么多的Star 呢，你有做过什么相关的推广吗？ 小鱼：没有，就是发了一下微博和V2EX，然后就好多人关注了。 G：作为中国区排名前十的开发者，你平时的工作应该也很忙吧，你是如何在这种情况下完成Pen 这个项目的呢？ 小鱼：工作也忙的，不过不会完全没有时间。我人生中最忙的阶段似乎是在写我这句话的前6 个月内，因为做产品的同时要带人，常态是回到家都是10 点以后，因此最近也没什么产出，除了m.ele.me 已经上线，并没有什么开源项目。相比构思Pen 应该是什么样的，体验要达到什么程度，写Pen 花的时间并不多，300 行代码对我来说难度并不大。顺路说下，ZenPen 当时应该是几千行级别的，但功能没有Pen 好。 G：你觉得作为个人开发者来开发和维护一个开源项目难度大吗？中间有没有想要放弃的时候呢？ 小鱼：难度还是要看项目吧。不过我相信人多不一定能解决问题，因为技术问题普遍都有天花板，对于核心思想和技术，大多情况下应该是由更少的人产出的。思想定了，核心技术定了，添加功能可能并没有想象中那么难。而对于有没有放弃，我通常是这样想的，最差的可能就是放弃。坚持会发生很多美好的事情，比如写博客。如果有很多紧要的事，时间不多，有时候也只能放弃，只做觉得紧要的。 G：你觉得纯个人开发开源项目和有公司背景的开源项目比起来有什么本质的区别呢，作为一个开发者应该如何选择？ 小鱼：本质上都是开源。个人并没有统计过个人开源的东西更成功，还是公司开源的东西更成功。不过像ElasticSearch 大多代码都是一个人写的，非常成功；Docker 是一个公司维护的，非常成功；Bootstrap 是2 个人开发的，公司维护的，非常成功。本质上我觉得是开源的产品真正有用，就会有人用；如果有公司给时间和金钱支持，那相当好；而最好的是有一个社区，大家一起维护。比如你可以在Google 上找到关于jQuery 的几乎所有答案，这就是社区的力量。所以如果你有一个好的项目，那么尝试培养一个社区，比一个人写，或者只有公司支持没有人开发的僵尸项目好。 G：如果有人也想走纯个人的开源路线，有什么话想对他们说吗？ 小鱼：做一个有用的产品比是否开源，是不是个人的都更有意思，如果可能，请只生产让这个世界更美好的东西。 G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用GitHub 呢？ 小鱼：开源是一种共享的精神。意义可能有很多种。让别人受益，自己得到改进反馈，让更多人从代码认识你，诸如此类，于每个人不同。开源并没有直接改变过我的生活，不过我喜欢写写代码，还能帮到人，于我已经是很大的乐趣，而有乐趣的生活就是我的意义。 对于GitHub，他只是工作/协作平台，这样的平台还有更多选择。不过我一直用它，是因为其他产品都做的太丑，无论是细节还是体验，而我更愿意选择好用的工具，即使付费。 Vue.js G：请简单介绍一下你自己吧。 尤雨溪：我叫尤雨溪，目前在一家创业公司Meteor 任职，做全栈式JavaScript 框架的开发。之前则是在Google 纽约的Creative Lab，主要负责HTML5 的界面原型开发。 G：MVVM 的框架现在也有不少，Vue 有什么独特之处吗？ 尤雨溪：Vue 相对于其他MVVM 框架，最主要有两个特点：1. 原生JS 对象即模型；2. 面向组件的开发模式。其他嘛就是比较轻量，侵入性比较低，容易上手。 G：最初是如何想到要做veu 这么一个项目呢？做得过程中有什么有意思或者让你印象深刻的事情呢？和我们分享一下吧 尤雨溪：最初是因为在原型开发的过程中，需要一个轻量、简单的框架来提高开发效率，但当时并没有符合我需求的框架。我当时研究了Knockout, Angular 和Ractive，但他们各自有各自我不喜欢的地方：Knockout 不能用原生JS 对象做model，Angular 太庞大，有很多我不需要的东西，Ractive 的API 最符合我审美，但它当时没有组件系统。另外一点就是我在看这些项目源码的时候觉得数据绑定的实现很有意思，很想自己写一个来加深理解。整个过程其实是比较随意的，一开始并没有什么计划，就是一点一点尝试去写，内部设计改过无数次，到0.11 更是彻底重写了一遍。 G：Vue 是如何获得这么多的Star 呢，你有做过什么相关的推广吗？ 尤雨溪：一开始刚发布Vue 的时候，主要是通过国外的一些软件开发新闻聚合站点，比如HackerNews, Reddit，以及一些前端开发博客/ newsletter。实际上就是发个链接上去看运气，之后除了维护一个官方twitter 账号之外并没有做什么刻意推广。我觉得个人开源项目能否获得长期关注，很重要一开始发布的那一波是否能够产生一个好势头，后面基本都是自然增长。当时Vue 发到HackerNews 之后被顶到了首页，这可能是最关键的一个契机，因为HN 带来的流量和关注度实在太厉害了，而且受众全都是开发者。另一方面就是我在Vue 的文档站点上也下了不少功夫，好的文档表现的是开发者的诚意，第一印象也很重要。 G：做一个框架应该要投入不少时间精力吧，你是如何安排时间来实现它的呢？ 尤雨溪：确实花了不少精力，有段时间我几乎所有的业余时间都花在上面了。当然因为Vue 也用在工作上的一些项目里所以也有理由在工作时间里分配一些。我做Vue 其实是有些周期性的，可能会有几个月特别投入，实现一些比较大的改进，然后会有几个月专注于别的事情，对Vue 只是改改bug。 G：你觉得作为个人开发者来开发和维护一个开源项目难度大吗？中间有没有想要放弃的时候呢？ 尤雨溪：这要看项目的规模了。一般来说适合个人维护的项目，最好是专注于解决一个较小的专门问题的库，否则可能会占用过多精力。项目的规模大到一定程度以后，最好是由社区或者团队来共同维护。说实话Vue 现在的issue 增长速度已经挺累人的了，好在现在也有很多社区开发者会积极地帮忙回答问题，让我省了很多精力。 G：你觉得纯个人开发开源项目和有公司背景的开源项目比起来有什么本质的区别呢，作为一个开发者应该如何选择？ 尤雨溪：有公司背景的开源，其背后肯定是有商业利益的推动，所以只要公司的商业利益和项目的发展状况是正相关的，这个项目就会有比较稳定的财力和人力支持。但这类项目通常更受公司决策的影响，对社区的意见不如个人开发的项目来得敏感。个人觉得选择一个项目的时候是个人还是公司开发并不是关键，关键是看背后的公司/个人是否靠谱。 G：如果有人也想走纯个人的开源路线，有什么话想对他们说吗？ 尤雨溪：我觉得做个人开源因为精力有限，所以需要专注，更需要对自己做的项目的定位有明确的理解，确保自己做的东西确实解决了一个痛点，这样花的精力才有意义。 G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用GitHub 呢？ 尤雨溪：我觉得开源的意义对于普通开发者来说，可以看别人的源码学习自然是最主要的了。在GitHub 上利用高级搜索去搜自己语言排在前列的项目和开发者，可以学到很多东西。另外每周看看trending 的新项目也可以发现很多好东西。另一方面，尽可能多地开源自己的代码也有好处，因为这可以迫使你对自己的代码保持一个高水准的要求，而不是得过且过。 参加者 (按姓氏笔画排名) 团队成员： 梁杰、栾俊清、夏天晗 コンサルタント： 胡少阳、李靖、李松峰、李涛、林峰、卢俊祥、阮一峰、唐巧、响马、周裕波、justjavac (迷渡)、sofish 采访嘉宾： 李成银、林峰、林顺、尤雨溪、sofish 本文出自：http://githuber.info/#/report |
