|
どの企業のオープンソース部門にとっても、社内ソフトウェアを評価し、オープンソースとしてコミュニティに貢献するのに適しているかどうかを判断することは、一般的な業務です。PayPalがこの業務を遂行した際には、Danese Cooperが確立したレビュープロセスを活用し、潜在的なオープンソースプロジェクトを精査し、以下の4つの質問に答える必要があることがわかりました。 1. それは誰と関係がありますか? 2. まだ使っていますか？ 3. 何か約束したことはありますか? 4. 共通のツリー構造内でスムーズに開発できるか？ 今日の記事では、これら 4 つの質問に焦点を当て、なぜそれらがそれほど重要なのかを探ります。 1. それは誰と関係がありますか? 企業以外に、このソフトウェアに興味を持つ人はいるでしょうか？活気のあるコミュニティの積極的な参加なしには、オープンソースプロジェクトは成功しません。外部からの関心が集まらなければ、既存の成果に基づいて活発なコミュニティを構築できる可能性は極めて低くなります。労使関係に依存していたプロジェクト開発者が徐々に離脱していくと、他の誰かが開発と保守を引き継ぐ必要があります。そうでなければ、歴史のゴミ箱に新たなゴミを追加することになるだけです。 外部からのフィードバックを得る方法は様々です。他社の同僚とのコミュニケーション、ブログの執筆、カンファレンスやイベントでの講演、プレゼンテーションなど、どれも効果的な方法です。中には生まれつきこうした才能に恵まれている人もいれば、自分の意見を正確に表現するために指導が必要な人もいます。また、仕事に関する話題を話すのが苦手な人も多くいます。しかし、多くの場合、従業員は社外で何を発言してもよいかについて、会社からの明確な許可を得る必要があります。このアプローチに関心のある従業員をトレーニングすることで、これらの問題に効果的に対処できるだけでなく、開発者がブログのコンテンツを充実させるのにも役立つことが分かっています。 2. まだ使っていますか？ ソフトウェアの使用を中止した場合、オープンソース化する前に必ず徹底的なレビューが必要です。ソフトウェアの開発を積極的に行わなくなった場合、そのソフトウェアをさらに発展させたり、コミュニティを構築したりすることはほぼ不可能です。個々のコンポーネント（またはソフトウェア自体）にセキュリティ上の脆弱性が存在する可能性があるため、誰かが常に監視し、解決する必要があります。エラーリクエストの分類、新規コントリビューターの誘導、ユーザーのニーズに合わせたタスク処理の適応といった、その他の日常的なタスクも言うまでもありません。これらすべてに時間がかかり、企業として、使用されなくなったソフトウェアのメンテナンスに多大な時間を費やすことは考えられません。 しかし、問題は、失敗した製品をオープンソース化すると企業の評判が損なわれる可能性があることです。あるソリューションが真の問題を解決できないという理由で他のソフトウェアソリューションに頼ってしまうと、それが他の企業の業務に真に役立つとは期待しにくくなります。オープンソースコミュニティはヘルプセンターでもゴミ捨て場でもないのです。不要なものをそこに放り込むわけにはいきません。企業が不要なソフトウェアをコミュニティに返却するのであれば、オープンソース化など考えないのと同じでしょう。 3. 何か約束したことはありますか? 前述の通り、オープンソースプロジェクトの維持には多大な時間投資が必要であり、その具体的な期間はプロジェクト全体の規模によって異なります。一般的に、オープンソースプロジェクトのメンテナンス時間はコアアプリケーションフレームワークよりも短いですが、それでもかなりの時間が必要です。開発者と管理者の両方にとって、時間は極めて貴重なリソースであることは間違いありません。管理者が開発者にプロジェクトのメンテナンスに時間を割くことを許可しない場合、プロジェクト自体が緩やかな衰退期に陥る可能性があります。 アジャイルフレームワークでは、いくつかの異なるアプローチが考えられます。プロセスが機能コンポーネントと短いスプリントに依存している場合、各スプリントに1つのコンポーネントを付随させることでプロジェクトを維持できます。開発者リソースの割り当てにタスクベースのアプローチを選択した場合、プロジェクト維持にかかる開発者の生産性コストを適切に削減できます。複数のメンバーに作業を分配する計画がある場合、当然のことながら、各メンバーがプロセスのどの部分を具体的に担当しているかを把握しておく必要があります。そうでないと、タスクが停滞する可能性が高くなります。プロジェクトによっては、フルタイムのコミュニティ技術スタッフの協力も必要です。これらすべてが経営陣にとって不合理または実現不可能と思われる場合は、プロジェクトをオープンソース化するための適合性について、さらに検討する必要があります。 4. 共通のツリー構造内でスムーズに開発できるか？ プロジェクトコードの公開開発を阻む、コード関連の障害は他に存在しますか？もしこのコードが社内システムと関連しているために公開できない場合は、この接続を分離、分離、あるいはモジュール化する必要があります。さらに、関連プロセスが外部の参加者やユーザーにとってのソフトウェアの魅力に影響を与えない場合は、プロジェクトのユーザビリティ向上のために、この内部関係の分離を検討する必要があります。さらに、公開するプロジェクトコンテンツがなくなった場合は、関連するコードの作成を事実上中止することができます。 さらに重要なのは、ソフトウェア開発を社内で完結させるべきではないということです。メジャーリリースはGitHubでライセンス供与され、公開されるべきです。同時に、優れたオープンソースリソースを適切に活用すべきです。社内外の開発者が設計・開発提案に関する議論に積極的に参加する必要があります。そうでなければ、コミュニティ全体が空洞化してしまうでしょう。つまり、社内の企業意思決定のバイアスに頼り続けるのではなく、コミュニティに議論の材料を提供し、技術的な決定を一般の人々が判断できるようにする必要があるということです。プロジェクトチームがこれに応じない場合、オープンソースを正しい方向に導くための重要なガイダンスを提供する必要があるかもしれません。 要約 これら4つの質問は、オープンソース化のプロセスで発生する可能性のあるすべての障害を網羅しているわけではありません。すべての企業は、自社のプロジェクトに関連する潜在的な知的財産上の問題をすべて評価する必要があります。さらに、既存のソリューションと重複しないよう、類似のオープンソースプロジェクトを調査する必要があります。同時に、プロジェクト自体が企業とオープンソースコミュニティ全体にとって実用的な価値を持つ必要があります。しかしながら、全体として、これら4つの質問は対話の良い出発点となり、初期のオープンソースプロジェクトとして不適切なソフトウェアソリューションを除外するのに役立ちます。 原題: プロジェクトをオープンソース化する前に尋ねるべき 4 つの質問、著者: Duane O'Brien [この記事は51CTOによって翻訳されました。提携サイトへの転載の際は、元の翻訳者と出典を51CTO.comとして明記してください。] |
