https://jp.techcrunch.com/2009/12/23/20091222google-open-when-convenient/
オープンソースカンファレンス2009 Tokyo/Fall - オープンソースの文化祭！
30日(金) ・MySQL 〜いろいろあったりもしたけれど、私はげんきです〜 （サン・マイクロシステムズ株式会社）（PDF/1.9MB） ・Firefox 3.6 & Thunderbird 3 リリース前徹底解説 〜ちょっと幸せになれる Tips も〜 （Mozilla Japan）（外部リンク） ・デモで学ぶGoogleApps勉強会 〜Google Secure Data Connectorでクラウドと社内システムを連携！〜 （株式会社 イーシー・ワン）（外部リンク） ・OpenOffice.org Baseで作る簡単アンケートシステム （OpenOffice.org日本ユーザー会）（外部リンク） ・オープンソースでシステム監視！統合監視ソフトウェアZABBIX 1.6の機能のご紹介とデモ （ZABBIX-JP）（外部リンク） ・オープンソースのアプリケーション・サーバー「Apach
ユーザー参加型製品開発が大量生産ビジネスを変える（その２） - ITビジネスフロンティアの狩人
3月20日付けのエントリー「ユーザー参加型製品開発が大量生産ビジネスを変える」で、2020年頃には、オープンソース化したハードウェアや開発支援ツールが製品開発のエンジンとなり、数台単位の超小ロット生産やユーザーの手元で作るパーソナルファブリケーション（多品種のオンデマンド生産）が可能になり、モノつくりのパラダイムシフトが起こるだろうという話しを書いた。 その後、4月6日付日経エレクトロニクスのUGD(User Generated Device)技術特集記事や家電ベンチャーを立ち上げるCerevoの岩佐社長の5月13日付のブログ「高度オープンソースハードウェアの現状とビジネスモデル」などを踏まえて、オープンソースハードウェア（OSH）技術がもたらす具体的なユーザー参加型製品開発の姿とビジネスモデルについて踏み込んで整理してみたい。ここにガラパゴス化を脱する１つの方向性が見えてくるような気がす
高度オープンソースハードウェアの現状とビジネスモデル 〜チップを売るにはOpenSourceHardware化!?〜 - キャズムを超えろ！
先日Arduino関係のイベントをやって、オープンソースハードウェアについて少し説明する時間があったので、会で話した内容を含めてもう少しだけ詳しくオープンソースハードウェアの現状とビジネスモデルについて説明しておこう。尚、長いのでオープンソースハードウェアはOSHと略す。 ３つのOSH GainarやArduinoといった安価小規模マイコンに開発環境などがセットになった類のOSHはどちらかというとあんまりビジネスのにおいがしない。あるとしても、これらのボードを売って利益を得ようというケースだったり、関連書籍で売上を上げようといったものが多い。どちらかというとNPO的な出自に近いと言えるかもしれない。実際Gainarの出自はアカデミック(大学)だし、Arduinoもアカデミック向けに作り始めたのが元だと聞いている。これが１つ目。 Chumbyのアプローチは割と変態的だ。Webサービスプラット
GitHubの登場はコミッタを特権階級から追い落とす革命だった - Hello, world! - s21g
弊社は、deployツールとしてcapistranoを使っています。 しかし、Capistranoのメンテナンスが終了するという話("Jamis Buck氏, CapistranoやSQLite/rubyの開発を終了"参照)を聞いても、 特に困らないという事に気がついて、あらためて驚きを感じました。 なぜだろうと考えてみると、それはGitとGitHubの存在による所が大きい。 GitHubにソースがある限り、メンテナが不在でも勝手にforkして 野良patchを書いたり、それを集めてきてちょっとした stable release的なものを作ったりする事ができてしまう。 もちろんそれは、今までだって頑張れば出来た事だけれど、 Git/GitHubは、それを全く違う次元で簡単にしてしまった。 かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの
Latest topics > オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられる
Latest topics > オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 無責任中間法入 Moezilla Japan 設立のお知らせ Main FUELが酷すぎる » オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた - Apr 02, 2008 オープンソースなライセンスとかコピーレフトなライセンスとかたくさんありすぎて違いがよく分かってなかった（自分で使ってるのに……）。特に、それぞれどう組み合わせること
幸せな「エンジニア」ライフの理由 － ＠IT自分戦略研究所
自らのアイデンティティを「オープンソースプログラマ」と定め、オープンソースと自分の可能性を追いかけるために海を渡って8カ月。現在は非常に幸せな日々を送っているというかずひこ氏。なぜ幸せな仕事ができているのか、これまでを振り返った。 今年の4月にフランスに渡り、Nexediというフランスの会社でオープンソースERP「ERP5」の開発に参加して、早くも8カ月がたちました。日本を発つ前は、どんな未来が待っているのか不安でいっぱいでしたが、いまはフランスでとても幸せなエンジニアライフを送っています。この幸せな状態があまりにも普通となっているので、普段は特に「自分が幸せだ」ということを意識しないのですが、なぜ私は幸せなのか、一度じっくり振り返ってみることにしました。 ■まっすぐオープンソースに向き合える 以前、「アイデンティティはオープンソースプログラマ」という記事で書いたように、私はオープンソース
Part1 オープンソース/C言語に学ぶ「ソースコードの読み方」：ITpro
「Code Reading―オープンソースから学ぶソフトウェア開発技法」（毎日コミュニケーションズ発行，写真1）という本があります。私はこの本の監訳者ですから，やや自画自賛になってしまいますが，ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール，データ構造，アーキテクチャ，さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家，他人の筆づかいを研究しなかった偉大な画家，同僚の肩越しに技を盗まなかった腕のよい外科医，副操縦席で実地の経験を積まなかった767機長――果たして，そんな人たちが本当にいるのでしょうか？ たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち，他の人の
未来のいつか/hyoshiokの日記 - Community Based Development
OSSの破壊力はバザールモデルとして知られるソフトウェア開発方法論である。バザールモデルというのは言いかえれば、コミュニティによる開発(Community Based Development)である。 企業は「カネ(利益)」をほぼ唯一の行動原理とするが、コミュニティの行動原理というのは実のところよくわからない。少なくともわたしには精密に記すことは難しい。知ったかぶって、さも判ったふりをして書くという愚行はおかさないようにする。 ある程度共通の行動原理は存在するかもしれないが、あえてここではそれをまとめることはしない。 コミュニティによる開発のお作法というのは企業が開発するソフトウェアのお作法と相当ことなるし、それを理解しない事には企業はコミュニティと上手に付き合うことができない。 日本の企業の多くはコミュニティによる開発経験を持たないし、特に大手企業にお勤めの中間管理職でそのような経験を持
ユメのチカラ: Community Based Development
オープンソースソフトウェア(OSS)の力はバザールモデルとして知られるコミュニティによる開発(Community Based Development)だと思う。 OSSの特徴としてフリーなライセンス(利用、変更、再配布の自由など)があげられる事が多いが、それはあくまで必要条件であって、十分条件ではない。ライセンスをフリーにしたからと言って、コミュニティが自然発生するとは限らない。商業ソフトウェアベンダは自社製品をプラットフォームとするために、あの手この手を使ってコミュニティを形成しようとするが、それには相当なコストと時間がかかる。 大雑把にソフトウェアを分類してみる。 最初のカテゴリは、プログラム。これは実行可能なソフトウェアで、趣味で作ったり学校の課題で作ったりする小規模なものとする。規模も小規模でせいぜい大きくても数千〜数万行程度のものである。おもちゃのプログラムに毛がはえた程度のもの
Why Open Source Fails to Fail : 404 Blog Not Found
2007年06月08日13:45 カテゴリOpen Source Why Open Source Fails to Fail これを読んで、なぜオープンソースがうまく行くかがまた少し理解できたような気がした。 Who is to blame? (内田樹の研究室) マニュアルというのは責任範囲・労働内容を明文化することであるからであるが、ミスはある人の「責任範囲」と別の人の「責任範囲」の中間に拡がるあの広大な「グレーゾーン」において発生するものだからである。オープンソースで一番重要なコンセプトってなんだろうか。 無料で使えること?ソースコードが公開されていること? 違う。オープンソースで一番重要なこと、それは責任者が制作者ではなく使用者になっていることなのだ。それを利用して得た結果に対して、制作者が代価を要求することもないが、制作者に被害を賠償してもらうことも出来ないのだ。オープンソースを利
オープンソースコミュニティ運営方法:Geekなぺーじ
Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。 ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。 要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.opencamera.cc/
Home - Make: DIY Projects and Ideas for Makers