Last fall I found Ohloh and I have to say… I'm still amazed by it. From one place, you can get summary information on the project's status, see similar projects, see a list of recent commits, who did them and overall information on the code itself. If you have any involvement in the Open Source Community either as a user or as a contributor – and if you're on this site, most likely you do – you should check out Ohloh and look up your favorite projects. You can easily comment upon or flag the projects you use or appreciate. I just updated mine. Anyway, the single most useful aspect I've seen shows the overall lines of code over time. For example, dotProject currently has 134kloc and is shrinking… wait, shrinking!?
Yes, you read that correctly, the dotProject codebase is shrinking.
But if dotProject development is moving faster – which according to the commit logs – it appears so, how is this possible? How could a codebase consistently have new functionality and bugs fixed but still reduce the overall lines of code? It took me a moment to realize it, but the answer is quite obvious.
Some of the problems we've faced in the past have been due to similar functionality performed in different places in different ways. This makes tracking, debugging, and closing issues a nightmare. Just because you fix the "File Checkout" issue in one user flow doesn't mean anything long term and you can have the same problem pop up in a different area… and you have to track down and apply the fix again. It gets even worse as you introduce a bit of complexity via slight variations in the logic or supporting queries.
Therefore, there has been quite a bit of effort in recent months to cleanup the codebase by eliminating this duplication. To date it has been we've been successful by simply moving many of the bits and pieces back to their respective underlying objects. Combine this with a cleanup and simplification of the corresponding SQL and it gets even easier and moves that much faster.
The best aspect of this is that it creates a dotProject API both for the core team and anyone looking to extend dotProject. It's getting to the point where if you want a list of Projects a User is allowed to see, you don't need to know anything about the database, the User's permissions, or anything besides the User's id. You simply call:
$CProject->getAllowedProjectsInRows($userId);
The point is that sometimes the best thing you can do is to work to reduce the lines of code through some careful analysis and a bit of thought. When you reduce the lines of code – thought it looks like you're moving backwards – it can mean the opposite. You can reduce the complexity of the project, speed development for everyone involved, and ensure that once a bug is fixed, it's fixed everywhere. All three aspects will help keep your team sane…
To date, the only thing which is not fully PHP4 compatible is the new Files Module Update – currently in Head, not released – but as time goes on the likelihood increases. As of the 2.1 Release Candidates, dotProject is fully PHP5 compatible… start thinking about an upgrade.