Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
79 lines (66 sloc) 3.75 KB

Open Source

Critical learning

Validation

You are an everyday open source user when you can:

  • Evaluate a project based on quality of code, tests, documentation.
  • Evaluate a project based on responsiveness of maintainers to developers' questions and feature requests.
  • Evaluate a project based on regularity of releases.
  • Evaluate a project based on the appropriateness of its license for your needs.
  • Evaluate a project by downloading and trying it.
  • Search issues for a similar problem you're having.
  • Comment with additional data on issues that you're also having.
  • Submit new issues with good environment (Ruby version, OS, etc.) info, error messages, and backtraces so the maintainer can quickly replicate it.

You are an everyday open source contributor when you can:

  • Get annoyed by a defect or missing feature.
  • Find the source code.
  • Create a copy of the source ("fork" on Github).
  • Check out (git clone) the source.
  • Poke around the source in your editor and shell (grep).
  • Read the contribution guidelines.
  • Write a failing test in the style of the project's test suite.
  • Write code to make the test pass in the style of the project's codebase.
  • Make sure the entire test suite passes.
  • Create a patch (push to your fork on Github).
  • Submit a patch ("pull request" on Github).
  • If it exists, email the project's mailing list asking for feedback.

You are an everyday open source maintainer when you can:

  • Apply an appropriate license to your project.
  • Document a clear public API.
  • Document where issues are managed, such as Github Issues.
  • Evaluate pull requests and provide kind, intelligent feedback.
  • Provide a clear place for questions, such as Stack Overflow. Only provide a Google Group mailing list if you're ready to support it.
  • Provide your code in easily accessible form (Rubygems, GitHub).
  • Select or reject open source software based on its license.
  • Use major, minor, and patch version numbers (Semantic Versioning).

Ongoing reference

Read selected chapters from "The Architecture of Open Source Applications":

Something went wrong with that request. Please try again.