GitHub Sponsorsの募集を始めてから2年が経ったので振り返る
この記事は、GitHub Sponsorsを募集開始してから、約2年経つのでGitHub Sponsorsについて振り返った記事です。 この記事では、GitHub Sponsorsを始めた理由、Tierの設計、やってみた結果と感謝、やったことによる変化、これからやる方へのアドバイスなどを書いています。 GitHub Sponsorsを始めた理由 2019年10月からGitHub Sponsorsのページを公開して、スポンサーの募集を開始しました。 GitHub Sponsorの募集ページを公開しました。https://t.co/YpSPfMPxjU#Promise本 や #jsprimer を書いたり、textlintを作ったり色々OSSを作ってます。 後は https://t.co/CXy3hOXJ8q を8年ぐらい毎週更新してたりもします。@jser_info Sponsorとかもある
オープンソース開発者として力尽きないための基本戦略
オープンソース開発者として力尽きないための基本戦略 ・愛情を注げるもの以外は作らない ・世界で一番と確信できるまでプロダクトを磨く ・ユーザーの声を真摯に受け止めつつも、誹謗中傷は「読まない」 ・ユーザーから開発を支援いただける仕組みを構築する ・自分だけの応援キャラクターを作る — hiyohiyo (@openlibsys) April 25, 2021 引退されていった諸先輩方に想いを馳せながら、オープンソース開発者として力尽きないために自分が心がけていることをまとめてみました。すでに個人開発をされている方、個人開発に興味のある方の参考になれば幸いです。 1. 愛情を注げるもの以外は作らない 個人開発の魅力は何といっても、自分の作りたいものを自分のペースで開発できることです。やりくりして捻出した貴重な開発時間を「愛情を注ぐことすらできないプロダクト」に費やすことに何の意味があるのでし
曲者に権限が渡らない OSS 権限移譲プロトコルが難しい - Qiita
曲者に OSS の権限が付与され、悪意のあるコードを埋め込まるような事件をおこさない OSS 権限移譲フローを考えてみました。 TL;DR 基本的に OSS の権限譲渡を 選ばない方 が安全といえそうです。なぜなら、次のように権限譲渡の安全性を担保することはとても難しく、かつ高価につくからです。 代わりに、プロジェクトを停止するか、信頼できる人物に fork を依頼する（現状の project は archive）のが、責任回避の意味で有効だと思われます。 背景 「2018/11/27に判明したnpmパッケージ乗っ取りについて」が世間を騒がせていますが、個人的に驚いたのは件の package の元々の作者である方への非難の声が多いことでした。 個人的には、この事件の根本は npm 側の機能不足が問題という認識（postinstall フックなどの自動的なフックによって操作ユーザーの権限で任
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
