GitLabは2011年にスタートしたオープンソースプロジェクトで、2014年に法人化、2021年にNASDAQへと上場し、2023年時点では年間の収益が4億ドル(約588億円)を超えるほどの大企業へと成長しました。主力製品がオープンソースであり、完全リモートワークを行うなど一風変わった特色をもつGitLabがどのように成長していったのかについて、コミュニティの力を伝えるメディア「Community Inc.」がまとめています。 Community Contribution at: GitLab - Community Inc. https://community.inc/deep-dives/contribution-gitlab GitLabはクローズドソースコードをホストするオープンソースプラットフォームで、スタート直後は「単なるGitHubクローン」と言われることもありましたが、設
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
「効率的で信頼できるソフトウェアを誰もが作れる言語」を提唱するプログラミング言語・Rust。その優れたパフォーマンスやプログラムとしての信頼性・生産性の高さなどから、近年非常に人気を集めています。 Rustのようなオープンソースソフトウェア（以下、OSS）の開発を支えているのは、機能開発やドキュメント整備など、プロジェクトに何らかの形で貢献をするコントリビューターたちです。今回はRustのコアコミッターである大櫛佑貴さんとTaKO8Kiさんに、知られざるRust開発の裏側とOSS活動に携わる魅力について聞きました。 * … 取材はリモートにて実施しました。 Rustに触れたきっかけ ――今回のインタビューでは、お二人のコントリビューターとしての活動内容を伺います。まずは、ユーザーとしてRustを書くようになったきっかけを教えてください。 大櫛：Rustとの出会いは2018年頃でした。私がま
少し前に仕事場のローカルに立てている、今や主力でなくなったウェブサーバに久しぶりにアクセスしたら、Wiki が PukiWiki なのに懐かしくなってこれまた久しぶりに公式サイトを見てみた。すると、今年バージョン1.5.4がリリースされており、開発は継続しているのに少し感動した。 かつてはそれこそ雨後の筍のごとく開発されていた Wiki ソフトウェア（エンジン、クローン）だが、Wiki が広義の開発環境の一つに統合されているのもあり、単体のソフトウェアとして今も開発が続いているところはだいぶ少なくなった印象がある。 果たして今も開発が継続しているオープンソースの Wiki ソフトウェアに何があるか、ざっと調べてみた。 具体的には、Wikipedia の Comparison of wiki software に名前があるもので（それくらいの知名度があり）、オープンソース、なおかつ安定最新版
このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu
オープンソースの黎明期において、知的財産（IP）関連での主な敵は、プロプライエタリーなソフトウェアを有する企業からの訴訟だった。こうした企業は、オープンソースプロジェクトが強大な競合となる前にたたきつぶしてしまいたいと考えていたのだ。その最も有名な事例は、Microsoftの支援を受けたSCO GroupがIBMや関連企業を相手取って起こした一連のLinux訴訟だった。SCOの主張は、Linuxの一部のコードがプロプライエタリーなUNIXのコードを盗用しているというものだったが、Linux陣営の企業はこれらの訴訟に勝利し、オープンソースソフトウェア界は平和な時代を迎えることになった。しかしそれはもはや過去の話だ。今日では、パテントトロールたちによってオープンソースソフトウェア開発者が脅かされる事例が増えてきている。 オープンソースはかつてないほどの成功を収めている。Microsoftも過去
オープンソースソフトウエア（OSS）はもはやシステム開発には不可欠なほどに存在感を強めた。ベンダーにとって開発・運営への参加は直接的に売り上げや利益をもたらさなくとも、OSSへの顧客ニーズの反映や受注で大きなアドバンテージを得ることにつながる。 ただ、多くのOSSの運営はボランティアや善意に頼るところが大きい。営利を目的とする企業が足を踏み入れるのはメリットが少ないようにも思えるが、日立製作所はアイデンティティー・アクセス管理のOSSソフトウエア「Keycloak」の開発プロジェクトなどをとりまとめる「メンテナー」に人材を輩出した。無報酬となるこのポジションはどういうもので、日立がメンテナーに人材を輩出した意味合いとは何か。 OSSは公開されたソースコードを自由に改変したり再配布したりできるソフトウエアを指す。利用できる分野もLinuxをはじめとしたOSやJavaScriptやPython
ここ数年で急速にOSSコミュニティが拡大している中国。クラウドネイティブ、スマートフォン前提の開発コミュニティだけに、OSやプログラミング言語といった、これまでの代表的なソフトウェアとは違うOSSが登場してきました。いくつか代表的な分野のOSSを紹介しましょう。 「世界の工場」を形作る、ネットワーク前提の組込みOS アリババ集団のAliOS Things、テンセントのTencent OS Tiny、ファーウェイのHarmony OS Embeddedと、中国テックジャイアントが、それぞれオープンソースで、ネットワーク接続が前提の組込みOSを公開しています。 AliOS Things（Open Source Chinaリポジトリ） Tencent OS Tiny（Open Source Chinaリポジトリ） Open Harmony（Giteeリポジトリ） アリババは、このAliOS Th
クソが！ というわけで、Mapbox GL JSが2.0よりオープンソース・ソフトウェアではなくなりました。 github.com Mapbox SDK for iOSで起きたことがJavascriptでも発生したという感じです。 何が変わるの？ mapbox.accessToken にアクセストークン(public access token)を埋め込まないといけなくなります。 以下のようなコードを試してみましょう。 <script> mapboxgl.accessToken = undefined var map = new mapboxgl.Map({ container: 'map', style: 'https://tile.openstreetmap.jp/styles/osm-bright-ja/style.json', center: [140, 35], zoom: 8 }
最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない（可能性がある） なぜ会社としてOSSをやるのか？ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou
はじめに Github Help Wantedでissueを選ぶ OSSのコントリビュート方法を確認する 実装 既存コードの動作確認 機能実装 プルリクを出す マージされる 最後に はじめに こんにちは。広告技術部のjohnmanjiroです。普段は広告配信のAPIや管理画面を作っています。 今回は最近自分が始めたOSS活動のやり方について紹介しようと思います。 issueを見つけたその日にプルリクを出し、約１週間後にマージされました。 「OSS活動始めたいけど、別に普段使ってる中でバグを見つけたりもしてないし、貢献したい明確なOSSもない、どうしよう🤔」そんなOSS活動未経験者の参考になれば幸いです。 ちなみに自分自身、活動を始めたばかりのペーペーです。 Github Help Wantedでissueを選ぶ OSS活動を始めるにあたって、まずは貢献するissueを選びましょう。iss
厚生労働省の「新型コロナウイルス接触確認アプリ」が公開された。 かねて話題になっていたように、ある程度匿名性を保ったままbluetoothで他のデバイスが近隣に留まったことを認識する方式らしく、割と安心できそうかと思う。 またITMediaの記事によればCOVID-19 Japanという有志によるオープンソースプロジェクトを元にしているそうだ。 ただし、記事を読む限りでは完全にオープンソースプロジェクトそのままというわけではなく「COVID-19 Radar」の技術を核として厚生労働省がベンダーに開発を委託したとある。 そうなると、いくつか気になる点がある。 「COVID-19 Radar」のソースは公開されているからプライバシー等への懸念がある場合にはそれを読んで確認すれば良い、というような意見もあるが、「COVID-19 Radar」と「新型コロナウイルス接触確認アプリ」がその点におい
■ OSSライセンスMeetup Vol.3「知財部門から見たOSSライセンス」へ行ってきた Vol.2が面白かったのでVol.3にも参加してみましたよ。今回は開発者サイドではなく、知財部門の人たちの話を聞く会。スタンスの異なる立場の人たちなので、これはなかなか良い着眼点。ただ、今回の講演者探しは難航したっぽくて、主催者がTwitterなどでつてを探すようすが観測されていましたね。 けっきょく同じ大手IT企業で知財を担当する(バックボーンがやや違う)2人が講演者ということで、バリエーションの乏しい感じになってしまったのは残念か。まぁ、もっぱら開発者だらけのミートアップにわざわざ話しに出かけてきてくれる知財担当者というのは、少ないだろうなぁというのはわかる。……というかですね、自分と同じグループ企業のわりとよく知ってる話を聞かされることになったおれの立場は(笑)。 とはいえこの世界ではわりと
OSSライセンスMeetup Vol.2「実録：GPL違反とその対応を振り返る」参加レポート 2019年2月21日（木）に開催された「OSSライセンスMeetup Vol.2「実録：GPL違反とその対応を振り返る」の参加レポートをお届けします。少しでもMeetupの雰囲気や魅力をお伝えできればと思います。 OSSライセンスMeetupとは その名の通り OSS（Open Source Software）のライセンスに関するテーマを扱うMeetupです。エンジニアに限らないさまざまな人に向けた「OSSライセンス」についての啓蒙や参加者間での知見の共有のための場という、ありそうでなかったMeetupです。 今回はGPLに主な焦点を当て、前半は日本国内でGPL違反事例として語られるプロジェクトで当事者となった会社に在籍していた宮田晃佳さんを迎えて、状況や経緯、解決策、対応後の反響などについて振り
世界を飲み尽くした後のソフトウェアとその保守 あまり Ruby と関係ないことを書く。 先日、epubcheckというツールの最新版である v4.1.1 がリリースされた。 epubcheck は epub をチェックするという、その名の通りの epub validator ツールである。 Web の開発に関わっている方であれば、HTML に対する HTML Lint や Nu HTML Checker、CSS Validator 等は使ったことがある方もいるかもしれない。 それらを合わせた上、さらに EPUB 固有の validation も追加したようなツールである。validation というと比較的賢いツールを想定されるかもしれないが、Ruby で言うと rubocop というよりは ruby コマンドの -c オプションつきの実行に近い。「ダメなやつを弾く」ためのツールとして使わ
https://anond.hatelabo.jp/20180207165151 の増田だ。見覚えあるエントリがタイムラインに現れ、なんで今拡散されているんだと驚いた。 色々ブコメやらツイートやらの反応があったので興味深いと思った反応に対する意見とかを落書きがてら書こうと思う。このエントリも書ききれなかったことを何度か加筆していることは許してほしい。 ブコメよりもTwitterでの反応が多いようで、以下の内容はエゴサした中から拾ってる物が多い。(https://twitter.com/search?f=tweets&vertical=default&q=MMD%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%AE3DCG%E3%82%92%E7%A0%B4%E5%A3%8A%E3%81%97%E3%81%A6%E3%81%97%E3%81%BE%E3%81%A3%E3%8
クラウドベンダなどによるサービス利用を制限したMongoDBの新ライセンス「SSPL」を理由にDebian、Fedora、RHELがMongoDBの配布取りやめを表明 MongoDBがAWSなど大手クラウドベンダによるサービス化に反発し、商用サービス化を制限する新ライセンスに変更したことは以前の記事で紹介しました。 参考：Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 新ライセンスはAGPLをベースにMongoDBが独自に作成したもので、「Server Side Public License」（以下、SSPL）と呼ばれています。 SSPLではサービス提供元もソースコード公開を義務化 SSPLでは、MongoDBをサービスとして提供する場合、サービス提供元が独自に変更した部分を含めて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
