Last week I finally finished Karl Fogel's “Producing Open Source Software“. I picked it up almost two years ago and life got in the way.
Anwyay, in one of the closing chapters, he discussed forking a project. As one of the leaders of web2project (the dotProject fork), this is near and dear to my heart. In reading through his perspective and opinions, a few things really struck me. Here's the most relevant passage:
Handling a Fork
If someone threatens a fork in your project, keep calm and remember your long-term goals. The mere existence of a fork isn't what hurts a project; rather, it's the loss of developers and users. Your real aim, therefore, is not to squelch the fork, but to minimize these harmful effects. You may be mad, you may feel that the fork was unjust and uncalled for, but expressing that publicly can only alienate undecided developers. Instead, don't force people to make exclusive choices, and be as cooperative as is practicable with the fork. To start with, don't remove someone's commit access in your project just because he decided to work on the fork. Work on the fork doesn't mean that person has suddenly lost his competence to work on the original project; committers before should remain committers afterward.
Source: Pages 226-227
After reading this, it struck me that although there has been an effort to trade security reports back and forth, that's pretty much where it's begun and ended. By all means, when either project makes a fix or improvement, the other should have it available to evaluate if it makes sense for them. It can't be an automated process as there are some significant – and ever growing – architectural differences between the systems…
So now the big question:
How do you coordinate collaboration between diverging codebases?
By the way, all of “Producing Open Source Software” is available under a Creative Commons license at ProducingOSS.com.