オープンソースの Python プロジェクトを成功に導くには、有用なコードを作成するだけでは十分ではありません。プロジェクトの成功には、コミュニティーの関与、協力の機会拡大、職人芸、そしサポートが関係してきます。この記事では、プロジェクトを成功させるために役立つベスト・プラクティスを探ります。

Patrick T. Altman, VP of Engineering, Eldarion

Photo of Patrick AltmanPatrick Altman は Pinax の中核的な開発者であり、他にも多くのオープンソース・プロジェクトを作成し、それらに貢献しています。彼は現在、Eldarionの VP of Engineering です。それ以前には、後に AOL に買収された StudioNow の Principal Software Engineer でした。彼は現在テネシー州ナッシュビルに住んでおり、妻と 3 人の子供がいます。



2012年 2月 10日

オープンソースの Python プロジェクトのためのエコシステムは充実していると同時に多様性があります。これは、次のオープンソース・プロジェクトを作成する際に経験豊富な開発者たちの助けを借りられることを意味するだけでなく、コミュニティーの規範とベスト・プラクティス一式があることも意味します。独自のプロジェクトでこれらの規範に従い、ベスト・プラクティスを適用して完成させたソフトウェアは、より広く採用される可能性があります。

この記事では、ユーザー・コミュニティーが広がる結果となった大小規模のさまざまなプロジェクトで成果を上げたベスト・プラクティスを取り上げます。ここで取り上げる提案は合理的で意味のあるものですが、結果はプロジェクトによって変わる可能性があるため、厳格な教義としては捉えないでください。

まずは、プロセスを切り離すことがコミュニティーの強化につながり、オープンソース・ソフトウェアの作成プロセス、保守プロセス、そしてサポート・プロセスのすべてにわたって処理能力が高まることになる仕組みを説明します。

連携と協力の違い

DjangoCon 2011 の開催中、David Eaves 氏は基調講演で、連携と協力の定義は似ているものの、そこには微妙な違いがあるという考えを雄弁に言い表しました。

「私の考えでは、連携のプロセスでは、協力とは異なり、プロジェクトの関係者が連帯責任で問題の解決にあたる必要があります」。

Eaves 氏はその後、GitHub がオープンソースの仕組みを革新する原動力となった仕組み、特にコミュニティー管理の側面について 1 つの記事を投稿しました。「How GitHub Saved OpenSource」(「参考文献」を参照) で、彼はこのように述べています。

「私はオープンソース・プロジェクトが最も功を奏するのは、トランザクション・コストの低い協力プロセスにコントリビューターが参加できるようにして、トランザクション・コストの高い連携プロセスを最小限に抑えた場合であると考えています。オープンソースの優れた特質とは、あらゆる課題を集団で討議して問題に取り組むグループを必要としないことであり、通常考えられる優れた性質とは正反対です」。

彼はその後の投稿で、プロジェクトをフォークする価値について、そしてトランザクション・コストの低い協力プロセスで人々が許可なくしてプロジェクトを前進させられるようにすることによって、トランザクション・コストの高い連携プロセスが減る仕組みについて話しています。プロジェクトをフォークすれば、ソリューションをマージする段階になるまで調整の必要がありません。そのため、遥かに迅速で動的な実験が可能になります。

プロジェクトをこのような形にすることによって、作成、保守、およびサポートのすべてにわたってトランザクション・コストの低い協力プロセスを増やし、トランザクション・コストの高い連携プロセスを最小限にするという同じ目標を追うことができます。


作成

白紙の状態からまったく新しいものや革新的なものを作り出す場合、あるいは既存のものから多少異なるものを作成する場合でも、新しいプロジェクトを発足し、その作業の成果を世界と分かち合うことに勝るものはありません。

保守とは異なり、作成のプロセスでは、既存のものを変更または修正するのではなく、新しいものを作り出します。プロジェクトを作成および作り込むことは、科学というだけでなく、芸術様式でもあります。他の人々はコードの実装を見て、そのコード品質を判断します。そして、コードに作成者の名前が永遠に刻み込まれます。

したがって、ソフトウェアを作成する際には職人の考え方と手法を理解することが重要です。新しいプロジェクトを作成するということは、コードを作成することを意味するだけではありません、プロジェクトの作成、作り込みには、読む喜びを与える美しいスタイルのコードを作成すること、プロジェクトの機能を必要に応じて検証するコードを作成すること、完全かつ参考になるドキュメントを作成することも含まれます。

職人芸

一般に職人というときの「職」は、通常は大量生産されることのない何らかの物を手作業で作るための特殊技能を要する手仕事または職業を指します。この定義をソフトウェアに拡張してみると、ソフトウェアの職人は量よりも質にこだわるという意味で、ソフトウェアにもこの職に関する定義が当てはまります。

職人にとって重要なのは、完成した作品が機能するだけでなく、人々を魅了することです。ソフトウェアの場合で言うと、ソフトウェアの職人は、コードが簡潔で美しいこと、アプリケーション・プログラミング・インターフェース (API) が見た目に美しいこと、ドキュメントとテストがユーザーに信頼できる製品を使用しているという感覚を与えることが確実となるように努力します。

