オープンソース：それはそれほど怖いことではありません！

公開: 2022-03-11

以下は、女性開発者のためのToptalScholarshipsの開始に先立って投稿されました。

開発者として、テクノロジーの最新トレンドに遅れずについていくことはエキサイティングで挑戦的です。毎日、新しい言語、フレームワーク、デバイスが私たちの注目を集め、交流会、フォーラム、チャットでの会話に拍車をかけています。しかし、私たちの開発者コミュニティはツールではなく人で構成されており、その社会政治的側面を探求することは魅力的です（より良い言葉がないため、「ソーシャル」は最近ソーシャルネットワークに関連付けられる傾向があります）。

Toptalでは、最近、女性がオープンソースにどれだけ貢献しているか、そして何が女性の貢献を妨げているのかについて興味深い会話を交わしたので、問題を調査しました。 BreandenBeneschottとBozhidarBatsovとの会話に参加していたので、疑問に思いました。BozhidarはGitHubのトップオープンソース貢献者の1人です。ここはどこ？今日の時点で私の公開GitHubアカウントを確認すると、これは主に、クラスで生徒のために使用した小さなテストプロジェクトです。彼らは中途半端で、私のスキルや専門知識を完全に代表するものではありません。（これについては私の言葉を信じる必要があります。）誰かがそのアカウントで見つけたものに基づいて私を雇うことを検討した場合、私は生計を立てるのに苦労すると思います。それでも、私は20年以上プロの開発者であり、日常の仕事では、覚えているよりも多くのオープンソースソフトウェアを使用しています。時間が経つにつれて、私はLinuxカーネルをハッキングして特定のニーズに合わせ、購入したすべてのルーターとNASを微調整し、Raspberry Pi待機リストで何ヶ月も辛抱強く待って、手に入れて自家製のドモティクスを入手しました。それはいいですね。それでも、これらの調整やテストのいずれも、オープンソースになるために私のGitHubに到達することはありませんでした。また、Tomcatの最初のバージョンの1つでバグを修正したことを除けば、私はオープンソースプロジェクトに貢献したことはありませんでした。好奇心旺盛ですね。

時間や興味が足りないと思うかもしれませんが、そうではないことはわかっています。私の個人的なプロジェクトに関しては、誰も私がやったことに本当に興味を持っているとは思わなかったかもしれませんが、ほとんどの場合、誰もが見て後世のために、そこで私の作品を公開するというアイデア自体が私をとても怖がらせます。また、GitHubから個人的なプロジェクトをいつでも破棄できますが、広く利用可能なオープンソースプロジェクトに貢献しようとすると、後戻りすることはありません。私のコードが十分でない場合はどうなりますか？問題を正しく理解していなかった場合はどうなりますか？プルリクエストが拒否された場合はどうなりますか？人々が私を荒らした場合はどうなりますか？

オープンソースに貢献することはあなたを怖がらせますか？

つぶやき

ほとんどが女性である仲間の開発者との簡単な電話で、すぐに私だけがこの問題を抱えているわけではないことを確信しましたが、エンジニアにとっては問題はなく、解決策だけですよね？

オープンソースプロジェクトに貢献することは劇的な違いを生む可能性があるため、これは解決すべき重要な問題です。

あなたのキャリアの中で：多くのクライアントはあなたを雇うことを決定する前にあなたの社会的すべてを見るでしょう。 GitHubアカウントとLinkedInの履歴書は、FacebookとTwitterのプロファイルとともにリストの一番上にあります。あなたはそれらを賢く使うべきです。
あなたの技術的スキルのために：他の開発者によって書かれたコードベース、そしてしばしば非常に優れたものを調べることはあなたに多くを教えます。ひどく書かれたコードベースから意味を引き出す能力は、あなたに同じように挑戦し、教えてくれます。
あなたのソフトスキルのために：オープンソースソフトウェアは共同プロセスであり、そこにあるほとんどすべての興味深いプロジェクトはチームによって構築されています。誰もが使用するツールを使用して他の開発者と協力し、チームに溶け込み、効率的にコミュニケーションすることを学ぶことは、熟練した開発者だけでなく、優れた開発者になるでしょう。
コミュニティの場合：オープンソースプロジェクトに貢献するすべてのビットが重要です。貢献すればするほど良いのですが、翻訳で小さなタイプミスを1つ修正するだけでも、最終製品はより良くなります。
あなたのネットワークのために：あなたは何百もの履歴書を会社に送ることができます、しかし個人的なつながりを持つ同僚を持つことほどうまくいくものはありません。オープンソースプロジェクトに積極的に参加することで、人々に会い、彼らの尊敬を得ることができ、あなたの評判は高まります。これは、どの専門家にとってもかけがえのないものです。

