Wed Apr 26 10:38:09 CEST 2006

Opinion: how forks could (and should!) cooperate with the mainstream? project has several forks or derived works, if you want to. I was asked privately how do I want forks to cooperate with the mainstream Here is my opinion.

Maintainers of forks do very hard work maintaining their patches/sources in separate CVS/other SCM systems and track both the development of and also their own developments containing their specific features and enhancements. Sun is using the same mechanism to work on their StarOffice, Planamesa is using the same mechanism to work on NeoOffice, some (many, in fact) GNU/Linux vendors are closely cooperating on ooo-build etc.

They can save a lot of work on their side (and on our side and all other forks' side as well) by closely cooperating with the mainstream and isolating the changes they need to get their stuff working and submitting the generic changes back to the mainstream and even working on their proper integration. This brings them not only much easier work in the future, better human relationship with the mainstream developers, but also community respect!

I more than welcome the recent change in ooo-build. They accept patches to the code only if the issue has its IssueZilla ID assigned. Of course it is not acceptable for all forks and all enhancements (imagine issues like "StarOffice: Prepare UI theme for NASA" or "Remove Patrick's brutal Java hack in dtrans" visible for all) but this is a way to go with general changes. Unfortunately all forks have (sometimes) problems with identifying what is special change and what can be used also by other forks/mainstream. But we have to live with that.

We can't force forks to work with us closely because we have chosen GNU LGPL as our license. But we can ask them to be polite and submit issues with fixes back to us and we can offer community respect to them.

Posted by Pavel | Permanent link | File under:, Mac OS X