Bare minimum you need to work for an open source project

Question

I have recently started working on some open source project which I found relevant to my interests.

During this initiation period I came across some terminologies/stuff that I am not acquainted with, like configure, tool chain, binutils, etc. which I agree depends upon the type of project you are working on.

Now my question is, are there some bare requirements a developer should know before starting to work on the project?

Any help/reference will be greatly appreciated.

EDIT:

I have seen the GNU configure and build system in most of the projects I have seen. If someone bothers about it "The GNU configure and build system" is a good place to start.

Answer 1

If it's a pre-existing one, you'll need to read their development docs (if any), learn how to use their version control system, and have the requisite tools for building the code and running it.

If you have all that, and the knowledge of the code/language, then you just need enthusiasm and some spare time :)

Answer 2

I would think that depends entirely upon the project. Most well set up software projects will specify:

• What language(s) they're written in
• What developer environments (if any) they're set up for
• What tools you need to build/compile/run the project
• Test data with which to test the software

What are you working on? Are you sure they don't provide any of this information?

Answer 3

I wouldn't define them as bare requirements in the sense that it appears you are looking for. If you're a programmer you already have (hopefully!) the self-learning and problem solving characteristics that probably led you to be a programmer at first.

You'll never really know 'everything', and will likely learn something new everywhere you go. Heck, I got my current job never even hearing the words "Model-View-Controller", but picked up the concept in no time.

Your examples, toolchain and binutils, are not complex concepts and a simple wiki article should suffice :).

Answer 4

It depends, as you say, on the project.

You'll have to know how to work in the language, you'll have to be familiar with the source code control system they use (usually subversion). You'll have to be able to build (usually Ant, often Maven).

Answer 5

I'd suggest downloading all the source code and making sure you can build it yourself as a first step.

Try and make sure you are familiar with the overall design and documentation before attempting to make any changes to ensure you don't inadvertently break anything on your first change!

The terminologies being used will probably depend on the technologies being used, for example an open source project written in C++ and running on Linux, will likely be very different to a C#/.NET application build to run on Windows.

Answer 6

It depends on how much involvement you will get into. If you just want to contribute with a feature, just get the tools to build the project, an editor to change the file and enough doc reading to find injection point for your feature. If you can find someone to help you getting started it will be fairly easy.

If you are to be committed to the project I recommend learning build tools, project history and aims. Also how the current authors try to solve the problems, their perspective on the project will help.

Answer 7

I would say being able to understand all of the architecture, tools and technology for whatever project you're working on is a must.

However, you then tried to make this a generic question that applied to any open source project. You kind of answered that for yourself didn't you?

which I agree depends upon the type of project you are working on

Answer 8

Caffeine.

Lots and lots of caffeine.

...I suppose that applies to all programming, though. :)

Answer 9

It depends on what you qualify as "work" on the project.

Most of the answers here suggest that you're coding (and your question hinted in that direction), but there are things that you can do to contribute to projects -- like testing and documentation -- that can be done without knowledge of how the program's written.

Now, for the coding aspect of it -- if it's a smaller project, I'd try to figure out what the other contributor's motivation and grand plans/goals for the project are. As with any team, coming in and trying to take things in a completely different direction than the others are planning, even if you have good intentions, can cause all sorts of problems.

(and then there's the technical advice that everyone else said ... source control, build system, project architecture, toolkits used, etc.)