Skip to main content

Branching open-source software: a bad thing?

Posted by mister__m on March 19, 2004 at 6:49 PM PST

It's been a while since I last blogged. Besides being busy in my regular job, I got sick and also had to finish this article about Reflection on Tiger. Well, I must say I am enjoying the new project I am working on, since I am being able to have almost full control about everything - except the deadline, but that's acceptable :-D Since the customer is really interested in achieving a quality product its employees can evolve, we have chosen technologies that would allow them to write their business code with minimum effort, but in a elegant way, resulting in a robust, performant application. So far, it looks like things are going fine in that sense.

However, I must say I am worried about something we started doing a few weeks ago. We are not using any technology in this project we haven't used before, so we already knew the limitations each technology had from day one and, even though, thought they'd be the most appropriate ones for this scenario. Many limitations were just bugs we had fixed before, posted to the code maintainers months ago, but that just hadn't been aplied. Others were lack of points of extension - interfaces, factories, protected methods and abstract classes, to name a few - that would allow us to adapt a framework or a tool to suit our needs. That's why the problem began. If you tell the project owner and the committers about bugs, provide them with patches, mention a few methods that need to be changed from private to protected, changes that would benefit most users and no one cares, what are you supposed to do?

We got our answer: we've branched those projects in our customer's local CVS. I have done it a few times in the past, but it always was just one branch for one project, not for nearly all of them! All the limitations we are facing are the ones we cannot simply workaround without making our daily code smell; generally speaking, there is no way to fix most of them in a single point and, when there is one, it would impose other limitations to our code that would make it even worse.

The problem with those branches is that they are really hard to manage. One thing is creating a CVS branch in a project your company owns; it's just a matter of communication and some work to manually resolve any conflicts when merging versions. Unfortunately, most open-source projects today tend to change frequently in incompatible ways, especially when you are not talking about classes most people use. Some developers will say: you just have to learn about what has been changed. But, sometimes, I don't want to!!! I just want to get a bug fixed, but if I've branched their code, it can become something too hard to do!

The real question is: why did I have to create a branch in the first case? Is it because the original code author assumed no one would need more flexibility or thought "I won't add it until someone needs it" and now is just too busy to take a look at the patch and get it fixed? Sadly, the answer most times is: yes, that's it. Nothing can be more frustating to a developer than writing code to fix a bug, write thorough instructions - and most of the times, code - to prove the bug exists and that your patch works and then noticing no one in the open-source project seems to care. It's a sad reality we have to face everyday when we push technologies a little bit. I just wish project leaders could learn to think ahead and to react quickly. And, no, it's not about having free time themselves to get it fixed; it's about managing a project. And it's something really, really harder to do than just coding.

Related Topics >>