1 |
On 10/10/2012 6:45 AM, karan garg wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> I have been an open-source enthusiast since 2010 and using Linux as my |
5 |
> operating system for last 2 years. However, now I want to take an active |
6 |
> part in open-source development and contribute to the society under an |
7 |
> expert guidance. I am an RHCE and have a basic understanding of a fair few |
8 |
> things like database, c, c++, ruby, shell scripting, etc. I would really |
9 |
> consider it an honor if you would guide me. |
10 |
|
11 |
The biggest challenge to contributing to open source is often to |
12 |
understand the social/cultural aspects. Lots of people have useful |
13 |
patches and publish them somewhere, but "nothing happens" unless they |
14 |
figure out how to interface with the relevant community, and present |
15 |
their innovations in a way that meets that community's needs and standards. |
16 |
|
17 |
There is also a question of "marketing" your improvements. Bear in mind |
18 |
that every open source project wants to maintain some sense of |
19 |
reliability and stability. So your contributions will be evaluated not |
20 |
only on the merits of what they improve, but also what they might break, |
21 |
how difficult they might be to maintain going forward, how consistent |
22 |
your coding style is with the existing conventions, and so forth. |
23 |
You'll need to explain why your patches are good/helpful. Don't expect |
24 |
people to read them carefully enough to figure it out for themselves -- |
25 |
give them a clear summary of what you are up to and what are the merits. |
26 |
|
27 |
Try not to undertake anything too ambitious. If you do have an |
28 |
ambitious plan, split it into small phases so that people can evaluate |
29 |
your work without being overwhelmed by it. |
30 |
|
31 |
In general, expect your contributions to be met with skepticism, |
32 |
especially the first few times you contribute. If people criticize your |
33 |
work, try not to take it personally. Often people will say "I think |
34 |
you're an idiot" when they mean "I think your code makes an idiotic |
35 |
mistake", so, seriously, if you feel offended, think for a second "what |
36 |
is this person really trying to tell me?" |
37 |
|
38 |
Usually there is some way to answer their concerns by revising and |
39 |
resubmitting your patches. Remember that (almost) every project is |
40 |
somebody's "baby," which they spent a lot of time an effort creating. |
41 |
They have every right to be a bit protective -- and of course sometimes |
42 |
egos do get involved. |
43 |
|
44 |
In general, most of the barriers you might encounter trying to make a |
45 |
contribution at the office apply equally -- sometimes more than equally |
46 |
-- to open source development. |
47 |
|
48 |
However, if you stick to it, the rewards can be tremendous, both |
49 |
"spiritually" and in the professional domain, where you will have |
50 |
bragging rights, forever, if you manage to make a meaningful |
51 |
contribution. By no means do I wish to discourage you -- in fact, I'd |
52 |
say the best way to answer your question is to "just go for it." |
53 |
|
54 |
You'll learn as you go, probably after a few embarrassing mistakes. |
55 |
Keep a stiff upper-lip, be humble, and don't hurry too much, and you'll |
56 |
do fine -- there's a reason so many people contribute to open-source: it |
57 |
really is quite a rewarding endeavor. |
58 |
|
59 |
-gmt |