incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: After AOO 3.4, attracting new contributors
Date Tue, 20 Mar 2012 10:09:39 GMT
	Hi Rob,

On 19.03.2012 13:41, Rob Weir wrote:
> There have been some side discussions on this topic.  I'd like to
> collect these ideas into one thread.
> My observations:
> 1) The OpenOffice code base has a reputation of being complex, hard to
> understand, even "haunted".  It is difficult for new developers to get
> involved with it.

Unfortunately true to a degree: There are new code parts which are 
attractive, most stuff based on UNO API and others, but there is also 
the old core code and application code. The UNO API was the start to 
modularize the office, and newer stuff often uses it. The quotient 
between this two classes of code is hard to guess, I personally think 
old code is still more. Most of the old code is in active use and not 
simply to be replaced, just think about more than a decade of fixes and 
extensions made there by developers also not knowing all of it (which is 
simply not possible) and thus leading to more and more entropy even with 
some good designed old interfaces.

> 2) We get regular offers of help from new volunteers for other project
> functions, such documentation, QA, website,etc., but we are not doing
> a great job getting them to be successful contributors in the project.

Right, hurdles when talking about code are (unfortunately) high, 
lowering them would be the prerequisite to attract more and to get to a 
point where the project scales to more developers and doing changes in a 
single area will not risk the whole office functionality.

> 3) Nothing is free.  Making the code easier to understand, or
> mentoring new contributors to the project, these things time and
> effort.

Correct, code refactoring would be necessary in many old code areas. It 
is doable and necessary, I'm doing it for DrawingLayer for six jears now 
and still a long way to go. It's like a gordian knot and even to find 
places to cut parts out for replacement without shredding the whole 
office is not easy. But doing so is possible and leads to better and new 
functionality (see AntiAliasing, better precision, speed, etc...). It 
needs to be done in far more areas than DrawingLayer, though. And it 
unfortunately needs a huge amount of knowledge of the code.

> So there is a natural trade-off between short term progress on
> features and long term growing of the contributor base.  With AOO 3.4
> we have biases the effort toward forward progress on the release. Post
> AOO 3.4 we might want to adjust to a more balanced approach.
> Any ideas and the best ways how we can improve in this area after AOO
> 3.4 releases?

The tradeoffs are hard, but splitting time in
- refactoring
- featues
- bugfixing
is the key, the ratio is hard to determine, maybe everyone has to find a 
balance for himself.

Others have detected that problem, and by also not having an endless 
resource count and not too many people with the needed deep knowledge of 
that old code the decision was to at least lower the entry hurdles by 
doing the doable: translating comments and removing unused code. Both 
not leading to direct benefits for the user, but targeted on attracting 

I personally would not put work in translating comments, but I do put a 
lot of work in dead code identification and removal. We need to go 
beyond that by refactoring, that is the key for slowly moving the big 
old codebase to deeper water, and I'll continue to do so for 
DrawingLayer. I hope to get back to aw080 (already available as branch 
under /branches/alg/aw080) where many deep changes to the DrawingLayer 
cores are already started, but not yet finished.

> -Rob


View raw message