gpoul's Out Of Memory Blog

I already blogged about open source versioning some time ago and what happens when you introduce multiple dependencies into your projects. More recently Bob Sutor discussed the issue of what happens when you use highly customized open source code. But how do you get your patches back into the upstream project so you don’t need to port all your customizations forward into new versions as they’re released, which can cause huge costs each time you have to integrate?

The decision seems to be easy. You needed a legal review to use open source in your commercial project anyway, so you get another approval to contribute your changes back. But what happens when the patch is not accepted or acceptance is dragged out for months? Open source projects usually don’t line up with your project schedule.

You’ll have to perform change integration anyways until the patch has been accepted upstream, but what will you do when the change is not accepted and you need to rework your patch for it to be accepted? Who’s going to pay for the costs associated with these changes? Who’s going to make sure that these changes are integrated into the software you developed based on the open source project and regression tested to make sure it performs as well as the old code?

I have a few ideas to address this type of situation, but their applicability varies depending on the project and what kind of open source project you might be using:

• The faithful approach: Don’t change the open source code and report issues to the bug tracker of the project and hope they’ll be fixed in a few days, months, or years.
• The painful approach: Plan for these continuous integrations and code rework and make them part of your schedule. It’s not easy to know how much cost will be associated with this and it’s probably not trivial to argue about them with a PM who wants to keep costs predictable, but that’s what “usually” happens when you change code that is owned and maintained by someone else.
• The commercial approach: Purchase a support contract for the open source code from someone who has project members with commit access on staff and have them fix the problem and integrate it upstream.
• The strategic approach: Have someone on staff who is a project member with commit access.

Did I miss any good ideas? Please feel free to share how you solve this problem in your organization!