GitHub、“Open Source Guides”の日本語訳を公開 ～OSSコミュニティのベストプラクティスを集約／オープンソース入門者だけでなく、すでに貢献をしている開発者にも
GitHubがオープンソースに関する調査報告を公開。「ドキュメントは非常に重要だが見過ごされやすい」「ソフトウェア選択時のデフォルトはオープンソースに」など
GitHubがオープンソースに関する調査報告を公開。「ドキュメントは非常に重要だが見過ごされやすい」「ソフトウェア選択時のデフォルトはオープンソースに」など 調査対象はGitHub.comで活動するユーザーからランダムに選択した5500人と、ほかのプラットフォームで活動するコミュニティから非ランダムに選択した500人。調査はアンケートによって行われました。 調査の結果得られた主な知見は、以下のようにまとめられています。 ドキュメントは非常に重要だがよく見過ごされやすい。コミュニティへのアクセスのしやすさや参加のしやすさにつながる役割を持つ。 アクティブなプロジェクト活動の結果においてネガティブなやりとりはめったにないが、目立つ。 オープンソースは世の中で広く使われているが、コントリビュータについてはまだその幅広い利用者を反映していない。 オープンソースの利用や貢献はしばしば仕事につながる。
ChakraCore GitHub repository is now open
In a December 2015 talk at JSConf US, we announced that we would be open-sourcing the key components of the Chakra JavaScript engine that powers Microsoft Edge. Today, we are excited to share with you that we’ve just made the sources for ChakraCore available under the MIT License at the ChakraCore GitHub repository. Going forward, we’ll be developing the key components of Chakra in the open. https
オープンソースプロジェクトで上手いことやってくための10の方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 何も考えずに書き始めたけど10の方法って書いちゃった。 いくつになるかはわかりません。 一般的なプロジェクト運用でもある程度同じ方法論でイケると思います。 なお、筆者であるvvakameはDefinitelyTypedのメンテナをしています。 そのため、これから先の文章について、TypeScriptやJavaScript関係固有の事象が含まれていると思います。 書かれている内容について、contributeする側、される側、両側へのアドバイスを書きます。 ちなみに、わかめ的にはTOMOYO Linuxに学ぶ説得術とかはすごい参考になりま
英語圏のオープンソースプロジェクトにおける翻訳ドキュメントの問題点とその解決のための一方策（仕切り直し版）
(追記：2014-2-26) 自動翻訳機能を追加しました。 翻訳ドキュメント作成支援ツールTogglateで翻訳要らず？ 少し前にオープンソースプロジェクトにおける翻訳ドキュメントの作成における問題点とその解決案について記事を書いたんだけど、要は翻訳ドキュメント内に原文をそのセンテンスごとに埋め込んで、原文と訳文の対応付けを保証しつつこれをトグル表示させることで原文が翻訳ドキュメントの表示上の邪魔にならないようにするといったもので、そのときに併せてこれをスクリプトで実現したtogglateというツールも作ってそのツールとgithub向けmarkdownのパーサーであるgithub-markdownを使ってmarkdownによるオリジナルドキュメントからhtmlによる翻訳ドキュメントを生成するプロセスについても解説したんだ。 英語圏のオープンソースプロジェクトにおける翻訳ドキュメントの問題点
GitHub 上で公開されているソースコードの半分はライセンス的に問題あり | スラド オープンソース
Githubをざっと調べると、 プロジェクトの半分はライセンス情報がない。 30%はソース内に書いてる。 20%は明確なライセンスファイルがある。 ベルヌ条約加盟国では何もしなくても著作権が発生し、コピーして使ったり改良したりするのは著作権侵害になる。 著作権法ではデフォルトで著作物の権利は著作者が保有するので、ライセンスの無いコードは法律上共有できない。 ライセンスの無いプロジェクト内のコードを使用すると、将来的に著作権侵害の訴訟になる可能性がある。 だからオープンソースライセンスが考えられた。 （訳注：オープンソースライセンスは著作者が著作権を保有した上で、著作者の権限で利用者にコードを共有する権利を与える。） Githubのプロジェクトをforkする人は、そのコードを使う権利があると思ってるが、そうじゃない pullリクエストをacceptする人は、そのコードを使う権利があると思って
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
OSS と GitHub