WordCamp Kansai 2015。貢献というテーマ、セッションvsハンズオン、スポンサーとGPL、Campの目的について

WordCamp Kansai 2015 へ行ってまいりました。また、スタッフとしても関わらせていただきました。

以下の小見出しで、感想を書いてみたいと思います。

  1. 貢献というテーマ
  2. 西川の担当
  3. セッション vs. ハンズオン
  4. スポンサーとGPLについて
  5. なんのためのWordCampなのか

貢献というテーマ

今回のテーマは “Get Involved 進化を続ける未来に出会おう” でした。

巻き込まれよう、参加しよう、その先に今までと違う何かがあると思うよ!という運営側からのラブコールですね。使う側から、作る側へ回ってみる楽しさ、そのことから得られる学びと信頼、そんなようなことを伝えたいという考えから決まったテーマなのだと思います。

WordPress › 日本語 « WordPress への参加・貢献

上記のリンクは、WordPress日本語のサイトに新しく追加された、スラッグも /get-involved となっているページで、日本語での参加方法のリストです。WordPressの本体の開発に参加することのみならず、参加の方法には、翻訳、ドキュメント、サポート、イベント開催、テーマやプラグインの共有という方法もあり、開発者からデザイナー、一般のユーザーであってもいろいろな選択肢があります。

私は、WordPress というソフトウェアにもそれを取り巻く人々にもたくさん助けられて私の今があると思っていますので、少しずつでも何かお返しをしつつ次に繋がる何かが得られたらということで、現在暮らしているバンコクでのMeetupの開催や、テーマをレビューするチームへの所属などをしています。

今回のキャンプで、このテーマを反映しているコンテンツには以下のものがありました。

貢献、というと堅苦しく感じられて無料で人のために善意のみを動機として行なうものというニュアンスを感じられる方もいるかも。でも、実際にはそうではなく、こうした活動を通して、

  • 翻訳やコードを書いたりテーマをレビューしている間に知識が深まる
  • WordPress の開発に近い立場にいることから最新の状況がつかめるようになる
  • 協働する人たちとのコミュニケーションによって仲間が増えたりその会話から深い場所にたどり着ける
  • 貢献者としての実績から、信頼を得ることができる
  • そもそも自分のコードをオープンソースにすると得るものがある

といったメリットを享受していることが浮き彫りになる話が多かったです。

今回のWordCamp関西2015は、そういう考えが自然に共有されたメンバーたちによるWordCampだったんじゃないかな、と思いました。最高です。

次の引用は、参加者の方が受け取った印象なのですが、これはとても嬉しいです。

(引用者註: 2014のWordCamp Kansaiでは、)WordPressの技術やデザイン以前に,その「理念」が高らかに宣言され,イベント全体に一つの芯が通ったものとなったと思います。
そして,今回のWordCamp Kansai 2015も,昨年の流れを受けて,セッション企画はWordPressの理念をより深く考えるものが多く配置されたのかなと勝手に考えています。

WordCamp Kansai 2015から何をつかむべきか | 司法書士松宮法務事務所

余談ですが、いろいろな人から影響を受けた私の今の考え方としては、WordPressに貢献すること・参加することは、「WordPress 全体と、自分自身の成長を望む人たちが、その目的のために、ともにコミットする共犯関係」というものです。

慈善活動だけではないし、差し出すだけでもない。WordPressも流行ってもらって育ってもらわないと困る。自分のスキルもあげたい。自分の利益と合致した部分について行動すればいい。利益に受け取って構わない。というかどんどん利益を生むといい。そして、その活動に加わる人が増えたほうが自分のコミットメントの寿命も伸びる。それがコミュニティのリアルな強さになっているのではないかなぁ、と思います。

西川の担当

私が担当したのは、主に以下の3つでした。

  1. セッションのタイムテーブルの土台作りを手伝った
  2. セッションをひとつ担当した
  3. 海外ゲストのセッションの翻訳と送迎や観光案内をした

1. セッションチームとタイムテーブルのこと

まず、一時瞬発力を出すことを頑張った自負はあるものの、その後の丁寧な連絡調整などについては粘り強さを発揮しない私の弱点が露呈してしまいまして、チームというのはいいものだと思うと同時に感謝の気持ちでございます。

今回のコンセプトを体現するために、以下のことが念頭に置かれていました。

  • 委員会側発案のセッションと公募のセッションを組み合わせる
  • 貢献者に登壇してもらう
  • ハンズオンをたくさん入れて、初心者や貢献者の今後に繋げる
  • 海外からのゲストに来てもらい、刺激を入れる
  • コントリビューターのための部屋を作り、なにか面白いことが起こる場を作る

タイムテーブル | WordCamp Kansai 2015

2. セッションを担当!

私は、WordCampでひとりで話すのは初めてで、機会をいただいてありがたかったです。緊張しましたw

内容は、

再利用可能性とメンテナンス性が高い WordPress サイトを、安全に、短時間で、チームで作るためのベスト・プラクティスを学び、日々のテーマ制作の方法を改善すること。

