私の考える「オープンソース」について。

私の考える「オープンソース」について。オープンソースとはソースコードを公開するだけのものではないと考えます。現在では一人では開発できないほどに何十万行のソースコードも普通にある時代だと思います。ソースコードの可読性についての議論も必要ですが、それ以外に、「ソフトウエアの概要、ソフトウエアのブロックダイアグラム、クラス図やオブジェクトの関係図、オブジェクトのインターフェース仕様、オブジェクト内部の変数やメソッドの説明、メソッド単位のアルゴリズムの説明、特殊なデータ構造とアルゴリズムの説明、仕様ファイルのフォーマット、通信プロトコル、リソースやUI情報、ソースファイルの関係図、何がどのソースファイルの何ページの何行目に関わるのかの情報」などを可能な限りの説明や、分かり易くするための情報などの第三者に理解してもらうための努力も必要なのではないかと思います。これに可読性や注釈などの議論が必要。ゲームや小さなユーティリティなどは別にしても、根幹的で致命的になりうる分野のソフトウエアは情報公開とインフォームド・コンセント、説明責任と責任の所在がとても重要になってくると思います。この国では重要な部門ほどこれらが欠如していると言えます。そしてもっとプログラミングが子供時代から根付いて、誰でもプログラミングやOSについて親しめる、これらの知識が一般化する時代が来ると良いです。#オープンソース #情報公開 #インフォームド・コンセント #説明責任 #責任の所在


ぼそっとフライング。
「プログラミングの世界に国境はない」。この言葉を着実に実践し実現していくこと。プログラミングや数学は全国共通の言語であり、世界的なツールです。これは神から与えられし「想像」と言う名の魔法の箱だと言えます。これは知のカンブリア紀を起こすことも出来るかもしれません。それほどの可能性に満ちていると思います。母国語のように誰もが理解し、皆で全てのものに当て嵌めて表現し議論する。もっと学問的なフォビー的なオタク的な力が、ボランティア精神が力となり、進歩発展していく道があるべきだと考えます。
様々な人間が様々な「データ構造」「アルゴリズム」「UI」「マンマシンIF」などを考え出し、それを様々な人間が議論し、受け継ぎ、また次なるアイデアを創出していく。プログラミングやアルゴリズムは世界の共通言語であり、様々な表現方法でもある。
人間工学的にも社会工学的にも、文化や哲学などももしかしたら世界共通に通じるものがあり、皆で育てて独特の文化に昇華し、新しいものを作り上げていく。
もっと「オープンソース」を育てて、プログラミング言語やプログラミング作法、アルゴリズムなどを体系化し、多くの人たちと共有し、相互作用や相互刺激を促して、知の科学反応を引き起こすこと。そして、もっと便利で使いやすく、新たな想像を引き起こす楽しい世界にして貰いたい。プログラムングから世界の変革を。これが私の願う夢でもあります。

ブラックボックスや閉鎖空間では健全性は保たれず、本当の意味での安全性などは多くの価値観が関わる開かれた空間でしか培われないのではないか。と思える状況になっています。水は低きに流れるのと同じように未完成な人類は日の本に照らして多様性のある価値観や論理、哲学などに晒して、その健全性を評価し維持していかなければならない。人間とはまだそのような位置にあるのではないでしょうか。やはり、ブラックボックス、閉鎖空間、偏った価値観の世界では、物事は低きに落ちやすく腐敗し易いという確率論は歴史が物語り、また世の常なのではないかと言えます。
また、進化や発展を促す原動力といったものは、オープンで開かれた多様性のある化学反応の起こり易い土壌が一番適しており、OS、コンパイラ、セキュリティ、ブラウザなどの現代の普遍的で基本的なデバイスにおいては、特に万人の生活に関わる重要なファクターであり、その重要性や影響度、優先順位的な考え方からも、万人が理解しそれを有効活用させて安定化していく義務があり責任がある大きな一分野です。また、議論する社会、考える社会、論理性が有効な人間社会においては、プログラミングやアルゴリズムなどは一番適合した分野であり、一番相互刺激、相互作用などを促していくべき世界なのではないかと私は考えます。

閉鎖空間やBBでは、必要以上に無駄に複雑化していくきらいがあります。これは混乱やカオス化の大本でセキュリティに対する逆効果を生み、脆弱性の確率を高めるものになります。設計や方法論に対してのオープンな議論と研究を促進させる必要があると思います。 
シンプルイズベストという基本的な原理。APIインターフェースや種類の集約化や調整が必要。また変換を考慮した設計の在り方を考える必要性。
必要最低限のモデルからシームレスに高機能モデルへとカスタマイズする技術(ユーザーのニーズに合わせて必要ないものは極力入れない構造であり、必要なら簡単に付け加えることができる構造)
上下互換性を維持しバージョンの違うAPIセット間での効率の良い変換方法
セキュリティ>効率>機能性を有線し維持する基本的な考え方を徹底した上での
 

スポンサーサイト

コメント