This document discusses how individuals can contribute to open source projects. It provides reasons for getting involved such as gaining experience, networking opportunities, and recognition. Tips are given for both contributors and projects, including finding a good fit, making code, documentation, testing, and other types of contributions. Suggestions are made for reducing barriers to contribution like publishing task lists and guides. The overall message is that open source relies on community involvement.

1. How Can I Contribute to
Open Source?
Dru Lavigne
Community Manager, PC-BSD Project
SELF 2011

2. This presentation will discuss:
Some reasons why YOU should get involved
Tips for both contributors and projects on
what a new contributor can do, finding a
community (and getting found), getting
started with contributions, and
overcoming/reducing barriers to
contributions

4. Why get Involved? Why me?
Why not you?
There's tons of stuff to do and not enough
people to do it.
Existing contributors can't sustain forever
(marriage, kids, crazy day job).
It's lots of fun! Really!

5. Benefits: Experience
Add to your experience portfolio (and your
resume).
Learn how to use industry tools in large,
collaborative, non-lab environments.
Learn hard and soft skills.
Learn from others in your spare time.

6. Benefits: Networking
Meet people from all over the world with a
shared interest.
Benefit from the experience of other
community members (some who are
famous and have written cool stuff).
If you're thinking about landing a job, it
really is about "who you know".

7. Benefits: Recognition
It is possible to build a name for yourself
and become an authority on topic XYZ.
One way to break the glass ceiling as you
become known for what you do, not what
you look like.
Savvy employers Google potential hires—
will they find you?

8. The better the “fit” with a community, the
better 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 as
two sides of a coin: one side is what the
contributor should be looking for and one
side is what the project should be providing.

9. When finding a community, a little research
in the beginning may save you wasted time
later: create a project short list.
Look for opportunities that match your
interests.
A technical fit is not always the best-fit.
Shop around and don't feel the need to stay
(or give up entirely) if the fit isn't working
out.

10. Code Contributions
As a contributor:
What languages do you know and/or are
interested in learning? (try searching by
language at sourceforge.net or ohloh.net)
What version control systems (e.g. git, cvs,
svn) are you familiar with, if any?
Do you already know people associated
with a particular project or have a project in
mind?

11. Code Contributions
As a contributor:
Lurk on the development team's
communication channels: e.g. mailing list,
IRC channel, forum.
Become familiar with the project's bug
tracking system.
Submit patches.
If eligible, apply for GSoC.

12. Code Contributions
Is there a bugs database? Any limitations
on who can submit bugs?
Is there a published style guide?
Are there opportunities to be mentored by
more senior members?
Are there regular bug or code sprints?
developer summits at conferences? who
can participate? are people or docs
available to guide new attendees?

13. QA Contributions
As a contributor:
Download and install testing, beta, or RC
versions.
Spend some time going through that
software's capabilities (e.g. screens,
switches).
Carefully record any errors and what you
did that produced the error and report your
findings.

14. QA Contributions
As a project:
Is there a published release schedule? Are
announcements made when beta or RC
versions become available?
Is there a testing mailing list or a bug
tracking system for testing feedback? Does
anyone respond to feedback?
Are instructions available to guide users on
how to submit useful feedback?

15. Doc Contributions
Does the project have a documentation
team?
Does it have any documentation?
How steep is the learning curve for the tools
used to manage documentation?
If steep, are their guidelines on how to use
the tools or opportunities to train new
contributors?

16. Doc Contributions
If not steep (e.g. wiki), what is the account
creation process, is there someone who
looks at changes, is there a process for
“publishing” in other formats to match
software release?
How open is the project to publishing or
linking to technical blogs, how-tos,
interviews, articles, whitepapers, etc.?
Is there a contact person for interviews,
articles?

17. Localization/Translations
Is the software suited to localization (e.g.
has menus)? How active are the translation
teams? What languages have been
translated?
Tools are available (e.g. Pootle) to
automate string generation and provide
user-friendly editor so that localizers only
have to translate text (no tool learning
curve)

18. Localization/Translations
Is the documentation translated? How
active are the translation teams? What
languages have been translated? Is there a
process for generating translated docs to
match software releases?
Translation tools are less automated and
often require more scripts, manual
intervention, and defined processes.