というゴールを設定し、そのゴールに至るためのベスト・プラクティスを、WordPress の公式テーマレポジトリの要件から学び取るというものでした。

そのベスト・プラクティスとは、

  1. 見た目に徹する
  2. どんなプラグインとも機能するための作法を知る
  3. WordPress の機能をフル活用
  4. コンテンツに触らない

というものでした。かなり抽象的なので詳細はスライドと後日公開されるビデオを見てもらいたいですが、これはなかなか正しく、深い話だと自負しています。

もうひとつ、セッションのスライドを作っていた中で気がついたのは、以下のことです。セッション用のメモから引用します。

WordPress の理念は、「パブリッシングの民主化」です。誰もが自分の思ったことを発信でき、誰にも制限されない、そのためのプラットフォームになることです。

ユーザーは、自分の好きなデザインを自由に選ぶことができます。必要な機能は、どのようなデザインを選んでいたとしても、できるだけ自由に取り入れられる工夫があります。ユーザーはコンテンツをデザインにとらわれずに持ち運ぶことができます。WordPress の理念であるパブリッシングの民主化を実現しようとすると、テーマからも機能からもWordPress からも、ユーザーとユーザーのコンテンツは自由でなくてはいけないのです。

公式レポジトリの掲載要件も、パブリッシングの民主化をテーマで表現するとこうなるよ、ということになっていることが分かります。自然、この要件に従うことが、WordPress の力を最も発揮できる形に近づくことになっているのです。

なるほどですね。

3. 海外ゲスト

日本のWordCamp、海外からのゲストを迎えるのが恒例になってきており、実行委員会の仕事にも、もうひとつの分野が生まれています。

  • 誰に来てもらうのがよいのかを考えること
  • ホテルや移動手段について事前に調べて伝えること
  • 翻訳するため、セッションの内容をできるだけ詳しく送ってもらうこと
  • 来日時、帰国時の送迎(必要な範囲で)をすること
  • 事前・事後で観光案内や懇親を深めるために動くこと
  • セッションを翻訳し、参加者にできるだけ伝わるように頑張ること

などがその内容です。

担当するのは大変な一方、ものすごく仲良くなれて、期間中に深い話もたくさん生まれ、だんだんと信頼関係が強くなっていくのを感じ、別れるときには「また会いましょう、世界のどこかで!」と言えるのはとても幸せなことだと思います。

ありがとうございました。

セッションとハンズオン

今回、ハンズオンがすごく充実していました。ハンズオンとは、体験学習のことです。

なぜ、体験学習を充実させたのか。それは、セッションへの限界を超えたいと思ったからです。丁寧に伝えたい、本当に持って帰ってもらいたい、仲間を増やしたいという気もちからするとハンズオンが増えます。

スライドがあって生身の人間が喋るセッションを聞くというのも、本当に素晴らしいことですし、僕も影響を受けたセッションが今までにたくさんあります。でも、セッションという形態には、向いているコンテンツと、向かないコンテンツが有るのではないでしょうか。

セッションでは、聞いただけじゃ動けない、動きたくても動けない、ということがあります。それは「○○のやり方」系のコンテンツの場合に顕著です。何ページものスライドを見て帰っても、本当にそれを真似して、自分のものにできる人は少ない。

WordCamp の運営をやると、そのコンテンツがどのくらいの影響を与えることができたのかを感じ取ることができます。その感覚が実際と合っているかどうかは、本当には分からないのですが、やっぱり感じます。数年にわたって何度もやっていると毎回同じようなことを感じます。

じゃあ逆に、セッションに向いているコンテンツってどんなものなんでしょうか。それは、経験をシェアするものだったり、考えを伝えるようなもの、概念・思想などに迫っていくものです。

この登壇者がこんなことを考えながらやってるんだったら自分もできるかもしれない。CMSのそんな捉え方があったのか。世の中にはこんなに貢献活動をしていてそれをビジネスにも結び付けてる会社があるなんて目からうろこ。問題の発見からその解決までそういう風に考えてWordPressのこともそんなに信じて作りきって利益を出せるとは。

というようなことですね。何かのやり方を示すことではなく、誰かの経験や実績や考え方を登壇者がババーンと発することで、誰かの行動に影響がある形。

ハウツー、ノウハウ系はセッションだと伝えるのが難しい

そう考えると、

  • 「デザイナーのみなさん、_sや子テーマをやってみよう」
  • 「英語が読めるなら、翻訳を実践してみよう」
  • 「Codexを整備すると勉強になるんだよ」
  • 「ユニットテストを導入しましょう、継続的インテグレーションを取り入れよう」
  • 「WordPress.com っていいんですよ」
  • 「WordPressとテーマとプラグインだけで、ここまでできますよ」

と、壇上から伝えたとして、人の行動に本当に影響をあたえることって、実は難しいんですよね。

さて、受け取る方だって、やる気があるから会場に来てくれています。

