We have a really huge project with 20-30 modules, but it is mostly done. It's in a maintenance stage (mostly bug fixes and rarely new features). I am trying to come up with a number of developers that will be required to maintain the product.
Is there a good way to measure this number?
The project is mostly WinForm-based C# applications (mix of .net 1.1 and 2.0) with a sprinkling of vb6 apps.
I think that's going to depend on a lot of variables: the quality of the developers you hire, their familiarity with the code, the quaility of the code, and the language used for starters. I don't think there is going to be an equation that is going to work.
This will entirely depend on the code quality, the frequency of changes, and the level of testing.
For instance, a system with thousands of lines of code, but very infrequent changes and a full library of unit/integration tests will probably require fewer developers that a small system that frequently changes and has no testing.
Another important factor is the experience of the developers involved, not only in general, but specifically their understanding of the specific project.
In the end, this is a very hard statistic to estimate, and you are probably best off looking at the workload of the developers that are currently on the project and slowly moving people to or from the project as needed.
I don't think that there is a good way to choose this. It will depend on several factors:
You may just want to start with a small team, see how the work goes, and add more members later if needed.
It depends more on the quantity and difficulty of the bugs that need to be fixed than on the size of the project. As a start:
If you have used an issue-tracking system over the life of the project, you could run a report showing you average number of issues per month and average time to fix which would then give you the historic maintenance requirement.
You could then extrapolate this into the future.