I know that the default advice for open source projects, and getting started, is to start fixing bugs. But I have a feeling that its the path that one would want to take if they wanted to be a tester/fixer of bugs in the project. How does one become an active contributor of an opensource project? [I.e. on the level of architecture]
1
-
15Step 1 - Become huge contributor. Step 2 - cut back a little.– psrMar 30, 2012 at 17:12
Add a comment
|
3 Answers
This is probably going to sound like a bit of a tautology, but if you want to become a major contributor of new features, use the product for a while, find a new feature that would improve it, write up the code to implement the feature, and contribute it.
The reason people are advised to start out with bugfixes is that that gets them to dig around in the codebase and familiarize themselves with the way things work. That'll also get you to participate in the project's discussion community, whatever that may be, (usually a mailing list or forum,) so you'll get a feel for the direction of the project. You'd feel a bit foolish if you get 80% of the way done with your new feature only to find that someone else has been working on it all along and they just finished it!
answered Mar 30, 2012 at 17:03
-
Far enough, so would you say that this more political or an embarrassment tactic? [Aka. advertising a patch on a blog, before getting permission to commit]– monksyMar 30, 2012 at 17:05
-
2@monksy - it is neither, as you would not normally make it public, but contribute it via whatever mechanism is appropriate to the code-base. You're trying to gain trust via shared experience. You don't get commit privs by annoying people!– sdgMar 30, 2012 at 17:14
-
1@monksy: Don't advertise your patch on a blog; how do you know anyone from the project will even see it? If you have a patch, take it to the discussion community and talk about it there. That's where you're likely to get the most useful response. (BTW if you have a bug fix, be prepared to prove that there's actually a bug. This means you understand what the code is supposed to do and you can show a reproducible case where it does something else. Make sure you know the difference between a bug and the code doing something that it's supposed to do that you don't like.) Mar 30, 2012 at 17:17
There are no shortcuts. Open source projects are extremely merit based. When you have shown you are capable of handling smaller tasks, you will eventually be trusted with larger and larger tasks. Open source projects also have a lot of drive by contributors who contribute one or two patches then move on, and even more people who "contribute" one or two grand but unimplemented ideas then move on. If you want to make larger contributions you'll have to show you're in it for the long haul.
That being said, incremental architectural improvements are often welcome, especially if they solve a major bug or performance problem. For example, several years ago one of a handful of patches I contributed to the Cinelerra project was an architectural change to the undo stack that significantly reduced memory consumption and latency for undoable operations.
You're going to find the most success if you're solving a problem you are personally facing, rather than just setting out to "become a contributor to an open source project." When I submitted that patch to Cinelerra, I wasn't trying to contribute an architectural change to a randomly chosen open source project, I was trying to figure out why it took so freaking long to move an in/out point when editing my videos.
answered Mar 30, 2012 at 19:20
-
Nice! I always wanted to use Cinelerra, but it was always a pain in the arse to install it on gentoo. Thanks for the contributions. But this is exactly the kind of change I'm suggesting and asking about. Its a large enough changes to make people concern, but its not a bug fix.– monksyMar 30, 2012 at 20:10
You can do this by getting to know those already in that position and demonstrating an interest to join them, which is best accomplished by fixing bugs, finding bugs, and participating in development.
-
That seems like a long path to making architectural/design decisions. [I'm operating under the premise that forks are bad]– monksyMar 30, 2012 at 17:14
-
@monksy it seems like you are starting from a different premise than perhaps your question indicated. If you believe you have a much better way than a current project does, perhaps engage in a low-key open conversation to better understand why things are they way they are, and then go from there...– sdgMar 30, 2012 at 17:19
-
5@monksy moving up the ladder takes time, you don't get to decide to start at the top unless you make your own ladder.– RyathalMar 30, 2012 at 17:35