伝える側は本当に伝えたくてやってみてほしくて仲間になってほしくて、一方の受け取る側もやる気があって上達したくて何かを持ち帰りたくて会場に来ていて、それでもセッションでやり方を伝えても、持って帰ってもらうというのは難しいんですね。

セッションの会場で300人の人が聞いて、そのうち本当に行動が変わる人数と、ハンズオンの会場に30人しか入れなくて、でもその全員が始められて、その中から続けられる人が出てくるという数、後者のほうが多いんじゃないでしょうか。

ハンズオンの準備って、実際に手を動かすというすごくリアルなことなので、準備にすごく時間がかかります。当日も、セッションなら一人が数十分話すと終わるのに比べて、ハンズオンだと複数人が2時間位。

そうであったとしても、伝わる質と量のことを考えると、ハンズオンを選択をすることは頑張れるなら頑張りたい。今回のCamp関西チームは人数が少なくても、それを可能にするチームでした。

上記で挙げた、_s, 子テーマ、翻訳、Codex、ユニットテスト、.com実践、テーマとプラグインでサイト構築というコンテンツは全部ハンズオンで実現されました。
詳しい人が、まだそれをやったことのない人と一緒に、パソコンを目の前にして伝えた、というのはすごい事実でした。

次回は、実行委員じゃない人たちにも、もっとハンズオンの担当になってもらうといいかもしれません(スタッフ的熱量がないと準備へのコミットメントが発生しない問題を解決しないとですね)。

スポンサーとGPLについて

今回、印象的だったのは、スポンサーさんたちがとても良い形でWordPressのコミュニティと関わってくれているということでした。1日中バタバタしており、すべてのスポンサーさんたちのブースを回ることができず、また、スポンサーブースが設置されている場所で行われていたトークもすべてを聞くことができなかったのですが、ユーザー側・主催側・貢献者側からのフィードバックをすることも、健全さに寄与すると思い、感想を書きたいと思います。

さくらインターネットのスライドの中で、WordPressコミュニティに関わる方法・可能性の模索ということが書かれていました。これまでのスポンサーシップを含めてどのような関わりを持って来られたのかということが語られ、他の関わり方も模索されていると。私からは海外の事例として、貢献者を採用して、その社員の時間の半分(あるいは100%)をコアへの貢献やサポートフォーラムでの活動、REST APIの開発、イベントの開催に使わせるという超ダイレクトなやり方があることを伝えてみました。ホスティング会社の存在は超重要なので、採用とかじゃなくても、もっといろいろな関わり方ができるようになるといいなと思いました。

もうひとつ、ファーストサーバの社長さんのセッションでビックリしたのは、テンプレートキングというウェブサイトのデザイン・テンプレートの無料配布サイトがあるのですが、ここで配布されているテーマが100% GPLだそうです。俄然応援モードになりました。もっと言っていけばいいのに、とも思いましたし、コミュニティはそれをもっと宣伝したりできればいいなと思います。WordPressの公式テーマレポジトリへの登録もお待ちしています!有料のテーマ販売もご検討いただいて、儲けてください!ホスティングしている人はダウンロードし放題とかどうでしょうかw!

さて、 GPL でないライセンスを選択している企業は WordCamp、WordBench、WordBenchを母体にするイベントに参加できないというルールがあります。

前回の記事(有料で販売されているテーマとプラグインの「1サイトでのみ使えます」表記の話から、開発者&ユーザコミュニティがあるWordPressでビジネスするってどうすればいいのかな、ということを考えた話のメモ)でも書いたのをもう一度ここにコピペしたいと思います。

100% GPL というのは、

  • まずはユーザーが使いやすいというのを追求するとそうなる

というところから始まっていて、本来はphp部分のみGPLにすればライセンスに違反しないところを、ユーザーの利便性を考えて、また、WordPress.org の考え方に賛同しているところじゃないと採用しないものだと思います。利用規約を定めるときに、社内のリソースで作ったものを無料で配布しつつ再配布・再販を許容するというのは、企業の中で理解を得るのはすごく難しいんじゃないかなと思うわけです。それを押し進めるということが、あの時にブースにいたメンバーや社長さんによって行われたというのは大きなことだと思います。

なので、コミュニティ側としてはそういう文化を持ち込んでくれた人たちのことは大事にして応援して、たとえば他のホスティング会社よりも目立ったり儲かったりするようにしていくという共犯関係が築ければいいと個人的に主張したいです。

GPLじゃない人たちを排除するのではなくて、GPLな人たちがGPLにするといいことがあるなぁ、お得だなぁ、損がないなぁと思うような、強いコミュニティになれるといいですね。

100% GPL で配布・販売されているテーマが見つかる日本のウェブサイト

なんのためのWordCampなのか

WordPress を使う人を増やす、WordPress 周辺のビジネスが潤うように頑張る、WordPress のノウハウをシェアする、WordPress の理念を伝える、WordPressの貢献者を増やす。

