オープンソースプロジェクトの作成方法

今週サンクトペテルブルクでITフェスティバルが開催されます テックトレイン。 講演者の一人はリチャード・ストールマン氏です。 エンボックス も参加しており、もちろんフリーソフトウェアの話題も無視できません。 これが、私たちのレポートの XNUMX つが次のように呼ばれる理由です。 「学生の工作からオープンソースプロジェクトまで。 エンボックス体験」。 オープンソース プロジェクトとしての Embox の開発の歴史に焦点を当てます。 この記事では、私の意見では、オープンソース プロジェクトの開発に影響を与える主なアイデアについて話したいと思います。 この記事もレポートと同様、個人的な経験に基づいています。

オープンソースという用語の定義から簡単なことから始めましょう。 明らかに、オープン ソース プロジェクトは、プロジェクトのソース コードへのアクセスを許可するライセンスの XNUMX つを持つプロジェクトです。 さらに、オープンなプロジェクトは、サードパーティの開発者が変更を加えることができることを意味します。 つまり、一部の企業または開発者がその製品のコードを部分的または完全に公開しても、その製品はまだオープンソース プロジェクトにはなりません。 そして最後に、プロジェクトの活動は何らかの結果をもたらす必要があり、プロジェクトのオープン性は、この結果が開発者自身だけで使用されるわけではないことを意味します。

オープンライセンスの問題点については触れません。 これは大規模かつ複雑なトピックであるため、詳細な調査が必要です。 このトピックに関しては、非常に多くの優れた記事や資料が書かれています。 ただし、私自身は著作権分野の専門家ではないので、ライセンスはプロジェクトの目的を満たさなければならないということだけを述べておきます。 たとえば、 Embox の場合、GPL ライセンスではなく BSD を選択したのは偶然ではありませんでした。

オープンソース プロジェクトが変更を加え、オープンソース プロジェクトの開発に影響を与える機能を提供する必要があるという事実は、プロジェクトが分散されていることを意味します。 それを管理し、整合性とパフォーマンスを維持することは、一元管理されたプロジェクトに比べてはるかに困難です。 そもそもなぜプロジェクトをオープンにするのか?という当然の疑問が生じます。 答えは商業的な実現可能性の領域にあり、特定のクラスのプロジェクトでは、このアプローチの利点がコストを上回ります。 つまり、すべてのプロジェクトに適しているわけではなく、オープンなアプローチが一般に受け入れられます。 たとえば、オープン原理に基づいて発電所や航空機の制御システムを開発することを想像するのは困難です。 いいえ、もちろん、そのようなシステムにはオープン プロジェクトに基づくモジュールが含まれている必要があります。そうすることで多くの利点が得られるからです。 ただし、最終製品には誰かが責任を負わなければなりません。 システムがオープン プロジェクトのコードに完全に基づいている場合でも、開発者はすべてを XNUMX つのシステムにパッケージ化し、特定のビルドと設定を行った後、基本的にシステムを閉じます。 コードは公開される場合があります。

オープンソース プロジェクトを作成したり、オープンソース プロジェクトに貢献したりすることで、これらのシステムにも多くのメリットが得られます。 すでに述べたように、エンド システム コードは公開されたままになる可能性があります。 その理由は、システムをテストするために同じ航空機を所有する人がいない可能性が高いことは明らかだからです。 これは事実ですが、コードの特定のセクションをチェックしたい人がいるかもしれません。また、たとえば、使用されているライブラリが正しく構成されていないことに気づく人もいるかもしれません。

企業がシステムの基本的な部分を別のプロジェクトに割り当てれば、さらに大きなメリットが得られます。 たとえば、ある種のデータ交換プロトコルをサポートするライブラリです。 この場合、プロトコルが特定の主題分野に固有であっても、システムのこの部分を維持するコストをこの分野の他の企業と共有できます。 さらに、パブリックドメインでシステムのこの部分を研究できる専門家は、それを効果的に使用するために必要な時間がはるかに短くなります。 そして最後に、ある部分をサードパーティ開発者が使用する独立したエンティティに分離することで、この部分をより良くすることができます。なぜなら、効果的な API を提供し、ドキュメントを作成する必要があるからです。テスト カバレッジの改善について話しているわけでもありません。

