2016年2月28日日曜日

変な人対策として勉強会の運営ができること

勉強会・ハッカソン運営者の皆様、参加には料金とるか審査制にしてください

この方の場合は単に「騙されやすい人だった」というものだと思う。
有料化は、「無料だしとりあえず席を確保しておこう」といって参加登録して結局来ない、みたいな人のために本当に参加したい人が参加できない問題は解消される。しかし、それが変な人対策として有効かは疑問。変な人は「自分が問題ある人間であることを自覚できない人」である場合があり、行動規範のようなものを用意したとしても読んでか読まずか来るものは来る。なので、オープンなイベントである限り、変な人が来ないよう運営がなんとかすることは事実上できない。
運営にできることは、問題ある人物が入り混んで実際に問題が起きたときのために、そういう人を追い出せるポリシーを明文化するくらい。
参加者にできることは、運営に全任せするのではなく、自衛の手段を持つこと。

##追記(2016/02/28 22:40)
言及先の方を単に「騙されやすい人」と呼称していましたが訂正し、より具体的に書きます。
まず一般化した具体的な対策を書きますと、「これは変な人だ」と認識できる感性と知識を磨くことと、「あなたに興味がありません。どこかに行ってください」のように言葉と態度で拒絶を示せることの2つが必要だと思います。
今回の場合は、変な人であることを認識するのが難しいかもしれませんが、話を進めていくうちに「ハッカソンと言いつつ、この人は何もしない人だ」ということに気付けています。こういったことからは、仕事でクライアントと契約をする前に行うことと同じようなことをすればよいとわかります。つまり、要件定義やその人のことの調査などですね。安請け合いをすると「こんなはずじゃなかった」という結果につながりますので、仕事の請け方を身につけると対策につながるでしょう。

2016年2月21日日曜日

オープンソースはどのようにして成功するのか

What success really looks like in open source - And how we can support them

「伽藍とバザール」ではもう今日のオープンソースは語れないので、いまのオープンソースの成功について考えよう、という記事。和田さんが言及してたので読んでた。
てきとうに気になったところを持ってくる。しっかりと全訳する気力はないです。

==
バザール方式は説得力はあるが、現実的ではない
外からは、Linuxのようなプロジェクトにはバザールが本当に存在したことを証明したように見えた。しかし実際には、皆がその考えを売り払った。

・インターネット・セキュリティ・アナリストのNikolai Bezroukovは、1999年に「あまりにも単純」、「ソフトウェア開発の下品なマルクス主義的な解釈だ」と即座に反論記事を書いた
・FreeBSDの開発者であるPoul-Henning Kampは、「いまの世代からバザールが失われた」という記事のなかで、「品質の向上は、誰かが責任をもって取り組んだときにのみ起こる」と語った
・StackOverflowの創始者であるJeff Atwoodは2015年の投稿で「十分なお金が与えられるなら、全てのバグは浅い」と語り、HeartBleedと呼ばれるセキュリティバグが2年間見つからなかったことを指摘した。「君が自分のコード、ウェブサイト、アプリケーションにあるバグを見つけたかったら、昔ながらの方法として彼らにお金を払うことだ」(訳注:OpenSSLは、世界中で使われているセキュリティのライブラリであるにも関わらず、フルタイムで働く開発者は2人しかおらず、しかもほぼボランティアな状態だった)

「伽藍とバザール」の著者Raymondは間違っていたのか?いいえ。それが出版された時代背景を考えよう。それは1997年で、Microsoft、Oracle、IBMのソフトウェアに支配されていた。LinuxやLAMPといったプロジェクトは敗者だった。Raymondが書いたようなエッセイは、クローズドソースが標準だった世界で、Linuxを正当化し、活性化を助けた。
それは私たちを魅了したが、現実的な説得力(rhetoric)を間違えてはならない。オープンソースが成功するために必要なことを掘り下げてみよう。

(中略)

私たちがオープンソース・インフラストラクチャの「成功」について話すとき、成功はいくつかの構成要素を持つ:

・「人気」のあるプロジェクトは、多くの人に使われることで、理想的に成長する
・「健全」なプロジェクトは、メンテナがコミュニティと積極的な関わりを持つ
・「サポートされる」プロジェクトは、メンテナがプロジェクトの人気を管理し、健全なコミュニティへと成長させるようリソースを割く

この3つを全て持っていることが理想的だが、これには多くの組み合わせがありえる。そしてこれはなぜか、オープンソースを維持する万能の解決策ではない。
お金はプロジェクトをサポートできるだけで、人気や健全性を作り出すことはできない。

(中略)

ではどうすればプロジェクトを、人気で、健全で、サポートされるものにできるか
(中略)

Critical -> Legacy
重要なものを使い古されたものにしていく

・(コントリビュートしやすくしろって書いてる)
・誰がプロジェクトを管理しているか明確にする。マイナスの影響や法的な衝突などのリスクはあるか?そのプロジェクトはどのように探し出せばよいか?新鮮な才能のコントリビュートがあるか?(ウェブサイトを作ったり、デザインを改善したり、GitHubのようなプラットフォームに移行したり、新しい開発者を支援したりといった機会を作る)