いろいろな目的があって、ひとつのCampの中で複数の目標があります。主催者としては何を選ぶのか。たとえば僕が、バンコクでWordCampを開催するとしたら、ユーザーを増やす、知識をシェアすることの楽しさを共有する、同じソフトウェアを使っている人たちが繋がる機会を作る、地域コミュニティとしての強さに繋がる運営を目指す、というのがゴールになりそうです。

https://japan.wordcamp.org によれば、今回のWordCamp Kansai 2015は日本国内で通算17回目の WordCamp のようです。国内での初めてのWordCampが開催されてから8年が経過しています。その間に、ユーザーの意識も情報量も層の厚さも変わってきました。

本屋さんに行くと本当にたくさんの WordPress 関連書籍が並んでいて、ブログの記事も充実しており、オンラインで受講できる講座もたくさんあります。学ぼうとする人にとって十分といえる量の情報と機会があります。

そうした環境にある現在の日本で、WordCamp が果たす一番の役割はどんなものなのか。難しい問いだと思うのですが、今回の運営チームの答えは、 “Get Involved 進化を続ける未来に出会おう” で、僕の感想は、デザインもコンテンツもチームの意識も、スポンサーの様子も、そして来場者に伝わったものの中心にあったものも、今回のテーマ・コンセプトを実現しており、素晴らしかったなと思います。

楽しい WordCamp で、はるばるやって来てよかったな、と思いました。スタッフの皆さん、スポンサーのみなさん、来場者のみなさん、ありがとうございました。

↓ プラグインを作る方々への本、書きました。 ↓

有料で販売されているテーマとプラグインの「1サイトでのみ使えます」表記の話から、開発者&ユーザコミュニティがあるWordPressでビジネスするってどうすればいいのかな、ということを考えた話のメモ

全然未完成でもっといろいろあるんだけど、取り急ぎのメモです。

(保険:間違ってたらごめんなさい。あと、GPLそのものの話よりも、それがWordPressでどのように運用(?)されて生かされてどういうビジネスがあって、みたいな話がこのポストの趣旨なのでいじめないでください。間違っているところはツイッターでもこのブログのコメントでも、ご指摘大歓迎です。)

きっかけは以下のものでした。

WordPress の管理画面にログインすると、左上にWordPress のロゴがあります。「 WordPress について」というところへ進み、「自由について」というタブをクリックすると、この件に関する基本的な WordPress のライセンスとスタンスを読むことができます。

「WordPress の自由について」はすべてのWordPressサイトの管理画面に入っている。
「WordPress の自由について」はすべてのWordPressサイトの管理画面に入っている。

そのまま引用しますと以下のことが書かれています。

WordPress はフリーかつオープンソースのソフトウェアで、世界中のボランティアの開発者たちの分散型コミュニティによってつくられています。WordPress はそのライセンス、つまり GPL のおかげですばらしい、世界観が変わるような権利を備えています。

  1. ユーザーは、目的を問わず、プログラムを実行する自由を有します。
  2. ユーザーは、ソースコードを入手可能であり、プログラムがどのように動作しているか研究し、そのプログラムに必要に応じて修正を加え、採り入れる自由を有します。
  3. ユーザーは、身近な人を助けられるよう、コピーを再頒布する自由を有します。
  4. ユーザーは、プログラムを改良し、コミュニティ全体がその恩恵を受けられるよう改良点を公衆に発表する自由を有します。

WordPress はあなたのような人たちが友人に WordPress のことを語るにつれて成長します 。WordPress 上やその周りで構築されている何千という事業やサービスがそのユーザとともにその事実を共有します。誰かが WordPress という言葉を広げるたびに私たちはうれしく思います。まずはじめに必ず商標のガイドラインをよく確認してください。

WordPress.org のディレクトリで提供されるすべてのプラグインとテーマは 100% GPL ライセンスであるか、あるいは同様のフリーで互換性のあるライセンスとなっているので、そこで安心してプラグインとテーマを探すことができます。別のところからプラグインやテーマを手に入れるなら、まず GPL であるかどうかを確認してください。もしそうしたプラグインやテーマが WordPress のライセンスを尊重していないものであるなら、お勧めしません。

とあります。

@kurudrive さんがツイートしているのは、一度配布を受けたら、何に使っても、何回使っても、それを誰にあげてもいいはずなのに、「1ドメインだけ」とか「1サイトだけ」とかって書かれているのは、GPL に違反するという趣旨だと思います。

GPL とは、フリーソフトウェア財団というところが作ったもので、GNU General Public License の頭文字をとったものです。くわしくは、WordPress を使うなら知っておきたい GPL ライセンスの知識【基本編】 | WP-Dを読んでもらうとよいです。

WordPress に関わるところ、今回の趣旨に関わるところをおさえるには、以下が大事だと思います。

  • GPL で受け取ったプログラムを使って、なんのために、何をしてもよいし、ソースを研究したり改変して使用してもよいし、人にあげたり、広く一般に向けて配布してもよい。