企業は、オープンソース プロジェクトを作成しなくても商業的利益を得ることができ、その専門家が社内で使用されるサードパーティ プロジェクトに参加するだけで十分です。 結局のところ、すべての利点が残ります。従業員はプロジェクトについてよく知っているため、プロジェクトをより効果的に使用でき、会社はプロジェクト開発の方向性に影響を与えることができ、既製のデバッグ済みコードの使用により会社のコストが明らかに削減されます。

オープンソース プロジェクトを作成するメリットはそれだけではありません。 ビジネスの重要な要素をマーケティングとして考えてみましょう。 彼にとって、これは市場の要件を効果的に評価できる非常に優れたサンドボックスです。

そしてもちろん、オープンソース プロジェクトは、あらゆる専門分野のキャリアであることを宣言する効果的な方法であることを忘れてはなりません。 場合によっては、これが市場に参入する唯一の方法です。 たとえば、 Embox は RTOS を作成するプロジェクトとして始まりました。 競合他社が多いことは説明する必要もないだろう。 コミュニティを作成しなければ、プロジェクトをエンド ユーザーに提供するための、つま​​りサードパーティ開発者がプロ​​ジェクトの使用を開始するための十分なリソースがなかっただろう。

オープンソース プロジェクトではコミュニティが鍵となります。 これにより、プロジェクト管理コストを大幅に削減し、プロジェクトを開発およびサポートできます。 コミュニティがなければ、オープンソース プロジェクトは存在しないと言えます。

オープンソース プロジェクト コミュニティを作成および管理する方法については、多くの資料が書かれています。 すでに知られている事実を蒸し返さないように、ここでは Embox の経験に焦点を当てて説明します。 たとえば、コミュニティを作成するプロセスは非常に興味深い問題です。 つまり、多くの人が既存のコミュニティを管理する方法を教えていますが、それが当然のことであると考えて、コミュニティの作成の瞬間が無視されることがあります。

オープンソース プロジェクト コミュニティを作成するときの主なルールは、ルールはないということです。 つまり、プロジェクトが大きく異なるという理由だけで、特効薬がないのと同じように、普遍的なルールはないということです。 JS ログ ライブラリや高度に特殊化されたドライバーのコミュニティを作成するときに、同じルールを使用できる可能性はほとんどありません。 さらに、プロジェクト (したがってコミュニティ) の開発のさまざまな段階で、ルールは変わります。

Embox は、システム プログラミング部門の学生がアクセスできるため、学生プロジェクトとして始まりました。 実際、私たちは他のコミュニティに入っていました。 私たちは、このコミュニティの参加者である学生に、専門分野における優良産業慣行、システムプログラミングの分野における科学的研究、コースワークおよび卒業証書に興味を持ってもらうことができます。 つまり、私たちはコミュニティを組織する基本的なルールの XNUMX つに従いました。つまり、コミュニティのメンバーは何かを受け取る必要があり、その価格は参加者の貢献に対応する必要があります。

Embox の次の段階は、サードパーティ ユーザーの検索でした。 ユーザーはオープンソース コミュニティの完全な参加者であることを理解することが非常に重要です。 通常、開発者よりもユーザーの方が多くなります。 そして、プロジェクトの貢献者になりたいと思うために、彼らはまず何らかの方法でそれを使い始めます。

Embox の最初のユーザーは理論サイバネティクス学部でした。 彼らは、Lego Mindstorm の代替ファームウェアを作成することを提案しました。 そして、これらは依然としてローカル ユーザーでしたが (私たちは彼らと直接会って、彼らが何を望んでいるかについて話し合うことができました)。 しかし、それでもとても良い経験でした。 たとえば、ロボットは面白くて注目を集めるため、他の人に見せることができるデモを開発しました。 その結果、真のサードパーティ ユーザーが Embox とは何か、その使い方を知り始めました。

この段階では、ドキュメントやユーザーとのコミュニケーション手段について考える必要がありました。 いいえ、もちろん、これらの重要なことについては以前から検討していましたが、それは時期尚早であり、良い効果は得られませんでした。 その影響はむしろマイナスでした。 いくつか例を挙げてみましょう。 wiki が多言語対応をサポートしている googlecode を使用しました。 私たちは、ほとんど意思疎通ができない英語やロシア語だけでなく、ドイツ語やスペイン語など、いくつかの言語でページを作成しました。 したがって、これらの言語で質問されると非常にばかげているように見えますが、まったく答えることができません。 あるいは、ドキュメントの作成とコメントに関するルールが導入されましたが、API が頻繁かつ大幅に変更されたため、ドキュメントが古く、役立つというより誤解を招くことが判明しました。

