当店は、ソフトウェアソリューションをオープンソースコミュニティにリリースすることが良い考えである理由をいくつか特定しました。しかし、ビジネスの観点から、当店をオープンソースに転換することが疑問視される理由はいくつかあります。この移行を経験した、または進行中の人の助けが必要です。具体的には政府機関です。
当店について:-地元の法執行機関向けのWebおよびクライアントアプリケーションを開発およびサポートしています。 -私たちは民間企業ではなく、公的機関です
この議論をするときに起こりがちないくつかの質問は次のとおりです。
いいえ、私は政府を知らないのではないかと心配しています。オープンソースに転換するセクター企業。突く場所はMITREかもしれませんが、政府との契約をサポートし、研究を行い、公共の利益のために働く場所として非常に興味深いダイナミックさを持っているためです。誰かがこの領域に入ったとしたら、それはMITREだと思います。
私が考えること:
セキュリティ-2つの哲学があります:
目が多ければ多いほど良いです-真のオープンソースプロジェクトでは、あなただけが貢献者ではありません。理論的には、製品の使用に貢献したい善人の数は、欠陥を悪用したい悪人を上回ります。善人の能力と豊富さが悪人よりも優れている場合は、安全なソフトウェアベースラインを維持するための優れた公式があります。この一般的な哲学は、セキュリティビジネスの多くの有名人によって議論されています。
どんな犠牲を払っても秘密を守ってください-あなたの組織によって精査された十分な社内の専門家がいて、あなたの閉じた組織がハッカーを輝きと勤勉さで打ち負かすという基本的な仮定。これはMicrosoftにとってはあまりうまく機能していませんが、多くの政府機関が運営するポリシーです。オープンソースは現在公開されているため使用できない状況を知っています。開発はクローズドで行われたため、ハッカーによく知られているものは、ハッカーが見たことのないものよりもハッキングしやすいという理論があります。何も漏れていない回路。
私はそれについて判断を下すつもりはありません。実際、2番目のパスの最終的な例は十分に秘密であり、これらの秘密のシステムがハッキングされた回数に関する統計が大衆に利用可能になることは決してないと私は信じているので、メトリックは学習できないと思います。では、オープンソースとシークレット開発をどのように比較できますか?あなたができる最善のことは、オープンソースと民間セクターの開発を比較することです。
最後に-ビジネス-
おそらく最も重要なのは-これはあなたにとって正しいですか?製品を構築し、複数の顧客にまたがって成長させてきた場合、オープンソースへの移行は、ある意味で製品開発からソリューション開発およびコンサルティングへの移行になります。両方の技術的な問題を検討する必要があります。たとえば、外部の関係者がベースラインで必ずしも必要としないものを提供している場合、コードベースをどのように管理しますか?また、コードが無料でWeb上にある場合でも、自分の価値を顧客に説明する必要があるため、ビジネスモデルの一部を変更する必要があります。
これらのことは実行可能だと思いますが、それが考慮すべき最大のことだと思います。完了した後も仕事を続けたいと考えており、ソリューションの作成にビジネスライン全体を関与させる必要があります。
これはあなたが下す決定ではありません-それはチェーンの上の管理のためです。
「知的財産の譲渡」を含め、オープンソース開発の影響と影響について説明する必要があります。 (彼らがあなたを十字架につけるものについて彼らを誤解させてください-そして当然そうです)。
あなたが彼らの尻を持っている人々からの承認を得た場合にのみ、あなたはこれをするべきです。通常(特に)公共サービス組織では、彼らはあなたの給料を支払う人々でもあります。
そして、あなたがそれを書面で持っているという承認を得たかどうかを確認してください。そして、実際に決定を下す力を持っているのに十分な高さの誰かから。 (隣の席にいる上級開発者はおそらく十分に許可されていません)。