という自由の部分と、

  • ただし、人に渡す時(再配布する時)、自分が受け取った自由を、次の人にも必ず渡してあげないとダメ

という「コピーレフト」という大発明部分です。この2個めの他の人にも自分と同じ自由を保証するというところが肝で、これがあるからずっと自由が保証され続けるという素晴らしい仕組みだと思います。

次は、よくある誤解についてです。GPLでは、以下のようになっています。

  • GPL 下で受け取ったものをベースに開発したとしても、配布しない限り、ソースを公開しなくたっていい(公開しなきゃいけないという誤解がある)
  • GPL で配布する場合、お金を受け取ってもいい(無料じゃなきゃいけないという誤解がある)

ポイントとして、「GPL の効力が発動するのは配布する時」である、というのが大事です。受け取った人はひたすら自由なだけなんです。何してもいい。ただし、次の人に渡す時にはGPL(かその互換ライセンス)で配布していこうということです。配布しないなら何も考えなくてもOKです。エンジニアじゃないならGPL知らなくても問題起きません。なので、ライセンス怖いとかそういう声が時々聞かれるのですが、ライセンスはユーザーを守ってくれているものなので、本当は怖がる必要なんて全然ないはずなんですよね。

次のお金周りのところ。配布には販売も含まれます。これ、ソースコードをzipで固めてemailで送信する手数料とか、販売用のウェブサイトを設置した手数料とか、そういう理解でいいんじゃないかと思っております。

GPLで配布(販売して渡す)するわけなので、購入した人はそれを無料で配ってもいいし、1万円で買ったものを3万円で売りさばいてもいいわけですね。ここが、販売する人たちが「1サイトだけ」とか「1ドメインだけ」とかの制限をかけることになる理由です(そして、それはGPLに違反しています)。

さて、ちょっとややこしいのですが、以下のツイート。ここからは、GPL 一般を離れて、WordPressとそのコミュニティ内のルールの話になります。つまり、WordPress じゃないソフトウェアでは関係がない話になります。分けて理解しておくのは大事です。

100% GPL というのはなんのことかと言いますと、JavascriptやCSSや画像やフォントなどの、PHPではないものに対してもGPLで配布することです。

WordPress のテーマは大抵の場合、

  • PHP
  • Javascript
  • CSS
  • 画像
  • フォント
  • その他のドキュメント

などなどでできています。本来、これらのファイルをすべて自分で書いた(写真なら撮影した/フォントなら描いた)として、この内、GPLが自動的に適用されるのはPHPだけです。

これはなぜなのかといいますと、テーマは WordPress がないと動かないから、テーマはWordPressの派生物であり、従ってGPLの特徴を全部継承(?)するという説明がされています。アメリカでも日本でも実際には裁判になったことはなく、判例などはありませんし、すごくざっくりした言い方なので、ちょっと怖いですが、基本的にはこういう説明でWordPressのコミュニティの大部分が理解しています。

具体的に言いますと、テンプレートタグやその他のWordPress内のAPIを利用しているから、テーマは(プラグインも)WordPressとリンクしていて別のソフトウェアとは言えないのですよ、ということです。

その上で、Javascript他のリソースについてもまとめてGPLにして配布しようというのが100%GPLという概念で、多分、WordPressのコミュニティでしか使われていないと思います。

ソースコードを離れて人間っぽくなってくるのですが、100%GPL であることで配布する人は以下のメリットを享受することができます。

  • WordPress.org の公式のテーマレポジトリやプラグインレポジトリに登録できる
  • WordCamp などのイベントに登壇できる
    • 登壇だけでなく、スタッフとして参加したりスポンサーになったりといったことが全部できるようになる
  • その流れの中で、自分のテーマやプラグインがコミュニティ全体に指示・応援されてマーケティングに役に立つ

GPLであるだけでも、ソースが公開されていることでオープンソースのメリットを受けられるわけですが、100%GPLにすると、それに加えて上記の人間側のメリットも得られるようにしようじゃないか、ということですね。

自分のサイトや WordPress.org 以外のマーケットプレイスなどでテーマやプラグインを販売する場合、GPLにしないと違反になりますが、別に100%GPLにする必要はありません。再配布や販売をする人たちに対して「100%じゃないなんて違反だ!」という権利は誰にもありませんし、WordPressも言ってません。

さて、以下は英語圏のWordPress商売の様子を見ていて考えたことになります。

GPL であること、ソースが公開されていることでプロプライエタリなソフトウェアを販売するのとは違うメリットや商売の方法があるということですね。

ソフトウェアを売るというよりも、

  • サポートを売る(英語圏の商売でサポートが重視されているっぷりは驚くほどです)
  • フォーラムなどのクローズドなコンテンツへのアクセス権を売る
  • アップデートへのアクセス権を売る

といった形です。

APIキーによるサービス側のサーバに寄る認証がないと動かないパターンは、GPLに違反してないけど趣旨からするとちょっと「微妙」かもしれません。が、やれないことはないですね。