その結果、私たちのすべての努力は、たとえ間違った努力であっても、外部ユーザーの出現につながりました。 そして、独自の RTOS を開発してほしいという商用顧客さえ現れました。 そして、私たちには経験と基礎があるので、それを開発しました。 ここでは、良い瞬間と悪い瞬間の両方について話す必要があります。 悪いところから始めます。 多くの開発者が商業ベースでこのプロジェクトに参加していたため、コミュニティはすでに非常に不安定で分裂しており、当然のことながらプロジェクトの開発に影響を与えざるを得ませんでした。 さらなる要因は、プロジェクトの方向性が XNUMX 人の商業顧客によって設定され、彼の目標がプロジェクトのさらなる発展ではなかったことです。 少なくともこれは主な目的ではありませんでした。

一方で、良い面もたくさんありました。 真のサードパーティ ユーザーを獲得しました。 それは顧客だけでなく、このシステムの対象者でもありました。 プロジェクトへの参加意欲が高まりました。 結局のところ、面白いビジネスでお金を稼ぐことができれば、それは常に素晴らしいことです。 そして最も重要なことは、顧客からの XNUMX つの要望を聞いたことです。当時はそれは私たちにはクレイジーに思えましたが、今ではそれが Embox の主なアイデアになっています。つまり、すでに開発されたコードをシステムで使用したいということです。 現在、Embox の主なアイデアは、Linux なしで Linux ソフトウェアを使用することです。 つまり、プロジェクトのさらなる発展に貢献した主な肯定的な側面は、プロジェクトがサードパーティ ユーザーによって使用されており、それによって彼らの問題の一部が解決されるはずであるという認識でした。

当時、Embox はすでに学生プロジェクトの範囲を超えていました。 学生モデルに従ったプロジェクトの展開における主な制限要因は、参加者のモチベーションです。 学生は在学中に参加しますが、卒業時にはまた違ったモチベーションが生まれるはずです。 やる気が現れなければ、学生はプロジェクトへの参加をやめてしまいます。 学生はまず訓練を受ける必要があることを考慮すると、卒業するまでに優れたスペシャリストになっていることがわかりますが、経験が浅いため、プロジェクトへの貢献はそれほど大きくありません。

一般に、オープンソース プロジェクトの作成、つまりユーザーの問題を解決する製品の作成について話すことができる主要なポイントにスムーズに進みます。 上で説明したように、オープンソース プロジェクトの主な財産はコミュニティです。 さらに、コミュニティのメンバーは主にユーザーです。 しかし、使用するものが何もない場合、それらはどこから来るのでしょうか? したがって、非オープンソース プロジェクトと同様に、MVP (実用最小限の製品) の作成に集中する必要があり、それがユーザーの興味を引く場合は、そのプロジェクトの周りにコミュニティが現れることがわかりました。 コミュニティ PR を通じてのみコミュニティを作成したり、世界中のすべての言語で wiki を書いたり、github 上で正しい git ワークフローを作成したりすることに取り組んでいる場合、これはプロジェクトの初期段階では問題になる可能性は低いです。 もちろん、適切な段階では、これらは重要であるだけでなく、必要なことでもあります。

結論として私が指摘したいのは、 コメント私の意見では、オープンソース プロジェクトに対するユーザーの期待を反映しています。

この OS に切り替えることを真剣に考えています (少なくとも試してみてください。彼らはこの OS を積極的に追求しており、素晴らしいことを行っています)。

PSオン テックトレイン レポートは最大 XNUMX つまであります。 XNUMX つはオープンソースに関するもの、XNUMX つは組み込みに関するものです (そして XNUMX つは実用的です)。 ブースでは、マイクロコントローラーのプログラミングに関するマスタークラスを実施します。 エンボックス。 いつものように、ハードウェアを持ってきてプログラミングしてもらいます。 クエストやその他のアクティビティも予定されています。 お祭りや屋台に来てください、楽しいですよ。

出所： habr.com