これは、この恐怖と戦うための私の小さな個人的な旅です。この記事の公開は、旅そのものの一部です。ブログの投稿をブロックされている人や、少しでも投稿することを恐れている人が、最終的にはそれほど怖くないことを理解してくれることを願って書いています。また、オープンソースに貢献したいが、どこから始めればよいのかわからない人を支援することを目的としているので、基本から始めます。

オープンソースソフトウェアとは何ですか？どこにありますか？

オープンソースソフトウェア（略してOSS）は、そのソースコードとともにリリースされたソフトウェアであり、変更および再配布を可能にするライセンスが含まれています。ウェブサイト、メーリングリスト、フクロウなど、どこにでも配信できます。最も一般的なシナリオであり、私たちが関心を持っているシナリオは、コードベースがコラボレーションリポジトリで維持されている場合です。ここではGitHubに焦点を当てていますが、SourceForgeやBitbucketなどの他のオプションもあります。 GitHubは非常に使いやすく、膨大なユーザーベースを持ち、あらゆる種類のコードに使用でき、使用するあらゆる開発環境で使用できます。重要なのは、非オープンソースプロジェクトにも広く使用されていることです。次のクライアントプロジェクトはそこでホストされる可能性が高いので、それをどのように扱うかを知ること自体が有用なスキルです。

コーディング方法がわからない場合はどうなりますか？

これを読んでいるなら、コーディングの仕方を学びたいと思うでしょう。あなたはいくつかの無料と有料のウェブサイトで素晴らしいコースを見つけることができます。学習する言語を1つ選択する必要があります。好みがない場合は、JavaScriptを使用してください。 Webブラウザーで開始するために必要なものはすべてすでに揃っており、最も広く使用されており、市場性のあるスキルの1つです。私の個人的なお気に入りはPythonです。これは、Web開発と科学アプリケーションの両方で使用されています。また、私はUdacityで個人的に好きな初心者コース「コンピュータサイエンス入門」を持っています。学びながらプロジェクトに取り組むハンズオンコースなので気に入っています。また、Coursera、Khan Academy、PluralSightには他にもいくつかのコースがあります。

Gitがわからない場合はどうなりますか？

前述のように、Gitを知ることは重要なので、Gitクラスを受講してください。しばらくGitを使用している場合でも、それを実行してください。実際にGitを研究するまで、Gitについてどれだけ知らないかわかりません。 rebaseコマンドの機能を自信を持って説明できない場合は、これを実行してください。間違ったリベースがあなたを怖がらせなくてもそれをしてください。私はCodeSchoolでGitの完全な道を歩みましたが、ここでも、他のサイトを探索してより多くのオプションを探すことができます。

GitHubでプロジェクトを選択するにはどうすればよいですか？

日常の開発でOSSを使用している可能性があります。使い慣れたフレームワークを選択することは、良い出発点です。あなたはすでに機能とフレームワークがどのように機能するかをよく知っています。ソースコードに飛び込むと、より多くのことを学び、そのロジックをさらに明確に理解できるようになります。特に気に入ったテクノロジーやツールがある場合は、それについて言及しているプロジェクト、またはツールのプロジェクト自体を探してください。最後の手段として、GitHub Showcasesでプロジェクトを確認し、興味のあるカテゴリを選択することから始めることができます。

たとえば、GitHubの検索で「Raspberry」をすばやく検索すると、17,000を超えるリポジトリが表示されます。迷子になりやすいので、優れたコミュニティと優れた問題追跡システムを備えたプロジェクトを探してください。プロジェクトを選択するときは、次の数を確認してください。