プラグインがインストールされているWordPressが、プラグイン販売者が提供するサービスの利用クライアントになるという形はスマートですね。

WP Booster、Akismet、VaultPressなどなど。

コアの部分は無料だけど、アドオンやエクステンションと呼ばれるプラグインの拡張プラグインは有料というのもあります。フリーミアム。

WooCommerceなどは、これでたくさんのお金を稼いでいます。この例はいっぱいあります。

また、コアの部分は無料でその拡張は有料という形の場合、コアの部分は、100%GPLであれば、WordPress.orgのテーマ/プラグインレポジトリに置いておいて、無料ユーザをたくさん集めるということも可能です。

シンプルだけど、今からやっても全然遅くないオーソドックスなスタイルだと思います。

次の例は、有料のプラグイン自体が実はGithubにおいてあって誰でもダウンロード・インストールして使える例です。

AffiliateWPのGithubレポジトリのreadmeには以下のことが書かれています。

AffiliateWP is a commercial plugin available from http://affiliatewp.com. The plugin is hosted here on a public Github repository in order to better faciliate community contributions from developers and users alike. If you have a suggestion, a bug report, or a patch for an issue, feel free to submit it here. We do ask, however, that if you are using the plugin on a live site that you please purchase a valid license from the website. We cannot provide support to anyone that does not hold a valid license key.

AffiliateWP は http://affiliatewp.com で入手可能な商用プラグインです。このプラグインはこのGithubの公開レポジトリにホストされており、その目的は、コミュニティからの貢献を、開発者やユーザーから受け取りやすくすることです。もし、提案やバグレポート、イシューにたいするパッチがあるのであれば、どうぞここに提供してください。ただし、もし公開サイトでこのプラグインを使うのであれば、ウェブサイトでライセンスを購入してください。有効なライセンスキーを持たない方には、なんのサポートも提供されません。

というわけで、オープンソースのメリットである、

  • みんなが試せる
  • 提案やバグレポートが集まる
  • パッチやプルリクが受け取れる

というメリットのほうが、彼らにとっては購入されないまま使われるというデメリットよりも大きいということですね。

また、AffiliateWPには数多くのアドオンがあり、その開発者はコア部分の開発者だけに限らず、他の人たちも参加しています。参加している人たちはAffiliateWPのウェブサイト上でそれらのアドオンを販売し、コア開発者と利益を分けあっています。

2014年の売上は1億円!

この1億円なんですけど、これがもし閉じられた場所で作られたソースが公開されていないプラグインだったら実現しなかったんじゃないだろうかと思うのですよね。

上記が、僕が日本もこうなったら素敵だけどまだ難しいのかなぁ、とこういう話になるといつも思っている結論的なところです。

GPL、100%GPL について、イベントへの出入りを禁止する排除のためのものだ、みたいな雰囲気になっているのを見ると、いや、そういうネガティブな感じではなく、ポジティブな流れを作るためのうまいこといきそうな仕組みなんだから、みんなでそういうプラスの共犯関係を作っていければいいのにな、と思っております。

その他

ThemeForestのライセンスの表記がおかしい話がWordPressのSlackチャンネルで上がってました。

最近のニュースで、Thesisというテーマがあるんですが、この作者が「いや、Thesisはテーマなくたって動くし!独立なのでプロプライエタリでいきます。それにThesis目当てでWordPressに入ってくる人たちがめっちゃいっぱいいるんだから、関係ないし。」というようなことを言っており、最近、Thesis.com というドメインをAutomattic が入札で落としてしまっていや、Thesisという商標を持ってるのはうちなんだから Automattic だめじゃんという訴えをThesis側が起こしたけれども負ける、という流れがありました。

Mullenweg and Pearson Square Off on Patents, GPL, and Trademarks

このニュース、なんでFoundationじゃなくてAutomatticがすごいやり方で戦いの全面に出てきちゃうの?とか、以下の動画ではマットとThesisオーナーが喧嘩別れしてたりとか、いろいろと難しいです。

では最後に、GPL、あるいはFLOSSについて、『WP で作るえっちサイト』という非常に分かりやすくその理念を表現しているゆりこさんのスライドを紹介して終わりたいと思います。

ありがとうございました。

↓ プラグインを作る方々への本、書きました。 ↓

WordPress の多言語化で考えることとプラグインの比較

WordPressで多言語サイトを制作する場合、いろいろな選択肢があります。

  • プラグインを使う
  • マルチサイトを有効化してプラグインを使う
  • 別々のWordPressを使う

また、プラグインにもたくさんの種類があり、それぞれに一長一短がありますので、以下の6つのタイプごとにまとめてみました。

  1. 1投稿に複数言語型
  2. 1言語1ポスト -> ポストメタ紐付け型
  3. 1言語1ポスト -> テーブル紐付け型
  4. 1言語1ポスト -> タクソノミ紐付け型
  5. マルチサイト型
  6. 別々のサイト型

