One of the best things about Open Source Software is the fact that you can customize it to your heart's desire.
It allows you to choose a tool and fit it exactly for your needs. It's a powerful concept. Have you every tried to use a hammer or screwdriver which is seems to be a bit off? Maybe it's the wrong size/type for what you're trying to do or maybe your hand is too small/big to use it. Now imagine you can adjust the tool as necessary to fit your needs. Nifty, huh?
One of the worst things about Open Source Software is the fact that you can customize it to your heart's desire.
Yes, you read that correctly. When someone customizes an Open Source project for their needs, they've created a small fork in the project. Whether it's public or not, this can cause problems.
If you have a development team with great foresight, these changes can be implemented in a way which limits the affected code and modularizes the entire change. If the team is less than stellar (possibly), the new features are extensive (sometimes), or the project is rushed (usually), this effort can suffer. I can't count the number of times where I included a comment like TODO: This code works, but it's messy and should be broken out asap or TODO: This is a huge kludge. Fix this!
Is this a perfect solution? Not a chance. Does it work? Well, mostly…
Atleast until the new version of something comes out. Now what do you do? Say you've spent $X000 customizing dotProject for all your needs. It works beautifully, integrates with your backend systems, and serves as a great tool for your team(s).
Now dotProject v2.0 is out. Then dotProject v3.0 is out. What do you do? If you simply deploy these versions, they might have some of the improved functioality that you've developed, but it could work differently. If you lose any features, your users are going to complain. But what if major security problems have been fixed? Can you effectively support your users without the changes?
The process is a tightrope between doing innovative things and keeping the code solid and clean. Sometimes this will slow innovation, but sometimes even better things can result.
Of course, sometimes you have to break the old systems. You have to get rid of some of the cruft. As long as you provide a way to get the users into the new architecture, it's not a problem…
Just my 0.02