オープンソースソフトウエア(OSS)をいかに使いこなすか。トヨタ自動車、日立製作所という日本を代表する2社がいま、そろって重視する経営テーマだ。設計図にあたるソースコードが公開されたOSSは無償で利用、改変できる。開発プロジェクトごとにコミュニティーがあり、一流エンジニアも集う。「多くの人が同じ問題に取り組み革新的な成果を生む。安くて速いだけではない」。世界のコミュニティーを後押しするNPO
TL;DR Pythonの型チェッカーを一人で作っていたらそれが仕事になりました。 私は(大学院生として物理学を専攻する傍ら)以前よりプログラミング言語やその周辺ツールのデザイン・実装に興味があり、趣味で開発したプロジェクトをOSSで公開するなどしていました。 ErgはPython APIと互換性を持つトランスパイル型の静的型付け言語で、pylyzerはこれの型検査器を流用したPython向け型チェッカーです。 ありがたいことに両方とも結構反響を受けて、公開から数年経っても未だにissueなど報告をいただいております。これはもう少し大きな話にできるのではないかと考え、Ergの開発の方で2023年度の未踏IT人材発掘・育成事業に応募し、運よく採択され、スーパークリエータにまで認定していただきました。 これだけでもかなりの僥倖ですが、それだけではなく、今年の3月からcontract softw
さくらインターネット 便利なOSSを多数開発。“隙間家具職人”の開発モットーとは? 藤原俊一郎(fujiwara)インタビュー【前編】 # ガバメントクラウド# エンジニア# 社員インタビュー Welcome Talk「ようこそ、さくらへ!」 2025年2月28日 社会を支えるパブリッククラウドを一緒に作りませんか? >>さくらインターネットの経験者採用情報を見る 社員インタビュー記事や求人情報をお届け! >>さくマガのメールマガジンに登録する さくらインターネットではエンジニアの採用を積極的におこなっています。今回は、2025年2月に入社したクラウド事業本部の藤原俊一郎にインタビューを実施しました。インタビュアーは、一足早くさくらインターネットへ入社したクラウド事業本部 荒木靖宏。前編となる今回は、これまでのキャリアのほか、興味のある技術や開発のスタンスなどを聞きました。 藤原 俊一郎(
物騒な世の中です。皆様お気をつけください。 3行でまとめ 自作の OSS、fujiwara/apprun-cli のマルウェア入り偽物を作られて GitHub で公開されました 偽物には大量の新規アカウントがスターを付けていたため、検索でオリジナルのものより上位に表示される状態でした GitHub に通報したところ、偽物を作ったアカウントはbanされたようです 経緯 2024年末に、さくらのAppRun用デプロイツール apprun-cli という OSS を公開しました。 github.com 2025年2月10日 12時過ぎのこと、謎の人物が X で apprun-cli を宣伝しているのを見つけました。 どう見ても自分の物と同じ(コピー)なのですが、妙にスターが多い。リポジトリをのぞいてみると、fork ではなくコードがすべて commit 履歴を引き継がない状態でコピーされ、スター
OSS活動を「技術的なスキルを活かしてコミュニティに貢献するもの」だと捉えている人は多いかもしれません。そのため、「自分のような未熟なエンジニアがOSSに関わっていいのだろうか」「他の人の役に立てる自信がない」と悩み、なかなか一歩を踏み出せない方もいるのではないでしょうか。 Laravelのスペシャリストであり、OSSへのコントリビューションも行う武田憲太郎さんは、「OSS活動を崇高なものだと考えなくていい」と語ります。そんな武田さん自身の活動は、「楽をしたい」という理由からスタートしたのです。 コントリビューションの始まりはTypeScriptから ――今回のインタビューでは、武田さんのこれまでのOSS活動の歩みについてお話を伺います。最初にコントリビューションしたOSSのプロジェクトは何でしたか? DefinitelyTypedという、TypeScriptの型定義ファイルを提供するリポ
この記事は fujiwara-ware advent calendar 2024 の25日目です。 "fujiwara-ware" は、私 fujiwara が作ったOSSのツールやライブラリの総称です。このアドベントカレンダーでは多数ある fujiwara-ware から毎日1つずつ、合計23個の OSS を紹介してきました。 どれも小物のツール、サーバー、ライブラリなのですが、自分がここ10数年間開発や運用をしてきた中であったら便利だなと思うものを OSS として制作し、公開してきました。今回紹介したのは、日々の業務において本番で実用されているものばかりです。これらの中で、皆さんの開発や運用のお役に立てるものがあれば幸いです。 気に入ったものがあれば、ぜひ GitHub でスター🌟をお願いします。また、GitHub Supporter に登録していただけると開発やメンテナンスの励みに
Someone who develops OSS for fun. 「趣味でOSSをやっている者だ」とは 「趣味でOSSをやっている者だ」は、OSS作家の @songmu がゲストを交えながら趣味や仕事についての雑談を不定期にお届けするポッドキャスト番組です。感想のTweetは#oss4funをご利用ください。番組への感想・リクエスト・ご連絡はこちらから https://oss4.fun/voice Subscribe Episodes 81: OSSを新たに作るか貢献するか (hokaccha) 2026-04-10 Adventar開発者のhokacchaさんをゲストに迎え、Ubie社でのNode.jsバックエンド開発、Adventarのこれまで、ハーネスエンジニアリング、AIとエンジニアリング・OSSの変化などについてお話しました 80: インターネット黎明期の憧憬と起業、そしてEm
企業がソフトウェアビジネスを持続的に行えることと、ソフトウェアのソースコードを公開することの両立を実現するための新しいライセンスへの取り組みとして「Fair Source」が登場しました。 意訳すると、ソースコードが公開され、開発者のビジネスを守るための最小限の制約がありつつもコードの利用や変更、再配布が可能で、計画的に一定期間後にオープンソースとなるもの、と言えるでしょうか。 具体的なライセンスとしては「Functional Source License (FSL)」が推奨されているのに加えて、「Fair Core License」「Business Source License (BSL)」が該当するとされています。 Fair Sourceの目的とは 公式Webサイトでは、Fair Sourceの目的が次のように説明されています。 The purpose of Fair Source
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
OSPN Press Open Source People Network (オープンソースカンファレンス事務局)から最新の開催情報などを発信! RSS OSSマスコットキャラクター大集合! (ぬいぐるみ編) 12/22 OSPN Press編集部OSC News, コラム 3 Comments Tweet 世界中にはたくさんのオープンソースコミュニティがあるように、それぞれの コミュニティにも様々なマスコットキャラがいるようです。 Linuxのマスコット、ペンギンの「tux(タックス)」は有名ですが、オープンソ ースカンファレンスの展示ブースでは、他にもたくさんのマスコットが活躍し ている姿を目にすることができます。今回は、編集部にいる、オープンソース のマスコットに焦点を当ててご紹介したいと思います! —————————————————————————————- ■フォクすけ:Mozi
これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ
yusukebe さんの OSSで世界と戦うために を読んで感銘を受けた。 hono の快進撃もさることながら、OSSで日本のコミュニティの外にリーチしたり、 GitHubスター数を伸ばしたりみたいな話は、 自分も10年くらい挑戦し続けているけどあんまり表に出てこない気がするネタなので興奮した。 僕はいくつかの点で上記の記事とは違う方法でOSSで世界と戦っているのだが、 その中でうまく行っているものや、良くないと思っているものなどについて紹介したい。 GitHubのスター数 OSSを始めたばかりの学生時代、GitHubのスターへの執着がもはや煩悩の域であり、 集めたスターの数を合計するCLIツールを作ったり、 同じ計算方法でランキングを作るWebサイトを作ったりした。 このサイトによると、僕の今のスター数は9000を超えている。 自作したOSSの中では、スター数が1600くらいのものが2つ
サーバーサイドからインフラ領域を中心としたWebエンジニアとして、リードエンジニアからプロダクトマネージャー、CTOと、順調にマネジメントの階段を上がってきた松木雅幸(Songmu)さん。その後、再びプレイヤーとして転職し、現在またマネジメントに取り組んでいます。この螺旋(らせん)のキャリアと呼ぶ働き方の変遷と、それを支えるOSSへの取り組み方について寄稿いただきました。 ▲ベストスピーカーを獲得したYAPC::Tokyo 2019での登壇(写真提供:Japan Perl Association) 私は、小粒ながら多くのOSSを開発してきました。他にも技術的な情報発信や、ISUCONでの優勝経験、エンジニア向けSaaSのプロダクトマネージャーやCTOといった経歴があるため、技術力でキャリアを築いてきた人間だと思われがちです。しかし実は、エンジニアの中では相対的に高めなヒューマンスキルを武器
(結論はなく、ダラダラ昔話を書いただけ。) サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア(OSS)を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
2006年からほぼ毎年、日本で開催されているオブジェクト指向スクリプト言語Rubyに関するイベント「RubyKaigi」。今年は長野県松本市にある「まつもと市民芸術館」で5月11日〜13日に開催され、参加者1,200人を超える盛況のイベントとなりました。株式会社Algoageのエンジニアである石塚大策と纐纈優樹は「RubyKaigi」に参加し、多くの学びがあったといいます。 今回は石塚と纐纈に加え、Algoageでスクラムマスターを務め2017年〜2019年のオーガナイザーでもあった日高尚美、第1回の「RubyKaigi 2006」から運営に携わる角谷信太郎さん*、「RubyKaigi 2015」からチーフオーガナイザーを務める松田明さんにインタビュー。「RubyKaigi 2023」の感想や参加する意義などを語り合いました。 *…角谷さんは、株式会社Algoageでプロダクトチームのアジ
JSONを操作するコマンドラインツールであるjqは、これまでオリジナル作者であるStephen Dolan氏 (@stedolan)のリポジトリ(github.com/stedolan/jq)で管理されていました。 メンテナンスはNico Williams氏 (@nicowilliams)とWilliam Langford氏 (@wtlangford)の二名が行なっていましたが、近年は活動が減っておりメンテナンスが滞っていることが度々指摘されていました。 最新のリリースは2018年11月に行われた1.6であり、その後に様々なバグ修正やパフォーマンス改善、新機能の実装が行われているのにリリースされておらず、またissueやPRも放置されがちになっていました。 さらにCI (AppVeyor)は常に落ちるので、簡単なドキュメント修正でもCIが通らず苦情が来る、数か月放置されたPRは作った人が諦
1行で カジュアルな気持ちでk8sの翻訳に関わり始めたよ。 背景 YAPC KYOTO 2023はYouTubeで視聴していて、Linux Conferenceの主催側立場だったりした頃を思い出したり、Debian ConferenceやRuby会議も楽しかったなーなどと感慨にふけっていた(今年のRuby会議はちょっと行きたいなと思ったんだけど、業務とつなげるのが現状では難しそうなのもあって見送り)。 yapcjapan.org 発表はどれも印象深かったのだけれども、最後のLTで@nasa9084さんの「Kubernetesの翻訳協力者募集!」を聞いて「Kubernetes使える人は英語で特段問題なさそうだなぁ」と感想を呟いたところ、@nasa9084さんに拾っていただいて反応をもらった。 speakerdeck.com そもそも翻訳をできる人は日本語のドキュメントを必要としてないので、コ
追記: 2022年1月11日 2:29 JSTにDoS脆弱性としてセキュリティアドバイザーが出されて、悪意あるバージョン(1.4.1や1.4.2)はnpmからunpublishされ、npmの最新は安全なバージョンである1.4.0へと変更されました。 Infinite loop causing Denial of Service in colors · GHSA-5rqg-jm4f-cqx7 · GitHub Advisory Database 2022-01-08 に colors というnpmパッケージにDoS攻撃のコードが含まれたバージョンが1.4.44-liberty-2として公開されました。 GitHub: https://github.com/Marak/colors.js npm: https://www.npmjs.com/package/colors 問題についてのIssu
「公式ドキュメントを読め」というのが急に話題になっていたので自分なりに整理してみました。 注意: そんなに真面目に推敲していません。フィーリングで書いているので実態に即してない部分もあるかも…… 公式ドキュメントとは何か あなたが使おうとしている道具 (ライブラリ、フレームワーク、プログラミング言語、ミドルウェア、コマンドラインツール、etc.)[1] は必ず誰かによって作られています。ある程度成熟した道具であれば通常、その作った人・組織自身によって公開されているドキュメントがあるはずです。これが公式ドキュメントです。 公式ドキュメントは、OSSにおいてはソースコードと双璧をなす最も信頼できる資料のひとつです。ソースコードが非公開の場合は通常、公式ドキュメントが最も信頼できる資料でしょう。 (以降はOSSを主に想定して説明します) たとえば…… Python のソースコードはGitHub上
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く