19. Localization/Translations
Contributors don't necessarily need
technical knowledge of the
software/documentation being translated,
just fluency in two languages.
Project should have a published style guide
for what does and does not get translated
(e.g. acronyms, technical terms that remain
in English, commands and output which
should remain in English).

20. UI Design Contributions
Does the project have a UI (user interface)
design team? What about accessibility?
Are requests for UI improvements taken
seriously or ignored?
Is UI part of the roadmap creation process?

21. Graphics Contributions
Does the website need a design revamp?
Does the project have a logo or recognized
“brand”?
Is there an artwork page where users can
contribute and download artwork?
Is there cover art for the project's
publications?

22. Social Media Contributions
Does the project have official social media
sites (blog/planet, Facebook page, twitter
account, etc.)
Are these updated regularly with content?
Is it easy to find these sites from the
project's website?

23. Helper Contributions
As a contributor:
Respond to unanswered questions in IRC,
mailing lists, forums.
Point new users to the information they
need.
As a project:
Recognize such contributions, they ease the
workload for many!

24. Advocacy Contributions
Every project needs help in this area!
You could create brochures, arrange events
and contests, administer research surveys,
perform datamining, maintain a news feed
or blog roll, create ads for ezines, etc.
Allows you to use your talent and
imagination without necessarily requiring
deep technical knowledge.

25. Tips: Communication Channels
Contributors need to be aware which
channels are available, what each is
appropriate for, and to use the correct
channel for the task at hand.
Projects need to review their available
channels. Are they effective for the types of
contributors you need? Prune ineffective
ones and consider creating new ones that
may reach more users. Make sure all
channels can be found from the main
website and each has a useful description.

26. Tips: Communication Channels
New contributors should lurk for a while or
skim existing archives to become
comfortable with the type of conversations
that occur on each channel.
Projects should be aware of the tone of
each channel and have a policy for
acceptable behaviour and how to quickly
deal with unacceptable behaviour.

27. Tips: Get to Know People
People tend to stay when they feel welcome
and that their contributions add value.
Some communication channels should be
non-technical to allow for informal
discussions (e.g. introductions sub-forum or
chat IRC channel, Facebook page).
Join a local user group or create one if none
exists.

28. Tips: Get to Know People
Attend a conference; if funds are tight look
for volunteer, speaker, or sponsorship
opportunities. Don't underestimate the
value of meeting community members in
person.
Project should hold at least an annual
conference with sponsorship opportunities.
Project can assist users in creating and
advertising local events (e.g. installfest,
unconference).

29. Tips: Overcoming Problems
Learn the rules of Netiquette.
Read the Project's FAQs.
Treat others how you want to be treated.
Be persistent--don't just pop in then
disappear.

30. Tip: Overcoming Problems
If you encounter elitism, sexism, racism, or
some other nasty-ism?
Don't pretend it didn't happen.
Privately bring it to the attention of a leader
in the Project.
Project should have a policy for dealing
quickly with incidents.

31. Tips: Finding Opportunity
Publish a wish or TO DO list containing
small, concrete tasks suited to new
contributors.
Look to reduce getting started barriers: e.g.
account creation process, submission
queues.
Look for ignored contributions and find out
why: e.g. lack of manpower, lack of
communication.

32. Tips: Reducing Barriers
Publish a “how you can help” list
prominently on the Project website.
“Groom” people on IRC and forums: help
them write a good bug report, encourage
them to publish a how-to, blog their
experience, tweet what is happening.
Have an outreach program to introduce the
project in local schools.

33. Tips: Reducing Barriers
Use recognized tools and include “getting
started” guides to reduce learning curve.
Hold regular code/doc/idea-athons.
Organize face-to-face events: local user
groups, unconferences, participation in
global events such as Software Freedom
Day.

34. Tips: Reducing Barriers
Acknowledge contributions! e.g. don't let
patches rot in a queue.
Pair new contributors with community
members.
Think beyond the codebase!
Remember: open source is about
community...

35. Questions?
URL to slides:
http://www.slideshare.net/dlavigne/self11
dru@freebsd.org