open source projects...management

There is a process to follow, that's why there's a change log. Every contributor keeps a record of the modifications and updates they performed and it's results. The updates are then gathered and mixed and internally tested between them. Then they decide if it's enough to release an update version. The more changes and fixes there are, the higher the jump in version number. Example a version 1 alpha will become version 1.1 alpha with small changes, but may jump to beta with the increments or there is a major update...

You may also have a version control system set up, and a bug tracker. Liam (Jeevesbond) just took over my old computer so we can run a little server for this purpose.

He'll have more to say about it when he finds this topic, I'm sure!

I think that usually there is someone who sort of manages the project. I don't think you'd normally have a huge number of people working on the same project at once. Version control means that you can track who has made changes to what file and when. I think you could also ensure that two people aren't working on the same problem or the same files at the same time. So someone might have to "check out" a file to start working on it.

Hopefully Liam will see this and correct anything I say that's wrong!

benf wrote: Is there some sort of technique when lots of people are working on one particular project / file / section....???

Wow, now there's an interesting can of worms! This is 'Open Source' we're talking about, so there are more techniques and ways of doing things than you've had hot dinners.

Although, am trying to think about it from a high level and most projects have a few things in common:

• Most Open Source projects are dictatorships, Linus Torvalds coined the term 'benevolent dictator for life', when talking about his role in development of the Linux kernel.
• The balance to dictatorship in any FLOSS (Free/Libre Open Source Software) project is its openness. A project leader cannot afford to annoy their community too much, or the project may be 'forked' and a new one created.
• All projects rely on some form of version control to control their code. Usually developers will download a copy of a project to their local machines (for instance to get VLC--a popular GNU/Linux & Mac media player-- I would just have to type: [incode]svn checkout svn://svn.videolan.org/vlc/[/incode] from the command line to get the latest copy of their source code).
• When a developer has made some changes (and tested them) he submits a patch back to the project maintainer(s). This is so that all the source code doesn't need to be transferred, a patch just contains the code that has been changed.
• This is the dictatorship bit: it's up to the project maintainer(s) whether the patch is merged into the source.
• As a project grows more people can be given rights to merge code into the main source tree.
• Projects are organic, they tend to start off small and grow. Typically a project begins because a developer needs some software, writes it themselves, then releases it for all to use. They grow from there.
• There are a couple of large sites where projects typically live: http://sourceforge.net and http://freshmeat.net people usually use these services when searching for a Free software application. As an example: try searching for 'instant messaging' on SourceForge. There's also Google Projects and many people run their own repositories (like the VLC example) then copy major releases to SourceForge.
• Many people (mainly lawyers and business owners) are scared of FLOSS, particularly the freedom part. They imagine that if they release their code some nefarious individual will immediately 'steal' the project by forking it. The reality is this rarely, if ever, happens. People are well aware when someone is up to no good; secondly why would anyone want the bother of maintaining a project when someone else is already doing a good enough job? Things just don't work that way.

An interesting insight into FLOSS projects, and the Linux kernel in particular, is the article 'Who Wrote 2.6.20?'. It shows a detailed breakdown of who contributed to creating the last Linux kernel release.

If none of this makes any sense, don't worry. I had much the same questions as you did, but instead of worrying about how it all works I decided to just get on with using GNU/Linux and let the rest happen naturally. I'd advise you to do the same: concentrate on learning what you need to know, the rest will all slot into place as you go along.

Unless there's a particular reason (project etc.) you need to know all this stuff up-front?

Sorry to double-post, but I wanted to answer your other questions too:

Quote: So is there ultimately someone who manages the whole project for releases and modifications before it is finalized.

Maybe, depends upon the project. There could be be more than one person with access rights to merge code into the main source tree. There's usually one maintainer/admin person who has final say though, but again, it depends upon the project.

Quote: Does this mean that different people have lots of different copies of the main project and are therefor tested separately. How is all this integrated and tested for the final versions?

Again, depends upon the project and the version control software being used. At this moment there is a large discussion over whether distributed (e.g. the system you described) are better than version merging systems.

Mostly it happens the way you describe it though. In theory if everyone has written good code it should all work together, also a hacker should always ensure they have an up-to-date version of the code when they start working every day. The first thing anyone does when they work on a project (and I mean every time they sit down to do any coding) is do an update. This will automatically merge other peoples changes into their own copy and show any conflicts it can't resolve. Then when the bug is fixed, or new feature added the developer will create a patch file and submit it for inclusion in the main code tree. Because they've kept their working copy of the repository updated there should be no conflict with anyone elses changes.

That's roughly how it works, although I may have mixed up some of the finer points between centralised vs distributed version control.

Quote: Im not sure i understand how a big project is managed if you have say more than 10-20 people all working on the same thing?

See above, pretty-much. It's all down to the system being used and who the maintainer allows to check in changes to the main source tree.

I gleaned this from an argument about Firefox and Epiphany, from one of the people who started Firefox:

Quote: Firefox Developers who have checked into our CVS source code repository number around 140. There are also an additional 250 or so people who have submitted patches that were checked in to Firefox by someone else. Based on my quantitative and qualitative analysis of how many people could be considered “serious” Firefox code contributors since the beginning of the project, I’d put the number at around 90.

There’s another 700 or so developers who have checked significant code into to Mozilla’s Gecko rendering engine which is a core Firefox component and not included in the Firefox numbers above (Gecko also a core Epiphany component, responsible for everything inside the content area). There are also about 600 people who have contributed Gecko code that was checked in by someone else.

That's a lot of people and it's all down to using version control and managing the rights of those who can check-in. The key point of allowing a lot of people access is that if a patch is rubbish, the code can just be rolled-back to how it was before. No harm done.

Hope this helps. Hopefully Abhi will be along shortly to fill in the gaps I have--no doubt--missed.