Take the 2-minute tour ×

I read the questions asked on Stackoverflow.com about starting open source projects. I follow all the steps, but the issues still remains unanswered.

  1. How do you find out if you the dev. community of that project is not hostile. Are they tolerant to a few mistakes or not? I am a decent developer and I am good in algos,systems etc. But I don't have any experience in the whole process of open source projects. Like I have not done much merging of branches or merging of code. What process related things should I know of about a project. How will I know what process that particular project is following. Who tells me what to do? Or should I just pick up something feature/bug and fix it. What if someone else is also working on it.


share|improve this question
You mean "starting work inside an open-source project," right? There is only one way to "start an open-source project", and it's very simple, you write code that does something and you release it. –  Pascal Cuoq Nov 25 '09 at 22:33
@pascal Alternatively, you can write code that does nothing and release it, as that's what some of them seem to be ;) –  Justin Johnson Nov 25 '09 at 22:42
@Justin: Ah, you've been browsing through Sourceforge projects, haven't you? –  David Thornley Nov 25 '09 at 23:02
add comment

4 Answers

up vote 6 down vote accepted

The best place to ask questions like these would be the developer mailing list of a given project in my opinion. Maybe search its archives first for similar questions and, if you can't find anything close, post a little intro and ask your questions as you just did here. I'm pretty sure someone will be kind enough to provide pointers if their process is documented (projects have sometimes a "How to contribute?" section to ease contributions) or guidance (where to start, what standards to follow, where to look at, etc, etc). Contributions are generally welcome and appreciated.

And don't worry too much about version control stuff for now, as long as you know how to do a checkout and how to create a patch. The open source landscape is a meritocracy landscape and I doubt you'll be a committer immediately, becoming a committer is usually something that takes some time. Start small, with easy issues to learn how the code works (it's often hard to get started with complex things), submit patches respecting the project's standards, contribute to the dev/users mailing list, be active on the project IRC channel, etc. In other words, become visible and prove that you deserve being elected and accepted as a committer. Meanwhile, you'll have learned enough about their process and tools.

share|improve this answer
Good answer. Also, do your best to be a net contributor. Submit patches in the form they want (including doc patches), ready to check in. Follow the project standards. –  David Thornley Nov 25 '09 at 23:03
@David Thanks. And yes, your points are perfectly valid, I've slightly modified my answer to include them. –  Pascal Thivent Nov 25 '09 at 23:41
add comment

There is no overriding "open source project" standard that we can advise you on. Like any other set of disjoint communities, they're all different. Contribute to one you're interested in and try it, and if they're jerks/intolerant, move on to something else.

Conversely, if you want to get in a practice run, start your contributions with a project you don't care about at all, so if you bail on it there's no loss for you.

share|improve this answer
add comment

Many open source projects have their own IRC channels. You could probably get to know the community a little by spending some time there.

share|improve this answer
add comment

Don't worry too much. If you are contributing to a project, you will pretty quickly find out whether your code is up to their standards or not. If you are starting one yourself, try to pick nice people to work with. If you are unsure about a best practice, ask in a community like SO. Open Source is a free country, and in the end, you are free to do what you want.

share|improve this answer
add comment

Your Answer