寄稿者：10人を超える寄稿者をターゲットにします。これにより、プロジェクトに十分な関心があり、単なる小さなチームの努力ではないことが保証されます。 OSSを初めて使用する場合、またはスキルがあまりない場合は、検索対象を最大50人の貢献者がいるプロジェクトに限定してください。より大きなコミュニティは、より大きなコードベースとより複雑なプロジェクトを意味します。
コミット：少なくとも1,000のコミットがあり、最新のアクティビティが1週間以内のプロジェクトに進みます。 1か月以上非アクティブになっているプロジェクトは、OSSの観点からは古くて古く、おそらくすぐに応答を得ることができません。毎日の活動は健全なプロジェクトのしるしです。
問題：問題とは、未解決の問題、報告された、または実装する機能を要求されたバグです。それらはあなたに出発点を与え、プロジェクトへの関心の良い指標となります。

また、プロジェクトの主要言語が何であるかを調べます。プロジェクトのメインページのトップバーに言語統計が表示されます。議論のトーンを読んで、コメントがどれほど友好的で教育を受けているかを見てください。一部のプロジェクトは積極的なコミュニティで悪名高いため、適切な出発点ではない可能性があります。

私はデータに興味を持っているので、列指向データストレージプロジェクトであるScyllaDBを選びました。パフォーマンスに関連するものなら何でも。私はそれを使ったことがありませんが、そのコードベースに飛び込むことができると期待しています。私が知っているツールを使用する方が簡単かもしれませんが、私はこれを挑戦と新しいことを学ぶ機会としてとらえています。残りの部分については、それは法案に完全に適合します。 18の寄稿者、6.5kのコミット（最新のものは執筆時点で23時間前）、178の未解決の問題があり、アクティブに見えます。

私は今何をしますか？

まず、リポジトリのクローンを作成し、ソフトウェアをマシンにインストールして、その可動部分を把握します。次に、問題を読み始めます。準備ができたら、マシンで問題を再現できるかどうかを確認してから、ソフトウェアの誤動作の原因の分析を開始します。

もう1つのアプローチは、自分で改善または変更できるものを見つけることです。たとえば、タイプミスやフォントのずれに気づいたかもしれません。私は小さなバグ、特にスクリプトのドキュメントで使用されている間違った変数名を修正することを選択しました。

小さいように見えますが、間違ったドキュメントは、ドキュメントがない場合よりもはるかに悪いです。ユーザーはScyllaDBをインストールし、インストール手順を実行します。ユーザーはそのスクリプトに記述されている内容に盲目的に依存し、フラストレーションの山になってしまいます。これは私の能力にとって完璧であり、それを修正するには、プロセス全体をたどり、コードベースに少し慣れることが必要になります。バグ修正は退屈ですが、プロジェクトへの道を見つけるための素晴らしいスタートです。

フォークの作成

これは些細なことかもしれませんが、現時点では、ScyllaDBプロジェクトの場合、私は誰もいません。監督なしでコードに変更を加えることを許可するのは危険です。私がする必要があるのは、自分のGitHubアカウントに「フォーク」を作成することです。これが私のScyllaDBフォークです。それは私がすべてのコードにアクセスできる私自身の遊び場であり、私は好きなようにファイルを変更することができます。 ScyllaDBの独自のバージョンを作成し、それを微調整して元の目的とはまったく異なることをしたい場合は、ここでそれを行うことができます。フォークの作成は簡単です。プロジェクトのメインページに移動し、「フォーク」ボタンをクリックします。まったく怖くない。

バグを修正する時間

次に、コンピューターでコードをテストし、必要な変更を加えます。まず、マシンにGitクライアントがインストールされていることを確認してください。次に、SSH公開鍵をGitHubに追加し、ssh-agentによって読み込まれていることを確認します。コードをローカルで取得するのは簡単です。メインブランチの代わりに、フォークを指すgit cloneコマンドを使用するだけです。

 git clone [email protected]:acbellini/scylla.git

