Published on

My presentation for SouthEast LinuxFest 2011.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. How Can I Contribute to Open Source?Dru LavigneCommunity Manager, PC-BSD ProjectSELF 2011
  2. 2. This presentation will discuss:Some reasons why YOU should get involvedTips for both contributors and projects onwhat a new contributor can do, finding acommunity (and getting found), gettingstarted with contributions, andovercoming/reducing barriers tocontributions
  3. 3. Why get Involved? Why me?Why not you?Theres tons of stuff to do and not enoughpeople to do it.Existing contributors cant sustain forever(marriage, kids, crazy day job).Its lots of fun! Really!
  4. 4. Benefits: ExperienceAdd to your experience portfolio (and yourresume).Learn how to use industry tools in large,collaborative, non-lab environments.Learn hard and soft skills.Learn from others in your spare time.
  5. 5. Benefits: NetworkingMeet people from all over the world with ashared interest.Benefit from the experience of othercommunity members (some who arefamous and have written cool stuff).If youre thinking about landing a job, itreally is about "who you know".
  6. 6. Benefits: RecognitionIt is possible to build a name for yourselfand become an authority on topic XYZ.One way to break the glass ceiling as youbecome known for what you do, not whatyou look like.Savvy employers Google potential hires—will they find you?
  7. 7. The better the “fit” with a community, thebetter the benefits.Making a good fit takes work on both sides:the community and the contributor.Definitely a 2-way street.All of the following tips can be looked at astwo sides of a coin: one side is what thecontributor should be looking for and oneside is what the project should be providing.
  8. 8. When finding a community, a little researchin the beginning may save you wasted timelater: create a project short list.Look for opportunities that match yourinterests.A technical fit is not always the best-fit.Shop around and dont feel the need to stay(or give up entirely) if the fit isnt workingout.
  9. 9. Code ContributionsAs a contributor:What languages do you know and/or areinterested in learning? (try searching bylanguage at or version control systems (e.g. git, cvs,svn) are you familiar with, if any?Do you already know people associatedwith a particular project or have a project inmind?
  10. 10. Code ContributionsAs a contributor:Lurk on the development teamscommunication channels: e.g. mailing list,IRC channel, forum.Become familiar with the projects bugtracking system.Submit patches.If eligible, apply for GSoC.
  11. 11. Code ContributionsIs there a bugs database? Any limitationson who can submit bugs?Is there a published style guide?Are there opportunities to be mentored bymore senior members?Are there regular bug or code sprints?developer summits at conferences? whocan participate? are people or docsavailable to guide new attendees?
  12. 12. QA ContributionsAs a contributor:Download and install testing, beta, or RCversions.Spend some time going through thatsoftwares capabilities (e.g. screens,switches).Carefully record any errors and what youdid that produced the error and report yourfindings.
  13. 13. QA ContributionsAs a project:Is there a published release schedule? Areannouncements made when beta or RCversions become available?Is there a testing mailing list or a bugtracking system for testing feedback? Doesanyone respond to feedback?Are instructions available to guide users onhow to submit useful feedback?
  14. 14. Doc ContributionsDoes the project have a documentationteam?Does it have any documentation?How steep is the learning curve for the toolsused to manage documentation?If steep, are their guidelines on how to usethe tools or opportunities to train newcontributors?
  15. 15. Doc ContributionsIf not steep (e.g. wiki), what is the accountcreation process, is there someone wholooks at changes, is there a process for“publishing” in other formats to matchsoftware release?How open is the project to publishing orlinking to technical blogs, how-tos,interviews, articles, whitepapers, etc.?Is there a contact person for interviews,articles?
  16. 16. Localization/TranslationsIs the software suited to localization (e.g.has menus)? How active are the translationteams? What languages have beentranslated?Tools are available (e.g. Pootle) toautomate string generation and provideuser-friendly editor so that localizers onlyhave to translate text (no tool learningcurve)
  17. 17. Localization/TranslationsIs the documentation translated? Howactive are the translation teams? Whatlanguages have been translated? Is there aprocess for generating translated docs tomatch software releases?Translation tools are less automated andoften require more scripts, manualintervention, and defined processes.
  18. 18. Localization/TranslationsContributors dont necessarily needtechnical knowledge of thesoftware/documentation being translated,just fluency in two languages.Project should have a published style guidefor what does and does not get translated(e.g. acronyms, technical terms that remainin English, commands and output whichshould remain in English).
  19. 19. UI Design ContributionsDoes the project have a UI (user interface)design team? What about accessibility?Are requests for UI improvements takenseriously or ignored?Is UI part of the roadmap creation process?
  20. 20. Graphics ContributionsDoes the website need a design revamp?Does the project have a logo or recognized“brand”?Is there an artwork page where users cancontribute and download artwork?Is there cover art for the projectspublications?
  21. 21. Social Media ContributionsDoes the project have official social mediasites (blog/planet, Facebook page, twitteraccount, etc.)Are these updated regularly with content?Is it easy to find these sites from theprojects website?
  22. 22. Helper ContributionsAs a contributor:Respond to unanswered questions in IRC,mailing lists, forums.Point new users to the information theyneed.As a project:Recognize such contributions, they ease theworkload for many!
  23. 23. Advocacy ContributionsEvery project needs help in this area!You could create brochures, arrange eventsand contests, administer research surveys,perform datamining, maintain a news feedor blog roll, create ads for ezines, etc.Allows you to use your talent andimagination without necessarily requiringdeep technical knowledge.
  24. 24. Tips: Communication ChannelsContributors need to be aware whichchannels are available, what each isappropriate for, and to use the correctchannel for the task at hand.Projects need to review their availablechannels. Are they effective for the types ofcontributors you need? Prune ineffectiveones and consider creating new ones thatmay reach more users. Make sure allchannels can be found from the mainwebsite and each has a useful description.
  25. 25. Tips: Communication ChannelsNew contributors should lurk for a while orskim existing archives to becomecomfortable with the type of conversationsthat occur on each channel.Projects should be aware of the tone ofeach channel and have a policy foracceptable behaviour and how to quicklydeal with unacceptable behaviour.
  26. 26. Tips: Get to Know PeoplePeople tend to stay when they feel welcomeand that their contributions add value.Some communication channels should benon-technical to allow for informaldiscussions (e.g. introductions sub-forum orchat IRC channel, Facebook page).Join a local user group or create one if noneexists.
  27. 27. Tips: Get to Know PeopleAttend a conference; if funds are tight lookfor volunteer, speaker, or sponsorshipopportunities. Dont underestimate thevalue of meeting community members inperson.Project should hold at least an annualconference with sponsorship opportunities.Project can assist users in creating andadvertising local events (e.g. installfest,unconference).
  28. 28. Tips: Overcoming ProblemsLearn the rules of Netiquette.Read the Projects FAQs.Treat others how you want to be treated.Be persistent--dont just pop in thendisappear.
  29. 29. Tip: Overcoming ProblemsIf you encounter elitism, sexism, racism, orsome other nasty-ism?Dont pretend it didnt happen.Privately bring it to the attention of a leaderin the Project.Project should have a policy for dealingquickly with incidents.
  30. 30. Tips: Finding OpportunityPublish a wish or TO DO list containingsmall, concrete tasks suited to newcontributors.Look to reduce getting started barriers: e.g.account creation process, submissionqueues.Look for ignored contributions and find outwhy: e.g. lack of manpower, lack ofcommunication.
  31. 31. Tips: Reducing BarriersPublish a “how you can help” listprominently on the Project website.“Groom” people on IRC and forums: helpthem write a good bug report, encouragethem to publish a how-to, blog theirexperience, tweet what is happening.Have an outreach program to introduce theproject in local schools.
  32. 32. Tips: Reducing BarriersUse recognized tools and include “gettingstarted” guides to reduce learning curve.Hold regular code/doc/idea-athons.Organize face-to-face events: local usergroups, unconferences, participation inglobal events such as Software FreedomDay.
  33. 33. Tips: Reducing BarriersAcknowledge contributions! e.g. dont letpatches rot in a queue.Pair new contributors with communitymembers.Think beyond the codebase!Remember: open source is aboutcommunity...
  34. 34. Questions? URL to slides: