openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: working on a OpenOffice roadmap
Date Sat, 22 Oct 2011 12:55:13 GMT
On Sat, Oct 22, 2011 at 7:09 AM, Christian Lohmaier
<> wrote:
> On Sat, Oct 22, 2011 at 3:16 AM, Rob Weir <> wrote:
>> On Fri, Oct 21, 2011 at 8:28 PM, Andrew Douglas Pitonyak
>> <> wrote:
>>> Are you aware of the number of changes that have already been applied to the
>>> LibreOffice code base? It is very large. So, although it seems like a
>>> realistic desire on the surface, it may be difficult in practice. How long
>>> ago was the fork? Many people have spent significant time making changes,
>>> and many of those changes depend on earlier changes.
>> It really is not that hard.  At IBM we have our own fork of OOo called
>> Lotus Symphony.  We've made millions of lines of our own changes, but
>> we still have merged in many patches from OOo.  It requires some care,
>> but it is not rocket science.
> Yes, it is so easy and simple - and because it is such a piece of cake
> the contribution of the IA2 stuff is still not integrated years after
> its contribution has been promised and announced by IBM.

I think you prove it by the examples that have occurred, not the
examples that have not.  For example, did you ever wonder how how did
IBM Symphony and Novell's OpenOffice get VBA support around the same
time?  Hint:  it is the same code, and it was merged into both code
bases without great difficulty.

This is not rocket science.  It is the well-known economics of
software reuse.  A patch is another form of reuse.  it has a cost to
integrate that you compare to the cost avoided by not rewriting the
code. Where the balance is positive, then reusing the patch saves
effort  This is often, but not always, the case.

In any case, we should not be deterred by those who are arguing
against collaboration because it is hard.  Of course it is hard.  But
the hard part is more social than technical, and dogmatism is the
greater obstacle than code merging.


> But Martin Hollmichel's initial statement is already wrong on so many
> levels that the technical stuff doesn't really matter.
> ciao
> Christian

View raw message