本題に入る前に、ちょっと整理してから。

多言語サイトの条件とは?

続きを読む WordPress の多言語化で考えることとプラグインの比較

↓ プラグインを作る方々への本、書きました。 ↓

WordPressの多言語化をコアがどうサポートするのかしないのか、プラグインで複数言語をどう持つのかについての議論がWordCamp Europe 2015で行われたらしい

Photo CC BY-SA 2.0 Andrey Savchenko

WordCamp Europe 2015 で Drupal のコントリビューターを招いて、WordPressの多言語機能について話し合ったということで、Make.にレポートが上がってました。ヨーロッパはいろんな言語が混ざり合っていて、複数言語を話す人(Polyglots)もたくさんいる土地柄なので、この話が欧州で行われるのはなるほど感があります。

WordPress › WordCamp Europe 2015 – Multilingual Discussion « Make WordPress Core

Drupal の多言語機能の概要(Drupalの人の談話)

Drupalはすでにいくつかの多言語用の機構が組み込まれていて、Drupal 7ではコンテンツが何語なのかを指定することができるモジュールがある。WPにもあるi18nの機構もすでにある。

リリース予定のDrupal 8では、コンテンツの翻訳用のUIを提供する。

7と8でデータの持ち方が違う(西川感想:え、マジで?WordPressが常にアップデート前提でみんなで進む感じなのに比して、Drupalはバッサリ捨てて前に進むというのは聞いていたけど、もう、本当に7でできたサイトは8にはいけない感じなのがすごいですね。。。)。

7では、ポストがコピーされる。問題化するのは他のモジュール(プラグインかな?)が多言語をサポートしていない場合に、全部表示されちゃったりする。

8では、ポスト自体はコピーせずポストメタ的なところに保存する。タイトルとかコンテンツなどなどを。

WPからDへのQとA

Q. Drupalはどうやってひとつのコンテンツを言語違いということでグルーピングしてるの?
A. もしポストが他のポストの翻訳なのであれば、リンクするためのフィールドが持たされている。D7は2つのポストに分かれてるからそれでひもづけるということ。D8の場合には1ポストなのでメタ情報として、言語属性を持ちつつ保存される。
Q. 問題化しているのはどんなこと?
A. (西川注:D7でのことだと思われる)2個の違うポストになっているので、プラグインが多言語化を考慮していなければ、システムはそれらを異なるコンテンツだと認識するので問題になる。UIとか。たとえば、レイティング(西川注:星をつけるとか)のプラグインがあったとして、同じコンテンツで言語違いのポストは、そのレイティングをシェアしたいはず、など。

コンテンツに言語属性を持たせるいくつかのWordPress プラグインがとっているアプローチ

言語とコンテンツをどのようにまとめたり識別したりしているのか、いくつかの多言語化プラグインを見てみた。

  • WPML: 別々の投稿。WPMLのデータベースがヒモ付を行なう。
  • Babble: 翻訳を別の投稿タイプに保存する。たとえばpost, post_fr_fr, post_jaのような。で、タクソノミを利用してコンテンツをグルーピングする。当然、ポストタイプが違うのでそれに起因する問題が起こる。
  • Multilingual Press: マルチサイト内の違うサイトにそれぞれ保存し、ヒモ付用のテーブルが別途ある。
  • Polylang: 新規テーブルの追加は一切なし。4つのタクソノミが追加される。language(追加された言語)、term_language(タームの訳語。例:英語 – Uncategorize、日本語 – 未分類)、term_translations(タームの紐付け)、post_translations(ポスト同士の紐付け)。かなり軽くて、他のプラグインともちゃんとうごくようだ。

提案

まず、WordPress自体が多言語化をサポートするのはよして、プラグインに任せることで、いろんなシナリオに対応できるようにするのがよい。

ただし、コアがなんらかのサポートを提供することで翻訳プラグインがよりよくなるようにできるはず。

提案1

コンテンツ(ポストやターム)を言語でマーキングするためのミニマルな方法を、コアが持つ

  • 単言語サイトであれば気にならない
  • 多言語サイトプラグインに対し、コンテンツ(ポストやタームなど)をマーキングできるようにすることを義務化
  • 見えない機能になるので事例は必要
  • エクスポート/インポートどうする問題。多言語化プラグインの必須機能にする?なんかフック足したりしないと。
  • no language 的な特殊なロケールがサポートする?Drupalはしてる。
  • wp_postsおよびwp_termsにカラムが追加されるべきかも。その際、postとtaxonomy APIには、プラグインからアクセスできるなんらかの機能追加が必要だろう。

提案2

たとえばウィジェットみたいなコンテンツオブジェクトの文字列を翻訳する際のお作法や標準的な手法をコアが提供する

