If you've been reading my blog for a while now, it's probably no secret to you that I'm a fan of Open Source Software. I enjoy the benefits of using many open source products like NUnit, NCover, NAnt, etc. At the same time, I also believe that you need to be careful when modifying code in an open source product for use within the enterprise. Why? Because there are several hidden costs associated with modifying OSS that are not realized by your average company or developer. For the sake of this post, I am making an assumption that the developers making the modifications are not involved with and contributing back to the open source production in question (as I have seen this happen before).
The first of these hidden costs is the maintenance cost. When modifying an open source product, you have to think of the long term impact to the company of the changes you are making. As soon as you modify the source, your upgrade path becomes a bit more complex. Usually when a new version of a product is released, you can install the new version, do some testing of your dependencies and call it good (granted, this is, at at times, a gross oversimplification of the process (especially when there are API changes in that upgrade)).
However, when a new version is released of an open source product that you have custom modified for your company, you now need to not only upgrade the code but also make sure that the changes you made before are brought over if necessary. If the change is small, this may be manageable. However, if the change is not trivial this can be a huge investment of development time (that most likely could be better spent elsewhere). What happens if there was a good amount of refactoring that took place in the new release? Well, now you have to do the investigation again to understand the new code base and make any necessary changes again. To complicate matters, what happens in the all-too-common case of when the original developer has moved on and is no longer at the company. Now you're requiring the person(s) doing the upgrade to not only comprehend what and how the original changes were made, but to also understand how those changes are integrated into the new release (and remember, reading code is a lot more difficult than writing code).
Another hidden cost that is not often realized is a cost that younger developers are susceptible to. When developers become eager to modify source code and lean toward modifying source code as a solution to every problem, their skills as integrators are often degraded. One thing I have learned when working with Enterprise software is the rule "if it ain't broke, don't fix it". There has been a lot of time put into writing that code base and getting it to work the way it is. If the company needs to use that product with some additional functionality and you can provide the additional functionality without modifying the existing source code base, do it :). Please realize though that this is just a _general_ rule and is dependent on the context of the necessary changes.
The impact of this degradation of skill becomes more obvious when it comes to maintaining the company's current code base. I believe an important object-oriented development skill is to be able to write code that adds functionality by extension, not through modification (check out the Open-Closed Principle if you're not familiar with this concept). When your first tendency as a developer is to _modify_ the existing code to do what you need to do instead of _extending_ that same code, I believe you are doing the company an injustice as you are introducing more risk into the change. If the change you are making is similar to changes that have been made in the past, you should contemplate refactoring the code base so that the changes (and future changes along that same vector) are done through extension instead. To me, it's a sign of a mature and pragmatic developer to think along these lines. But then again, I'm still a youngin' and I'm sure some of you might disagree with me on this point.
So, is modifying OSS a "Bad Thing"? Not at all. You just have to realize that modifying the code comes with some added responsibilities. Can the company handle those added responsibilities? If your company can handle these and has the capacity to manage the upgrade path, then you can do so if necessary. Just remember though, just because you can modify the software doesn't necessarily mean you should. Are you and the company ready to pay the costs for your decision?