この考え方で作業をすれば、オープンソース・ソフトウェアを作成する上でのやりがいにも、大きな楽しみの源にもなります。納期、クライアント、そして他の外部からの要求に応える必要はありません。時間をかけて、素晴らしいソフトウェアの作成を楽しむことができます。

コードのスタイルとリンティング

PEP (Python Enhancement Proposal) 8 (「参考文献」を参照) は、Python プロジェクトの基準とすべき (あるいは少なくともプロジェクトのスタイル・ガイドとすべき)、詳細な Python スタイル・ガイドです。PEP 8 に固執することが重要であるというわけではありませんが、プロジェクトが PEP 8 に沿っているほど、他の Python 開発者が標準的な Python コミュニティー・スタイルの簡潔なパッチを提出しやすくなります。

スタイルへの準拠に加え、コードの「リンティング」の概念はインポートの欠落や未定義の変数などといったエラーを発見する上で重要です。スタイル・チェッカーの他に、「リンター」(リンティング用ツール) もいくつかあり、コードを検査してデフォルトのルール・セットまたは独自に構成したルールからの逸脱を見つけるのに役立ちます。最もよく使われているユーティリティーには以下のものがあります。

  • pyflakes
  • pylint
  • pep8

以上のツールについては、「参考文献」のリンクを参照してください。

どの規範に従うかに関わらず、その規範が PEP 8 に沿っていない場合には、その違いを文書化し、あなたのプロジェクトに貢献したいと思っている人々がプロジェクトで採用されているコーディング・スタイルを認識できるようにしてください。暗黙的に示唆するよりも、明示的に文書化するほうが賢明です。

pyflakes はとりわけ役に立つリンターです。バランスの良い有用な機能を備えたこのツールは、マイナーな違いに必要以上にこだわることなく、エラーを捕捉して強調表示します。以下に示すのは、Python プロジェクトで pyflakes を使用したセッションの一例です。

$ pyflakes kaleo
kaleo/forms.py:1: 'form' imported but unused
kaleo/forms.py:4: undefined name 'forms'
kaleo/forms.py:6: undefined name 'forms'

上記のように、このツールはすぐにインポートに関するタイプミスがあることを教えてくれます。kaleo/forms.py を調べると、以下のようになっています。

1: from django import form
2: 
3: class InviteForm(forms.Form):
4:    email_address = forms.EmailField()

これで、行 1 を from django import forms に変更する必要があることがわかります。

テスト

コードが機能することを検証するテストをプロジェクトに用意するのは、どのような場合でも賢明なことです。気付かないうちにリグレッションが発生することを防げるだけでなく、場合によっては、テストがドキュメントとしての役割を果たすことにもなります。テスト・コードを読むと、ライブラリーの API がどのように機能するかがわかることがあるためです。

そうは言っても、私はプロジェクトにテストが含まれているかどうか、そしてテストが含まれている場合にはどれほど完全なテストであるかどうかを基準に、プロジェクトの完全性や実現可能性を判断することはしません。テストが存在するからと言って、コードの品質が保証されるわけではないからです。論議を呼ぶ考えかもしれませんが、私は誤ったものをテストするのであれば、テストを行わないほうがましだと考えています。したがって、テストを作成する際の重要な点として、テスト対象のユニットごとに、さまざまな情報を入力することを検討してください。

ドキュメント

一方、テストとは違って、ドキュメントの品質と、ドキュメントがカバーしている内容の広範さは、プロジェクトの品質と職人芸を判断する基準になります。コードの作成に取り組む方法と同じように、ドキュメントの作成および保守に取り組んでください。十分な情報が書かれた詳細なドキュメントは、コントリビューターを触発し、そのドキュメントに倣ってユーザーに一層使いやすいプロジェクトにしようという意欲を起こさせるはずです。

Sphinx や Read the Docs などのツール (「参考文献」を参照) を使用すれば、素晴らしい見栄えの最新ドキュメントを公開することができます。これらのツールは、ドキュメントの内容を入力してコミットを push するだけの単純な手順で使用することができます。ドキュメントの変更を適宜コミットする習慣をできるだけ身に付けてください。


保守

PyPI (Python Package Index) の最初のバージョンをリリースし、さまざまなツイートやブログの投稿でリリースを発表した後、プロジェクトのユーザーが徐々に増えてくるうちに、作成者としての継続的アクティビティーに加え、保守作業を行う必要が出てきます。ユーザーは、バグ・レポートや機能リクエスト、そしてドキュメントで明確にされていない点についての質問など、さまざまな反応を返してきます。

実際に問題に対処する代わりに次善策を提案できる場合もありますが、そうでない場合は、ドキュメントまたはコードの修正が必要になります。git のような分散バージョン管理システム (DVCS) を使用して頻繁に開発者向けパッケージをリリースすることで、面倒な保守作業を大幅に軽減することができます。

