|
オープンソースの詳細については、以下をご覧ください。 51CTO オープンソース基本ソフトウェアコミュニティ https://ost..com オープンソースに関わって3年近くになります。今回のMeetupでは、純粋に技術的なトピックは取り上げませんでした。当初の意図は、オープンソースコミュニティのメンテナーの視点からオープンソースを捉え、皆さんに何か気づきを得ていただくことでした。もちろん、このトピックに関する意見には主観的な部分もあるかもしれませんので、ご容赦ください。 オープンソースとは何ですか?ここで言及するオープンソースとは、オープンソースソフトウェア（OSS）のことです。オープンソースソフトウェアは、ソースコードが無料で利用できるコンピュータソフトウェアです。GitHub、GitLab、Giteeなど、パブリックドメインで公開・ホストされているオープンソースソフトウェアもあります。 一般的なオープンソース ソフトウェアには次のようなものがあります。オペレーティング システム: Linux カーネル、Chrome OS、およびカーネルに基づくさまざまなディストリビューション。 データベース: Postgres、MariaDB、MongoDB、Redis など。 プログラミング言語: JavaScript、OpenJDK、CPython など。 ミドルウェア: Nginx、Apache HTTP、Moby (Docker)。 オープンソース作曲ある飲料会社は、誰もが愛する飲料を生み出す非常にユニークな製法を持っています。その製法はあらゆるレベルで秘密にされており、地域全体、国全体、あるいは世界全体でもその会社だけがそのような飲料を製造できるのです。私が話しているのはコカ・コーラです。このモデルは、その製法が会社の時価総額を上回るという噂を生み出しました。 素晴らしいアイデアがあります。このアイデアは市場で非常に応用可能です。かつて経済主体は、コカ・コーラのように、このアイデアを企業秘密として厳重に守っておきたかったでしょう。 しかし、オープンソースではそうではありません。例えば、何か面白いものを開発したら、オープンソース化すること、より多くの人に使ってもらい、参加してもらい、そして皆からフィードバックをもらえることを願うことを、より強く意識します。 このプロセスでは、一部の作者は、**製品をオープンソース化するプロセスは名誉をもたらし、その成果が認められる** と考えています。私の観点からすると、これは私の問題と他の人の問題の両方を解決し、私のコードをより有意義にするプロセスです。 **プロジェクト管理。** 飲料会社の製法は、この中央集権的なアプローチの好例です。同社は、多くの人に製法を知られたくないだけでなく、秘密の製法が存在することを他者に知られたくもありません。同様に、ソフトウェア業界はかつて、ユーザーがプラグインを開発できるようにSDKを公開することはよくありましたが、コードをオープンソース化することはありませんでした。彼らは製品の管理者であり、他者は単なる参加者であるべきだと考えていたのです。 しかし、オープンソースは違います。プラグインの書き方を学べるだけでなく、プロジェクトのコアコードを閲覧し、修正することができます。そして、修正が正しければ、コミュニティのメンテナーがそれを承認します。オープンソースでは、コントロールはもはや個人、企業、あるいは国ではなく、コミュニティによってコントロールされます。このコントロールとは、開発面、そして修正や統合のレビューに関するものであり、ソフトウェア自体や参加者に対するコントロールではありません。 **チーム構成。** 仕事を始めた頃は、わからないことがあればリーダーに質問していました。しかし、オープンソースに参加してからは、1対1でコミュニケーションを取るよりも、パブリックドメインで質問する傾向が強いことに気づきました。質問があるときは、メーリングリストやSlack/WeChatグループに投稿すると、他のユーザーから助けを得られることがよくあります。コミュニティの貢献者はユーザーほど迅速に返信しないことがあり、これはチーム構成の問題を浮き彫りにしています。 コミュニティとは、多くの場合、より多くのユーザーシナリオを収集し、製品を改良してより適用可能なものにするために、熱心に取り組んでいる人々の集まりです。3～5年前は、Little Dolphinのユーザー数はそれほど多くなく、適用性に課題がありました。しかし、ユーザー数とフィードバックが増えるにつれて、Little Dolphinの適用性はますます高まりました。多くの企業は、Little Dolphinに触れた瞬間から、基本的にワンクリックで導入できます。一部のOAや特別な認証を除けば、ビジネス全体を非常に迅速に実行できます。 ゲームの中でオープンソースは生活から遠いものだと考える人が多いかもしれませんが、私は個人的にそれは誤解だと考えています。実際、ほとんどの人は既にオープンソースに関わっています。オープンソースソフトウェアを使う限り、あなたは無意識のうちにオープンソースという組織全体の一部になっているのです。あなたはコミュニティのユーザーであり、コミュニティの技術活動やミートアップに参加すること自体がコミュニティへの参加方法の一つです。オープンソースは私たちにとって決して遠い存在ではないのです。 ライブラリ書き込み権限を持つApache Foundation傘下のオープンソースプロジェクトに加え、Google、Facebook、Alibabaなどの企業がオープンソース化したプロジェクトでも、コードの貢献と書き込み権限があれば、メンテナーとして認められます。特定の分野で非常に役立つ小さなツールを作成し、それがオープンソース化され、ユーザーやスターを獲得している場合でも、あなたはオープンソースのメンテナーであり、オープンソースプロジェクトに深く関わっている参加者とみなされます。 寄稿されたコードオープンソースプロジェクトにコード（ドキュメントでもコードでも）を提供した方は、貢献者とみなされます。次に、コミュニティの議論に参加することも重要です。例えば、Dolphin Schedulingにはメーリングリストとそれに対応するGitHub Issuesがあります。私たちはメーリングリストで問題について議論しており、これらの議論、あるいはWeChatグループやSlackグループに参加していれば、あなたはディープユーザーとみなされ、オープンソースへのフィードバックの促進に関わっているとみなされます。 もう1つ付け加えると、オープンソースソフトウェアにとってフィードバックは非常に重要です。ユーザーシナリオを継続的に掘り下げていく必要があります。Dolphin Schedulerは現在もユーザーインタビューを継続し、未解決の問題点を明らかにし、コミュニティの最適化と改善のための領域を特定しています。特に多くのユーザーから同じ問題点が報告された場合、オープンソースのメンテナーは継続的にその解決に向けて働きかけます。おそらくバージョン3.5または4.0がリリースされる頃には、この問題点は解決されているでしょう。 プロジェクトの使用者 - ユーザーもう1つのタイプのユーザーがいます。それは、ソフトウェアを頻繁に使用するものの、議論には一切参加しないユーザーです。上のファネルチャートを見ると、このユーザーグループがコミュニティ内で最大かつ最も重要なグループであることがわかります。よく書かれたコードを持つオープンソースソフトウェアでも、ユーザーがいない、あるいはユーザーベースが非常に小さいものがあります。オープンソースソフトウェアかもしれないけれど、素晴らしいとは思えない、ということもあります。ユーザーベースの規模は、製品の良し悪しを決定づける重要な要素です。 貢献者の権利次に、コミュニティで2番目に大きなグループはコントリビューターであることがわかります。ユーザーが重要であるならば、コントリビューターはオープンソース活動全体を推進する中核的な力と言えるでしょう。例えば、DolphinSchedulerの使用中に最適化の機会を発見し、ソースコードやドキュメントを修正するためのプルリクエスト（PR）を送信した場合、メンテナーやコアコントリビューターは喜んでそれを採用し、PRをブランチにマージする方法についても話し合い、交渉します。こうしたコントリビューターの存在こそが、コミュニティの繁栄の源なのです。 メンテナーオープンソースコミュニティにおけるメンテナーとは、コードへの書き込みまたは変更権限を持つ人のことです。ただし、ファネルチャートは量の変化を示すものであり、コミュニティ内における各役割の相対的な重要性を必ずしも示すものではないことを明確にしておくことが重要です。前述の通り、私はDolphinSchedulerのPMCですが、自分の役割が他のユーザーよりも重要だとは思っていません。もしDolphinSchedulerの初期段階でユーザーがいなかったら、プロジェクトはここまで発展しなかったでしょう。 オープンソースの興味深い点私は現在、百景オープンソースでデータエンジニアとして働いています。百景オープンソースは主にDolphinSchedulerの商用化に注力していることをご存知の方もいらっしゃるかもしれません。この会社の社員である以上、Dolphinスケジューリングコミュニティにもっと力を入れ、皆さんの質問に答えたり、アイデアを実現したりすることにもっと時間を割くべきだと考える方もいるかもしれません。確かにその通りですが、完全に正確とは言えません。なぜなら、私の時間へのコミットメントは、他のほとんどの人と比べてそれほど多くないからです。 時間配分実際には、オープンソース商用化企業のエンジニアとして働くことは、多くの人が想像するほど多くの自由時間をもたらしてくれるわけではありません。日々の業務では、時間の70%を会社の業務ニーズへの対応に費やし、オープンソースに集中できる時間はわずか30%です。もちろん、これは私がDolphinSchedulerのコードに30%の時間しか貢献していないという意味ではありません。私と同僚は日々の業務の中で、ほとんどのコードをDolphinSchedulerに提供していますが、企業でプロジェクトを開発するときと同じように、時間枠があります。例えば、ユーザーベースを拡大するために、SaaS関連のコンポーネントとPython APIサポートを開発しました。私たちはこれらのコードをすべてDolphinSchedulerリポジトリに提供していますが、ビジネス関連であり、特定の時間的制約があるため、私はそれを日常の会社業務の一部に分類しています。 現実には、コミュニティ コード レビューなどの作業を行う前に、会社から割り当てられたタスクを完了する必要があります。 残りの30%の時間は、課題やPRだけに目を通すのではなく、コミュニティで自分が担当しているモジュールに集中して取り組んでいます。現在は主にPython APIとドキュメントモジュールを担当しています。この分野で具体的なPRが提出されると、すぐにタグ付けされ、事前にその部分を確認します。これは会社や個人に対する責任ではなく、コミュニティに対する責任だと考えています。コミュニティの一員として自分がすべきことだと感じています。言い換えれば、メンテナンスや貢献に参加するコミュニティのメンバー全員が、コミュニティの繁栄と発展を確実にするという責任感を持つべきだと考えています。 誰かが DolphinScheudler に PR を送信すると、彼はすぐに他の数人にレビューを依頼することに気が付くでしょう。これがコミュニティ内での彼らの責任の範囲です。 PRや問題への返信がタイムリーでないことに気づいた場合は、手動でタグ付けすることができます。担当者はすぐに確認してくれるはずです。タグ付けされたメッセージを見ても返信がない場合は、単にメッセージを見逃した可能性があります。 リリースに必要な時間リリース対応にはまだ20%ほどの時間が残っています。コミュニティメンバーの中には、リリース頻度が低いとおっしゃる方もいましたが、**実際には、コミュニティリリースは皆さんが考えているよりもはるかに複雑です。** まず、リリースするバージョンは各リリース担当者の責任であり、新しいバージョンが効率的かつ安定して動作することを保証する必要があるため、リリース担当者はプレッシャーを感じています。**次に、Apache Foundationにはリリースプロセスがあります。** 投票プロセスだけでも3日かかります。万全の準備をしても、テストとリリースのプロセスを経て最終的にリリースされるまでに1週間以上かかることもあります。 他の人からのリクエストへの対応に費やす時間は、全体の約10%です。例えば、同僚からSlackやWeChatでコードを見てほしいと頼まれたら、すぐに確認します。忙しすぎる場合は、GitHubに「後で見る」と短いコメントを残します。その後、現在の課題/PRリストを積極的に検索するのは、全体の約10%だけです。 問題または PR に必要な時間。 問題PRリクエストの返信に時間がかかったり、メーリングリストやSlackの返信がタイムリーでないとおっしゃる方もいらっしゃるかもしれません。例えば、ユーザーが急いでいたり、オンラインの問題だったりして、始めようとして行き詰まって先に進めないといった状況です。コミュニティのメンバーからすぐに返信が来ない、半日、あるいは丸一日かかるといった事態も考えられます。多くの場合、皆さんが想像するほど時間がないのが原因ですので、少し余裕を持って対応していただければ幸いです。 問題処理の手順とタイムラインシンプル (1 ～ 5 分):ドキュメントのガイダンスとテキストの説明を通じて問題を解決できます。 中程度（6〜20 分）：ローカル再生。 難しい（20分以上）:
バグを報告して PR を送信してくれたことに対して、どのようにお礼を言えばよいでしょうか?これは非常に興味深い点です。コミュニティにバグレポートやPRを提出した時に、コミュニティから感謝されるべきだと考えている人がいることに気付きました。これはオープンソースに対する誤解です。誰かの利益になるものを提出することではありません。コミュニティはグループであり、オープンソースソフトウェアは多くの人が取り組むものであり、一人だけが解決しなければならないものではありません。もちろん、特定の問題を解決するためにPRを提出していただければ、個人的には心から感謝します。しかし、PRを提出したからといって、自分の功績を主張できると感じているのであれば、それは不要だと思います。 長い間言及されてきましたが、実装されていません。実際に収集したすべての問題は、問題リストまたはディスカッションに記録しています。問題やプルリクエストを送信する際には、事前に類似の問題がないか検索できる仕組みがあります。類似の問題がある場合は、該当する問題にコメントしてください。コミュニティはこれらのコメントを定期的にレビューし、多くの方から要望が寄せられた場合は、次のバージョンで実装される可能性があります。 ただし、これが特定のニーズ、あるいは社内の少数の同僚に限定された個人的な要件である場合、コミュニティではその特定のニーズを実装できない可能性があります。これは、Dolphin Schedulingが汎用プラットフォームを目指している一方で、すべてのユーザーではなく、ほとんどのユーザーのニーズを満たすことを目指しているためです。実装のためのコードを提供していただける場合は、ぜひご協力をお願いいたします。 PR処理のワークフローと時間シンプル (1 ～ 10 分):一目で理解でき、提案も提供されます。 中（11～30分）:
難しい（30分以上）:
オープンソースレイヤー有意義なオープンソース少人数のグループのニーズを満たすオープンソースプロジェクトであれば、どれも意義深いものと言えるでしょう。また、タイムリーなアップデートやメンテナンスを必要とせず、リリースされるバージョン数が非常に少ない場合でも、高い耐障害性を備えている必要があります。これらはすべて、意義のあるオープンソースプロジェクトと言えるでしょう。 少し前に、リリース頻度が非常に低く、1年もリリースされていないライブラリを使ってPRを作成しました。しかし、私の問題はうまく解決されたので、今後も使い続けようと思います。これは意義のあるオープンソースプロジェクトだと思います。 優れたオープンソースこれは、特定分野の問題を解決し、多くの人々のニーズを満たし、業界でも一定の認知度を持つオープンソースプロジェクトです。同僚たちは日常会話でこのソフトウェアの存在を広く知っており、ユーザーからも広く推奨されています。さらに、このオープンソースプロジェクトは時代の変化に適応しており、現在のDolphinSchedulerと同様に、Kubernetesへの対応や、最近取り組んでいるSaaSサービスへの対応拡大など、長期的な計画も持っています。 成功したオープンソースこのオープンソースプロジェクトは、ほとんどの実務家にとって馴染み深い存在です。既に一定の評価を得ており、企業への導入を積極的に進めています。中には、本日のMeetupの講演者をはじめ、積極的に製品を推奨している方もいらっしゃいます。彼らは皆、Dolphin Schedulingの支持者です。皆様のDolphin Schedulingへのご支援に深く感謝申し上げます。成功するオープンソースプロジェクトのもう一つの特徴は、迅速なイテレーションと継続的なリリースであり、これはプロジェクトを支える多くのメンテナーの存在も意味します。 DolphinSchedulerは現状、良い状態と成功状態の中間くらいだと考えています。私たちは、これをオープンソースプロジェクトとして成功させ、人々がスケジュール管理について話す際にDolphinSchedulerが良い選択肢だと思ってくれるように、そして様々な選択肢を比較検討する際に必ずDolphinSchedulerが考慮されるようにしたいと考えています。 Flaskコミュニティからの短編小説少し前、Flaskコミュニティのメンテナーは、Flaskリポジトリ全体のすべての問題とプルリクエストを解決しました。5万以上のスターを獲得し、月間7,000万回以上のダウンロード数を誇るプロジェクトであることを考えると、これは私個人の見解としては驚くべき成果です。メンテナーの努力は計り知れないほどのものでした。 しかし、問題が提起された際にコミュニティが適切な解決策を見出せず、単にクローズしてしまうことが多々あるというコメントも見かけました。これは間違っていると考える人もいます。彼の行動が正しかったか間違っていたかは私には判断できませんが、非常に感銘的で素晴らしい行動だと思います。彼らが払った努力は、おそらく私の想像をはるかに超えていたのでしょう。 PraquetコミュニティPMCからの反省最近、このコミュニティの新しい PMC 議長が選出され、新しい PMC が、これまでの貢献に対して先輩世代に感謝するメッセージを投稿したことを知りました。 これは私が以前言ったことですが、オープンソース コミュニティ全体において、それは継続的な蓄積と継続的な向上のプロセスです。 数年前にコミュニティに貢献した人が、そのままコミュニティに留まることを期待することはできません。なぜなら、それぞれの開発や成長の軌跡はそれぞれ異なるからです。A社ではDolphinSchedulerの二次開発に注力していたかもしれませんが、B社に移った後は別のことに取り組んでいるかもしれません。 会社を転々とした彼に、コミュニティへの貢献を期待することはできませんが、それでも私たちは彼が貢献し続けてくれることを心から願っています。一時的に離れ離れになった友人たちが戻ってくる時、私たちは自然と彼らを歓迎するでしょう。 コミュニティ全体は、成長と変化の絶え間ないサイクルの中にあります。私たちは、古い世代の貢献者から新しい世代の貢献者へと進化していきます。どの世代にも才能ある人材が現れ、若い世代が古い世代を凌駕していきます。コミュニティ全体が繁栄し、より強く成長し続けるでしょう。 本日のシェアはこれで終了です。皆様ありがとうございました。 オープンソースの詳細については、以下をご覧ください。 51CTO オープンソース基本ソフトウェアコミュニティ https://ost..com。 |
