これは、プロジェクトの成果を第三者が一定の範囲で利用できるよう公開する"オープン化"を効果的に実施するための原則を記したガイドラインです。成果をオープン化することによって、より多くの人々がアクセスできるようになり(アクセシビリティ)、アレンジや波及を通じて深く接してもらう機会が増え(エンゲージメント)、プロジェクトの多様性が増えていく(ダイバーシティ)といった効果が期待できます*1。これによって、プロジェクトが成長していきます。
オープン化を通じてクリエイティビティ*2が高まり、新たな表現が生まれたり、様々な問題が解決されるようになると考えられます。また、プレゼンスの向上、ビジネスの展開、フリカールチャーへの貢献にもつながり得ます。
このガイドラインは、山口情報芸術センター[YCAM]でのオープン化の経験(と反省)や、プロセスベースのオープン化のマニュアル(ガイドラインの旧バージョン)からオープン化に効果的と思われるキーワードを取り出し、グループ分けし、それぞれのポイントを抽象化して原則(principles)として表現したものです。つづいて、この原則に関連するもう少し具体的な事柄(ガイドライン)を示しています。また、事例や補足情報についても"e.g.""fyi"として記述しています。これまでに気づいた課題については、問題提起や解決方法の提案をしています。それぞれの原則は関連し合っています。必要に応じて行き来しながら利用してください。
ガイドラインの利用者として、インタラクションデザイン、デジタルコンテンツ、メディアアートといった分野の、プロデューサー、キュレーター、エデュケーター、大学教員、クリエイター、学生を想定して制作しています。
さらに、前述の分野を超えたより広いクリエイションの分野において、比較的小規模な主体(e.g.スタートアップ、中小のプロダクション、休日クリエイター)が、利用できることも目指しています。
成果のオープン化の実作業のために、オープン化のマニュアルを準備しています。実際の手順についてはこちらを参照ください。
*1 「アクセシビリティ」「エンゲージメント」「ダイバーシティ」については、以下を参照ください。
ファッションは更新できるのか？会議 報告書 on Web
Vol.4「ファッションがアノニマスデザインに託す願いとは」（前編）
http://dotplace.jp/archives/12272
*2 クリエイティビティ = 新たなアイディアや成果の創造を促す要因(その質、量、可能性などを高めるもの)
ステークホルダのクリエイティビティに配慮する
つくる人のクリエイションへの影響を検討する
いい感じでやる
運営方針とマッチする
プロジェクトの目的とマッチする
デメリットはある、(いくらか)コストもかかる
オープン化に必要な要素を捉える
制作フロー全体で捉える
説明やディスカッション
(オープン化の)仕様や必要なタスクを企画書に示す
(オープン化の)仕様や必要なタスクを契約書に示す
クリエイションサイクルをデザインする
開放系をデザインする
持続的に発展させる
消極的なオープン化は否定しない
隙間を作る
より多く(のひとが、機会で)使えるようにする
使いやすいオープンソースにする
拡張機能
スタンドアロン的であることは否定しない
それが何なのかを明確にする
ドキュメントを充実させる
より自由に利用できるようにする
ライセンス・利用規約をえらぶ・つくる
成果とユーザ、開発者らをつなぐしくみを作る
アップデートを頻繁にする
リーガルデザイン
法的に適切に
ウェブサイト
見栄えを大切に
[Increase Creativity!]
人々のクリエイティビティ*が向上することによって、より新たな表現が生み出されたり、様々な問題が解決されるようになると考えられます。このクリエイティビティを向上させることが、本ガイドラインに通底する原則であり、以降の原則はこの効果を高めるように設定されています。
*クリエイティビティ = 新たなアイディアや成果の創造を促す要因(その質、量、可能性などを高めるもの)
どういった成果を誰がどのように(どういった範囲で)利用するのか、それによってどのような効果が生まれるのかを想定します。これがクリエイティビティを向上するのかを検討します("オープン化を伴うクリエイションの系のデザイン")。
クリエイティビティの向上を試みる時、まず、それが誰のクリエイティビティなのかを考えます。成果をオープン化するとき、様々なステークホルダーが関わってきます。代表的なのは、その成果を"つくる人"、"使う人"、さらに、ワークショップや開発などに"参加する人"といった人々です。
プロジェクトの成果をオープン化することで、こうしたステークホルダーのクリエイティビティを向上するよう配慮します。具体的な項目は次以降の原則で示しますが、それが誰のためになるのかについて常に意識をし、また、特定のステークホルダーだけではなく他のステークホルダーにとっても効果があるよう、そのバランスに配慮します。
e.g. ステークホルダの例
| 該当する人 | |
|---|---|
| つくる人 | プロデューサー、キュレーター、エデュケーター、大学教員、クリエイター、学生、コラボレーター etc |
| 参加する人 | ワークショップ参加者、ある地域に着目したプロジェクトに巻き込まれる地域住民 etc |
| 使う人 | ユーザ、二次利用者(n次利用者)、学生 etc |
fyi
多くの人がまず気になるのは、"使う人"ではないでしょうか。たとえばドキュメント(後述)は、成果を使い始めること、そして使いづつけることにとても大きな役割を果たします。これはアクセシビリティ、さらにエンゲージメントに大きな影響を与えます。
(意外かもしれませんが、)オープン化は"つくる人"のモチベーションやクリエイションの効率の向上を促します。良い成果を生み出すために、まず、"つくる人"にとってのメリット(e.g.フィードバックを得られること、コラボレーションの可能性が高まることなど)を認識することが重要です。
適切にオープン化のプロセスを設定することで、"つくる人"のモチベーションや、成果のクオリティ、作業効率を向上することができます。権利を共有することを明確にしたり、第三者に見られるようになること、再利用の可能性の担保することによって、クオリティ向上へのモチベーションが高まると考えられます。
e.g. オープン化を行ったプロジェクトメンバーのコメント
YCAMで実施したプロジェクトReactor for Awareness in Motion (RAM)は、その成果をオープン化しています。これに参加したメンバーは、次のようにコメントしています。
「権利などについて(オープン化するよう)決められることで、しっかりしたものを作ろうと思う。」
「(後に)自分も使う、他の人の目に触れるものだから、ちゃんとしたものを作ろうと思う。」
「成果のオープン化は、クリエイターにとって、営業活動でもある。経済的に合理性があり、コマーシャルな活動として意味がある。」
「オープン化を前提としているから、成果のクオリティを上げることができた。普及につながるオープン化を前提とすることで、再利用ができるように作るようにしたことが大切。クリエイター自身と第三者にとっての、再利用性を高めた。」
オープン化の要素やプロセスについて、ロジックで固めすぎてしまうと、クリエイションのテンポやスピード感(ある種のグルーヴ感)が悪くなってしまうこともあります。こうした要素はクリエイティビティに影響を及ぼします。よく考えること、そして考えすぎて息詰まらないこと。余白を残しつつ、いい感じの落とし所を目指すことで最適解に近づけるでしょう。
楽しい-スピード感がある-フレンドリーなど、プロジェクトに応じたポジティブなテイストを、一つでも良いので意識しながら進めるのも良いかもしれません。
e.g. GRP Contract Formでは、成果に関する権利の帰属などはきっちり規定しますが、クリエイションの可能性を担保するための余白を残すため、一部の詳細は別途協議で定めるとしています。
fyi
とはいえ、法的な対応は、きっちり行う必要があります。("法的に適切に"を参照ください。)
[Check Policy and Goal!]
成果をオープン化することが、プロジェクトを実施する主体の運営方針、そして、プロジェクトのコンセプト・ゴールとマッチしているか確認します。
この原則は、オープン化を実施するかどうかの判断基準としても用いることができます。つまり、これらがマッチしているなら、成果のオープン化を行った方が良いと判断できる、ということです。
fyi
これを確認するためのオープン化実施のチェックリストを制作しました。
オープン化がもたらす効果が、実施主体の運営方針と矛盾しないかを確認します。運営方針とは、例えば、プロジェクトを実施するグループ(e.g.プロダクション、研究室)の運営方針、企業の経営方針、個人のプロジェクトのならその人のポリシーといったものです。
公共性の高い団体や大学の研究室、社会貢献を社是にあげている企業などはオープン化と整合性が高いと思われます。助成金を利用したプロジェクトの場合は、その利用目的とのマッチングも検討すべきでしょう。
また、オープン化と収益化と距離があるように思われることもあるかもしれませんが、オープン化と営利活動とは、フリーミアムにみられるように、整合するケースがあります。
fyi
一般論として、公共のアートセンターや研究機関にとって、生み出された成果を市民(=citizen)が広く利用できるようオープン化することは、そのミッションと合致します。
fyi
法律や条例によって設置された組織であるならば、条文に示されたミッションを運営方針と捉えることができるでしょう。
e.g.
YCAMは山口市条例によって設置されています。このなかで、実施事業として以下が定められており、これは運営方針と捉えることができます。
（1）文化及び芸術の創造並びに振興のための事業
（2）市民の自主的な文化活動の支援に関する事業
（3）情報技術を活用した教育・学習支援活動及び調査・研究事業
（4）資料,情報等の蓄積及び提供に関する事業 など
(山口情報芸術センター設置及び管理条例 第5条より抜粋)
生み出された成果を一般市民が広く利用できるようオープン化することで、成果の利活用の可能性（芸術や教育を含む）を担保し、あたらな創作を促します。これは市民の文化活動の支援につながります。必然的にアーカイブを作成し、技術や活動の蓄積を行うことになります。制作において、オープン化を前提とすることで、研究の質（汎用性・再利用性など）をより高めるという効果も期待できます。さらに、オープン化による成果の周知・波及を通じ、アートセンターのプレゼンスを高めることができます。このため、YCAMの運営方針と成果のオープン化はマッチしていると考えることができます。
プロジェクトの目的は様々です。プロジェクトの目的についても、運営方針と同じように、オープン化がもたらす効果とマッチしているかを確認します。
この目的に応じて、オープン化する対象の範囲や利用許諾する範囲なども変わってきます。あわせて、そのプロジェクトにおいてどの成果をオープン化するのか、なぜオープン化を行うのかを明確にします。
e.g.
2013年にYCAMで実施したForest Symphonyは、世界各地の樹木の生体電位データをインターネット経由で山口に送り、そのデータを元に14チャンネルのサウンドデータを生成し、その音響を体験するサウンドインスタレーション作品です。全方位スピーカを空中にレイアウトするなど綿密に設計された空間で提示されました。
このプロジェクトの研究開発成果としてサウンドデータ、アンプシールド、樹木の生体電位データがあります。樹木の営みを取り入れ表現に用いるという作品コンセプトを実現するコア技術(アンプシールド)や、取得した生体電位データについては、さらなる表現やプロジェクトが生まれることを期待し、オープン化することにしました。一方で、サウンドデータについては、他の場所で同様の体験はできないことから公開を行わないことにしました(また、公開するにはシステム改変やサーバ環境の準備などのコストがかかります)。
オープン化には、特許権の取得などよりは少ないですが、コスト(労力・費用)がいくらかはかかります。方法によっては、デメリット、リスクが発生し得ます。これらについて冷静に検討します。こうしたマイナス要因を正しく認識し、オープン化するか否か、するならどのよう実施するのかを検討します。
どんな活動でも必要なことですが、経済的合理性について検討します。コスト(労力・費用)を見積もり、プロジェクトのリソース(予算、マンパワー)に納めるよう配慮します。営利目的の組織・プロジェクトであれば、前述のように、フリーミアムのビジネスモデルを参照しつつ収益を確保するプランを立てるのも良いかもしれません。
fyi
“作品やコンテンツの特性を考慮し”、“オープンとクローズドのバランスをはかることが大切*”�と指摘されるように、常に全ての成果をオープン化すれば良いとも限りません。例えば、あるコア技術に頼った企業があったとして、適切な対処なしにその技術をオープン化することで、その優位性が失われ、経営を継続できなくなるというケースも考えられます。
*オープンデザイン, Bas Van Abelら, オライリージャパン, pp.228(水野祐:ライセンスデザインの思考).
fyi
このテキストはオープン化することを啓蒙したり"布教"したりすることを目的とはしていません(以前はオープンソースは一種の宗教である、と揶揄されたそうです)。もしあなたが関わるプロジェクトにおいて、オープン化の効果が全くない、コストパフォーマンスが悪すぎるのであれば、オープン化を見送ることも検討すべきです。
オープン化には、ウェブサイトの構築やドキュメントの作成、特許制度における新規性の喪失など、一定のコスト(労力、機会損失)が必要になります。こうした"コスト"に対する対価である"ベネフィット"の説明としては、以前は、"コミュニティへの貢献の喜び"や"コミュニティからの評価"があげられることが多くありました。
一方で、近年ではオープン化を通じて収益を増やす、というビジネスモデルが実践されるようになってきました。(見たことがないなら、ちょっと検索してみて下さい。)また、公共性のある組織(大学、研究機関、アートセンター)にとっては、そこで生み出された成果を市民が広く利用できるようオープン化することは、そのミッションと対立するものではなく、むしろ合目的的なことです。プレゼンス向上と社会貢献を同時に行うツールであるもいえるでしょう。(あなたのラボの研究開発の成果が他の大学のラボで用いられて派生研究が生まれたり、あなたがつくった映像やインタラクションシステムなどをだれかがターミナル駅のガイドに用いたり。)
fyi
もちろん、誰かが、あなたの成果をまるで自分の成果であるかのように用いてしまう、という"リスク"も"ゼロ"ではないかもしれません。成果を独占排他的に運用することで、"確実に"ベネフィットを増やすことができるなら、そちらを優先すべきかもしれません。逆に、オープン化しないことで(=お蔵入りしてしまうことで)、今後誰にも用いられないという"リスク"も"ゼロ"ではないでしょう。(死蔵特許は一種の不良在庫といっても良いでしょう。)(知的財産の独占排他的な運用とオープンな運用とは必ずしも相反するものではなく、組み合わせて用いることができます。ポストプロダクションを参照ください。特許権をオープン化に利用する方法もあります。)
独占排他的な運用とオープンな運用を組み合わせている例として、Arduinoを挙げることができます。Arduinoのオープン化は「商標を用いたライセンシング」を行っていることに特徴があります。これは、他の事例のオープン化とは一見異なります。このライセンシングにおいて、派生物にArduinoの商標を付す場合は、ライセンス料の支払いと品質チェックを受ける義務が生じ、逆に派生物にArduinoの商標をつけない場合は、ライセンス契約が必要がありません。 このライセンシングにより、品質を確保し、"自由なバリエーションの登場による活性化と、Arduinoブランド及び開発の継続に必要なコストの確保を両立"できているといいます(小林茂 "Prototyping Lab" オライリー・ジャパン, 2010). OSHWDefintionにも商標に係る条項が取り入れられており、注目すべきトピックです。
fyi
もしあなたが、自身のプロジェクトをオープン化した経験がなく、プロジェクトのオープン化を行うべきか否かを迷っているのなら、まずひとつのプロジェクトをオープン化してみて、そのワークフローを経験してみても良いでしょう。(小さなプロジェクトなら意外とすぐにできてしまいます。)
[Reach Consensus for Open Sharing!]
成果をオープン化するには、いくらかの設定(e.g.オープン化の対象、権利の設定、ドキュメント制作、メンテナンス実施)やタスク(e.g.ウェブサイト構築、クレジットの確認)の実施が必要になります。これらについて、関係者(プロジェクトメンバー、コラボレータなど)と事前にコンセンサスを取ることが大切です。
これによって、トラブルを避けるだけでなく、クリエイションの効率や成果のクオリティの向上が期待されます。
必要なタスクや設定すべき項目を事前に確認し、プリプロダクションに含まれるものはもちろん、ポストプロダクションに分類されるものについても、関係者間でコンセンサスを取ります。
個人のプロジェクトであるなら、いったん自己確認を行うことで、クオリティや効率の向上につながるでしょう。
オープン化に必要な要素、効果を上げるために検討すべき要素はさまざまです(e.g.成果の性質、利用環境、拡張機能など)。どのような要素があるのかを把握し、自分(達)のプロジェクトにどのように当てはまるかを検討します。なぜオープン化を行うのか、その成果をオープン化するのかもこの要素に含まれます。("プロジェクトの目的とマッチする"と関連があります。)
成果の種別によって検討すべき要素が異なってきます(software、hardware、contents、今後はbiowareも?)。コラボレーションにおいては、さらに、参加メンバー同士が協議し設定すべき要素があります(権利の設定,クレジット表記, ライセンスなど)。
fyi
オープン化に必要な要素とそれぞれの指針について、オープン化の基本ガイドラインにまとめています。成果の種別ごとのガイドライン、つまり、ソフトウェア・ハードウェアのためのものとコンテンツのためのものを用意しています。
fyi
成果のオープン化を実現する共同研究開発のための契約書ひながたであるGRP Contract Formでは、コラボレーター間で同意すべき要素について設定しています。
クリエイション(プロダクション)は時系列によって、プリプロダクション(制作の準備段階)、プロダクション(制作段階)、ポストプロダクション(仕上げや展開の段階)のように分けることができます。オープン化の実践には、様々な要素(e.g.ライセンスの設定、ドキュメント制作、ウェブサイト制作)が含まれ、それぞれが行われるフェーズによって分類することもできます。しかしこれらの要素を、時系列や段階で分けて考えるのではなく、全体のながれとして、要素同士の関連とともに一体的に把握します。
fyi
オープン化のプロセスのマニュアルは、このフェーズごとに書かれています。
事前にプロジェクトに参加するメンバーやコラボレーターが、プロジェクトの目的、オープン化の意義やその仕様について、情報共有し、ディスカッションします。これは、理解を深めたり課題を発見するだけでなく、クリエイションの効率向上にも効果があると考えられます。必ず行うべき事項です。先行事例や基本情報(このガイドラインなど)の共有を行うのも良いでしょう。
e.g. YCAMでは、成果のオープン化を行う共同研究開発プロジェクトでは、初期の段階でYCAMにおけるオープン化の考え方、事例、契約書ひながた(GRP Contract Form)の説明を行っています。
このミーティングを行うことについて、あるコラボレータは「説明して欲しかったポイントを話せた。」とコメントしています。
成果のオープン化を行うこと、それに必要な要素(前述)、必要なタスク、担当などを企画書などに示し、メンバーとのコンセンサスをとります。不明な部分があれば分かる範囲で(それを包含するように)示します。個人でクリエイションを行う場合でも、事前に確認することで、作業効率やクオリティが向上すると考えられます。
外部のメンバーや組織とコラボレーションを行う場合は、契約書(共同研究契約書など)に、オープン化に必要な要素を盛り込みます。
e.g.
こうした要素を盛り込んだ共同研究開発のための契約書のひながた(GRP Conract Form)を制作しています。
[Design Creation System including Open Sharing]
成果をオープン化することで、新たなクリエイションやムーヴメントが引きおこされ、新たな表現が生まれたり問題が解決される可能性がでてきます。そこからオリジナルのクリエイターがなんらかのフィードバックを受け取り、次のクリエイションのモチベーションとなったり、新たなつながりが生まれていく。こうしたクリエイションサイクルをまわす環境、つまり影響を及ぼしうる複数の要素を含む"系"を効果的にデザインすることで、さらなる波及や発展を試みます。成果を育てる、進化させる環境のデザインといっても良いかもしれません。
オープン化を伴うクリエイションサイクルやそれが展開するクリエイションの系について、そこに含まれる概念・要素を生態系の概念・要素をメタファとして利用し表現することもできます。なぜなら、両者にはなんらかのサイクルを回す場所としての性質があり、また、要素が系を超えて出入りする(ことを志向する)という共通点があるからです。成果を循環(クリエイション-利用-(分解)-クリエイション)(物質循環)できるしくみがあり、それを動かすエネルギー(太陽光)が投入され、活動を持続する場所がある、こうした環境をデザインするということです。すでにある環境の影響は大きく、他の系とも関連しあっています。サイクルが進むにつれて、また社会的状況の変化の影響(環境圧)を受け、いずれ大きな構成の変化(遷移)が起きるかもしれません。
オープン化することで、成果が再利用され、新たな成果が続けて生み出されていく。こうした循環が機能することで、様々な派生が現れてきます。こうした循環のサイクル全体(生産-消費-分解)で捉えることが大切です。どのような人にどのように利活用されたいかを想定し、クリエイションのサイクルモデルを作り、これの実現を試みます。
開放系のデザインと合わせて、広義のビジネスモデルデザインと捉えても良いかもしれません。これをもとに、成果のユーザビリティや、オープン化の方法、ウェブサイトの仕様、コミュニティーサポートなどをデザインしていくことになるでしょう。
また、時間は無視できない要素です。時間の経過を考慮し、サイクルを拡大、縮小、変化させるプランを立てるのも良いでしょう。
クリエイションサイクルが循環する場所(広義のマーケット)や後述するコミュニティは、物質循環が進められる生息空間(ビオトープ/住息環境)のような存在と捉えられます。
fyi
Kyle McDonald氏のコメントはクリエイションサイクルのデザインのヒントになるかもしれません。
「オープンソースは、茶室です。それは誰もが等しい存在であり、魂の鏡です。オープンソースの芸術は、各投稿者が自分自身の作業を如何に完成させるかであり、不完全なもの（バグ）に如何に協業で立ち向かうかにあるのです。」*
*「すべてを明け渡すことではじめて完成する、茶道としてのオープンソース」 Yazaki Yuichi, http://visualizing.jp/howtogiveeverythingaway/
e.g.
(成果をオープン化し、そこから循環を引き起こすモデルとは異なりますが、)YCAMでは、成果のオープン化を取入れたプロジェクトの方法論・プロセスについて、PDCAサイクルをもとにしたプロセスモデルをつくり、研究を進めています。このプロセスに必要なツールの開発、問題の検討を行っています。(GRP Contract Formやこのガイドラインもその一つです。)
e.g.
製造業ではオープン化されたものをある段階でクローズにして事業展開した例があります(e.g. Makerbot)。オープン化の形態は、プロジェクトを取り巻く状況に応じて変化します。
ここでいう開放系のデザインとは、物質やエネルギーのInout/Outputが閉じていないということに加えて、他の系とつながることができるような環境を設計する、ということを指します。成果が属する分野だけではなく、他領域(他の系)とつながることで、思いがけない相乗効果、突然変異が生まれるかもしれません。
e.g.
Reactor for Awareness in Motion (RAM)の成果の一つであるRAM Dance Toolkitは、openFrameworksと連携して動作し、openFramworksのさまざまな機能を用いることができます。また、様々なモーションキャプチャシステムと連携できる機能があります。
fyi
たとえば、研究開発ツールを研究者向けだけでなく教育向けにも展開することや、特定のデータの解析ツールを様々な種類のオープンデータを扱うようにインターフェイスを改良することも、選択肢となるかもしれません。デジタルファブリケーションにおける様々な成果が一般市民に展開してきた経緯は、一つの系が拡大した、もしくは他の系と接続したともとれますし、大きな遷移が起きたとも理解できるでしょう。
クリエイションサイクルが持続的に進められるしくみをデザインすることが望ましいです。イニシャルコスト抑制だけでなく、ラニング(運営)コスト(労力・費用)を抑えることは、サイクルを回す抵抗を減らすことにつながります。こうした対応は、予算規模や、継続してかけられるコストの有無によってかわってきます。
fyi
サイクルを回すためのエネルギーを取り入れることも大切です。成果のメンテナンスやアップデート、コミュニティサポートはこうしたエネルギーが必要とされる代表的な活動です。第三者がボランタリーかつ継続的にこうした活動にエネルギーを投入してくれることが理想的です。予算を準備し、スタッフを確保するのも一つの選択肢となるでしょう。後述する利用事例の収集(ofxAddons)も参照ください。("参加しやすくする"と強い関連があります。)
fyi
既存のウェブサービス(e.g.Github、Thingiverse、Instructables、その他のSNS)を利用することを検討しても良いでしょう。なぜなら、容易にウェブサイトを構築できる、コミュニティ機能を有している、メンテナンスコストが小さいからです。既にウェブサイトを持っているなら、たとえばプロジェクトを実施する組織が自らのウェブサイトを持っているならば、そこにページを追加することで対応するのも良いでしょう。
(構成については公開ウェブサイト構成のガイドラインを参照してください。)
ここでは特に推奨することはありませんが、第3者を巻き込むことをゴールに含まないプロジェクトにおいても成果をオープン化することはあり得ます。たとえば、個人が自分のために作ったツールを誰に使って欲しいわけでもなくオープン化すること、誰か使いたい人がいるなら勝手に自助努力で使えば良い、という態度での、いわば消極的なオープン化です。それでも生産性を高めることにもつながりますし、(どんな情報でも世界で誰かが必要としているのであれば)それをオープン化してしまうこと、放擲してしまうことで(give everything away)、どこかで誰かを助けることにつながるかもしれないからです。
こうした場合でも最低限のオープン化の有効性、つまり法的な合理性は確保する必要があります。また、最低限の持続的発展の可能性を担保すべきでしょう。いずれも、トラブルを避けつつ、他者のクリエイティビティを高める"かもしれない"、という状況を確保するためです。企業のプロモーションプロジェクトなど、短期的に話題を作るという目的でオープン化を行うもケースでも同様です。
e.g.
GitHub, Satoru Higa, Repositoriesはクリエイティブコーディングにおける神(もしくは仏)といわれる比嘉了氏のGitHubのリポジトリです(敬意を込めて!!)。大変な数のopenFrameworksのアドオンが公開されていますが、ドキュメントがあるのは数えるほどです。しかし、、、
e.g.
"積極的には公開しないけれども、オファーがあったら提供する"というセミオープンソース(by馬場哲晃氏)的な考え方もあります。
fyi
多くのユーザに受け入れられるか不明な場合(持続的発展が見込めるか不明な場合)や、投入できるリソース（費用や労力）が限られる場合など、当初はオープン化に必要な全てを行うことができなくとも、プロジェクトの発展に応じて段階的に対応して行くという戦略も採り得ます。
はじめから完全な生態系を作ることはとても難しいことです(e.g.バイオスフィア2)。後発の要素が補完できるような余地を残すこと。予想される経路のみをデザインしそれ以外を締め出すのではなく、ユーザによる予想外の要素が入り込める隙間を作る、作り込みすぎないこと。こうしたこともよりよいサイクルを生み出す、多様な環境に対応するのに意味があると考えられます。
育つ、進化するためには、それを助ける要素だけでなく課題(環境圧や淘汰圧)が役立つこともあるでしょう。
e.g.
Government Digital Service Design Principlesでは、"Do Less"を原則の一つとしてあげています。
"If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core."
[Improve Usability]
ここでいうユーザビリティは、一般的な使いやすさ、使い勝手に加え、再利用して新たなクリエイションにつなげるのに有益な点(特に成果の性質)にもフォーカスしています。キーワードとして、汎用性(様々な用途で用いられる)、応用性(カスタマイズしやすい)、可用性(多くの状況・環境で利用できる)を上げることができます。(成果の利活用をすすめるために、アクセシビリティを向上することといっても良いかもしれません。)
その環境の中で生きていけるまで育てる、ある種のインキュベーションといっても良いかもしれません。
成果を利用できる機会をより多くすることがポイントです。たとえば、汎用性の高いプラットフォームの性質を持たせること、より多くの目的で使えるようにすることとも言えるでしょう。
成果を(特に何らかの機能に特化したものであれば、)より多くの環境で利用できるようにします。例えば、既に普及しているプラットフォームで利用できるようにする拡張機能(後述、addonなど)として制作する、マルチOSに対応するのもよいでしょう。
fyi
成果の汎用性は、応用可能性や波及効果に大きな影響を及ぼす重要な要素です。機能や利用目的が限定されていた場合、ユーザも限定されます。一方で、新たな機能を追加しやすかったり、他の目的に利用できるようアレンジしやすい性質を持っていた場合、潜在的なユーザは広がります。つまり、波及を考慮した場合、オープン化する成果は汎用性が高いプラットフォームとしての性質を持った方がよいといえます(e.g.Processing、openFrameworks、Arduino)。コンテンツについては、完成したデータだけでなく、二次利用を促進するための素材データも併せて提供する、という方法が考えられます(コンテンツのオープンソースと呼ばれることもあります)(e.g.Choreography filmed)。
e.g.
Guest Research Project vol.2の成果であるDuration・ofxTimelineは様々なリアルタイム処理システムをタイムラインでコントロールできる汎用性の高い、プラットフォーム的な機能を持っています。
GitHub YCAMInterlab / Duration
e.g.
Forest Symphony のアンプシールドは、広く普及しているArduinoのShieldであり、他のShieldと同様、(マルチOSに対応しひろく普及している)Arduino用のプログラムでコントロールできます。
YCAM InterLab Forest Symphony
成果の素材(ソフトウェアであればソースコード)を公開すること、そして、そのソースがなるべく使いやすいように整えられていることが大切です。
e.g.
OSHW Definitionでは、素材が一般に利用できる様式で公開されることが規定されています。
e.g.
映像作品などは、素材は公開しない、作品から取り出したものを素材として扱えば良い、と考えることもできます。一方で、編集前の素材を作品とは別に公開することで、新たな作品が生まれることもあります(e.g.Choreography filmed)。
成果がプラットフォーム的な性質を持つものならば、ユーザが作ったオリジナルの機能などをかんたんに追加できる仕組みがあれば良いでしょう。 (成果そのものの派生も望ましいですがそれに加え、)ユーザが自らの課題を解決する機能を追加し共有することで、プロジェクトにコミットできフィードバックを得やすくなります。同じ課題を持つ他のユーザにとってはより簡単に課題を解決できるようになり、また新たなクリエイションの着想の手助けにもなります。
e.g.
ArduinoのShield(Arduino Shields)やopenFrameworksのaddon(ofxAddons)は典型的な例といえるでしょう。
e.g. ofxAddons.comは、GitHubで公開されたaddonを自動的に収集し提示するウェブサイトです(主催はJames George氏とGreg Borenstein氏)。ユーザにとっては、多様な拡張機能を一覧できるもので、これらの拡張機能の利用や新たな派生の生成を助けていると考えられます。"make your own!"というaddon作成のイントロダクションのページも存在します。
当初より担保された拡張機能をもとに生み出された成果が、個人によって自発的に活用され、さらに多くのユーザを取り込み、プロジェクトの発展に寄与している事例といえそうです。成果のオープン化を伴うプロジェクトにおいて、オープンなライセンスだけでなく、ユーザが参加しやすい仕組み(拡張機能)も重要な役割を果たすことを示した事例とも考えられます。
e.g.
RAM DanceToolkitでは、ユーザがダンサーのための環境であるシーンを作成し、追加する事が出来ます(シーンの作り方)。
閉鎖系であることを否定しないことと同様に、ここでは推奨しませんが、明確に第三者を巻き込むことをプロジェクトのゴールに含まない場合、汎用性の充実や拡張機能の実装などは必須ではありません。("非開放系であることを否定しない"と関連があります。)
[Involve!]
つくるための知識を共有・交換しつつ市民自らクリエイションを行うムーヴメントがひろがり(FabLab)、消費者がデザインのコアプレイヤーになっていくという考え方(オープンデザイン)も現れています。これによって、新たな表現がうまれたり、様々な問題が解決されています。こういった状況を促進するため、人々が参加しやすい(初期導入が容易な)・参加し続けやすい環境、成果を育てやすい・進化させやすい環境を作ります。
"成果のユーザビリティ向上"に対して、「プロジェクトのユーザビリティ向上」と位置付けてもも良いかもしれません。
様々な種の移入を呼び込む、多様性を増していく、エネルギーを取り込み、循環を促進することにつながります。同種の派生が増え、個体群を生み出し、異なる種も含む群集をつくっていきます。
fyi
プロジェクトの周知のため、ウェブサイトの公開だけでなく、各種メディアを通じたコミュニケーション(宣伝)もわすれないようにします(e.g.SNSを経由した広報)。
いったいその成果が何であるのか、何ができるのか、誰に向けられているのか、どのような可能性があるのかを的確に示します。これによって、理解が深まり、訴求力が高まるでしょう。オープン化しているプロジェクトであることをわかりやすく示すことも重要です。
e.g.
YCAMでは、ウェブサイトにどのような要素を含むべきかを示した公開ウェブサイトの構成ガイドラインを準備しています。ここに示した要素が揃っていることを(トップページのメニューなどに)一目でわかるようにすることで、必要な要素を準備することに加え、そのプロジェクトがオープン化したプロジェクトであること(いわばオープンプロジェクト感)を示すことができます。("見栄えは大切"と関連があります。)
ここでいうドキュメントには、様々な種類があり(e.g.プロジェクトの概要、マニュアル、チュートリアル、サンプル、利用事例、ウェブページのコンテンツなど)、映像・文書などによるものが一般的です。ユーザが成果を利用し始めるのを助ける効果が大きく、非常に重要な要素です。ドキュメントの制作には一定の時間・労力といったコストが必要ですが、完成度の高いものを用意すべきでしょう。事前に十分に準備し、コンセンサスをとることが重要です("同意を得ること"と関連があります)。
fyi
プロジェクトの概要には、プロジェクト自体の概要、公開する成果のアウトライン、適用されるライセンスの概要(どの成果に何のライセンスが適用されているのか)を含みます。
fyi
公開当初に利用事例がみあたらない場合、後に利用事例の調査を行い、まとめてウェブサイトに掲載するのも一つの方法です。
利用事例は成果がどんなものであるのか、どのように利用できるかを伝えることができる重要な項目です。しかし、その追跡には一定の労力が必要です。対策としては、公開後に定期的に調査を行うこと、利用者からの通知を促すインセンティブを準備することなどが考えられます。
e.g.
ofxAddonsは、GitHubで公開されたopenFrameworkasの拡張機能であるaddonを自動的に収集し紹介するウェブサイトです。ここには800以上のaddonが掲載されています(2014年10月)。
fyi
想定ユーザのカテゴリを設定し(一般利用者/開発者)、それぞれのマニュアルを設けるのもよいでしょう。ドキュメント政策の為のリソースが不足する場合は、当初は一般利用者向けのドキュメントのみを準備するのも選択肢のひとつとなりえます。
ドキュメント作成ガイドラインや作成支援システムがあれば、制作の労力・時間を低減できると考えられます。
fyi
チュートリアルは、システムの導入方法や具体的な利用方法を示したマニュアルで、ユーザが実際に成果を利用するために役立つものです。サンプルは、成果を利用した簡単な実施例で、ユーザが実験したり派生物を制作するのに役立ちます。利用事例は、作品やビジネス、社会実験などで実際に用いられた事例の紹介で、実用性、成果の特徴、優秀さをアピールできます。
(成果自体がコンテンツである場合、データである場合は、一部のドキュメントのみ(たとえば、チュートリアルを省略する)で充分なこともあるでしょう。)
fyi
マニュアルはテキストが基本ですが、適宜映像を準備します。特に、導入方法や、多くの人が慣れているとは言えない作業(e.g.クリームはんだの使い方)などについて解説映像があれば効果的です(e.g.MOTIONERのマニュアル)。チュートリアルの形式について、わかりやすさ、制作のしやすさから、ステップバイステップ形式をまず検討するのが良いでしょう。一つ一つのステップのマニュアルを並列するのではなく、よほど長いものでない限り、Instructablesのように連続して表示する方がわかりやすいようです。(Instructablesを用いるのも良いでしょう。)
サンプルは、単純な実装のためのフルセット(ソフトウェアであるならそのままコンパイルできるセット)が良いでしょう。多くのユーザは、サンプルを変更しながら自身の派生物を作り出して行きます。
利用事例には、もし事例自体についてのウェブサイトがあるなら、そのリンクを張り、事例のサマリーを添えます。事例自体のウェブサイトがないなら、その紹介テキスト映像を制作します。
プロジェクトの概要には、成果の紹介映像があれば効果的です。
作品制作を行うプロジェクトにおいて、作品自体とオープン化する成果とに違いがある場合は(たとえば作品の一部をオープン化する場合は)、プロジェクト自体のアウトラインとオープン化する成果のアウトラインが異なることになります。このとき、もしプロジェクト自体のウェブサイトと、オープン化のためのウェブサイトの制作者が異なる場合は、各ウェブサイトに共通する情報について(たとえばプロジェクト自体のアウトライン)、齟齬が無いよう注意すべきです(e.g.ForestSymphony)。
e.g.
Motionerのマニュアルにはハードウェア製作の映像チュートリアルが含まれています。
利用される状況をイメージし、それを実現するよう、第3者(想定するユーザ)が利用できる範囲(利用許諾する範囲)をきめていきます。想定する利用範囲の中で、なるべく利用制限を少なくする、つまり、利用できる機会をより多くし、より自由に派生物を作成できるよう気をつけます。
この際、運営方針、プロジェクトの目的、成果の種類、スポンサーやコラボレータとの権利関係にも配慮します。
fyi
("ライセンス・利用規約をえらぶ・つくる"とも関連しますが、)クリエイティブ・コモンズ・ライセンスにはさまざまなバリエーションがあります。このうち、CC BY(表示)とCC BY-SA(表示-継承)のみがフリーカルチャー・ライセンスとされています。フリーカルチャー・ライセンスであるかどうかは、利用者に与える自由について、「作品を利用し、上演する自由」「作品を修作氏、その情報を応用する自由」「複製を頒布する自由」という観点から判断されています*。利用範囲やライセンスを選ぶひとつの基準としても良いかもしれません。
*"フリーカルチャーをつくるためのガイドブック" ドミニク・チェン, フィルムアート社, pp.126
fyi
想定しないユーザ、他の領域のユーザが利用することで、プロジェクトのより広範な進展が期待されます。ですので、想定するシチュエーションに限定した範囲を設定するよりも、なるべく、想定外のユーザが想定外の方法で利用できるよう範囲を設定します。(明らかに問題を引き起こすと想定される範囲以外を利用可能範囲とするよう調整してもよいでしょう。)
ライセンスはさまざまです。設定した利用許諾する範囲を実現できるよう、最も適したライセンスを選択します。
ライセンスのマニュアル(運営方針に基づいて、成果やプロジェクトの目的に応じて、どのようなライセンスを設定するのかを示したもの)を準備しておくと、効率的にライセンスを選択でき、また、ディスカッションのたたき台としても利用できます。
既存のライセンスでは、想定する利用範囲を実現することができない場合、ライセンスを制作したり、利用規約で対応することも検討します("リーガルデザイン"と関連があります)。
e.g.
YCAMでは、デフォルトのライセンスを示したリストライセンスのマニュアルを準備しています。同じ成果物をオープン化するにしても、オープン化を行う主体によって、適用するライセンスは変わりえます。自分たちに適したライセンスは何か、どのように使い分けるかについていちど議論し、まとめておくと、後のプロジェクト利用でき便利です。
fyi
ソフトウェアライセンスについて、GPLが適用されたコードは,二次利用しオブジェクトコードを配布した場合にソースコードの公開義務があります(GPL v3 第6条)。さらに,派生物についても同様のライセンスを適用しなければなりません(同5条)。これは、何世代にもわたって派生物が公開されつづけるというメリットがあります。“価値ある機能を付け加えられたバージョンが独占的に販売され、囲い込まれてしまうという状況を防ぐことができる”という効果もあります。
しかし、インタラクションデザインを応用するクライアントワークにおいては、強力な秘密保持を求められることがあり、GPLの公開義務は、こうしたケースでの利用にはかえって障害となり、利用を止まらせてしまう場合があります。こうした状況を回避するためには、公開義務のないライセンスを用いるべきでしょう。
openFrameworksもPureDataもこうした公開義務がないライセンスを用いているかかわらず、オープン化が保たれ、プロジェクトが継続しています。こうした状況を鑑みると、明確な意図がない場合は、公開義務のないより自由度の高いライセンス（MITライセンス、BSDライセンスや、特許関連条項を含むApacheLicense2.0など）を採用してもよいでしょう。
fyi
メディアアート/インタラクションデザインでは、成果はビジネスに直結し得ます。こうした性質から、両者を相互に往来しながら、産業・文化が発展することは自然で、望ましいことです。前述のように、クリエイタが企業から何らかの制作業務を受注した場合、既存のビジネス形態では、成果をオープン化することが難しい場合があります。
クライアントワークにおいて、その成果を公開できるようなクリエイター-クライアント間の契約、もし商用利用したコードそのものを公開できなくとも、これをもとに一般化したコードや、開発段階で生み出されたコードを、問題なくオープン化できるクリエイター-クライアント間の契約の普及が望まれます。(ウェブサイト構築における業務委託契約ではこのような例も現れています。)
fyi
ハードウェアに適したライセンスについては、まだ議論が熟していません。現状では、ハードウェア設計情報(図面など)を著作物として捉え、Creative Commons Licenseを用いるのが妥当と思われます。OSHW Definitionはハードウェアのオープン化に必要と思われる事柄を示しています。
ユーザや開発者たちがコミュニケーションを行うコミュニティは、プロジェクトの持続的発展の中心となり、また、様々なユーザーが参加することで多様性をもたらす苗床ともなる場所です。クリエイションのネットワークを形作りコラボレーションを促進する場所でもあります。
コミュニティを運用する代表的な場所はウェブサイト(Forum)です。ウェブサイトだけでなく、コミュニティのための実空間(パーマネント、テンポラリ問わず)を作ったり、ワークショップやユーザーギャザリングの機会を設けることもその一つとなるでしょう。
プロジェクトが成長するためのポジティブフィードバックの場でもあり、内容が入れ替わりながらも安定的に循環する場でもあります(動的平衡)。エネルギーのインプットを促し、多様性をうみだす、前述のビオトープの(中心的な)一部にあたるものです。
多様性は、成果の展開先を増やすことでクリエイティビティを向上させ、また、サイクルを構成する要素に危機的状況(e.g.パーツのディスコン)が起きた時に、代替となる要素や方法を供給することにもつながります。
fyi
成果の利用のハードルをさげるパッケージの提供も、たとえばハードウェアの完成品や半完成品を提供することも、成果とユーザをつなぐしくみを作ることにあたるでしょう(e.g.Linuxのディストリビューション、ForestSymphonyのアンプシールドの提供)。これは、オープンソース・ハードウェアのビジネスモデルにつながります(e.g.Arduino)。このために資金を集める方法としてクラウドファウンディング(e.g.KickStarter)は重要な役割を果たすでしょう。
fyi
コミュニティの維持は長期にわたる作業であるため、短期的なプロジェクトのタスクに含めることは難しいかもしれませんが、立ち上げの段階であきらめることは得策ではありません。何らかのユーザとのコミュニケーションの場(e.g.Forum)だけでも準備しておくべきでしょう。 共同研究開発においては、コラボレータにコミュニティのサポートを求めることがあります。プロジェクトの進展に応じてコミュニティ運営を行う、という対応もとりえます。
e.g.
YCAMでは、Reactor for Awareness in Motion (RAM)のオープン化された成果を用いて、エンジニアとダンサーが協働するワークショップを実施しました。
「Reactor for Awareness in Motion」ワークショップ
CBC-NET メディアテクノロジーを介した身体と知覚の新しい回路 YCAM InterLab＋安藤洋子 共同研究開発プロジェクト「Reactor for Awareness in Motion」レポート
e.g.
ofxTimelineのIssues(Forum)ではリリースから時間が経ってからもユーザ同士のコミュニケーションが行われています。
YCAMInterlab/ofxTimeline Issues
fyi
コミュニティを生み出し活性化していくことは、YCAMのオープン化に関する活動の中で最も難しいと思われることのひとつです。汎用性の高いソフトウェアにおいては、ある程度成功していると言っても良いでしょう。これは、汎用性の高さによる訴求力や、すでにユーザが参加するカルチャーができているソフトウェア分野によるところが大きいと考えられます。何かに特化したもの、またハードウェアに関するものは、利用事例が出てきてもコミュニティがうまれなかったり、サポートができないという理由から、そもそもコミュニティのプラットフォーム(Forumなど)を設置しないこともありました。いかにユーザのコミュニケーションを引き起こし、コミュニティを生み出し活性化していくかは今後の課題です。前述のようにKickStarterなどを利用した完成品の提供も一つの解決法となるかもしれません。
成果のアップデートやメンテナンスはそのプロジェクトが生きていることを示す重要な指針です。アップデートを続けていること、それを伝えることは、プロジェクトの魅力を高めます。新たなプランの告知や、利用事例の掲載・共有も同様です(ニュース)。利用者からの(利用の)通知を促すインセンティブを準備することも、コミュニティの活性化に重要な要素です。
e.g.
(前述の)ofxAddonsは自動的に利用事例を収集するシステムとして捉えることができます。
fyi
メンテナンスもコミュニティと同様難しいポイントです。YCAMで実施したプロジェクトに参加したメンバーから、メンテナンスについて以下のようなコメントがありました。
「メンテナンスがなければ、コードはコンパイルできなくなる、oF(注:openFrameworks)もハードも使えなくなる。」
と重要性が指摘される一方、
「現実にはメンテナンス作業が立て続けに発生すると、大変なことになる。」
「(メンテナンスについて)実務上はどのようにスケジュール管理するかが難しい。 (中略) 手放しでできるわけではないので。」
その労力の確保の難しさが指摘されました。
Linuxをはじめ、ofxTimelineなど、メンテナンスが行えているプロジェクトもあれば、そうでないものもあります。この違いの原因は、コミュニティのそれと同じようなものかもしれません。
メンテナンスへのモチベーションは、プロジェクトへのコミットの程度や、もしかすると一種のワークライフバランスに関する文化と関連があるのかもしれません。単なるマンパワーの確保だけでなく、モチベーション、クリエイションの系、背景にある文化と合わせ、今後、検討を進めるべき課題です。
e.g.
GRP Contract Formでは、メンテナンスに関する項目が設けられています。
[Open Finely!]
適切にオープン化を行うための幾つかの注意点を示します。これまでのガイドラインと重なる部分もありますが、特に重要と思われる点を挙げます。
オープン化は、既存の知的財産制度(著作権制度など)をそのまま利用するのではなく、制度で認められた権利にもとづいて、成果を自らが望む形態で運用できるよう、民間のひとびとが設計したしくみ(ライセンスや利用規約など)にもとづいて実現しています。
個々のプロジェクトでオープン化の目標や方法を考え、それを実現するため、ライセンスの選定や契約・利用規約といった法的な設計を運用していくこと、これらはリーガルデザイン*の実践のひとつと捉えられます。クリエイションを行う人々自らが(場合によっては専門家の助けをえながら)、こうしたリーガルデザインを行えることを認識し、実践していくことが大切です。("ライセンス・利用規約をえらぶ・つくる"と関連があります。)
fyi
既存のライセンスを適用して公開するだけでは目標を達成できない場合、新たなライセンスや利用規約を作ることで対応できることもあります。コラボレータや参加者、ユーザ、その他のステークホルダと用いる契約書や同意書についても、単に既存の内容になぞらえるだけではなく、より良いクリエイションのためにその内容を設計し、契約書や同意書を制作し利用することもあるでしょう。こうしたリーガルデザインの成果をオープン化することで、他者のクリエイションを助けることにつながり得ます。いずれ制度の変更や律法につながることになるかもしれません。リーガルデザイン・メタデザイン(デザイン環境のデザイン)のオープンデザインも、これからのクリエイションにより重要な役割を果たすのではないでしょうか。
*リーガルデザイン = 法や契約,権利を,社会をドライブさせる潤滑油として積極的に市民の側が設計すること
オープンデザイン, Bas Van Abelら, オライリージャパン, pp.230(水野祐:ライセンスデザインの思考).
e.g.
Creative Commons Licenseは標準化したリーガルデザインの成果のひとつといえるでしょう。
e.g.
YCAMでは、いくつかのリーガルデザインの成果をオープン化しています。
GRP Contract Form
YCAMサマースクールでの成果公開の同意書
e.g.
Perfume GLOBAL SITE のMOTION CAPATURE DATA Terms of Useは、既存のライセンスを用いずに、Music Data、Motion Dataの利用許諾、利用できる範囲について規定しています。
ライセンスを有効に機能させるには、一定の手続き(e.g.ライセンスの表記、その適切な場所)、クレジット表記などが必要です。また、既存のオープン化された成果を利用する時はそのライセンスを守る必要が有ります。
オープン化された成果(素材)を用いてクリエイションを行う場合、そのライセンスに定められた利用範囲が、新たな成果の利用やライセンシングをどのように制限するかを検討します。つまり、素材を選ぶときは、その内容や機能だけでなく、適用されたライセンスによって許諾された利用範囲も考慮します。その他、利用規約や参加同意書などを含むリーガルデザインが法的に適切であるよう注意します。(ある種のコンプライアンスといっても良いかもしれません。)
fyi
スタンダードなオープン化の設計・実践においても、法務的なプロセスがいくらか発生します(ライセンス適用など)。新たな運用方法を模索する場合は、法的な合理性について検討する場面が多く出てきます。よって、プロジェクトの性質を理解し、権利関係の設定やライセンスの判断、利用規約の設計を含めたリーガルデザインに対応できる、オープン化についての法律知識、運用事例についての知識を有する法務アドバイザへのアクセスを確保します。(例えば、企業・研究機関の知的財産担当部署、顧問弁護士は、オープン化についてのノウハウを有することが望ましいです。)
e.g.
YCAMの研究開発で、GPLが適用されたコードを利用したため、成果に適用するライセンスにGPLを選ばざるを得なかったというケースがありました(MOTIONER)。コードを書き直せば他のライセンスを自由に選択できましたが、その労力を鑑み、書き直しを行わないことにしました。
その他、Apple社AppStoreのライセンスとの関係で、AppsにはGPLのコードを使えず、BSDのコードは用いることができたという事例もあります。
公開ウェブサイトに、オープン化された成果のユーザにとって必要な項目を設けます。制作したクレジット表記、ライセンス表記を用います。構築方法については、(前述したように)バジェットや用途に応じて、既存のウェブサービスを使っても良いですし、サーバを立てても良いでしょう。ユーザビリティの向上に配慮します("参加しやすくする""それが何であるかを明確にすること"と強い関連があります)。
公開時期も重要です。多くの人にとっては、ウェブサイトの公開・周知が、プロジェクトのスタートを意味します。遅すぎるとプロジェクトメンバーのモチベーションを保つのが難しくなり、また、"旬"を逃してしまうことになってしまいます。
fyi
YCAMでは、ウェブサイトにどのような要素を含むべきかを示した公開ウェブサイトの構成ガイドラインを準備しています(前述)。
fyi
ウェブデザインのガイドラインとして、イギリス政府のGovernment Digital Service Design Principlesなどがあります。
fyi
ウェブサイトを利用することが多いですが、展示会場で配布する紙媒体を用いることもあります(ThinkThingsのあそログ)。
[Improve Appearance!]
プロジェクトの見栄えはとても大切な要素です。さまざまな構成要素(成果そのもの、公開ウェブサイト、ドキュメント、広報物、利用規約やライセンス表記も!)を通じてプロジェクトの魅力や伝えたい情報を適切に伝えます。
Fogel Karl氏は、“あるプロジェクトの存在を知った人が最初に目にするのは、そのプロジェクトのウェブサイトの見た目”であり,“見栄えは重要である”とし、具体的には“リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておく”べきとしています。("ウェブサイト"と関連があります。)
どのようなテイストにするかはプロジェクト次第ですが(ポップ、ギーキー、スマートetc)、なんらかの方針を立て、デザインしていくことが大切です。特に、情報デザイン、グラフィックデザインは大きな役割を果たします(Octocatとか!!)。Zachary Liebermanは、Hiphopのテイストを取り入れることが大切だと言及しています。
e.g.
OctocatがGitHubの普及に少なからず貢献していると思いませんか?
fyi
YCAMの活動のうち、このガイドラインやその他のリーガルデザインの成果のオープン化では、情報デザインやグラフィックデザインを今後改善していきたいところです。