これで、メインブランチでプロジェクトをテストする必要があったので、コードをローカルでビルドして同じ方法でテストします。参照は相対的であるため、プロジェクトが依存している他のGitHubプロジェクトをフォークする必要があることに注意してください。私の場合、seastar、scylla-ami、scylla-swagger-uiをフォークする必要がありました。

修正する必要のあるバグは比較的単純です。 conf/scylla.yamlのドキュメントには、3つの構成可能なディレクトリが記載されています。1つはデータファイル用、1つはコミットログ用、もう1つは明らかに未使用のキャッシュ用で、すべてデフォルトで$CASSANDRA_HOMEのサブディレクトリになります。

コードを詳しく見てみると、デフォルトが異なっていることがわかります。私が始めた問題＃372で述べたように、 $CASSANDRA_HOMEは使用しないでください。いくつかの異なる設定でコードをテストし、構成ファイルから設定を削除し、使用されているディレクトリを確認することで、仮説を検証します。すべてが正しいことを十分に確信したら、変更したファイルを追加、コミット、およびプッシュできます。

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

コミットメッセージでハッシュが前に付いた問題番号を導入したことに注意してください。これにより、GitHubにコードを問題自体に自動的にリンクするように指示されます。

注意すべきもう1つの重要な点は、コードを調査したときに、キャッシュ用の3番目のディレクトリが実際には使用されていないことに気付いたことです。一歩踏み込んでこの設定自体を削除したり、使用されていないコメントを追加したりするのは魅力的ですが、それは問題＃372の範囲外であり、これに厳密に関連しないものをコミットするのは誤りです。問題。変更を集中させ、目前のタスクに限定する必要があります。

この時点で、コードは修正され、GitHubのプライベートフォークにあります。ここで怖い部分が出てきます。ScyllaDBの人々に私のコードを受け入れるように頼むのです。これはプルリクエストと呼ばれます。

最後のステップ：プルリクエスト

GitHubのウェブインターフェースから直接プルリクエストを作成するのが好きです。コマンドラインから実行するよりも、直感的でエラーが発生しにくいと思います。プルリクエストを作成するために必要なのは、ブランチ名の横にある小さな緑色のボタンをクリックすることだけです。

コメントはGitHubによって自動的に計算されたことに注意してください。私のブランチには新しいコミットが1つありますが、フォークを作成してからメインリポジトリにさらに14のコミットがあるので、左側の緑色のアイコンをクリックします。

幸いなことに、私の1つのコミットは他の14のコミットと競合しないので、GitHubは私に行ってもいいと通知します。他にコメントやメッセージを追加する必要はありません。コミットメッセージは非常に短いですが、すべてを示しています。コードの変更は何をし、何に関連しているのか。最後のボタンをクリックしてリクエストを確認していると、ほんの数日前にこんなに怖かったのは何だったのだろうか。今、私に轟音を立てるモンスターはいないし、地獄の炎は燃えているようには見えない。正直、全然怖くありませんでした。万が一、間違えた場合、修正は受け入れられず、それだけになります。

ここで問題の詳細を確認すると、GitHubがこの問題を参照するプルリクエストがあるというメモを自動的に追加したことがわかります。これは、コミットメッセージの＃372の魔法です。これは、他の人がすでに修正されたものを修正するために時間を無駄にすることを回避するのに役立ちます。

オープンソースはそれほど怖いものではありません。

つぶやき

最終メモ

プルリクエストが受け入れられるのを待っています。それが発生すると通知が届きます。これには数日、場合によっては数週間かかる可能性があることに注意してください。誰かが私のコードをレビューし、説明どおりに機能することをテストし、問題を修正し、最終的に、コードの残りの部分の機能に悪影響を与えないことを確認する必要があります（読んでください：新しいバグを作成します）。これにはすべて時間がかかりますので、しばらくお待ちください。最終的に、プルリクエストが受け入れられると、ScyllaDBにはもう1人の貢献者がいて、問題は1つ少なくなり、最初のOSSの貢献があります。さあ、あなたも試してみる時が来ました。結局のところ、それはまったく怖くないです。