ソース管理

利用できる DVCS は、git および mercurial をはじめ (「参考文献」を参照)、多数あります。どのバージョン管理システムを使用するにしても、そのシステムが必ずソース管理にも対応するようにしてください。ソース管理により、ユーザーにプロジェクトをフォークさせて自分たちでバグに取り組めるようにすることができます。

プル・リクエスト

プル・リクエストとは、リポジトリーの他のフォーク (通常は親フォーク) に送信して、そのリポジトリーの所有者に一連の変更をプル、またはコミットするよう要求するメッセージのことです。プル・リクエストのプロセスによって協力が増え、連携のトランザクション・コストが削減されるため、革新サイクルが加速されます。

変更の頻度を左右する要因は多数ありますが、なかでも極めて重要な要因は、ターゲット・オーディエンス (例えば、他の開発者、技術者以外のエンド・ユーザーなど) です。開発者をターゲットとしたプロジェクトを作成している場合、プル・リクエストでバグ・レポートや機能リクエストを送るように奨励することで、保守者の負担はまさに軽減されます。さらに、コントリビューターの貢献が将来のリリースにマージされることから、連帯意識を高めることにもなります。

dev ビルド

dev リリースは、できるだけ早期かつ頻繁に、そしてパッチ一式を追加した後には何度も公開する必要があります。そうすることで、プロジェクトを使用している他の開発者が、プロジェクトで行われた最新の変更に非常に容易に対処しやすくなるためです。異なる状況でコードを使用するユーザーが多ければ多いほど、新しい安定版をリリースする時点での品質が高くなります。


サポート

保守に付随するサポートには、ユーザーとコントリビューターを関与させ、そこからコミュニティーを構築することが不可欠です。他の人々にサポートを支援する権限を持たせれば、プロジェクトの全体的な協力要因が増え、それによってプロジェクトは規模の点でより柔軟に拡張できるようになり、ユーザーの問題に対する解決案も自然と増えてきます。

そのためには、必ず複数のチャネルを提供し、ユーザーがさまざまなアクセス手段で容易にプロジェクトの作成者に連絡したり、プロジェクトに関与したりできるようにしてください。チャネルの選択肢には、例えば IRC、メーリング・リスト、そして Twitter などのソーシャル・メディアがあります。

IRC

freenode などの IRC にチャネルをセットアップするのは賢明です。私のプロジェクト、nashvegas にもそのようなチャネルをセットアップしています。私以外のユーザーが利用していることはまれですが、IRC クライアントはバックグラウンドで控えめに実行されます。たまに利用するユーザーの質問に対して、ほとんどトランザクション・コストなしで、しかも E メールより遥かに動的に応答することができました。

メーリング・リスト

ほとんどのオープソース・プロジェクトでは標準的なプラクティスとして、サポート用、そして開発の進捗状態をコントリビューターの間で討議できるように、メーリング・リストを用意しています。私が推奨する方法は、始めはメーリング・リストを 1 つに絞り、ユーザーあるいは開発者のそれぞれにとって不要な情報があまりにも増えてきた時点で、「ユーザー用」リストと「開発者用」リストに分けることです。

Twitter

プロジェクトの Twitter ハンドル名を取得して、人々があなたの作業について公にあなたに話しかけられるようにしてください。Twitter アカウントは、プロジェクトを発表する場としても最適です。


まとめ

オープンソース・ソフトウェアを作成して Python コミュニティーに貢献するのは、面白くもあり、実りある経験でもあります。トランザクション・コストの高い連携プロセスを減らす一方、トランザクション・コストの低い協力プロセスの機会を増やすことに重点を置けば、アクティブなコントリビューターによるプロジェクトの成長を促すことになります。プロジェクトの作成に関して言えば、オープンソースでは、作成者が職人気質でプロジェクトを作成する自由があります。この点を最大限に利用して楽しんでください。一貫したコード・スタイル、堅実なテスト、そして十分な情報で作成されたドキュメントに重点を置くと、より多くのユーザーや他の開発者がプロジェクトを採用するようになります。また、DVCS を使用し、プル・リクエストに留意し、頻繁に開発リリースを公開することも重要です。さらに、複数のサポート・チャネルを提供して、プロジェクトのサポートをコミュニティーが支援できるようにすることで、プロジェクトの普及および成長を一層促すことができます。

参考文献

学ぶために

製品や技術を入手するために

  • 使用できるリンターは数多くあります。よく使用されているリンターとしては、pyflakespylint、そして Python スタイル・ガイド・チェッカーの pep8 が挙げられます。
  • プロジェクトのドキュメントを追加する準備ができたら、いくつかのオンライン・ツールでこのジョブを容易にすることができます。その 2 つの例は、SphinxRead the Docs です。
  • gitMercurial は、どちらも優れた DVCS です。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=791400
ArticleTitle=成功する Python プロジェクトを作成する
publish-date=02102012