Michael Nascimento Santos's Blog

Branching open-source software: a bad thing?

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.

Comments

• It's a good thing
  If you have access to the source code and can fix your bug or solve the problem, go for it - after all, that's the main advantage about open source software
  And if you're in position to submit the changes back to the community (you could be working in a BSD-like license which didn't require you to do so and your company would prefer that you didn't give the chances back), better yet (after all, that's the "payment"the open source community excepts from you :-).

  Now, if they (the project developers) are accepting it, it's another issue. You said:

  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.

  I agree with you, but it's not that simple. If you provide a patch, chances are someone will commit it back to the project's main branch. The problem is, after your changes have been committed, the maintainer of that piece of code becomes the committer, notyou. What if your changes introduces more bugs later on? Remember, these committers usually work on these projects as volunteers...

  Let me show you 3 situations that happened with me on distinct Jakarta projects.

  1.I submitted an Ant patch months ago (the whole history was blogged here). It is a minor enhancement I thought it would be very useful, but it hasn't been accepted. I thought it very frustating too, but then I realize Ant receives lots of new bugs everyday, many of then as patches. So, it 's not that the developers didn't like my patch - they probably did, but they are already too busy with so many bugs/issues to handle that they would not want to deal with one more.

  2.A couple of weeks ago I had to setup a datasource on Tomcat. I never did it before, so I followed the documentation and realized it could be improved a little bit. Consequently, I submitted a bug and said I could send a patch if someone committed it - I didn't want to spend time on a patch that would not be accepted at all. Then someone (Remy) accepted my bug, I created and submitted the patch, it's now integrated on Tomcat's patch and everybody won.

  3.I'm a committer for the Jakarta Taglibs project. There is a couple of bugs with patch instructions I'd like to handle, but they are related to taglibs I'm not familiar with yet. I might be incorporating these patches in a near future, but I won't do so until I'm confortable enough about how the taglib works and what does the patch do.

  So, long story short:

  1.If you think your bug/improvement is really important but the project developers are ignoring it, you should try to convince them it's really important. The best way to do so is convincing other people of the importance - one thing is a person requesting a change, other thing is an angry mob :-)
  PS: that 's the approach I was going to follow on my Ant patch, but then someone pointed out a tool called Ant console did something similar to my proposal.

  2.If you are always fixing bugs on a project in order to get your work done, I'd suggest you join that project as committer, "sponsored" by your company (i.e., you would spend some of your paid hours working on that project). Of course, only your company's approval is not enough, you would need to gain the current committers' trust before joining the project. It shouldn't be a problem, though, in this situation (when you're already colaborating in the mailing lists and bug management). Actually, there was a good JavaOne session about the issue last year( either this or that, not sure).

  Just my 2 cents,

  Felipe

  
  

  Posted by: felipeal on March 21, 2004 at 08:17 AM

• money
  I've had contact with a few open source projects in the past, either to report problems we were having or to try to help out.

  The experience was generally not encouraging.

  One project I joined and submitted code to (I was a committer there for a while) the maintainers kicked out the other committers and started selling the code, we didn't even get a license to use it.

  Another time the only answer I got was that they would help if only we paid them first (this was on a bugreport, we'd likely have offered them help to solve it had they been responsive).

  With experiences like this I've about had it with most of the open source movement.
  

  Posted by: jwenting on March 22, 2004 at 12:11 AM

• An unrepresentative sample?
  "With experiences like this I've about had it with most of the open source movement."

  Since when does two bad projects represent the whole of the Open Source movement?

  Do you have any references to the projects which gave you the responses you mention? *Please* back up your assertions with references, otherwise it may appear to some people that your statements are simply anti-open source FUD.

  Posted by: philwebster on March 22, 2004 at 05:10 AM

• An unrepresentative sample?
  Note also that neither is actually a 'bad project', at least going by the evidence presented.

  If the first project was BSD licenced then the maintainers (or anyone else for that matter) have every right to take it closed source. If there was no-one left to maintain the open source'd project, well, see my next point, but regardless the original poster would still have access to the previously open code to do with as they wished.

  The second 'problem' is simply a sovereign human being not immediately doing what the original poster wanted them to do, and *shock* *horror* expecting to be paid to do work for someone else.

  The fact that the programmer was willing to negotiate a fee for rearranging their development priorities and doing this work first, combined with the fact that their code was under a licence that allows you to hire anyone qualified to do the work shows more willing than many people I've done business with.

  Posted by: bawjaws on March 22, 2004 at 06:17 AM

This work is licensed under a Creative Commons License.