My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Someone from our last houston.rb meetup asked me about contributing to open source software, so I wrote an email that talks about the little things I do. I thought others might find it helpful, so I'm also posting the email here. It is below:

It occurred to me I totally ignored your question about open source, so apologies for that, and here I go attempting to rectify it.

Here's basically what I do:
  • Any time I'm using an open source project I haven't used before (or using a new-to-me feature of it), I am reading the docs about it as I implement whatever it is I'm using it for. If I find something unclear, or something unaddressed, I fork the project, improve the docs to mention it, and send a pull request. Examples: How to use init.d services with rvm, apartment code sample
  • Any time I come across a bug, I don't stop at finding a workaround for my project -- I look to see if it is caused by something in the open source project, and if so, make the fix and send it to them. Examples: Slow MySQL count in composite_primary_keys, Stretch background in ruby-prof output
  • Any time I am using an open source project and have need of functionality that could conceivably be provided by the project, if it's general enough I think it would be of use to others, I'll implement it in that project instead of mine, and send a pull request. Depending on the project, I might ask them if they'd be interested first. Examples: Rails table migration generator, Spree refactoring for reuse
Now, I don't tend to contribute a lot to any one project. If you're more interested in that, I would guess you ought to do something similar, but focus it all in that one or two projects that really excite you. Go through the issue tracker, see if you can reproduce and fix the bugs people are reporting (or leave a comment telling them how to fix there problem if it's not really a bug), etc.

For example, Steve Klabnik wrote up a how-to contribute to Rails, which talks a little more on the human side of things, as opposed to just the project contribution guidelines. I think his blog post can be generalized to other projects as well, so it's worth a read to get an idea of how to go about interacting with bigger open source projects when you want to contribute.

Lots of projects will mention their own contribution guidelines though, so make sure you read them and follow them!

Hope that helps,
Sam

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner