  |
はてなキーワード: ソースコードとは
以下、センスという言葉は字義通りの意味、つまりテクニカルな要素に先立つ感覚的な要素の意味で用いる。
これは考えてみれば当然だ。
たとえば力学の質量や速度などの概念は理論的に定義されるから存在するわけではなく、それに対応するものは感覚や認識として存在しており、理論はそれを上手く反映したモデルなのだ。
いくら数式の変形が得意でも、速度という概念が日常的な感覚として理解できていなけれは、力学を理解することは不可能だろう。
もちろん、知識によって補強されるセンスもある。たとえば電磁気学の概念の多くは、力学の概念のアナロジーであるから、力学を正しく理解していることが、ここでいうセンスに該当する。
なお、センスというのはプラスアルファの特別な才能ではなく、必要条件に過ぎない。
彼らは、自分が理解できないことを話し手の説明のせいにしたがるが、ほとんどの場合、彼らのセンスが無いのである。
普通の人に何かを系統立てて説明する場合、以下のような手順を踏めば、よほど前提知識が足りていない場合を除いて、おおよそ通じる。
2番目と3番目は入れ替えても構わない。これは演繹的に考えるか、帰納的に考えるかの違いであり、どちらか一方が優れているというものではない。
およそどんな分野にも、異常にセンスのない
奴は存在して、奴らは、どんなに言葉を変えて説明しようが、具体例を示そうが、たとえ話をしようが、絶対に理解しない。
何せ、センスの無い奴は上の工程のどの箇所も、特に(1)すら理解していないからだ。奴らはたとえば、「2次方程式を解くのは1次方程式を解くよりも難しく、別の方法が必要になる」というところからまず理解していない。こういう奴らに平方完成とか教えても無意味である。
教育にナイーブな幻想を抱いている奴は、適切に教えれば誰でも理解できると思っている。特に、分からない原因を突き止めて改善すれば分かるようになると思い込んでいる。たとえば、微分法で接線の方程式が分からないのは、2点を通る直線の方程式の立て方が分からないからだ、とか。
もちろん、これは原理的には正しいのだろうが、ほとんど現実的ではない。おそらく、小学校低学年まで遡らないと、そういう原因を解消することは不可能だろう。
センスの問題を感じる奴の多くに欠けていると思うのが、言語的なセンスだ。
たとえば、プログラミングを教えていると、「ソースコード」や「オブジェクト」という言葉の意味が分からなかったとか、フィードバックしてくる奴が結構いる。もちろん、一部はやる気が無くてそういうことを書いているのだろうが、数が多いので実際にそういう奴はいるのだろう。
普通の人はそんな感想は抱かない。その話の中でそれらの語が何を指しているのかは明らかであるし、そもそも「それらの語の厳密な定義を知らなくても内容は理解できる」ということは分かるからだ。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
530あとで/4137users NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020 - diary.sorah
304あとで/1974users 高等学校情報科「情報Ⅱ」教員研修用教材(本編)：文部科学省
204あとで/2230users iPhoneでの料理撮影が苦手なライターがカメラマンに論理的に指導を受けた結果→憂鬱な撮影が楽しくなった - メシ通 | ホットペッパーグルメ
202あとで/1706users 天才プログラマーの「締切に対する考え方」に、感銘を受けた。 | Books&Apps
177あとで/1946users ネットワークエンジニアとして | www.infraexpert.com
170あとで/1064users 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
169あとで/826users 7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
168あとで/1180users ローカル開発環境の https 化 | blog.jxck.io
166あとで/1005users ソースコードブランチ管理のパターン | Martin Fowler's Bliki (ja)
164あとで/991users 大学に行かずにコンピュータサイエンスを学ぶときに優れている教科書や講義映像はどんなものがあるのか？ - GIGAZINE
164あとで/1541users 衝撃の結末が話題 無名ラッパーが投稿したYouTube動画が異例の48万再生、投稿者と大学側を取材 - ねとらぼ
161あとで/1789users 無印良品によるサーキュレーターの季節別の活用方法が有益すぎる→早速効果を実感する人も「部屋が快適…！」 - Togetter
147あとで/2111users 批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
143あとで/809users データベース設計の際に気をつけていること - 食べチョク開発者ブログ
142あとで/731users Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
136あとで/1777users 「言い切る人」が強すぎる。 | Books&Apps
129あとで/1655users iPhoneのNFCシールでの自動化が便利すぎてシール貼りまくった – ごりゅご.com
129あとで/616users 良いコードを書くための8つの習慣 - New Relic公式ブログ
128あとで/1164users GAFAコーディング面接こんな感じでした - yambe2002’s diary
126あとで/1345users 無料で美麗な絵画やカオスなポスターなどがダウンロードし放題、編集や商用利用も可能な「Artvee」が登場 - GIGAZINE
125あとで/687users デザイン脳を鍛える方法｜ハラ ヒロシ｜note
125あとで/993users １からイラストの勉強をした話｜せたも｜note
124あとで/608users Dockerとはどういったものなのか、めちゃくちゃ丁寧に説明してみる - Qiita
124あとで/992users Web制作の常識が変わる、便利な最新オンラインツール48個まとめ - PhotoshopVIP
121あとで/1091users なぜ、国ごとに差が出たのか。そして第二波がどうなるか。 - 楽園はこちら側
119あとで/1321users アメリカの美大で学んだこと05:「絵がうまい」より大切なこと｜Kenta Shimbo｜note
119あとで/1684users 自民系の地方議員です。カネ配りについて書きます。 | はてな匿名ダイアリー
118あとで/1444users 料理に対するモチベーション「ゼロ」のぼくがたどり着いた、これだけで料理が簡単＆美味しくなる調味料 - ソレドコ
118あとで/1195users 視座の可視化｜kgmyshin｜note
116あとで/1224users 【公式】ぷよぷよeスポーツ×プログラミング | SEGA
あとで読むタグの数が1月に近いレベルまで大幅に反発、増加した。
一昨日ホットエントリを選択するアルゴリズムが変わったというアナウンスがあったが、影響を受けているかどうかは不明。
「パートIII.Dで、当財団は、ダイムラーが使用した違法操作機器の運用にかかる委託研究について説明する。 ••••••（以下：••••••）が実施したこの調査では、これまで他の利益団体や当局が使用していない根本的に異なる方法論を採用した。端的にいえば、当財団が購入したEuro 6 Test Vehicleでテスト走行を行い、エンジンと排気ガス管理を制御するECU（Electronical Control Unit）から走行中の情報を読み取ったのである。これにより当財団は、試験車両の違法操作機器の根本的なメカニズムと機能を初めて洞察する者となった。本調査により当財団が同定できる限り、少なくとも8つの違法（SCRおよびEGR）操作機器が配備された、驚異的に複雑で洗練された排出詐欺が明らかになった。これらの違法操作機器はそれぞれ、実際の運転条件でシステム全体の効率を大幅に低下させる。ダイムラーのトリックの結果として、これらの違法操作機器はNEDCテストサイクル外でのみ動作する。」
「III.B.1. 序文
255. このセクションでは、当財団は、排出規制および適用される判例法に基づいて、違法操作機器の特性について説明する。 前述のとおり、当財団はとりわけ、2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見※に特に注意を払っている。（図14を参照）。」
※「2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見」はこちら。↓
"Court of Justice of the European Union PRESS RELEASE No 52/20
Luxembourg, 30 April 2020
Advocate General’s Opinion in Case C-693/18CLCV and Others (defeat device on a diesel engine)
According to Advocate General Sharpston, a device that adjusts upwards the operation of the emission control system of diesel engine vehicles during the approval testing of those vehicles is a ‘defeat device’prohibited by EU law
The objective of slowing down the aging or the clogging-up of the enginedoes not justify the use of such a device"
https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-04/cp200052en.pdf
III.D.1. イントロダクション、研究の関連性、および主要な調査結果
295. このセクションでは、当財団の研究結果について論ずる。 この研究は、その方法論によって、上で説明した研究※とは区別される。 前述のように、この研究は、入力値（周囲温度や車速など）と出力値（PEMSで測定された排出量）を測定するのみならず、ECU自体の内部機能を測定することを目的とする。 テスト中にECUから直接情報を読み取ることにより、ECUの設計と操作を再構築可能である。」
※直前のIII.C で、第三者が公表した調査結果を挙げている。
「296.このアプローチは、概ねメーカーのソースコードがなければ違法操作機器の動作を検出および分析することは不可能であると考えられていることから、これまでどの型式承認当局・関連団体にも採用されていない。間違いなく可能であるとはいえ、費用と時間がかかり、専門知識を用いねばならない。この理由もあって、当財団はこれまでのところ、この研究を単一のテスト車両（本テスト車両）に限定している。本テスト車両は、第306項でさらに指定されているユーロ6対応型メルセデスE350である。モダンなユーロ6車両を選択する理由は、この車両タイプに、EGR（排気ガス再循環）とSCR（選択的触媒反応）の組み合わせからなる高度で複雑な排出制御システムが装備されているためである。このような複合システムでは、SCRシステムが処理の大半を引き継ぐため、EGRシステムはNOx排気負荷を減らすために「ハード」に動作しなくてもよくなる。 Euro 6モデルのECUソフトウェアはEuro 5ソフトウェアの拡張バージョンであるため、以前のバージョンの多くの機能がまだソフトウェアに存在している。調査が示すように、本テスト車両のECUには、機能しているEGR操作機器も多数含まれている。この点で、本研究結果は、EGR装置のみが装備されていた古いメルセデスベンツモデルにも関連している。
297. 要するに、この調査により、SCRとEGRの違法操作機器の範囲が特定された。これらはそれぞれ、特定の条件下でシステムの全体的な効率を大幅に低下させ、これによりSCR触媒コンバーターはほとんどの条件で動作容量のうち最大で60％に制限されることとなる。」
「300. 本調査の結果、違法なSCRおよびEGR操作機器は、NEDC検査下の状況では動作せず、通常の使用状況でのみ動作するようにプログラムされていることが判明した。 違法操作機器は、条件がNEDC検査条件から少しでも逸脱している場合にアクティブになることがわかっている。 さらに、SCR関連のいくつかの違法操作機器には、車両が数か月間使用された後にのみ違法操作機器を操作するように設定されたタイマー機能があり、NEDC検査を確実に通るようになっている。」
「302. 本調査はまた、これらの違法操作ツールのほとんどがソフトウェアの更新後にテスト車両から削除されたことを示している。これは、エンジンの損傷を防止したり、車両の安全な動作を確保したりするために違法操作ツールが必要ないことを意味している。このソフトウェアの更新によって、テスト車両のすべての違法操作機器が実際に削除されたかどうかは明らかではない。……」
III.D.2.a）はじめに
305. 本調査で使用されるメソドロジーは、データ収集、ソフトウェア分析、およびテスト車両から生れたテスト結果の解釈とを、組み合わせることである。306. 前述のように、本テスト車両は、メルセデスベンツ E 350 BlueTEC 4 MATIC Tであり、OM 642型 190 Kw、2987 ccm、6気筒エンジンを搭載している。本テスト車両の検査文書のコピーを別紙57に提示した。……
307. ECUの情報チャネルは複雑で量が多いため（ECUは内部で10,000を超える信号を処理）、イテラティブなプロセスを用いた。 最初のフェーズでは、通常使用中に車両のECUのプロファイルを作成するために、広範なデータ収集が行われた。 排出制御に関連するソフトウェアとデータは、ソフトウェア分析を使用して特定した。 その後、データ収集プロセスをさらに洗練し、より詳細なデータを得た。」
308. 調査中のデータ収集は、OBD-2ポートを使用して実行した。……」
「310.前述のように、ECUソフトウェアのソースコードや完全なドキュメントについては、ダイムラーがその情報を慎重に管理しているために、本調査者はこれらを得ていない。 ただし、ドキュメントやソースコードが利用できないソフトウェアの分析については多くの研究があり、そのような分析はIT業界で定期的に行われている。研究者は、「逆アセンブル」（ソフトウェアが人間が読める形式に変換される）やソフトウェアシミュレーションなどのいわゆるリバースエンジニアリング手法を使用している。 これらの手法により、ソースコードが利用できない文書化されていないソフトウェアの分析が可能になり、本テスト車両のECUソフトウェアの分析にも使用されている。」
315. 本SCRシステムでは、主な制御変数の1つはAdBlueまたはDEF（ディーゼル排気流体）の投与量である。本テスト車両のECU、Bosch EDC17CP57 は、システムに投与されたAdBlueの量を計算する。 SCR触媒コンバーター内で、AdBlueはアンモニアに変換され、次にアンモニアがNOxと酸素と反応して窒素と水に変換される。
316.有効性の尺度は、「SCR除去効率」または「変換効率」である。 SCRの潜在的な効率は、以下を含む多くの物理的条件によって制限される場合がある。
317. 以上のリストは完全なものではないが、適切に機能しているSCRシステムが物理的な制限を受けていることを示している。 これらの制限に対処するために、本ECUソフトウェアには、2つの異なる動作モードが含まれている。
318.最初のモードは、以下「アンモニア負荷モデル」と呼ぶもので、SCRシステムが完全に機能するモードである。 このモードは公的にアクセス可能なメディアでは説明されておらず、この用語自体は文献で使用されている標準ではないことに注意されたい。
319. 2番目のモードは「代替モデル」である。 これは、不正な操作ツールによってアクティブ化されるモードである。 代替モデルがいずれかの操作ツールによってアクティブ化されると、通常SCRは最大60％となる。 特にいくつかの違法操作ツールが同時にアクティブ化されている場合は、効率が大幅に低下する可能性もある。……」
330. 本調査による観察結果の要点は、代替モデルでは、実際の運転条件のほとんどで、SCRシステムのターゲット効率が比較的低い値に保たれるが、これは物理的な制限に基づいていない要因やポリシーの選択によって生じているため、 違法だということである。 言い換えると、SCR触媒でのNOxの還元に直接影響を与えることがない入力に応じて、効率目標が意図的に低い値に低減される。 したがって、これらの要素とポリシーの選択、およびそれらが有効にするメカニズムは、違法な操作手段と見なすことができる。
331. これらの違法なSCR関連の操作ツールは、以下の機能を共有する：
（i）それらは、温度、排気ガスの質量流量といった、極端な条件下で一般的に制御する必要がある物理的特性に応答する。
（ii）ただしそれらは、通常の「実際の」運転条件では、システマティックにアクティべートされる。
（iii）それらは、たとえば、正当化されないヒステリシスを使用することにより、アクティベート後に、ある効果が出るように設計されている。
簡単に言えば、ヒステリシスという用語は、新しい状態への切り替えを引き起こす値と元の状態への戻りを引き起こす値との間に特定の「範囲」がある状態を表す。一般的な例は、特定の温度で加熱がオンになるサーモスタットで、温度が初期値よりも数度低い場合にのみオフになることで、システムのオンとオフが連続して行われないようになっている。今回のケースでいうと、ヒステリシスは、元の状態（この場合は「アンモニア負荷モデル」）に切り替えるしきい値が「代替モデル」が動き出す状態に切り替えるレベルよりもかなり低い（または高い）場合に発生する; そして
（iv）それらはSCRシステムの目標効率を大幅に低下させ、AdBlueの投与を大幅に削減する。これにより、NOx排出量が大幅かつ大幅に増加する。
332. 本調査の結果、8個以上の違法操作機器が発見されたが、そのうち6個はSCRシステム（およびAdBlueの投与量）に関連している。……」
「III.D.4.a）SCR操作ツール1：排気ガスの質量流量
335. 最初の違法SCR操作機器は、SCR触媒コンバーターを通過する排気ガスの体積（排気ガスの質量流量）を参照する。
336. 上述したように、排気ガスの質量流量がSCR触媒の処理能力よりも大きい場合、排気ガスはSCR触媒から逃げることができ、NOxチャージを減らす機会が与えられないこととなる。 これに対処しないと、SCR効率の過大評価につながり、AdBlueのオーバードーズにつながる可能性がある。 このことで、SCR触媒がアンモニアでオーバーフィルされ、アンモニアのスリップが発生する可能性がある。 したがって、質量流量を監視し、過剰なマスフローが通知されたときにSCRのターゲット効率の推定値を下げることは、原則として、有効なストラテジーになる可能性がある。
337. ただし、テスト車両では、フィルタ後の排気ガスの質量流量の制限は、時速170 kgに設定されており、これは、実際の運転状況では約100 km / hに相当する。 このしきい値は、技術的な観点から見て、言い訳けができないほど低くなっている。 このしきい値を超えるとすぐに、ECUは代替モデルに切り替える。 さらに、（-80 kg / hの）強いヒステリシスが適用されるため、負荷モデルに切り替える場合、質量流量は90 kg / h未満でなければならない。 60 km / h程度の低速でも、このしきい値は日常的に超過している。 さらに、エンジンが一定している場合、短時間では負荷モデルに戻らない。
338. この制限は、正確には、SCRシステムの「エージングファクター」によって決まることに注意せよ。この機能に関連して、ECUはSCR触媒コンバーターがその耐用期間中にさらされた温度を記録し、これに基づいて経年変化の影響をモデル化する。ただし、以下のグラフに示すように、この違法操作機器のエージングファクターは、完全な100％（完全に新しい状態）が1％～99％（すなわち実質的に新しい）まで減少するとすぐにアクティブになるように設定されている。すでにその時点で、上限は時速200 kgから時速170 kg へ削減され、下限（ヒステリシス）は時速120 kg / hから時速80 kg / hに削減されている。 NEDC検査は完全に新しい車両で行われるため、輸入検査でこの違法操作デバイスを検出できないと推定できるのである。これに対し、本テスト車両はこれらの観測の時点で70,000マイル走行しており、ソフトウェアは69％のSCRエージングファクターを示していた。」
OSSってのは「フリーソフトウェア」が無料ソフトと混同されがちだからっていうので作られた言葉で
利用者がソースコードにアクセスできるっていう要件が満たされてればOSSだよ
本家の開発者がパッチを全拒否して一人で開発してたとしても別にいい
「ソースがオープンであること」と「OSSであること」を混同してる人が多すぎない？
発注者がいてそれを引き受けたコミュニティ・チームがあって、緩いながらも納期が設定されていたわけでしょ？
シビックテックか知らんけどかっこいいことしたい偉い人と自意識過剰なエンジニアが運悪くマッチしたプロジェクトでしょ。
そもそも「とりあえずリリースして素早く直す」みたいなのはユーザがサービスを選んで使ってれてるから通用する話であって
ITリテラシーのない数百万人が適切なインストラクションもないのにバグだらけのソフトウェア掴まされて文句が出ないはずないでしょ。
もう一回良く考えて欲しいんだけど
-----
いやいやいや、当然でしょう。OSSコミュニティの開発ではない。
発注者がいて納期があったからチームはリリースを拒否できずにバグだらけのソフトウェアをリリースしたんでしょ？
それともチームは自分たちで今の状態のソフトウェアをリリースする意志決定をしたってこと？それならバグの責任を持つのはチームでしょ。
何度でも書くけど「ソースコードが公開されている」ことと「OSSであること」は別物だよ。
ここ最近の COVID19Radar https://github.com/Covid-19Radar/Covid19Radar 上でのゴタゴタにより、開発者の @kazumihirose さんが https://twitter.com/kazumihirose/status/1274616019420471296 疲弊してしまいっているのを見て、(今回の揉め事の根本的な原因はソフトウェアがOSSとして公開されているのが原因ではないと思うが)いたたたまれない気持ちになったので書く。書いてみた結果ただのとりとめもないOSSへの愚痴になってしまった。
いくつかのOSSプロジェクトのメインコントリビュータとして関わっています。
私の周囲のソフトウェアエンジニアがOSSに対して以下のような意見を述べているのをよく聞く。
確かに、OSSは特定の企業に所属していないので特定企業の方針で運営が捻じ曲げられる心配がなく民主的で、細かい実装が気になったらソースコードを読むことが出来、顔も合わせたこともない優秀なエンジニアと議論を交わし共通のゴールに向かってともに開発を進められる。OSSは楽しい。
しかし一方、OSSメンテナのバーンアウトが近年問題になってきている(なんとなくここ数年で目につく数がなんとなく増えてきている)気がする。
というのも、OSSを運用していく上では楽しく優秀なエンジニアと開発をすすめるだけではなく、ドキュメントを読めば分かるようなことを質問してくる人、PR に対して changes required を下すと怒ってくる人、Twitter でこのライブラリは使いにくくて最悪だと罵ってくる人、こういった普通の会社ならカスタマーサポートさんがワンクッション挟んでくれる人たちに対しても開発者が直接対応しなければならない。
元々楽しくて始めた/関わり始めたはずのサイドプロジェクトだったのに、いつの間にか日々やってくる頓珍漢で再現環境のないバグレポートや、Issueも立てずに突然提出される意味不明なPRに対して、義務感で、就業後や土日の時間を削って、根気よくコメントを続けていると、何で貴重な自由時間をこんな訳のわからない連中のために使っているんだ?という気持ちになってくる。
実際、私の関わっていた一つのプロジェクトでは、もともと6人ほどいたアクティブなコントリビュータが徐々にプロジェクトを離れていき、(私を含めて)2人はメンテナンスに疲れてしまったのでしばらく距離を置くと宣言し休みを取っている(あまりに精神が回復したので戻れるのかは不明...)。
こういう現場を見ていると、手放しにオープンソース万歳！透明性最高！と言いながら自分自身は大してOSSに貢献してない人たちに対して苦い気持ちを覚える。
一方、私の関わっているもう片方のプロジェクトは非常に円滑に運用が回っていた。もうひとつのプロジェクトと何が違ったかというと、そちらのプロジェクトはいくつかの企業がソフトウェアエンジニアの業務時間の半分/全部をそのプロジェクトのメンテナンスに費やしていたのである。(何人かのメインコントリビュータが企業から出向する(?)する形で運用している)。
issueへの一次対応などの日々のつまらないタスクは業務でメンテナンスしてくれているエンジニアがやってくれるおかげで、他のメンテナが対応する必要のあるissueやPRは減り、みんなが開発やバグ対応に集中できている。業務でOSSに取り組んでいるエンジニアにストレスはないのかと聞いたところ、多少大変ではあるけれどお金をもらいながら自分の仕事をオープンにできるし、仕事だと思えば多少のストレスは我慢できる。とのことだった。
このプロジェクトに限らず、なんとなく長期間運用がうまくいっている大規模なOSSプロジェクトはだいたいどこかの企業が支援しているような印象を受ける(Facebook とか MS とか Google とか(大企業ばっかだな...))。もちろん全てのソフトウェア企業に大してOSSに大して大金をつぎ込めというのは現実的ではないが、open collective や github sponcers なんかに企業として少しずつでも寄付してくれたら、OSSコミュニティはもう少し良くなるんじゃなかろうか。
結局何が言いたかったかというと、エンドユーザー(OSS利用者)がめちゃくちゃ増えてきた昨今、個人レベルでそれなりの規模のプロジェクトをメンテナンスしていくのは最早厳しくなってきており、結局企業によるバックアップなんかがないと持続的な開発は難しいんじゃないかと思っている。
今日になって思ったより多くの方に読んでいただいて驚いています。あまりオープンインターネットで話しにくい話題だけど皆がどう思っているのか気になっていたので嬉しい。増田がブクマされても通知は来ないんですね(そりゃそうか)。
@bouzuya
まず焦点を当てている持続可能性が見出しから思い浮かべるものより狭いんだと思う。「最悪フォークすれば持続可能」みたいなのがぼくだと最初に思い浮かぶ
確かに、OSSの持続可能性という少し主語の大きいタイトルにしてしまったが、この文章はソフトウェアの持続性というよりかはOSSに携わる人のバーンアウトに対する憂いをつらつらと綴っているもので、ソフトウェアの持続性という意味では他にも色々やりようがある気はする。
また、私が目にしたうまく回っているのが企業による支援を受けたプロジェクトだったので、バーンアウト対策として企業による支援について述べたが、企業による支援がなくともうまく回っているプロジェクトは世の中にはいろいろあるだろうし、今後OSSは企業による支援がないとやってけないと決めつけるのは早合点ではあった。反省。(とはいえ問題意識は変わらないし、その一つの解決策が企業による支援だと思っているのも変わりない)。
---
自分の記事を読み直してみて、一番問題に感じているのはユーザーサポートの工数なんだなと分かったが、@mathane さんがその問題への一つの解答をつぶやいていた。
@methane
雑な質問やバグレポート（99％レポート者のミス）をする場所は、とにかくメンテナ以外の人が回答しやすい場所でしてもらう事が重要だと思う。
これは確かに。私はまだOSSコミュニティど初心者なので、こういうOSSをメンテナンスする上で重要なことをどんどん知りたい。
もちろん、その通りだと思う。
だからOSSのソースコードや設計について改善案を出すのはいいと思う。
だけど、～が悪いなどの強い言葉や、何も知らない人や勘違いしやすい人に対し専門家の印象を下げるような表現に終始する言説は誹謗中傷でしかないので、
日本からアメリカにソースコードをチェックインして、受け渡しって、普通に十年 二十年前から現場では普通にやっていて、だってインターネットつながってるじゃん。え？何が問題でしょうか？とか、なにかおかしい？普通そうするよね？わざわざ何度もソースコードレビューして、CD-Rにやいて、国際郵便で送ったりしない。git でpushして、マージってなにがおかしいの？
会社は違うよね？っていわれると、そりゃまぁ違うと言われれば違う。
現場にそんな難しいこと言われても わかんない。めんどくさいから北米にgit作ってみんなでいれようぜって 普通そうすると思うんだけど・・・難しいことはやって
いや、いちおう日本でもpullしとけばいいじゃん。
日本ではomankoっていっちゃだめ とかリストにして配布しづらいだろうけど であるがゆえに わかんないよそんなの
