GitHubがオープンソースをサポートするためにアップデート最近、オープンソース開発者への企業貢献を求める声が強まる中、GitHubは2019年に導入されたスポンサー機能をアップデートし、スポンサーユーザー専用の新しいリポジトリを導入しました。現在、このリポジトリは世界36の地域で利用可能です。 GitHub公式ブログによると、スポンサーリポジトリとは、スポンサーのみがアクセスできるプライベートリポジトリです。このリポジトリを有効にすると、開発者は、オープンソースプロジェクトに対して、支払額に応じて異なるスポンサーシップレベルを定義し、スポンサーシップレベルごとに異なるアクセス権限とそれに応じた報酬を設定できます。プロジェクトのユーザーは、ニーズに応じて異なるスポンサーシップレベルを選択し、必要なアクセス権限を得るために適切な料金を支払うことができます。 GitHubのスポンサープロダクト担当責任者であるジェシカ・ロード氏は、この種のリポジトリを通じて開発者とスポンサーの交流を促進し、開発者がオープンソースプロジェクトから相応の利益を得られるよう支援することが目標だと述べています。このアップデートはオープンソースプロジェクトの開発者にとって朗報であり、プロジェクトからより多くの金銭的利益と支援を得られるようになります。しかし、GitHubの今回の動きは、オープンソース開発者が現在直面している苦境と、ほとんどのオープンソースプロジェクトが長期的な持続可能性の維持に苦戦しているという現実を反映しているとも言えます。 オープンソース開発者は依然として苦境に立たされている資本の搾取が常態化している。オープンソースは長らく、開発者がプロジェクトの構築、保守、アップデートのあらゆる段階に心血を注ぎ、オープンソースを通じてより多くの人々を助けたいという思いから生まれた、無私の献身的な行為とみなされてきました。しかしながら、今日、一部の営利企業は個々のオープンソース開発者を無償の労働力とみなし、彼らのオープンソースにおける成果を搾取し、踏みにじり、自らの利益を追求する傾向にあります。このような状況に直面して、個々の開発者には、自らのためにより大きな選択肢を生み出すための人的資源と資金が不足していることは明らかです。 今年1月、著名なオープンソースライブラリFaker.jsの作者であるMarak氏は、営利企業によるフリーローディングと盗作に抗議し、ライブラリを削除して逃亡したことで、業界に大きな波紋を引き起こしました。この事件では、複数の大手営利企業が長きにわたりFaker.jsの価値を享受する一方で、プロジェクトや開発者に一切の支援を行っていませんでした。さらに、作者が財政難からプロジェクトの商業化を試みていた矢先、一部の企業が悪質な盗作行為に手を染め、彼の経済的生命線を断ち切りました。最終的に、Marak氏は抵抗できず、10年以上の努力の結晶である自身の作品を破壊することを選択しました。 さらに残念なのは、このような事件は今回が初めてではないということです。2020年には、オープンソースのパッケージ管理ツール「AppGet」の開発者であるケビン氏も同様の不当な扱いを受けました。ある企業に開発のアイデアや提案を複数回依頼されたにもかかわらず、ケビン氏は約束された地位や福利厚生を得られませんでした。それどころか、ケビン氏の協力を得た企業は、彼のプロジェクトを模倣し、独自の商用製品を開発しました。この結果に直面したケビン氏は、失望のあまり、AppGetの今後のアップデートを断念すると発表しました。 愛で力づけると、肉体的にも精神的にも疲れてしまいます。個々のオープンソース開発者が商業企業からの尊敬と支援を得るのに苦労しているだけでなく、数え切れないほど多くのオープンソースプロジェクトのメンテナーも困難な状況に直面しています。彼らの多くは、情熱と責任を貫きながらフルタイムで働いており、最終的には精神的にも肉体的にもストレスを抱えています。 最近のLog4j2脆弱性インシデントでは、プロジェクトのコアメンテナー3名が直ちに脆弱性修正作業に加わりました。彼らは余暇を利用して自発的に、そして無償で緩和策を模索する一方で、世界中からの厳しい批判にも耐えなければなりませんでした。さらに注目すべきは、この脆弱性の規模を考えると、Log4jはインターネット業界のほぼ半分で使用されていると言っても過言ではないということです。しかし、これほど大規模なオープンソースプロジェクトが、脆弱性が露呈する前に受けた個人からの寄付はわずか3件に過ぎませんでした。 もちろん、この現象は特異なケースではありません。オープンソースのイベントログツールDoczの作者であるペドロ氏も、オープンソースプロジェクトの維持管理は非常にストレスフルであると公言しています。当初、Doczの開発のためにペドロ氏は3時間早く起き、3時間遅く寝ることさえありました。Doczはペドロ氏の生活に大きな喜びをもたらしました。しかし、プロジェクトが発展するにつれて、要求は増大しました。ペドロ氏は仕事で忙しくなり、休息時間の多くを無償でプロジェクトの維持管理に費やす必要がありました。最終的に、健康上の問題からペドロ氏はDoczへの投資を削減せざるを得なくなり、その結果、プロジェクトは非常に劣悪な状態に陥り、長期間メンテナンスされない状態になりました。 Log4jのコアメンテナーやDoczの作者のような開発者は珍しくありません。彼らはプレッシャーにも屈せず、多くの人々の期待と厳しい監視に耐え、自らの信念を貫いています。しかし、現実的には、これらの才能豊かで献身的な貢献者への注目とサポートは、まだ十分とは言えません。 中国のオープンソースへの取り組みは成功と挫折の両方をもたらした。確かに、上記の事例はすべて国際舞台で発生したものです。では、中国におけるオープンソースの現状はどうなっているのでしょうか?そして、同様の問題は存在するのでしょうか?最近発表された「2021年中国オープンソースパイオニア」リストからもわかるように、現在、中国におけるオープンソースは主に企業が主導しています。リストに選ばれた33人のうち、10人以上は大企業に所属し、8人は企業や機関のリーダーであり、残りは中小企業の幹部や国内外のオープンソースコミュニティのリーダーです。しかし、個人開発者は含まれていません。 OSCHINAの調査レポートによると、中国国内の開発者はオープンソースへの関与歴が浅く、そのほとんどが5年未満の経験しかありません。さらに、これらの開発者の55%以上は、オープンソースに週1~2時間しか費やしていません。中国国内の開発者が主導する個別のオープンソースプロジェクトは数多く存在しますが、大きな影響力と広範な普及を実現しているのはほんの一握りです。このような状況下では、中国においてオープンソース開発者に関連する問題はまだほとんど表面化していませんが、この状況が長期的に持続できるかどうかは依然として疑問です。 知的財産権に関して、中国には現在、オープンソースソフトウェアに特化した法律は存在しません。オープンソースソフトウェアを規制する主な法律は、著作権法とコンピュータソフトウェア保護条例です。さらに、オープンソースプロジェクトに関する問題の中には、契約法や特許法といった法律が絡むものもあります。こうした状況下では、個人や営利企業がオープンソース契約に違反し、オープンソースプロジェクトの開発者の権利を侵害する可能性が高くなります。専門チームを持たない個人開発者にとって、これらの問題に直面した際に権利を効果的に保護することは非常に困難です。 安定した収入の確保の難しさも、中国におけるオープンソースが直面する現実的な問題です。データによると、中国の開発者の約82.2%が無償でオープンソース活動に参加しており、収入を得ている開発者の最大のグループは、会社員として参加し、固定給を得ている開発者です。調査対象者全体のうち、個人のオープンソースプロジェクトから商業的な収益を得ているのはわずか4.7%で、そのうち約55%は月収1,000人民元未満です。オープンソース開発者の安定した収入の確保は、国内外で共通の課題となっています。「収入がなければオープンソース活動を続けるのは不可能だ」という回答は、調査で最も多く寄せられました。 現在の動向から判断すると、中国におけるオープンソースは急速な発展段階にあります。国の政策支援と大企業のリーダーシップの下、ますます多くの開発者がオープンソース貢献者の仲間入りを果たしています。2021年だけでも、Giteeは180万人以上の新規ユーザーを獲得し、アクティブなリポジトリの数も200万以上増加しました。中国におけるオープンソースの理念の受容が進むにつれ、今後、より多くの高品質なオープンソースプロジェクトが中国の開発者の手から生まれるでしょう。このような活況を呈する中で、オープンソース開発者が直面する様々な課題に効果的に対処し、才能ある開発者たちがより一層の熱意を持って技術貢献するよう促し、ひいては中国国内、ひいては世界規模でオープンソースエコシステムのさらなる繁栄を促進することは、喫緊の課題であり、検討が必要です。 結論は中国のオープンソースへの取り組みは前向きであるべきであり、活気に満ちた開発者コミュニティこそがオープンソースプロジェクトの真の保証です。アリババの技術担当副社長である賈陽青氏はかつて知乎(Zhihu)で次のように述べています。「オープンソースは情熱によって推進されますが、一方で、無私な人々を飢えさせることは絶対に許されません。だからこそ、オープンソースに関わるすべての人にとっての障害を最小限に抑えるために、体系的な能力の蓄積と優れたプロセスを確立する必要があります。」冒頭で述べたGitHubスポンサーの機能アップデートは、間違いなく業界にとって良い例を示しています。今後、オープンソースの長期的な持続可能な発展を支える、より効果的なソリューションが登場するかどうかはまだ分かりません。しかし、一つ確かなこと、そして今、堅持すべきことがあります。それは、大衆のために薪を運ぶ人々を雪の中で凍えさせるべきではないということです。 |
オープンソース: 他人のために薪を運ぶ人が雪の中で凍えてしまうことがあってはならない。
関連するおすすめ記事
-
TypeScript ソースコード公開: 驚異の 52,000 行のコード。
-
-
申し訳ありませんが、オープンソースはあきらめます。
-
オープンソース市場は混雑しすぎです!Dark Side of the Moon が Muon オプティマイザーの新バージョンをリリースしました。
-
Ant Groupのオープンソースの信頼できるプライバシーコンピューティングフレームワーク:「Hidden Language」—オープンで汎用的
-
89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">resource ( s )
2022/07/02 13:17:33 1 つのリソースを作成しています
2022/07/02 13:17:33 1 つのリソースを作成しています
2022/07/02 13:17:33 検出キャッシュをクリアしています
2022/07/02 13:17:33 タイムアウト1 分で4つのリソースの待機を開始
2022/07/02 13:17:39 43個のリソースを作成しています( s )
2022/07/02 13:17:39 5分0 秒のタイムアウトで43のリソースの待機を開始
2022/07/02 13:17:40 デプロイメントの準備ができていません: argocd / argocd - applicationset - controller 。 予想される1 個のポッドのうち0 個が準備ができています
2022/07/02 13:17:42 デプロイメントの準備ができていません: argocd / argocd - applicationset - controller 。 予想される1 個のポッドのうち0 個が準備ができています
……
2022/07/02 13:19:44 デプロイメントの準備ができていません: argocd / argocd - applicationset - controller 。 予想される1 個のポッドのうち0 個が準備ができています
2022/07/02 13:38:27 デプロイメントの準備ができていません: argocd / argocd - dex - server 。 1 個のポッドのうち0 個が準備完了です
2022/07/02 13:38:30 リリースインストールに成功しました: argocd / argo - cd - 4.9.11
2022-07-02 13:38:30 ✔ [ 成功] ツール( argocd / default ) の作成が完了しました。
2022 - 07 - 02 13 : 38 : 30 ℹ [ 情報] -------------------------- [ 処理の進行状況: 4/4 。 ] --------------------------
2022 - 07 - 02 13 : 38 : 30 ℹ [ INFO ] 処理中: ( argocdapp / default ) -> 作成...
2022-07-02 13:38:31 ℹ [ INFO ] application . argoproj . io / dtm - test - go が作成されました
2022-07-02 13:38:31 ✔ [ 成功] ツール( argocdapp / default ) の作成が完了しました。
2022-07-02 13:38:31 ℹ [ 情報] -------------------- [ 処理が完了しました。 ] --------------------
2022-07-02 13:38:31 ✔ [ 成功] すべてのプラグインが正常に適用されました。
2022-07-02 13:38:31 ✔ [ 成功] 申請が完了しました。適用プロセス中、実行状態は定義された状態バックエンドストレージに保存されます。例えば、ローカルストレージを使用している場合、実行状態はルートディレクトリのdevstream.stateファイルに保存されます。合計4つのツールチェーンがあり、最初の2つが完了し、最後の2つが認識された場合、最初の2つのプラグインの状態がこのファイルに保存されます。次回の再適用時には、最後の2つのツールチェーンのみを実行する必要があります。
上記で定義したツールチェーンは、最終的に GitHub 上に Golang Web 用のスキャフォールディングされたアプリケーション コード リポジトリを作成します。
GitHub Actions は、CI 操作と Docker イメージの構築に使用されます。
CI プロセスは最終的にイメージを Docker Hub にプッシュします。
その後、ArgoCD が Kubernetes にデプロイされます。
$ kubectl get pods -n argocd
名前準備完了ステータス再起動年齢
argocd - アプリケーション- コントローラー- 0 1 / 1 実行中0 5 分55秒
argocd - アプリケーションセット- コントローラー- 64 d8c477f4 - 2 wrg6 1 / 1 実行中0 5 分55秒
argocd - dex - サーバー- dbdbf5499 - krmfz 1 / 1 実行中0 5 分35秒
argocd - 通知- コントローラー- b67c4bdb4 - 22 t9l 1 / 1 実行中0 5 分55秒
argocd - redis - df9db799b - 8 gbpv 1 / 1 実行中0 5 分55秒
argocd - リポジトリ- サーバー- 56769 cdd47 - zs65j 1 / 1 実行中0 5 分55秒
argocd - サーバー- 7 d4745f689 - w5pp7 1 / 1 実行中0 5 分55秒最後に、ArgoCDを使用してCD操作を実行し、サンプルアプリケーションをKubernetesクラスターにデプロイします。基本的には、ArgoCDアプリケーションオブジェクトを作成します。
$ kubectl アプリケーションを取得- n argocd
名前同期ステータスヘルスステータス
dtm - テスト- go 不明健康ArgoCD を通じて、デプロイされたアプリケーションの詳細を表示することもできます。
最後に、ツールチェーン全体を削除する場合は、`dtm delete` コマンドを実行するだけです。
プロセス全体は非常にスムーズでした(ただし、何らかの理由でGitHubへのアクセスが非常に遅かった点を除けば)。必要なプラグインを設定ファイルで定義するだけで済みます。プラグインの設定方法の詳細については、公式ドキュメント(https://docs.devstream.io/en/latest/plugins/plugins-list/)をご覧ください。
YAML設定ファイルに必要なDevOpsツールを定義するだけで、たった1つのコマンドでDevOpsツールチェーンとSDLCワークフロー全体を構築できます。DevStreamはまさに魔法のツールと言っても過言ではありません。
Git リポジトリ: https://github.com/devstream-io/devstream。