エンジニアをやっている限り、OSSの恩恵にあずかりまくりなので何かしらの形で恩返しというか貢献したいって気持ち少なからずあると思う。僕はある。でも、実際OSSを公開とかコントリビュートするのってすごくハードルが高いイメージが強い。 OSSを公開したり、コントリビュートしたりする精神的な敷居をさげるために、どうしたらいいのかなぁって思いまずはガイドラインを作ってみることにした。率先してOSSに取り組んでるなかひこくん (@takanakahiko) にインターンで手伝ってもらったり、Debianのメンテナーをやっている Hideki Yamane さんにレビューしてもらったり、本当に感謝しかない。 https://sites.google.com/gaiax.com/gaiax-oss-guideline 会社の社員としてOSSに取り組むにあたり、あれやこれやとルールや注意事項や手続きやら、
ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」（death march）と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く