他に話し合われたこと

  • フロントエンドと管理画面の言語を別のものにできるような仕組み
  • ロケールの変種のサポート。たとえば「インフォーマルなポルトガル語」がポルトガル語とは別にあるのだけど、ISOスタンダートから外れてるのでこれをどうする。
  • コメント欄

    • qTranslate Xについての言及あり。これは、同じフィールドで特殊なhtmlコメントっぽいので言語ごとをラッピングしてる。
    • いろんな人を巻き込もう的な話あり。WPMLや他のプラグインの作者などを。
    • Working Group作る?みたいな話あり。
    • マット降臨あり。コア側でなんか変わるよりも純粋にプラグインだけでやったほうがよいとのコメント。コメントへの返信で、プラグインテリトリに留まるよとの返事はあったものの、複雑化とかクエリの増加とかシングルサイトに影響与えるのはな、というマットからの再返信があり、そういうつもりじゃないけどそうかもな気もするみたいな感じになった。

    ↓ プラグインを作る方々への本、書きました。 ↓

カスタムフィールド定義のデプロイ問題を解決する Advanced Custom Fields の Local/Synchronized JSON

カスタムフィールド製造業界のみな様、こんにちは!

「ACF ってすっごく便利なのだけど、フィールドの定義情報をデプロイするのが面倒くさい問題」が解決できる機能が、ちょっと前から追加されていたようです。

Advanced Custom Fields の、フィールドの定義情報を json 形式で保存でき、また、それをテーマに含めることができるというドキュメントにばったりと出会ってしまいました。みなさん知ってて僕だけが知らなかったのだとしたら、すみません。

簡単に言いますと、

  • ACF のフィールドグループを管理画面を使って定義すると、
  • テーマ内に json が生成されて、
  • git で管理できるし、
  • デプロイも簡単で、
  • json からデータベースへの逆同期(?)も可能

というものです。

みつけたきっかけは、マルチサイトで運用する多言語サイトで、全サイト同じフィールドを持たせたいのだけど、フィールドの定義を全部のサイトで変えるのは面倒くさすぎるのを何とかしたいと、「そういえば php を生成してそれを functions.php に含めれる」みたいな方法があったな、と思って検索していたのがきっかけでした。

この機能が使えるのは、ACF の Version 5 以降です。ドキュメントは以下です。

ACF | Local JSON

仕組み・使い方

スクリーンショット 2015-05-04 21.47.04

テーマの中に、acf-json というフォルダを作成して最低限の書き込み権限等を与えると、フィールドグループ(フィールド定義のセットのこと)を保存する度に json ファイルが生成されて、そのファイルがある場合にはそちらが読まれるとのこと。ドキュメントには、データベースにアクセスする回数が減りますよ、と書いてありました。

フィールドグループの編集画面ではデータベースの情報が読まれるそうですので、手動で更新した場合には、定義画面にはその変更は、そのままでは反映されません。
定義画面ではどんな場合にもデータベースの情報が読まれ、保存時に json ファイルが更新される。表側や入力画面( edit-post.php 系の画面とかオプションページとか)では、json があればそちらがロードされるということ。

json からデータベースへの反映は、以下のようなメニューが追加されていて同期が可能になっています。

スクリーンショット_2015_05_04_21_35

くわしくは、ACF | Synchronized JSON を読むと分かるのですが、

  • json 情報はあるけど対応する定義がデータベースがない場合に利用可能
  • json 情報もデータベース情報もあるけど更新時間が json の方が新しい場合に利用可能

という条件で、どっちが新しいんだっけ?という問題も起きないようになっているみたいです。

素晴らしい!

マルチサイトでの便利ポイント

ここまででも素晴らしいですが、マルチサイトでの運用時にも大変便利です。

  • マルチサイトで同じフィールドを使いたい場合、マスターになるサイトで定義をして json を生成してしまえば、同じテーマを利用する他のサイトでも同じフィールドが使える。
    • しかも、変更が全サイトに反映される
  • json さえバージョン管理されていれば、データベース側の情報が古くなってしまっていても大丈夫。
  • 本番の環境では書き込み権限を無くしてしまうと、なんとなくさらに安心感がある気がする

あとあと、WordPressのカスタムメニューが82個以上登録できねーおらおらーって時の対処方法 | Firegobyにあるような、フィールドが多くなりすぎてサーバで保存ができなくなって大変、というのもこの方法であれば(定義情報に限り)、プロダクション環境のセキュリティのレベルを下げることなく、事故がなくなり、その点も便利です。

ここ最近の案件用のプラグインにまつわる発見の中でも、すっごいびっくりしたのでした!

大きなプラグインは特にですが、やっぱりドキュメントをちゃんと読まないと損だなと思いました。

また、仕組みなどは違いますが、ファイルベースでフィールドを定義できるカスタムフィールドプラグインに、キタジマタカシさんによる、Smart Custom Fieldsもありますので、使わせていただきたいと思います!
くわしくは以下をごらんください。
Smart Custom Fields でカスタムフィールドの定義を Git で管理できるようになりました! | モンキーレンチ

↓ プラグインを作る方々への本、書きました。 ↓