I am trying to generate a metric for a company cost savings goal. To do this, I want to estimate the savings we realized by using an open source web application rather than building it from scratch or buying a COTS solution. One step in the process is to estimate how much it would have cost us to develop the application ourselves. Unfortunately, I'm at a loss for a really simple way to do this without going through a full estimation process.
Since I have the source code, I would think there should be some heuristic that could give me a very rough estimate of developer hours needed to write it. Unfortunately, my web searches on the topic mostly turn up articles and opinions on how lines of code are not a good indicator of productivity or quality.
My best solution so far is to pick a number of lines a developer could write in a day and work out the number of developer hours from there. If I go with that method, I would like to have some (preferably research based) evidence to back up my claim of developer productivity.
The one thing I have going for me is that to generate my final metric, all I really need is a lower bound on the developer hours or cost of the project. The higher the estimate, the better my metric will be, but I would rather the estimation technique be unassailable than have a high number.
Is there a better way to estimate the value of an open-source project?
Best Answer
For a rough estimate, use the SLOCCount program written by David Wheeler - it will analyze the lines of code and use industry estimates on programmer productivity to give you an estimate of time and money it would take to build said software.
By default it uses the COCOMO model for cost estimates, but you can customize this.