RedisやMongoDB、Kafka、Elasticsearchなどのオープンソースソフトウェアの開発元企業が、AWSなど大手クラウドベンダがそのオープンソースを用いたマネージドサービスを提供して大きな利益を上げていることに反発して、ライセンスを変更するなどで商用サービス化を制限する動きがあることは、今年の1月の記事で紹介しました。 Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 この動きに対してGoogleは4月、Google Cloudにオープンソースベンダによるマネージドサービスを統合すると発表し、彼らとの戦略的提携という姿勢を打ち出しました。 ［速報］Google、大手クラウドに不満を表明していたMongoDB、RedisらOSSベンダと戦略的提携。Google Clou
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは。あるいは、はじめまして。二度目ましての方も、おいででしょうかね。 オープンソース（OSS）の利活用コンサルをしています、渡邊歩です。好きなOSSライセンスは、Beerware Licenseです。 今回は本業のテーマで、「OSS管理のベストプラクティス」の必須要素である「組織」、「ポリシー」、「（正しい）知識」、「ツール」について書かせていただこうと思います。 OSSコンプライアンスって何から始めればいいの？OSS管理ツールってたくさんあるけどそれぞれどう違うの？というような方のお役に立てれば幸いです。 組織（Op
エンジニアをやっている限り、OSSの恩恵にあずかりまくりなので何かしらの形で恩返しというか貢献したいって気持ち少なからずあると思う。僕はある。でも、実際OSSを公開とかコントリビュートするのってすごくハードルが高いイメージが強い。 OSSを公開したり、コントリビュートしたりする精神的な敷居をさげるために、どうしたらいいのかなぁって思いまずはガイドラインを作ってみることにした。率先してOSSに取り組んでるなかひこくん (@takanakahiko) にインターンで手伝ってもらったり、Debianのメンテナーをやっている Hideki Yamane さんにレビューしてもらったり、本当に感謝しかない。 https://sites.google.com/gaiax.com/gaiax-oss-guideline 会社の社員としてOSSに取り組むにあたり、あれやこれやとルールや注意事項や手続きやら、
こんにちは！LIFULLのSoftware Engineer in Testグループ（通称：SETグループ）のヒキモチです。 我々SETグループは先日、自動システムテストツール「Bucky」のOSS化を行いました！ github.com github.com Buckyは元々社内の自動テストツールとして使われていたものなので、 それをOSSとして公開するためには色々と苦労がありました。 この記事ではその苦労やそこで得た知見などを共有できたらと思います。 目次 そもそもなぜOSS化するのか OSS化までの道のり 1. リファクタリング 2. システムテスト導入 3. RubyGems.orgへの登録 公開後のお話 使い手のことを考えられていなかった 問題 解決策１：ハンズオン資料を作成 解決策２：READMEの構成を変更 ruby version gem release 自動化 最後に そも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
