今回のインタビューラインナップ
ゲスト: The Book of Night Sky の著者、Apache Member & Incubator Mentor、Apache Flink Committer の Chen Zili tison 氏。
モデレーター: Zhuang Biaowei 氏、Open Source Society のディレクター、Huawei Open Source Management Center のオープンソース エキスパート。一年中さまざまなコミュニティ アクティビティに参加し、オープン ソース ガバナンス、オープン ソースの成長、およびオープン ソースの学問に関する研究と共有に熱心に取り組んでください。
Q: コミュニティには、あらゆる種類の開発者がたくさんいます。純粋に趣味でやっている開発者もいれば、コミュニティで学び成長したいと考えている学生もいます。企業からタスクを持ってコミュニティに派遣されている開発者もいます。あなたが会ったより興味深い開発者は誰で、彼らはどのように振る舞っていますか?
tison:生徒たちの環境は比較的シンプルで、純粋かもしれません。彼らの動機は通常、学校で多くの知識を学んだことですが、業界で比較的成熟したソフトウェアや、実稼働環境で使用できるソフトウェアにアクセスすることは困難です.オープンソース コミュニティに参加することで、知識は書籍と実際のソフトウェアは相互に検証されています。もちろん、将来のインターンシップや就職の基礎となるものもあります。
オープン ソース コミュニティは、ソフトウェアの価値に重点を置いています。コミュニティが決定を下すときは、ソフトウェア ユーザー全体の利益とコア開発者の要求を考慮します。一般に、コミュニティ メンバーには 3 つのタイプがあります: 1 つはユーザーまたはエンド ユーザー、もう 1 つはエコロジカル インテグレーションを行いたい開発者、もう 1 つはカーネル開発者です。エンタープライズ開発の習慣を持ってオープン ソース コミュニティに参加すると、承認プロセスに支配された共通の管理モードとエンタープライズの締め切り主導の作業方法がオープン ソース コミュニティでは機能しないことがすぐにわかります。オープンソース コラボレーションでは、自発的な参加が重視されます。
Q: 私たちは、他者と接する際に謙虚でも威圧的でもないと言っています. あなたが挙げた例はあまりにも「威圧的」ですが、一部の人々 (より多くの学生) はコミュニティで常に慎重であり、謙虚すぎます. この状況をどのように扱うのですか？
tison:この種の人々はしばしば謙虚さの範囲を超えていますが、まったく話したくない、または恥ずかしくて話すことができません. 彼らはあなたが何をしたいのかを非常に慎重に推測します。たとえば、パッチを提案した後、彼らはストレスを感じ、他の人がどのように反応するかを心配します. 前述の傲慢な人なら、メンテナがパッチをマージするのは当然のことだと思うでしょう。
謙虚すぎるという問題は、実際には貢献者だけでなく、メンテナーにも起こります。特に、メンテナが解約率、貢献者の数、およびその他の指標に注意を払いすぎる場合。これは、メンテナの傲慢さに対する貢献者の依存の一部でもあります。
新しく参加したコントリビューターについては、メンテナーが助けが必要だと思ったら、時間があるときに何をすべきかを指導して教えたり、緊張しているのに気づいたら大丈夫だと伝えたりすることができます。少し前に、spotless という Gradle プラグインのパッチを提案したとき、初めてマージされたパッチに問題がありました。すぐに修正を提案しましたが、それでもかなり恥ずかしかったです。このとき、spotless のメンテナーは、誰もが間違いを犯すものだと安心させてくれました。私が行った作業は、多くのユーザーが 1 年間楽しみにしていた機能であり、非常に誇りに思っていました。彼がそう言うのを聞いて、私はほっとした。メンテナが優れているわけではなく、コミュニティのすべてのメンバーは平等です。
Q: 自分のステータスをコミュニティでより適切なステータスにすばやく調整するにはどうすればよいですか?
Tison:オープンソース コミュニティが、この問題を確実に解決できる一連のメカニズムを備えているとは言えません。敬意を持って人々を扱うことは個人の資質の問題であり、唯一の完全な解決策は、より多くの本を読んで学ぶことであるためです。もっと根本的に問題を解決するために。
コミュニティに参加する過程でコミュニケーションの障壁に遭遇した場合、他のメンバーがどのようにそれを行うか、特にオピニオン リーダーがどのように自分自身を表現するか、特定の意味を表現するためにどのような言葉を使用するかなどを観察できます。コミュニティが異なれば習慣も異なります。重要なことは、コミュニティの価値観に適合することです。
Q: コミュニティへの個人の参加のさまざまな状況について述べましたが、実際には、より重要な主役は企業です。一部の企業は、オープンソースのものを密室で使用したいだけで、できれば誰もそれらについて知られていないことを望んでいますが、コミュニティに積極的に参加する企業もいくつかあります。
Tison:企業がオープンソースを利用する方法は、大きく分けて3つあります.1つはオープンソースソフトウェアを使用すること、もう1つはアップストリームコミュニティに参加すること、もう1つは自社の成熟したソフトウェアをオープンソース化し、オープンソースコミュニティを構築しようとすることです.
国内企業が無意識にオープンソースソフトウェアを利用し、それを発見してサプライチェーン分析やセキュリティコンプライアンス監査などを実施しようとすることはよくあることであり、これらはすべて利用範囲に含まれます。
Ali や Bilibili などの一部のテクノロジー主導型企業では、従業員がオープン ソース コミュニティに参加する動機と行動を持っています。会社レベルでは、Ali が Apache Software Foundation に寄贈した RocketMQ プロジェクトや、Bilibili のオープンソース go-kratos プロジェクトなど、影響力を構築するために成熟した内部ソフトウェアもオープンソース化します。その一方で、より多くの注目と協力を得るために、オープン ソース テクノロジを使用するか、独自のコア テクノロジをオープン ソース化することを選択するテクノロジ スタートアップがますます増えています。たとえば、PingCAP によって開発された分散データベース TiDB はオープン ソースであり、StreamNative はオープン ソース ソフトウェア Apache Pulsar の配布およびサブスクリプション サービスとして開始されました。
国内企業も、オープンソース プロジェクトに基づいて内部ソフトウェアを変更する、つまり二次開発を行うことがよくあります。修正版をリリースしたり、アップストリームに貢献したりできることも、ある種の参加です。少なくともすべきことは、魔法改造ソフトウェアを宣伝する際に、その声明がオープン ソース プロジェクトの魔法改造に基づいていることです。ほとんどのオープン ソース ソフトウェア ライセンスでは、作成者情報を保持する必要があります。企業がソフトウェアを外部にリリースする場合、そのソフトウェアでどのオープン ソース ソフトウェアが使用されているかを明確にする必要があります。
数か月前、Volcengine Inc. (Volcano Engine) は Apache SkyWalking に基づいて観測プロジェクトを作成し、自社開発であると主張しましたが、後に SkyWalking に類似していることが判明しましたが、SkyWalking の使用についての声明は見つかりませんでした関連するウェブサイト。このようなプロジェクトは上流から離れて開発され、同時にオープンソースの精神もありません.今日このプロジェクトを見ると、他の何千もの社内プロジェクトと同じくらい早く消えていくのも不思議ではありません.
Q: オープン ソース ソフトウェアの普及により、企業は徐々に改善されますか? 根本的な原因は何ですか？
tison:企業の技術開発とオープンソース運動の発展は互いに補完し合うことができると思います。このプロセスには、私たちオープンソース活動家の努力が必要です。
オープンソースの動きがなければ、従業員を採用して独自のソフトウェアを開発または購入するなど、ソフトウェアのビジネス要件を満たすことができます。つまり、オープンソース ソフトウェアだけがビジネス上の問題を解決できるわけではなく、存在しないのです。オープン ソース ソフトウェアの価値は、ソフトウェアを開発したオープン ソース コミュニティによって提供されます. オープン ソース コラボレーションには、20 ～ 30 年間テストされた一連の所有メカニズムと評判インセンティブ メカニズムがあります. 企業がオープンソース ソフトウェアの開発から力を得ることができ、すでに使用しているオープンソース ソフトウェアを通じて自分自身に価値をもたらすことができることに気付いたとき、企業はオープンソースの仕事とオープンソース ガバナンスの意味に向き合うことができると思います。 . これは、価値次元の第 2 象限の特徴と少し似ていますが、ユーザーは自分が何を必要としているのかわかりませんが、提供されればすぐに受け入れてくれます。
オープンソース運動の発展とオープンソースを実践する企業のプロセスを促進するために、私たちができることは、既存の巨大なオープンソース コミュニティと正しく効率的に協力する方法を宣伝し、潜在的なプロジェクトがオープンソース コミュニティを構築するのを支援することです。どのオープンソース コミュニティが有用であるかを指摘します。活力、つまり企業がオープン ソースの実践を実践することは良いことです。
たとえば、前述のオープン ソース ソフトウェアの違法使用を指摘し、批判する必要があります。何かがオープンソースとしてラベル付けされているという理由だけで、最終的な結論がなければ許容できません。よくできた事例については、「イエティアンの書」公式アカウントでも記事や紹介を多数書いています。
Zhuang Biaowei:当時、ニュートンは、私は巨人の肩の上に立っているので、私はとても良いと言いました. この「他人の貢献を土台にさらなる貢献をする」という考え方は、国内の考え方とは異なります。中国では、外部の力に頼らないほど、最初から最後までそれを行うことが名誉になります。逆に、人に頼っていては、それほど立派ではありません。でも言いたいのは、他人のいいところを参考にして、自分よりいいものを作るのは恥ずかしいことじゃないということです。
Q: 企業が独自のコミュニティを運営したい場合、何か奇妙なことを見たことはありますか?
tison:私は最近、友達と連絡を取り合って、「People Powered」で言及されたコミュニティの黄金律をよく引用しました。
コミュニティ メンバーにはどのような要求がありますか? オープン ソース コミュニティの最終的な目標は、優れたオープン ソース ソフトウェアを作成し、広く使用されるようにすることです。優れたコミュニティ メンバーの最終的な目標は同じであり、その過程でスキルを発揮し、ピア評価によって評判を得て、ソフトウェアに関する知識と蓄積された経験に基づいて仕事を見つけたり、キャリアを築いたりすることができます。
「Creating Value Together」という記事を書きましたが、企業の視点からコミュニティ運営を行う場合、基本的なポイントの 1 つは、コミュニティの価値、参加者の価値、および企業の価値の共通点を見つけ、オープンソースを使用することであると述べました。従来の企業管理方法の単純な適用ではありません。監査、業績評価などの企業内プロセスは、オープンソース コミュニティには存在しません。
コミュニティ メンバーが直接達成したいことは個人的な目標であり、その関心はソフトウェアの品質、個人の成長、およびコミュニティで発言する権利に関連しています。一方、ビジネスの最終的な目標は利益を上げることです。企業によって開始されたオープン ソース コミュニティの共通の問題は、エンタープライズ モデルでオープン ソース コミュニティ内の人や物を管理しようとして、企業の管理モデルをコピーすることです。これは、管理プロセスで多くの問題を引き起こします。
Zhuang Biaowei:企業の観点から、企業の論理についてお話したいと思います。企業には独自のコストが必要であり、コストを支払えば利益が得られます。たとえば、コミュニティで今 10 人に投票した場合、来年は 15 人に投票するべきですか、それとも 5 人だけに投票するべきですか? 5 人を投資して 20 人を引き付けることができる場合、1 人がコミュニティで 4 人を活用できることを意味し、5 人が 100 人を活用できる場合、コミュニティのコスト投資は費用対効果が高くなります。営利企業は慈善事業を行っているわけではありません. これらは、企業を代表して言いたいことです. ティソンはこの考え方についてどう考えていますか？
tison:この考え方は正しいと思います。企業はこう考えるべきです。企業にとっての課題は、オープンソース コミュニティの価値を測定する方法がわからないことです。これは、現在の評価システムでは一部の価値が見えず、企業が価値がないと誤って信じてしまう可能性があるためです。Apache にはプロジェクト成熟度モデルがあり、orbit.love にはコミュニティ インジケーターを測定する一連の手段もあり、ClickHouse はコミュニティ インジケーターを測定する独自のクエリをリリースしています。
企業が直面するもう 1 つの課題は、オープン ソースのコラボレーション モデルに慣れていないことです。労働力を活用するのは難しく、かなりの知識と実践的な努力が必要ですが、私が今日オープンソース コミュニティを確立したと主張しているわけではありません。
目標を達成することは難しくありませんが、難しいのは、企業がオープンソースをどのように理解しているかです.企業がオープンソースオフィスを設立した後、この部門の役割をどのように理解し、その価値をどのように上から下まで、どのように測定するか.部門。
Q: 企業は参加者を惹きつけ、労働力を活用するだけでなく、オープンソース コミュニティの技術開発の方向性をリードできる必要があるという問題をどのように見ていますか?
ティソン：できます。オープンソース コミュニティにおける企業の影響力は、ハードな影響力とソフトな影響力の 2 種類に分けられます。
いわゆるハード インフルエンスとは、Hashicorp からそのプロジェクト グループ、VMware から Spring コア モジュール、または PingCAP から TiDB を指します。この場合、ソフトウェアがどのように開発されるかは、当然、会社によって制御されます。
しかし、ソフトウェアの一部がますます多くの企業に採用されるようになると、それは常に一種の共和国システムに移行し、多くの企業が独自の影響力を持ちます. このとき、企業がコミュニティの開発方向を導きたい場合や、つまり、入力と貢献によってもたらされる方向と影響を指摘することです。
企業がどのような影響力を必要とし、この影響力を構築するためにどれだけの人員と時間を投資する必要があるかは、企業の存続と収益性がソフトウェアの優位性にどの程度依存しているかによって異なります。Red Hat と Ali はどちらも Kubernetes ディストリビューションを販売していますが、Kubernetes のアップストリームへの貢献はすべての参加者に利益をもたらします。彼らはこの種の影響力を必要としており、他のソリューションによって破壊されるのではなく、ソリューションを上流の標準ソリューションにする必要もあります。Google にとっては、Mesos の代わりに Kubernetes がコンテナ戦争に勝利し、新しいテクノロジーによる混乱からビジネスを保護することができ、業界のテクノロジー リーダーとしての Google の地位を維持することができました。会社。
別の観点から言えば、支配は中央集権ではありません。企業の存在がどこにでもあるというわけではなく、すべてを審査して承認する必要があります。こうなると、プロジェクトの生産効率は企業の効率によって制限されてしまいます.コスプレがオープンソースであっても、その実際の効率は、社内の開発ソフトウェアの効率と似ています.
Zhuang Biaowei:コミュニティには、アーキテクチャ レベルの決定から PR の統合まで、さまざまな決定があります。重要な決定はコミュニティ全体の 20% しか占めていないか、10% だけが重要な決定であり、残りの 80% はそれほど重要ではありません。したがって、コア機能の背後にある主要な数値を保証するだけで済みます。
tison:実際、オープンソース コミュニティでは、方向性の意思決定はメイン コンテンツではありません。ソフトインフルエンスの概念に言及し、その確立方法は、企業のバックグラウンドを持つ従業員がこのソフトウェアの価値ある機能を開発することでもあります。会社に対する会社の優位性、影響力、または発言権について言及するとき、会社が達成したい目標は何なのかを自問する必要があります。
実際、企業が達成したい目標は 1 つだけです。これは、オープンソース コミュニティを管理することで達成できることではありません。
企業が自社のビジネスを守りたい場合、アップストリームに参加し、企業のシナリオで蓄積された経験をアップストリームにフィードバックし、独自のテスト スイートをアップストリームの継続的インテグレーション パイプラインに追加することは、非常に信頼できる方法です。例えば、Alibaba は自社のフロー コンピューティング エンジンとして Flink を選択した後、2015 年から継続的に多くの人的資源を投入して、セッション ウィンドウやインクリメンタル チェックポイントを含む多数の機能を実現し、2019 年には多くの Apache コミッターを買収しました。Xiaomi は社内のストレージ システムとして大量の HBase を使用しており、独自の経験とアップストリームのニーズを満たしています。また、いくつかの Apache HBase コミッターをトレーニングしており、これは良い習慣です。コミュニティを 100%「コントロール」していなくても、お金を稼ぐペースには影響しません。
もちろん、オープンソース コミュニティは常に協力的であるとは限りません。実際、さまざまなメンバーからさまざまなソリューションが必要となる問題が発生します。現時点では、企業は不合理な解決策を拒否するために、長期的な運用を通じて意思決定における発言権を獲得する必要があります。Oracle が JCP の決定で Java モジュール化の公式ソリューションとして OSGi を強く拒否したことは、その代表的な例です。しかし、そのような方向性の決定は、オープン ソース ソフトウェア開発の主軸ではありません。企業は重要な決定に対して敏感さを保つべきですが、日々の開発と運用に注意を払うことによってのみ、十分なソフトな影響力を得ることができます。オープン ソース コミュニティには、最終的なフォークについての多くの話もありますが、これはフォークが脆弱でなければならないという意味ではありません。話が長くなり、ここでは拡張しません。