まつもとゆきひろ氏が“幻のPerl6”から学んだ教訓 「OSSの最大の敵」と「セカンドシステムの危険性」
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。3回目は、「Second System Syndrome」について。前回はこちら。 退屈は最大の敵 まつもとゆきひろ氏：次はPerlですね。ここまでですでに4回ぐらいPerlの話題が出てきています。なぜかというと、私はPerlが大好きなんですね。実は、Perlが大好きなんですが、Perlのプログラミングは大好きじゃないんですね。あと、Perlのソースコードも大好きじゃないんですね
OSSで世界と戦うために - ゆーすけべー日記
「日本人」を理由にしたくないし、「コードは全世界共通語」なのは分かっているけど、自分が日本人で日本語を母国語としていることはOSSにおいて不利になる。 この2年間のHonoの開発をしてきた経験で分かったことだ。 そこに目を瞑ってはいけないし、自覚することで世界と戦えるかもしれない。今回はそのことについて書こうと思う。 8k 現在、HonoのGitHubスター数は8,000を超えた。 これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。 数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。 なぜ「戦う」のか なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 ま
OSSすぐ死ぬ - kmuto’s blog
（結論はなく、ダラダラ昔話を書いただけ。） サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
OSSをベースにしたサービス提供の難しさ - knqyf263's blog
背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社（Aqua Security）ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し
オープンソースにコントリビュートする方法
オープンソースにコントリビュートする方法 オープンソースにコントリビュートしたいですか？このガイドではオープンソースへのコントリビュートの方法を、初めての人だけでなく熟練の方にも紹介します。
技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog
僕は2019年4月から技術ブログを始めているが、2ヶ月目くらいから「はてなブックマークでホッテントリを取るための情報収集」を心がけるようになった。その影響もあって何記事かはてなブックマークでホッテントリ入りすることもできたので、これから技術ブログなどでアウトプットを始める人の役に立てばいいなぁと思ってブログでまとめることにした。技術ブログを書く人でなくても情報収集先として参考になる部分はあると思う。 はじめに GitHub Trending プログラミング言語はPythonとJavaScriptとTypeScriptを重点的に見る プログラミング言語以外にもUnknown languagesをチェックする Advanced searchで直近の日付に絞り込む GitHub Trendingを参考にしたブログ記事 Product Hunt Product Huntを参考にしたブログ記事 Re
後輩がGitHub採用疲れの話をしてくれた
たしか、採用面接の方針を話していて、それぞれの採用に関する価値観を聞いたときのこと。ある後輩が「GitHub採用つらい」という話をしてくれました。聞いてみると、たしかにすんなり納得できない部分もある気がします。 GitHub採用とは 最近のエンジニア採用では、応募者のGitHubアカウント情報が流れてくるようになりました。同様に、LinkedInアカウントも流れてきますね。書いてきたコードや経験がオープンになってきたということなのでしょう。 情報がオープンになり、人材の流動性が高まるのは、個人的にはうれしいことです。なぜなら、いろんなことをいろんな場所で経験できることに魅力を感じるからです。一つの会社でいろいろできるのも魅力的ですが、土台となる文化が同じだと、体験に差が生まれそうですし。また、景気に影響を受けるとはいえ、クビになっても仕事を見つけやすくなるかもしれない。 一方で、マネージャ
オープンソースライセンス比較用早見表 - Google ドライブ
このファイルを使用中のユーザーが多すぎるため、一部のツールを利用できない場合があります。再試行詳細閉じる オープンソースライセンス比較用早見表 : Sheet1ABCDEFGHIJKLMN1ライセンスと著作権の表示変更した旨を示すことソースコードの開示ライブラリとして使用すること商用利用改変配布派生物に別のライセンスを課す特許の利用個人利用作者に責任を求めること商標の利用注記2No License必須可能禁止禁止禁止可能GitHubで公開したソフトウェアにライセンスを付記しなかった場合の条件3GPL v2.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし4GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし5Affero GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし6Artistic GPL 2.0必須必須必須必須でない可能可
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
Dockerで即実行できる、社内・自宅向けオープンソースWebアプリ - Qiita
デスクトップアプリケーションに比べるとWebアプリケーションの導入は面倒だが、DockerやVagrantの登場によって敷居が低くなっている。誰かがDockerHubへ使いやすいイメージを公開してくれたり、Webアプリの開発元がDockerfileを公式に提供しているケースが増えてきているためだ。 この記事では、筆者が実際に使用したことのあるWebアプリの一覧と、docker-composeの設定ファイル(またはDockerfile)をまとめる。既にDocker環境が整備されている状態であれば、YAMLファイルやDockerfileをコピペしてdocker-compose up -dするだけで自動的にWebアプリケーションが起動する。(もし動かなかったらスミマセン) セキュリティとかは考えていないので、LAN内のみでの使用を想定 記載の設定では、永続化データはDockerが動作しているマシ
自分の零細OSSで疲弊しないために - 思ったこと
自分のOSSをメンテしてもらうために出来そうなことメモ 開発ドキュメントを整備 CONTRIBUTING.mdを置く CHANGELOG.mdにコントリビューターの名前を書く Issueにpr_welcome/patch_welcomeなどのラベルを活用する このへんまでやっておけば、 issueにwelcome label付けて放置で大丈夫かなぁと思う。
ドメイン変更のお知らせ
OSS Radar Scope ® のページは移転しました。 新しいページは https://ossradar.scsk.jp になります。 お手数をおかけしますが、「お気に入り」の変更をお願いします。 なお、このページは、10秒後に新しいページに自動転送されます。
新日鉄ソリューションズがHTML5スマホアプリ開発基盤をOSSとして公開へ
写真●新日鉄ソリューションズがOSSとして公開するスマートフォン／タブレット向けアプリケーション開発フレームワーク「hifive」の構成 新日鉄ソリューションズは2012年4月11日、「スマートデバイスソリューションセンター」を設置したと発表した。また同社が開発してきたHTML5準拠のスマートフォン／タブレット向けアプリケーション開発フレームワークをオープンソースソフトウエア（OSS）として公開することも明らかにした。 新日鉄ソリューションズでは、スマートデバイスの開発フレームワークやMDM（モバイルデバイス管理）ツールを提供してきた。「企業情報システムへのスマートデバイス本格導入時代が到来した」ことから、2012年4月1日付けで専門組織を設置したとしている。 開発フレームワークは同社のシステム研究開発センターで開発しているもの。名称は「hifive」。スマートデバイス固有の開発知識を必要
【レビュー】開発前に読んでおきたいOSSライセンスの説明と比較 | エンタープライズ | マイコミジャーナル
情報処理推進機構 情報処理推進機構(IPA)は5月31日、GPL以外の主要なオープンソースソフトウェアライセンスについて、そのライセンスの特徴、プロジェクトにおける利用状況とそのライセンス戦略、ライセンスに関する係争などについて調査した結果を報告書として公開した。GPLv3に関してはすでに別の解説書を提出しているため、同報告書では軽く説明する程度にとどめている。 OSSライセンスの比較、利用動向および係争に関する調査 (報告書PDF) GNU GPLv3 逐条解説書 (解説書PDF) 報告書ではまず、数あるOSSライセンスを「コピーレフト」の観点から3種類に分類。次の2つの条件にどのように当てはまるかで分類している。(a)(b)ともにある場合はコピーレフト型、(a)のみなら準コピーレフト型、どちらも該当しないなら非コピーレフト型となる。 (a) ソースコードを改変した場合に、改変部分のソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux Foundation、「オープンコンプライアンスプログラム」を開始 | The Linux Foundation