Re-merging
While I love having the flexibility to edit source code to meet one's needs, the fact is, most organizations lack the talent to do so.
More importantly, though, is the difficulty caused in re-merging your changes later on. No IT executive that I have met will sign off on a project where if a critical update is released, not only do you need to re-test before pushing to Production, but you also need to check the changes in the patch against your customized changes.
As an example, a while back I was working with ZenCart. The thing was architected like a level from Pipe Dream. Every change I needed to make involved ripping apart the core of the system. Upgrading to a newer version would have involved at minimum a week of source code inspection, reverification, and code merging.
99.9% of IT shops are unwilling to take that on, and it is reflected in the number of enterprise IT shops that actually modify the source code to their OSS apps. When you pay thousands for RHEL or SLES because you need support, you are not going to turn around and invalidate that support by hacking up the code in the approved stack. When you call your vendor for support, they will hang up the moment they find out that you touched the certified stack.
In other words, one of the great strengths of open source goes completely unleveraged, because it is contrary to the needs of most businesses.
J.Ja
