OOO and LibreOffice.

["Ted Rolle, Jr." <st...@gmail.com>]

Perhaps I'm jaded, but when you have data in two places, you can be sure
of one thing:  they're both wrong.

I fear that the *Office camps will be in some sort of competition.
Competition means that there is a winner, and a loser.

The good thing is that one will survive and become the de-facto
standard.

Prove me wrong!

Re: OOO and LibreOffice.

[IngridvdM <In...@gmx-topmail.de>]

Hi Thorsten,

Am 04.07.2011 09:32, schrieb Thorsten Behrens:
> Ross Gardler wrote:
>> At present the only way I can see to start doing this is to a) drop
>> the ego on both "sides", this is a different world from the one in
>> which the fork was seen as necessary. There are still fundamental
>> licence differences, but I am sure that, for many, the licence is less
>> important than getting results. b) spending some time understanding
>> one another (for some that will mean rebuilding relationships) in
>> order to work towards your second suggestion...
>>
> Hi Ross,
>
> hm, not sure I like your particular combination of a) and b) here -
> understanding the other side should start with admitting that indeed
> for a not insubstantial subset of LibreOffice hackers, the license
> indeed *is* important. ;)
>
>> I don't know OOo or LO well enough to know if there is scope for a
>> "common, well-defined cooperative objective." It would be great if
>> some people could spend some time considering this. It might well be
>> that there is little scope for true collaboration. However, during the
>> proposal phase there were a few people who wanted to explore this.
>>
> To be frank - having two projects targetting the ~same {market,
> devs, QA, sponsors, code lines, ...} makes this extra-hard. It's
> like asking two boys in a dog fight to both voluntarily step back&
> shake hands - whereas in reality, it'll likely only stop after one
> side has "won" (for some values of "win" and "reality").
>
>  From the earlier discussions, the idea to focus on basis
> libraries/functionality at Apache, and build applications on top of
> that had some appeal to me - also since it appeared to be much more
> in line with (most of) the other Apache projects.
>
Is there any offer for cooperation from the LibreOffice/TDF side in your 
words?

Kind regards,
Ingrid

> Cheers,
>
> -- Thorsten

Re: OOO and LibreOffice.

[Thorsten Behrens <th...@documentfoundation.org>]

Ross Gardler wrote:
> At present the only way I can see to start doing this is to a) drop
> the ego on both "sides", this is a different world from the one in
> which the fork was seen as necessary. There are still fundamental
> licence differences, but I am sure that, for many, the licence is less
> important than getting results. b) spending some time understanding
> one another (for some that will mean rebuilding relationships) in
> order to work towards your second suggestion...
> 
Hi Ross,

hm, not sure I like your particular combination of a) and b) here -
understanding the other side should start with admitting that indeed
for a not insubstantial subset of LibreOffice hackers, the license
indeed *is* important. ;)

> I don't know OOo or LO well enough to know if there is scope for a
> "common, well-defined cooperative objective." It would be great if
> some people could spend some time considering this. It might well be
> that there is little scope for true collaboration. However, during the
> proposal phase there were a few people who wanted to explore this.
> 
To be frank - having two projects targetting the ~same {market,
devs, QA, sponsors, code lines, ...} makes this extra-hard. It's
like asking two boys in a dog fight to both voluntarily step back &
shake hands - whereas in reality, it'll likely only stop after one
side has "won" (for some values of "win" and "reality").

From the earlier discussions, the idea to focus on basis
libraries/functionality at Apache, and build applications on top of
that had some appeal to me - also since it appeared to be much more
in line with (most of) the other Apache projects.

Cheers,

-- Thorsten

RE: OOO and LibreOffice.

["Dennis E. Hamilton" <de...@acm.org>]

I concur.  It makes no sense for LibreOffice contributors to be asked to make their patches available under ALv2 as well as the LGPL3+ and MPL that they are already being asked to submit under (all without any CLA anywhere, of course).  It also makes no further sense to expect that commercial firms with proprietary implementations will start making code available under [L]GPL or accepting contributions with such licenses.

There are specific limitations that the different licenses (and the CLA requirement) have for folks and expecting the other guy to change seems to be nothing but an opportunity cost sink.

For example, I regard [L]GPL code as toxic and I avoid even reading it, although I have filed an iCLA, am an Apache OpenOffice.org Podling committer, and am happy to read and contribute to code under the ALv2 and other permissive licenses, including the venerable BSD license model.  It's my choice and the ALv2 licensing of the OpenOffice.org code base is a god-send for me to the extent it is a playing field I can consider entering.

At the same time, as I'm sure has been noticed, there are many folks who participate in both the Apache OpenOffice.org Podling and LibreOffice in various ways.  Apart from our differences, there is also a great deal where some of us are quite agnostic and have no quarrel with either and both projects succeeding, along with others, including (for some of us) commercial ones.  

My over-riding passion is about achievement of interoperability as well as some increased quality that is possible with more complete ODF specifications as well as descriptions of the extent to which ODF is supported in implementations.  I don't care how interoperability is achieved nor by whom, simply the fact of its achievement.

I say that there are a variety of areas of common interest that can be addressed cooperatively by the extended community, regardless of whether or not patches and code are shared, and in whatever directions.  We can and should avoid hot-button issues that become show-stoppers and focus on areas of agreement.  I believe there are many to be found.  It is for the mutual benefit of our users and I think that should be the compelling factor.

 - Dennis

-----Original Message-----
From: Michael Meeks [mailto:michael.meeks@novell.com] 
Sent: Monday, July 04, 2011 02:18
To: ooo-dev@incubator.apache.org
Subject: Re: OOO and LibreOffice.

Hi Rob,

On Sun, 2011-07-03 at 21:03 -0400, Rob Weir wrote:
> Any chance of TDF requiring Apache 2.0 for new code
> contributions, in addition to their current requirement
> for LGPL/MPL ?

	What an extraordinary question. I had thought it was (by now) fairly
clear that many companies and many volunteer developers around TDF had
made their pragmatic, and in some cases idealistic commitment to
copy-left licensing super-abundantly clear. I don't think that is a
matter of ego, personally.

	It seems ~pointless to suggest a copy-left license dualed with a
non-copy-left license: that is just a non-copy-left license.

	For TDF to -require- that would be incredibly dumb, cf. loosing many of
our developers. Of course, perhaps some of our membership, and more
importantly the developers owning the code might agree to that - but I
for one would argue strongly against it.

> Doing so would open up many more possibilities for future
> collaboration and cooperation.  Not doing so would severely
> constrain possibilities for cooperation.

	Sure - but there are lots of other options for opening up possibilities
for collaboration and co-operation, such as IBM making a commitment to
working with the developer community and respecting the license we (IBM
and the TDF) compromised :-) Of course the TDF door is always open to
new contributors no matter how they have behaved in the past.

	However so far I see no possibility of any such compromise, only of
reality eventually biting. Lets see which ideology is eventually bitten
hardest: it'll be an interesting experiment for sure.

	HTH,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot

Re: OOO and LibreOffice.

[Michael Meeks <mi...@novell.com>]

Hi Rob,

On Sun, 2011-07-03 at 21:03 -0400, Rob Weir wrote:
> Any chance of TDF requiring Apache 2.0 for new code
> contributions, in addition to their current requirement
> for LGPL/MPL ?

	What an extraordinary question. I had thought it was (by now) fairly
clear that many companies and many volunteer developers around TDF had
made their pragmatic, and in some cases idealistic commitment to
copy-left licensing super-abundantly clear. I don't think that is a
matter of ego, personally.

	It seems ~pointless to suggest a copy-left license dualed with a
non-copy-left license: that is just a non-copy-left license.

	For TDF to -require- that would be incredibly dumb, cf. loosing many of
our developers. Of course, perhaps some of our membership, and more
importantly the developers owning the code might agree to that - but I
for one would argue strongly against it.

> Doing so would open up many more possibilities for future
> collaboration and cooperation.  Not doing so would severely
> constrain possibilities for cooperation.

	Sure - but there are lots of other options for opening up possibilities
for collaboration and co-operation, such as IBM making a commitment to
working with the developer community and respecting the license we (IBM
and the TDF) compromised :-) Of course the TDF door is always open to
new contributors no matter how they have behaved in the past.

	However so far I see no possibility of any such compromise, only of
reality eventually biting. Lets see which ideology is eventually bitten
hardest: it'll be an interesting experiment for sure.

	HTH,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot

Re: OOO and LibreOffice.

[André Schnabel <an...@gmx.net>]

Hi Rob,


Am 04.07.2011 03:03, schrieb Rob Weir:
>
> Any chance of TDF requiring Apache 2.0 for new code contributions, in
> addition to their current requirement for LGPL/MPL?

You asked this already, and afair I did answer on that.

Although formally the SC can decide on this, I (with my hat as SC 
member) would veto any such decision that is not done by the TDF 
members.  It does not matter at all what the SC decides, when current 
developers stop contributing because we enforce apache license.

Although I like the idea of collaboration I would surely not advice our 
(TDF) members to stop working just to be able to collaborate.

regards,

André

Re: OOO and LibreOffice.

[Raphael Bircher <r....@gmx.ch>]

Hi Drini

Am 05.07.11 10:54, schrieb Drini Nosi:
> As I read this thread, it makes me a bit sad to see that the community of the OpenSourceOffice is actually splitting in two, and I don't understand why.
The history of the split is realy complicate, and you will have two 
different storries as minimum. One from the OpenOffice.org Community and 
one from the LibO Community.
> I am not a developer, just a user, so I don't understand the technicalities. I can understand the differences between the licenses and their meaning to the developers, but wouldn't it been better to have ONE open project? If LibreOffice would have not started, then Apache OpenOffice.org would have not happened.
Maybe, but not sure. A OOo has nothing to do with LibO directly. A OOo 
was happend because Oracle will step back from the project, and OOo need 
a new home. The reason why Oracle step back knows Oracle only. My 
meanign is cause the failure of ther Commercial products (Oracle Open 
Office and Cloud Office)
> TDF promisses an open and friendly environment to contribute. I don't (HONESTLY) understand why the developers don't want to contribute to LibreOffice, but want to spilt the project in two? (Speaking in user terms).
TDF and LibO has a complietly different development strategie to 
OpenOffice.org. Same people don't like me don't think that this is a 
goot choice vor a project like that. Time will tell who winns.

Greetings Raphael


-- 
My private Homepage: http://www.raphaelbircher.ch/

Re: OOO and LibreOffice.

["Pedro F. Giffuni" <gi...@tutopia.com>]

Hello ...

--- On Tue, 7/5/11, Drini Nosi <dr...@gmail.com> wrote:
...
> As I read this thread, it makes me a
> bit sad to see that the community of the OpenSourceOffice is
> actually splitting in two, and I don't understand why.
>

Corporate interests. Some linux distributions and developers
were not happy with the copyright owner and started a fork.
Please note that Apache didn't fork, and didn't split any
community, we were just offered the chance to do something new
and absolutely cool.
 
> I am not a developer, just a user, so I don't understand
> the technicalities. I can understand the differences between
> the licenses and their meaning to the developers, but
> wouldn't it been better to have ONE open project? If
> LibreOffice would have not started, then Apache
> OpenOffice.org would have not happened.
>

That's very speculative. Apache OpenOffice is not happening
due to LibreOffice, it's an entirely independent project with
different objectives; one of them providing a truly open
alternative to copyleft alternatives.

 
> TDF promisses an open and friendly environment to
> contribute. I don't (HONESTLY) understand why the developers
> don't want to contribute to LibreOffice, but want to spilt
> the project in two? (Speaking in user terms).
>

No one is splitting anything. I personally prefer not to
contribute anything different than bug reports to copyleft
projects, so for me Apache OO is a good opportunity to
actually contribute to something, otherwise I would choose
not to contribute at all.
 
> From one side, the concurrence can be good because it makes
> the participants of the two projects strive to make
> something better then the other, but at the end this is a
> voluntary BIG project (LibreOffice + Apache
> OpenOffice.org).
> 
> Why not be ONE project? 
>

Ask calligra, koffice, abiword, etc ... or the many linux
distributions (Remember United Linux?). I have no answer
for that, other than perhaps users value diversity.

cheers,

Pedro.
 

Re: OOO and LibreOffice.

[Drini Nosi <dr...@gmail.com>]

As I read this thread, it makes me a bit sad to see that the community of the OpenSourceOffice is actually splitting in two, and I don't understand why.

I am not a developer, just a user, so I don't understand the technicalities. I can understand the differences between the licenses and their meaning to the developers, but wouldn't it been better to have ONE open project? If LibreOffice would have not started, then Apache OpenOffice.org would have not happened.

TDF promisses an open and friendly environment to contribute. I don't (HONESTLY) understand why the developers don't want to contribute to LibreOffice, but want to spilt the project in two? (Speaking in user terms).

From one side, the concurrence can be good because it makes the participants of the two projects strive to make something better then the other, but at the end this is a voluntary BIG project (LibreOffice + Apache OpenOffice.org).

Why not be ONE project? 

I don't see differences in feature visions, only differences on names and brands, and maybe also licenses. Only about structures. LibreOffice is a great start, why make a second best start? As a result LibreOffice+Apache OpenOffice.org will have a long start because split.

I have meant for a long time to make this questions.

Best regards and hoping that the two projects will be ONE, lets say also a federation :)

Drini.

LO Changes ...

["Pedro F. Giffuni" <gi...@tutopia.com>]

Just thought I'd mention...

Looking at the initial LO-dev mail archive there are some nice
summaries of their first set of changes and in many cases they
include the OOo bugzilla ID:

http://lists.freedesktop.org/archives/libreoffice/2010-October/000311.html
http://lists.freedesktop.org/archives/libreoffice/2010-October/000812.html
http://lists.freedesktop.org/archives/libreoffice/2010-October/001143.html

The FreeBSD port is also mentioned there and you can
get Maho's latest FreeBSD patches here:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice.org-3-devel/files/

There is also an idea that I was considering for A-OOo:
using Coverity scans:
http://scan.coverity.com/developers-faq.html

Something to consider when we have a tree to start
with.

cheers,

Pedro.

Re: OOO and LibreOffice.

["Pedro F. Giffuni" <gi...@tutopia.com>]

--- On Mon, 7/4/11, Rob Weir <ap...@robweir.com> wrote:
...
> Pedro F. Giffuni wrote:
> > In general I avoid commenting threads like this, as
> > in my POV the licensing differences are not
> > surmountable..
> >
> 
> It is hard to tell whether 100% of TDF developers insist
> on copyleft.
>  Certainly there is a vocal contingent for which the
> license issue is a deal breaker.  But there are others
> who are indifferent, and will be willing to work with
> us on areas of mutual interest. 

Oh, I agree. Not everyone is visceral about the license.
Unfortunately we cannot expect them to contribute while
we are not offering them anything in particular, so I
think we have to finish setting up our stuff first and
eventually they will come.

On the long run I think what we have to offer is
openness. As I said in a FreeBSD list ... contributing
to Apache OO is the best way to make sure that our
changes will get into both projects.

Pedro.

ps. BTW Rob, a Lotus Symphony port to FreeBSD would
be welcome :).

Re: OOO and LibreOffice.

[Rob Weir <ap...@robweir.com>]

On Mon, Jul 4, 2011 at 12:19 PM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
> In general I avoid commenting threads like this, as in my
> POV the licensing differences are not surmountable..
>

It is hard to tell whether 100% of TDF developers insist on copyleft.
 Certainly there is a vocal contingent for which the license issue is
a deal breaker.  But there are others who are indifferent, and will be
willing to work with us on areas of mutual interest.  As Simon said,
TDF is happy to accept Apache 2.0 code.  Great.  So we work with those
who are willing to work with us, even if it is a subset of the full LO
project.  Even if it is a small subset.  I'm certain that we'll find
areas where we collaborate.

> --- On Mon, 7/4/11, Simon Phipps <si...@webmink.com> wrote:
> ...
>>
>> >
>> > As each developer retains ownership of their code it
>> maybe better to ask
>> > on the developers list [1].  The SC has no
>> control over the devs.
>> >
>> > [1] libreoffice@lists.freedesktop.org
>> >
>>
>> Since Rob is asking the Steering Committee to make a
>> statement, their list
>> is the best place to do that.
>>
>
> I don't see much hope in that request, especially since
> someone already mentioned the word "veto" if it ever
> happens.
>

I see nothing in the TDF bylaws that speaks of a "veto".  So I'm
taking that as just a "no" vote.

http://wiki.documentfoundation.org/CommunityBylaws

> What I think could be done is to work out some mechanism
> where LibreOffice developers can tag their commits as AL,
> and that we can take those changes without anyone signing
> an ICLA, but by the time that is arranged I doubt most of
> the LO patches may apply cleanly, and for the time being
> we do have a LOT to do to make the incubation successful.
>


So a few tangible modes of collaboration:

1) LO as downstream consumer.  This is what LO has done with OOo 3.3
and 3.4.0.  It is what LO's predecessor, Novell's Go-OO, did for many
years as well.  This can continue well into the future, if LO wishes.
 But I don't think they do.

2) Patch exchange.  A developer who fixes a bug or adds a feature can
contribute it to both projects under each project's respective
license.

3) A componentized approach to #1 above.  So instead of  the entirety
of AOOo, LO takes selected components, similar to how they (and we)
take components from other open source projects.

4) Like #3 above, but where we take components from LibreOffice.  This
might be possible in specific cases, even with LGPL licensed  code,
provided this is unmodified binaries, optional features, etc.  (I'm
not intimate with the exact rules at Apache for this, but it seems
that there may be some scope for collaboration even here).,

However you look at it, it seems the finer grained approaches give us
the most flexibility, since we only need to rely on the willingness of
individual developers to collaborate.  Of course, a modular approach
has many other benefits and is something we should be considering in
any case.

-Rob

> Pedro.
>

Re: OOO and LibreOffice.

["Pedro F. Giffuni" <gi...@tutopia.com>]

In general I avoid commenting threads like this, as in my
POV the licensing differences are not surmountable..

--- On Mon, 7/4/11, Simon Phipps <si...@webmink.com> wrote:
...
> 
> >
> > As each developer retains ownership of their code it
> maybe better to ask
> > on the developers list [1].  The SC has no
> control over the devs.
> >
> > [1] libreoffice@lists.freedesktop.org
> >
> 
> Since Rob is asking the Steering Committee to make a
> statement, their list
> is the best place to do that.
>

I don't see much hope in that request, especially since
someone already mentioned the word "veto" if it ever
happens.

What I think could be done is to work out some mechanism
where LibreOffice developers can tag their commits as AL,
and that we can take those changes without anyone signing
an ICLA, but by the time that is arranged I doubt most of
the LO patches may apply cleanly, and for the time being
we do have a LOT to do to make the incubation successful.
 
Pedro.

Re: OOO and LibreOffice.

[Simon Phipps <si...@webmink.com>]

On Sun, Jul 3, 2011 at 10:28 PM, Andy Brown <an...@the-martin-byrd.net>wrote:

>
> As each developer retains ownership of their code it maybe better to ask
> on the developers list [1].  The SC has no control over the devs.
>
> [1] libreoffice@lists.freedesktop.org
>

Since Rob is asking the Steering Committee to make a statement, their list
is the best place to do that.

S.

Re: OOO and LibreOffice.

[Andy Brown <an...@the-martin-byrd.net>]

Simon Phipps wrote:
> 
> It's certainly worth asking, although I believe their current LGPLv3+MPL
> policy is more a suggestion than a requirement so it would ultimately be up
> to each contributor. Perhaps you could ask on the steering-discuss list[1]?
> 
> 
> S.
> 
> 
> 
> [1]  http://listarchives.documentfoundation.org/www/steering-discuss/
> 

As each developer retains ownership of their code it maybe better to ask
on the developers list [1].  The SC has no control over the devs.

[1] libreoffice@lists.freedesktop.org

Andy

Re: OOO and LibreOffice.

[Simon Phipps <si...@webmink.com>]

On Sun, Jul 3, 2011 at 10:03 PM, Rob Weir <ap...@robweir.com> wrote:

> On Sun, Jul 3, 2011 at 8:40 PM, Simon Phipps <si...@webmink.com> wrote:
> >
> > On 3 Jul 2011, at 19:43, Ross Gardler wrote:
> >
> >> But before we can
> >> get to that point we need to address the technical differences between
> >> the two code bases. LO is already 8 months or so adrift of OOo (or at
> >> least that is what I am led to believe).
> >
> > It's worth observing that the code that new developers will be able to
> work on at Apache is also likely to have significant differences from the
> last release from the Sun/Oracle infrastructure, as well as a completely
> different workflow. I suspect we'll all have no choice but to accept there's
> a lot of refactoring and relearning to do whatever happens.
> >
> >> What happened to the plan for OOo and TDF people to get together?
> >
> > We attempted it here at FISL and had a good turnout to the sessions Jomar
> Silva organised (and which I attended too). The result is a commitment (in
> the form of a letter of intent signed by on behalf of the responsible
> minister) by the Brazilian government to invest in both AOOo and
> LibreOffice. I hope we'll have a news posting about it early in the week.
> >
> > It's tough, because there's a lot of emotion and history on both "sides",
> but I agree with Jomar that it's possible to devise ways to work together.
> One challenge we'll have with the new developers that Brazil will commit
> will be getting engaged with the codebase. We think a great way for them to
> do that now (rather than at an unknown point in the future) is to use the
> "Easy Hacks" page that LibreOffice has put together to go start work on the
> code now.
> >
> > I suggest we encourage others to do the same.  Doing so is educational
> and co-operative, and TDF are perfectly happy to accept contributions under
> the Apache license.
> >
>
> Simon,
>
> Any chance of TDF requiring Apache 2.0 for new code contributions, in
> addition to their current requirement for LGPL/MPL?  My reading of
> their rules suggests that a simple majority of their Steering
> Committee authorize such a change.  Doing so would open up many more
> possibilities for future collaboration and cooperation.  Not doing so
> would severely constrain possibilities for cooperation.
>

It's certainly worth asking, although I believe their current LGPLv3+MPL
policy is more a suggestion than a requirement so it would ultimately be up
to each contributor. Perhaps you could ask on the steering-discuss list[1]?


S.



[1]  http://listarchives.documentfoundation.org/www/steering-discuss/

Re: OOO and LibreOffice.

[Rob Weir <ap...@robweir.com>]

On Sun, Jul 3, 2011 at 8:40 PM, Simon Phipps <si...@webmink.com> wrote:
>
> On 3 Jul 2011, at 19:43, Ross Gardler wrote:
>
>> But before we can
>> get to that point we need to address the technical differences between
>> the two code bases. LO is already 8 months or so adrift of OOo (or at
>> least that is what I am led to believe).
>
> It's worth observing that the code that new developers will be able to work on at Apache is also likely to have significant differences from the last release from the Sun/Oracle infrastructure, as well as a completely different workflow. I suspect we'll all have no choice but to accept there's a lot of refactoring and relearning to do whatever happens.
>
>> What happened to the plan for OOo and TDF people to get together?
>
> We attempted it here at FISL and had a good turnout to the sessions Jomar Silva organised (and which I attended too). The result is a commitment (in the form of a letter of intent signed by on behalf of the responsible minister) by the Brazilian government to invest in both AOOo and LibreOffice. I hope we'll have a news posting about it early in the week.
>
> It's tough, because there's a lot of emotion and history on both "sides", but I agree with Jomar that it's possible to devise ways to work together. One challenge we'll have with the new developers that Brazil will commit will be getting engaged with the codebase. We think a great way for them to do that now (rather than at an unknown point in the future) is to use the "Easy Hacks" page that LibreOffice has put together to go start work on the code now.
>
> I suggest we encourage others to do the same.  Doing so is educational and co-operative, and TDF are perfectly happy to accept contributions under the Apache license.
>

Simon,

Any chance of TDF requiring Apache 2.0 for new code contributions, in
addition to their current requirement for LGPL/MPL?  My reading of
their rules suggests that a simple majority of their Steering
Committee authorize such a change.  Doing so would open up many more
possibilities for future collaboration and cooperation.  Not doing so
would severely constrain possibilities for cooperation.

-Rob

> S.
>
>
> [1] http://wiki.documentfoundation.org/Development/Easy_Hacks

Re: OOO and LibreOffice.

[Simon Phipps <si...@webmink.com>]

On 3 Jul 2011, at 19:43, Ross Gardler wrote:

> But before we can
> get to that point we need to address the technical differences between
> the two code bases. LO is already 8 months or so adrift of OOo (or at
> least that is what I am led to believe).

It's worth observing that the code that new developers will be able to work on at Apache is also likely to have significant differences from the last release from the Sun/Oracle infrastructure, as well as a completely different workflow. I suspect we'll all have no choice but to accept there's a lot of refactoring and relearning to do whatever happens.

> What happened to the plan for OOo and TDF people to get together?

We attempted it here at FISL and had a good turnout to the sessions Jomar Silva organised (and which I attended too). The result is a commitment (in the form of a letter of intent signed by on behalf of the responsible minister) by the Brazilian government to invest in both AOOo and LibreOffice. I hope we'll have a news posting about it early in the week. 

It's tough, because there's a lot of emotion and history on both "sides", but I agree with Jomar that it's possible to devise ways to work together. One challenge we'll have with the new developers that Brazil will commit will be getting engaged with the codebase. We think a great way for them to do that now (rather than at an unknown point in the future) is to use the "Easy Hacks" page that LibreOffice has put together to go start work on the code now. 

I suggest we encourage others to do the same.  Doing so is educational and co-operative, and TDF are perfectly happy to accept contributions under the Apache license.

S.


[1] http://wiki.documentfoundation.org/Development/Easy_Hacks

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

On 3 July 2011 23:29, Ted Rolle Jr. <st...@gmail.com> wrote:
> I've been a programmer for many years.  I've seen projects succeed and
> projects fail.
>
> Someone has said that managing programmers is akin to herding cats.
>
> Programmers put blood, sweat, tears, and ego into their code (or at least
> they should!).
> For many programmers, their code is their art.
> When this is the case, they - quite naturally - become protective of their
> code.
> With this philosophy/scenario, there can rarely be smooth roads.
>
> One of the philosophies that I had the unfortunate experience of working
> under was 'egoless code'.
> Yeah, sure.
> Sounded good to the managers.  It rarely worked in reality.

The Apache Way is all about what some might call "ego-less code".
However, this project does face a different issue, not commonly found
in other ASF projects.

How do we work with the community split between OOo and LO. It would
be great if we could get past ego and work together. But before we can
get to that point we need to address the technical differences between
the two code bases. LO is already 8 months or so adrift of OOo (or at
least that is what I am led to believe).

At present the only way I can see to start doing this is to a) drop
the ego on both "sides", this is a different world from the one in
which the fork was seen as necessary. There are still fundamental
licence differences, but I am sure that, for many, the licence is less
important than getting results. b) spending some time understanding
one another (for some that will mean rebuilding relationships) in
order to work towards your second suggestion...

> Another suggestion is that the teams pursue a common, well-defined
> cooperative (read: non-competitive!) objective.

I don't know OOo or LO well enough to know if there is scope for a
"common, well-defined cooperative objective." It would be great if
some people could spend some time considering this. It might well be
that there is little scope for true collaboration. However, during the
proposal phase there were a few people who wanted to explore this.

What happened to the plan for OOo and TDF people to get together?

Ross

>
> On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler <rg...@opendirective.com>
> wrote:
>>
>> Hi Ted,
>>
>> I think the warning in your mail should be heeded. Whilst there are
>> opportunities and established practices for collaboration on shared
>> code, ensuring the collaboration happens can be difficult. It requires
>> a certain level of humility, patience and effort on the part of all
>> involved.
>>
>> Since you are obviously concerned about this do you have any ideas
>> that can help us develop the right relationship for collaboration
>> between the different parties involved?
>>
>> Ross
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: OOO and LibreOffice.

["Ted Rolle Jr." <st...@gmail.com>]

I've been a programmer for many years.  I've seen projects succeed and
projects fail.

Someone has said that managing programmers is akin to herding cats.

Programmers put blood, sweat, tears, and ego into their code (or at least
they should!).
For many programmers, their code is their art.
When this is the case, they - quite naturally - become protective of their
code.
With this philosophy/scenario, there can rarely be smooth roads.

One of the philosophies that I had the unfortunate experience of working
under was 'egoless code'.
Yeah, sure.
Sounded good to the managers.  It rarely worked in reality.

<walkthrough>
One strategy that kinda/sorta worked was "code walkthroughs".
It was understood beforehand that these were code walkthroughs, *not* "code
walkons".
The programmer invited other programmers to a conference where they could
comment on (not criticize!) the programmer's code.
The invitees did not need to be familiar with the project.
It brought the programmer out of the solitary environment that we get into.
It was, for the most part, a learning opportunity for all involved.
It also increased respect for other's coding ability.
</walkthrough>

Another suggestion is that the teams pursue a common,
*well-defined*cooperative (read: non-competitive!) objective.

On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler <rg...@opendirective.com>wrote:

> Hi Ted,
>
> I think the warning in your mail should be heeded. Whilst there are
> opportunities and established practices for collaboration on shared
> code, ensuring the collaboration happens can be difficult. It requires
> a certain level of humility, patience and effort on the part of all
> involved.
>
> Since you are obviously concerned about this do you have any ideas
> that can help us develop the right relationship for collaboration
> between the different parties involved?
>
> Ross
>

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

Hi Ted,

I think the warning in your mail should be heeded. Whilst there are
opportunities and established practices for collaboration on shared
code, ensuring the collaboration happens can be difficult. It requires
a certain level of humility, patience and effort on the part of all
involved.

Since you are obviously concerned about this do you have any ideas
that can help us develop the right relationship for collaboration
between the different parties involved?

Ross

On 3 July 2011 04:39, Ted Rolle, Jr. <st...@gmail.com> wrote:
> Perhaps I'm jaded, but when you have data in two places, you can be sure
> of one thing:  they're both wrong.
>
> I fear that the *Office camps will be in some sort of competition.
> Competition means that there is a winner, and a loser.
>
> The good thing is that one will survive and become the de-facto
> standard.
>
> Prove me wrong!
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

On 7 July 2011 13:10, Mathias Bauer <Ma...@gmx.net> wrote:
> On 07.07.2011 13:09, Ross Gardler wrote:
>
>> On 6 July 2011 23:51, Andrew Rist <an...@oracle.com> wrote:
>>>
>>> To date the LibreOffice crew has taken the effort to merge in changes from
>>> the OOo code line, for each release.
>>> The most obvious and best way to collaborate in the future is to write good
>>> code, and make it worth their while to integrate it into LO.
>>> The more compelling the development effort at Apache, the more likely it is
>>> reused by LO.
>>> This also leads to the situation where they have an interest in pushing
>>> changes into the AOOo code line, to simplify their future merges.
>>
>> I agree 100% with this.

...

>> I'm a Java weenie, so I think in terms of JARs that can be reused
>> easily. Is there any scope in the OOo project for similar library
>> reuse? If so where is the low hanging fruit?
>
> Whether you need to merge changes does not depend on the code itself, it
> depends on whether you have any changes done and if you want to push
> them upstream. These changes can also appear in code that otherwise
> could be reused easily.
>
> IMHO it's not a matter what code can be shared easily as a separate
> package, but where merging code changes is harder. Sometimes there's a
> relation between these two, but not always. The more active development
> in a particular code part happens on both sides, regardless how the code
> is packaged at the end, the harder it will get to merge the changes.

Agreed. I may be being naive, but I'm not afraid of exposing such
personality traits if it helps us explore ways in which people can
become more productive.

> Nevertheless it would be an interesting approach to package some stuff
> separately and give it a life independent from the OOo application code
> base. Ideal candidates would be UNO and its runtime libraries (URE), the
> SDK and the build system.   That's the reason why I recommended these
> areas as a field for collaboration, with the goal to establish trust and
> relationships between the developers that we can build on.

Thanks, I've added those to my list of potential wins.

Ross

Re: OOO and LibreOffice.

[Mathias Bauer <Ma...@gmx.net>]

On 07.07.2011 13:09, Ross Gardler wrote:

> On 6 July 2011 23:51, Andrew Rist <an...@oracle.com> wrote:
>>
>> To date the LibreOffice crew has taken the effort to merge in changes from
>> the OOo code line, for each release.
>> The most obvious and best way to collaborate in the future is to write good
>> code, and make it worth their while to integrate it into LO.
>> The more compelling the development effort at Apache, the more likely it is
>> reused by LO.
>> This also leads to the situation where they have an interest in pushing
>> changes into the AOOo code line, to simplify their future merges.
> 
> I agree 100% with this.
> 
> My question, as someone who does not know the OOo code, is are there
> any obvious places in the code where this is likely to happen?
> 
> A strong Apache project has the broadest possible community of users.
> Some of these users become contributors and some of those become
> committers.
> 
> I wonder if there are any units of code that can be separately
> packaged in order to allow them to be included in downstream projects
> without "merging cnhanges" into a separate code tree?
> 
> I'm a Java weenie, so I think in terms of JARs that can be reused
> easily. Is there any scope in the OOo project for similar library
> reuse? If so where is the low hanging fruit?

Whether you need to merge changes does not depend on the code itself, it
depends on whether you have any changes done and if you want to push
them upstream. These changes can also appear in code that otherwise
could be reused easily.

IMHO it's not a matter what code can be shared easily as a separate
package, but where merging code changes is harder. Sometimes there's a
relation between these two, but not always. The more active development
in a particular code part happens on both sides, regardless how the code
is packaged at the end, the harder it will get to merge the changes.

Nevertheless it would be an interesting approach to package some stuff
separately and give it a life independent from the OOo application code
base. Ideal candidates would be UNO and its runtime libraries (URE), the
SDK and the build system. That's the reason why I recommended these
areas as a field for collaboration, with the goal to establish trust and
relationships between the developers that we can build on.

Regards,
Mathias

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

On 7 July 2011 13:17, Mathias Bauer <Ma...@gmx.net> wrote:

...

>> One thing would be to collaborate to remove any redundant code. I have heard
>> that the LibO people have already worked on this so removing code should be
>> something that is not too controversial license-wise and could filter up
>> stream from LibO to OOo. (hi guys we removed this this and this, you might
>> like to do the same as it hasn't broken anything) Same with identifying
>> inefficient stuff that is more a matter of reorganisation or replacing
>> existing code with something better. Such revisions could be less of a
>> license problem even if not completely resolving the issue.
>
> This would at least require that someone having done that at LO would
> contribute a patch for OOo. Having a patch could help to do the removal
> in the same way as in LO. That could make sure that afterwards the code
> bases became more similar and merging of code changes could become
> easier in the future. Perhaps that's something you should suggest on the
> LO dev list.
>
> (I hope this suggestion isn't seen as an offense - really, if you are
> asking for patches you have to ask those who did the work, not those who
> might receive it.)

My intention is to talk to as many LO folk as I can about the feedback
I get on this list. I want to try and work out where there is
potential for such collaboration. I want to figure out who can help
make it happen etc.

I've not talked to the LO folk about this topic yet, I want to be able
to go there with some constructive areas of collaboration that are
respectful of their licence choice and community objectives. I'm not
likely to make any of this happen, I haven't written any C++ code for
about 15 years, but I might at least be able to get a conversation
going.

Keep the suggestions going and don't be scared of suggestions that
require us to ask the LO project for patches. I know that brings the
question of licences back into it, but for now lets assume everything
is possible (I hope LO folk on this list do not think that I am
assuming patches will be forthcoming, there may be other approaches
that we can take to route around some of these issues, but we won't
find them if we don't talk about them).

Ross


-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: OOO and LibreOffice.

[Dave Fisher <da...@comcast.net>]

On Jul 7, 2011, at 2:47 PM, Greg Stein wrote:

> On Thu, Jul 7, 2011 at 12:45, Pedro F. Giffuni <gi...@tutopia.com> wrote:
>> ...
>> One of the things LibreOffice pretends to do, for
>> example, is to remove Java as a dependency, a move
>> that is not very attractive to Apache developers, I think.
> 
> Bah. I'd *love* to get rid of a JVM dependency :-)
> 
> (and I'm certainly not scared of Python)

Since we are getting silly:

"...Y'know, my python boot is too tight
I couldn't get it off last night
A week went by, an' now it's July
I finally got it off
An' my girl-friend cry ..."

Stinkfoot - by Frank Zappa


Regards,
Dave

Re: OOO and LibreOffice.

[Greg Stein <gs...@gmail.com>]

On Thu, Jul 7, 2011 at 12:45, Pedro F. Giffuni <gi...@tutopia.com> wrote:
>...
> One of the things LibreOffice pretends to do, for
> example, is to remove Java as a dependency, a move
> that is not very attractive to Apache developers, I think.

Bah. I'd *love* to get rid of a JVM dependency :-)

(and I'm certainly not scared of Python)

Cheers,
-g

Re: OOO and LibreOffice.

[Ian Lynch <ia...@gmail.com>]

On 7 July 2011 18:29, Mathias Bauer <Ma...@gmx.net> wrote:

>
>
> (1) removing code that was not compiled at all
> (2) removing code that was compiled, but not used
> (3) removing superfluous comment lines
> (4) translating comments from German to English
> (5) "real" code work: removing duplicated classes, simplifying code etc.
>
> The most valuable part is (5) but this is not what falls into the
> category that you have brought up, as it is not just removal of
> something, it's more code refactoring. There was some great work done in
> LO, like the removal of the "vos" library and the replacements of some
> old container classes. But again, it's more than just removing code.
>
> The same is true for (4).
>
> So we are talking about the first three cleanups. The smallest part is
> (2), but it's the most valuable part of the three, as not only the
> developers but also the users will benefit from it. There's not much of
> that kind as such code removals have been contributed to OOo until last
> summer anyway (a big "thank you" to Caolan Mc Namarra from Red Head, the
> "call catcher" magician). As far as I can see not that much has been
> added since then. Nevertheless, patches for that would be very welcome.
>
> So most of the time we are talking about (1) and (3). This is work I
> usually do "on the fly", when I'm at the code that contains stuff like
> that. If it helps collaboration, we could consider doing it as an end in
> itself (though it would take considerably more time doing it that way).
> If we wanted to repeat these cleanups in the OOo code base so that
> future code merges become easier, we have to do it in exactly the same
> way as it was done in LO. Let's see if patches will come.
>
> Wait a moment - there's something we have to do before! What was it? Ah,
> yes, we first have to get some code that can be patched! :-)
>

Thanks, Mathias, I think that analysis is very helpful.

-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: OOO and LibreOffice.

[Mathias Bauer <Ma...@gmx.net>]

On 08.07.2011 13:17, Stephan Bergmann wrote:

> On Jul 8, 2011, at 12:58 PM, Mathias Bauer wrote:
>> On 08.07.2011 12:50, Armin Le Grand wrote:
>>> I just want to mention that with the variable cleanup in OOo I
>>> had 1010 conflicting files on aw080 on the next resync, in
>>> average with 4-5 conflicts due to the fact that I already had
>>> changed the variables in the refactored code to something useful.
>>> This took me nealry 1 1/2 weeks where not really something
>>> productive could happen, just resynching and getting all compiled
>>> an running again.
>>> 
>>> So, please, when You do such changes, keep in mind that this will
>>>  produce a lot of work for people which You may not have on Your
>>> radar...
>> 
>> Good point. So it might make sense to integrate large cws before
>> doing any janitory work on the code base.
> 
> It might make even more sense to move to a development model with
> much more frequent integrations than what we did with CWSs in the
> past.  But that's getting off topic for this thread (and should be
> discussed once fresh development on the new repo actually takes
> place).
I assume that you know that I agree with you in that point.  :-)

Regards,
Mathias

Re: OOO and LibreOffice.

[Stephan Bergmann <st...@googlemail.com>]

On Jul 8, 2011, at 12:58 PM, Mathias Bauer wrote:
> On 08.07.2011 12:50, Armin Le Grand wrote:
>> I just want to mention that with the variable cleanup in OOo I had 1010 
>> conflicting files on aw080 on the next resync, in average with 4-5 
>> conflicts due to the fact that I already had changed the variables in 
>> the refactored code to something useful. This took me nealry 1 1/2 weeks 
>> where not really something productive could happen, just resynching and 
>> getting all compiled an running again.
>> 
>> So, please, when You do such changes, keep in mind that this will 
>> produce a lot of work for people which You may not have on Your radar...
> 
> Good point. So it might make sense to integrate large cws before doing
> any janitory work on the code base.

It might make even more sense to move to a development model with much more frequent integrations than what we did with CWSs in the past.  But that's getting off topic for this thread (and should be discussed once fresh development on the new repo actually takes place).

-Stephan

Re: OOO and LibreOffice.

[Mathias Bauer <Ma...@gmx.net>]

On 08.07.2011 12:50, Armin Le Grand wrote:

> Am 07.07.2011 19:29, schrieb Mathias Bauer:
>> On 07.07.2011 18:06, Ian Lynch wrote:
>>
> 
> <-----stuff removed that can be read one news back ----->
> 
>> Just to prevent that a false impression comes up (and the "2 meg" you
>> named gets a meaning that it doesn't have in fact): the "code cleanup"
>> in LO we are talking about comprises several things:
>>
>> (1) removing code that was not compiled at all
>> (2) removing code that was compiled, but not used
>> (3) removing superfluous comment lines
>> (4) translating comments from German to English
>> (5) "real" code work: removing duplicated classes, simplifying code etc.
>>
> 
> <-----stuff removed that can be read one news back ----->
> 
> I just want to mention that with the variable cleanup in OOo I had 1010 
> conflicting files on aw080 on the next resync, in average with 4-5 
> conflicts due to the fact that I already had changed the variables in 
> the refactored code to something useful. This took me nealry 1 1/2 weeks 
> where not really something productive could happen, just resynching and 
> getting all compiled an running again.
> 
> So, please, when You do such changes, keep in mind that this will 
> produce a lot of work for people which You may not have on Your radar...

Good point. So it might make sense to integrate large cws before doing
any janitory work on the code base.

Regards,
Mathias

Re: OOO and LibreOffice.

[Armin Le Grand <Ar...@me.com>]

Am 07.07.2011 19:29, schrieb Mathias Bauer:
> On 07.07.2011 18:06, Ian Lynch wrote:
>

<-----stuff removed that can be read one news back ----->

> Just to prevent that a false impression comes up (and the "2 meg" you
> named gets a meaning that it doesn't have in fact): the "code cleanup"
> in LO we are talking about comprises several things:
>
> (1) removing code that was not compiled at all
> (2) removing code that was compiled, but not used
> (3) removing superfluous comment lines
> (4) translating comments from German to English
> (5) "real" code work: removing duplicated classes, simplifying code etc.
>

<-----stuff removed that can be read one news back ----->

I just want to mention that with the variable cleanup in OOo I had 1010 
conflicting files on aw080 on the next resync, in average with 4-5 
conflicts due to the fact that I already had changed the variables in 
the refactored code to something useful. This took me nealry 1 1/2 weeks 
where not really something productive could happen, just resynching and 
getting all compiled an running again.

So, please, when You do such changes, keep in mind that this will 
produce a lot of work for people which You may not have on Your radar...

>
> Regards,
> Mathias
>

best regards,
	Armin Le Grand
--
ALG

Re: OOO and LibreOffice.

[Mathias Bauer <Ma...@gmx.net>]

On 07.07.2011 18:06, Ian Lynch wrote:

> I suppose it also depends on what you mean by code clean up. If for example
> the LibO people had identified say 2 meg of redundant code, ie stuff that
> doesn't do anything useful and they removed it and know it has not broken
> anything else it seems to me that would be an easy win. Even if we
> established there was no such code worth removing, it is something. I don't
> see any licensing problems with removing stuff so it is a non-controversial
> starting point that gets people working together. (Ok in practice some
> smaller replacements might be needed but I'm considering the ideal
> situation) I can see months of argument on larger scale issues that never
> had a chance of getting anything practical done so I'm working on the basis
> that something is better than nothing and making a start that is positive
> gets the possibility of incremental improvement. 

Just to prevent that a false impression comes up (and the "2 meg" you
named gets a meaning that it doesn't have in fact): the "code cleanup"
in LO we are talking about comprises several things:

(1) removing code that was not compiled at all
(2) removing code that was compiled, but not used
(3) removing superfluous comment lines
(4) translating comments from German to English
(5) "real" code work: removing duplicated classes, simplifying code etc.

The most valuable part is (5) but this is not what falls into the
category that you have brought up, as it is not just removal of
something, it's more code refactoring. There was some great work done in
LO, like the removal of the "vos" library and the replacements of some
old container classes. But again, it's more than just removing code.

The same is true for (4).

So we are talking about the first three cleanups. The smallest part is
(2), but it's the most valuable part of the three, as not only the
developers but also the users will benefit from it. There's not much of
that kind as such code removals have been contributed to OOo until last
summer anyway (a big "thank you" to Caolan Mc Namarra from Red Head, the
"call catcher" magician). As far as I can see not that much has been
added since then. Nevertheless, patches for that would be very welcome.

So most of the time we are talking about (1) and (3). This is work I
usually do "on the fly", when I'm at the code that contains stuff like
that. If it helps collaboration, we could consider doing it as an end in
itself (though it would take considerably more time doing it that way).
If we wanted to repeat these cleanups in the OOo code base so that
future code merges become easier, we have to do it in exactly the same
way as it was done in LO. Let's see if patches will come.

Wait a moment - there's something we have to do before! What was it? Ah,
yes, we first have to get some code that can be patched! :-)

Regards,
Mathias

Re: OOO and LibreOffice.

[Ian Lynch <ia...@gmail.com>]

On 7 July 2011 16:05, Rob Weir <ap...@robweir.com> wrote:

> On Thu, Jul 7, 2011 at 10:29 AM, Simon Phipps <si...@webmink.com> wrote:
> > On Thu, Jul 7, 2011 at 2:59 PM, Rob Weir <ap...@robweir.com> wrote:
> >
> >> On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:
> >> >
> >> > On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
> >> >>
> >> >> This would at least require that someone having done that at LO would
> >> >> contribute a patch for OOo. Having a patch could help to do the
> removal
> >> >> in the same way as in LO. That could make sure that afterwards the
> code
> >> >> bases became more similar and merging of code changes could become
> >> >> easier in the future. Perhaps that's something you should suggest on
> the
> >> >> LO dev list.
> >> >>
> >> >> (I hope this suggestion isn't seen as an offense - really, if you are
> >> >> asking for patches you have to ask those who did the work, not those
> who
> >> >> might receive it.)
> >> >
> >> > Not an offense, no, although we might consider it's unlikely that a
> >> volunteer in any project would want to do this sort of work twice. We
> may
> >> instead want to encourage new Apache volunteers who want to join the
> >> development activity but need to learn how everything works to create
> >> patches that mirror the cleanup at LO, as a route to learning about
> AOOo.
> >> >
> >>
> >> If one wished to make it impossible to ever collaborate at the source
> >> code level between two projects, to frustrate attempts at automated
> >> merging, then the ideal way of doing this would be to change millions
> >> of lines of code for trivial reasons, to "improve" variable names,
> >> indentation, remove code that the preprocessor was already removing,
> >> etc.  If you want to put two nails in the coffin of collaboration,
> >> then do such "clean up" twice, independently and in two different
> >> repositories, ensuring millions of future merge conflicts.
> >>
> >
> > Hence the desire to see the work that has already been done on LO
> > contributed here, rather than a related-but-different cleanup.
> >
>
> That would work, of course.  But my point was more of the trade-offs.
> Changing a million lines of code to improve performance a small amount
> has an immediate, tangible but small user benefit, but also has the
> side effect of making future collaboration more difficult.  This
> includes collaboration that down the road could have lead to even
> greater user benefits.
>
> But I do have my views on "code cleanup" colored by my own personal
> experience.  Every project I've seen that undertook "code cleanup" was
> very soon canceled.  The insight is this:  if a project has nothing
> better to do, no more pressing customer demands, no greater innovation
> to bring to market than changing code comments, then it is near death
> already.  Of course, that is only a corporate programmer view of
> things.  In an open source project I can see the benefits of having
> "easy tasks" to introduce new developers to the code and the
> development tools.  That is a different situation.  But I'd look for a
> balance: easy tasks that don't churn the codebase and have immediate
> user impact.  I think we'd all agree that this is the ideal.


I suppose it also depends on what you mean by code clean up. If for example
the LibO people had identified say 2 meg of redundant code, ie stuff that
doesn't do anything useful and they removed it and know it has not broken
anything else it seems to me that would be an easy win. Even if we
established there was no such code worth removing, it is something. I don't
see any licensing problems with removing stuff so it is a non-controversial
starting point that gets people working together. (Ok in practice some
smaller replacements might be needed but I'm considering the ideal
situation) I can see months of argument on larger scale issues that never
had a chance of getting anything practical done so I'm working on the basis
that something is better than nothing and making a start that is positive
gets the possibility of incremental improvement.

-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: OOO and LibreOffice.

[Rob Weir <ap...@robweir.com>]

On Thu, Jul 7, 2011 at 10:29 AM, Simon Phipps <si...@webmink.com> wrote:
> On Thu, Jul 7, 2011 at 2:59 PM, Rob Weir <ap...@robweir.com> wrote:
>
>> On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:
>> >
>> > On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
>> >>
>> >> This would at least require that someone having done that at LO would
>> >> contribute a patch for OOo. Having a patch could help to do the removal
>> >> in the same way as in LO. That could make sure that afterwards the code
>> >> bases became more similar and merging of code changes could become
>> >> easier in the future. Perhaps that's something you should suggest on the
>> >> LO dev list.
>> >>
>> >> (I hope this suggestion isn't seen as an offense - really, if you are
>> >> asking for patches you have to ask those who did the work, not those who
>> >> might receive it.)
>> >
>> > Not an offense, no, although we might consider it's unlikely that a
>> volunteer in any project would want to do this sort of work twice. We may
>> instead want to encourage new Apache volunteers who want to join the
>> development activity but need to learn how everything works to create
>> patches that mirror the cleanup at LO, as a route to learning about AOOo.
>> >
>>
>> If one wished to make it impossible to ever collaborate at the source
>> code level between two projects, to frustrate attempts at automated
>> merging, then the ideal way of doing this would be to change millions
>> of lines of code for trivial reasons, to "improve" variable names,
>> indentation, remove code that the preprocessor was already removing,
>> etc.  If you want to put two nails in the coffin of collaboration,
>> then do such "clean up" twice, independently and in two different
>> repositories, ensuring millions of future merge conflicts.
>>
>
> Hence the desire to see the work that has already been done on LO
> contributed here, rather than a related-but-different cleanup.
>

That would work, of course.  But my point was more of the trade-offs.
Changing a million lines of code to improve performance a small amount
has an immediate, tangible but small user benefit, but also has the
side effect of making future collaboration more difficult.  This
includes collaboration that down the road could have lead to even
greater user benefits.

But I do have my views on "code cleanup" colored by my own personal
experience.  Every project I've seen that undertook "code cleanup" was
very soon canceled.  The insight is this:  if a project has nothing
better to do, no more pressing customer demands, no greater innovation
to bring to market than changing code comments, then it is near death
already.  Of course, that is only a corporate programmer view of
things.  In an open source project I can see the benefits of having
"easy tasks" to introduce new developers to the code and the
development tools.  That is a different situation.  But I'd look for a
balance: easy tasks that don't churn the codebase and have immediate
user impact.  I think we'd all agree that this is the ideal.

>
>>
>> Of course, such clean up is an easy way to get impressive numbers for
>> patches and developers.  But on balance, I'd avoid the impulse to
>> churn the code unnecessarily. I like the idea of "Easy Tasks".  But
>> let's make them be real tasks.
>>
>

Re: OOO and LibreOffice.

["Pedro F. Giffuni" <gi...@tutopia.com>]

--- On Thu, 7/7/11, Simon Phipps <si...@webmink.com> wrote:
...
> 
> Hence the desire to see the work that has already been done
> on LO contributed here, rather than a related-but-different
> cleanup.
>

All these contributions are hypothetical ... at least
until we have a repository of our own. And then, even
after having our SVN repository working we have other
priorities like IP cleanup.

Even if the enhancements have been tested in LO, the
code has to be reviewed, and committers are expected
to have good judgement of the issues.

One of the things LibreOffice pretends to do, for
example, is to remove Java as a dependency, a move
that is not very attractive to Apache developers, I think.

I appreciate the thoughts and general objective of
collaboration but I think most of it will end up being
orthogonal to what we have to do first: set a new
development focus.

To be successful, Apache OO cannot depend on LibreOffice.
I am not saying any of this thinking is bad at all or
that you should stop trying to build bridges, but we
still have to do a lot of stuff to do *here* before
getting to that.

Pedro.

Re: OOO and LibreOffice.

[Simon Phipps <si...@webmink.com>]

On Thu, Jul 7, 2011 at 2:59 PM, Rob Weir <ap...@robweir.com> wrote:

> On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:
> >
> > On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
> >>
> >> This would at least require that someone having done that at LO would
> >> contribute a patch for OOo. Having a patch could help to do the removal
> >> in the same way as in LO. That could make sure that afterwards the code
> >> bases became more similar and merging of code changes could become
> >> easier in the future. Perhaps that's something you should suggest on the
> >> LO dev list.
> >>
> >> (I hope this suggestion isn't seen as an offense - really, if you are
> >> asking for patches you have to ask those who did the work, not those who
> >> might receive it.)
> >
> > Not an offense, no, although we might consider it's unlikely that a
> volunteer in any project would want to do this sort of work twice. We may
> instead want to encourage new Apache volunteers who want to join the
> development activity but need to learn how everything works to create
> patches that mirror the cleanup at LO, as a route to learning about AOOo.
> >
>
> If one wished to make it impossible to ever collaborate at the source
> code level between two projects, to frustrate attempts at automated
> merging, then the ideal way of doing this would be to change millions
> of lines of code for trivial reasons, to "improve" variable names,
> indentation, remove code that the preprocessor was already removing,
> etc.  If you want to put two nails in the coffin of collaboration,
> then do such "clean up" twice, independently and in two different
> repositories, ensuring millions of future merge conflicts.
>

Hence the desire to see the work that has already been done on LO
contributed here, rather than a related-but-different cleanup.


>
> Of course, such clean up is an easy way to get impressive numbers for
> patches and developers.  But on balance, I'd avoid the impulse to
> churn the code unnecessarily. I like the idea of "Easy Tasks".  But
> let's make them be real tasks.
>

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

On 7 July 2011 14:59, Rob Weir <ap...@robweir.com> wrote:
> On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:

...

>> We may instead want to encourage new Apache volunteers who want to join the development activity but need to learn how everything works to create patches that mirror the cleanup at LO, as a route to learning about AOOo.

...

> I like the idea of "Easy Tasks".  But
> let's make them be real tasks.

Agreed.

Ross

PS Do we really need to dilute sensible clarifications like the above
with language that many will (rightly or wrongly) interpret as
accusatory and confrontational? (hopefully this won't kick of a
debate, I just hope people will quietly consider this rhetorical
question).

-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: OOO and LibreOffice.

[Rob Weir <ap...@robweir.com>]

On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:
>
> On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
>>
>> This would at least require that someone having done that at LO would
>> contribute a patch for OOo. Having a patch could help to do the removal
>> in the same way as in LO. That could make sure that afterwards the code
>> bases became more similar and merging of code changes could become
>> easier in the future. Perhaps that's something you should suggest on the
>> LO dev list.
>>
>> (I hope this suggestion isn't seen as an offense - really, if you are
>> asking for patches you have to ask those who did the work, not those who
>> might receive it.)
>
> Not an offense, no, although we might consider it's unlikely that a volunteer in any project would want to do this sort of work twice. We may instead want to encourage new Apache volunteers who want to join the development activity but need to learn how everything works to create patches that mirror the cleanup at LO, as a route to learning about AOOo.
>

If one wished to make it impossible to ever collaborate at the source
code level between two projects, to frustrate attempts at automated
merging, then the ideal way of doing this would be to change millions
of lines of code for trivial reasons, to "improve" variable names,
indentation, remove code that the preprocessor was already removing,
etc.  If you want to put two nails in the coffin of collaboration,
then do such "clean up" twice, independently and in two different
repositories, ensuring millions of future merge conflicts.

Of course, such clean up is an easy way to get impressive numbers for
patches and developers.  But on balance, I'd avoid the impulse to
churn the code unnecessarily. I like the idea of "Easy Tasks".  But
let's make them be real tasks.

> S.
>
>

Re: OOO and LibreOffice.

[Sam Ruby <ru...@intertwingly.net>]

On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote:
>
> On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
>>
>> This would at least require that someone having done that at LO would
>> contribute a patch for OOo. Having a patch could help to do the removal
>> in the same way as in LO. That could make sure that afterwards the code
>> bases became more similar and merging of code changes could become
>> easier in the future. Perhaps that's something you should suggest on the
>> LO dev list.
>>
>> (I hope this suggestion isn't seen as an offense - really, if you are
>> asking for patches you have to ask those who did the work, not those who
>> might receive it.)
>
> Not an offense, no, although we might consider it's unlikely that a volunteer in any project would want to do this sort of work twice. We may instead want to encourage new Apache volunteers who want to join the development activity but need to learn how everything works to create patches that mirror the cleanup at LO, as a route to learning about AOOo.

I encourage everybody who considers doing this to read sections 5 and
7 of the ICLA:

http://www.apache.org/licenses/icla.txt

> S.

- Sam Ruby

Re: OOO and LibreOffice.

[Simon Phipps <si...@webmink.com>]

On 7 Jul 2011, at 13:17, Mathias Bauer wrote:
> 
> This would at least require that someone having done that at LO would
> contribute a patch for OOo. Having a patch could help to do the removal
> in the same way as in LO. That could make sure that afterwards the code
> bases became more similar and merging of code changes could become
> easier in the future. Perhaps that's something you should suggest on the
> LO dev list.
> 
> (I hope this suggestion isn't seen as an offense - really, if you are
> asking for patches you have to ask those who did the work, not those who
> might receive it.)

Not an offense, no, although we might consider it's unlikely that a volunteer in any project would want to do this sort of work twice. We may instead want to encourage new Apache volunteers who want to join the development activity but need to learn how everything works to create patches that mirror the cleanup at LO, as a route to learning about AOOo. 

S.

Re: OOO and LibreOffice.

[Mathias Bauer <Ma...@gmx.net>]

On 07.07.2011 13:25, Ian Lynch wrote:

> On 7 July 2011 12:09, Ross Gardler <rg...@opendirective.com> wrote:
> 
>> On 6 July 2011 23:51, Andrew Rist <an...@oracle.com> wrote:
>> >
>> > To date the LibreOffice crew has taken the effort to merge in changes
>> from
>> > the OOo code line, for each release.
>> > The most obvious and best way to collaborate in the future is to write
>> good
>> > code, and make it worth their while to integrate it into LO.
>> > The more compelling the development effort at Apache, the more likely it
>> is
>> > reused by LO.
>> > This also leads to the situation where they have an interest in pushing
>> > changes into the AOOo code line, to simplify their future merges.
>>
>> I agree 100% with this.
>>
>> My question, as someone who does not know the OOo code, is are there
>> any obvious places in the code where this is likely to happen?
>>
>> A strong Apache project has the broadest possible community of users.
>> Some of these users become contributors and some of those become
>> committers.
>>
>> I wonder if there are any units of code that can be separately
>> packaged in order to allow them to be included in downstream projects
>> without "merging cnhanges" into a separate code tree?
>>
>> I'm a Java weenie, so I think in terms of JARs that can be reused
>> easily. Is there any scope in the OOo project for similar library
>> reuse? If so where is the low hanging fruit?
>>
> 
> One thing would be to collaborate to remove any redundant code. I have heard
> that the LibO people have already worked on this so removing code should be
> something that is not too controversial license-wise and could filter up
> stream from LibO to OOo. (hi guys we removed this this and this, you might
> like to do the same as it hasn't broken anything) Same with identifying
> inefficient stuff that is more a matter of reorganisation or replacing
> existing code with something better. Such revisions could be less of a
> license problem even if not completely resolving the issue.

This would at least require that someone having done that at LO would
contribute a patch for OOo. Having a patch could help to do the removal
in the same way as in LO. That could make sure that afterwards the code
bases became more similar and merging of code changes could become
easier in the future. Perhaps that's something you should suggest on the
LO dev list.

(I hope this suggestion isn't seen as an offense - really, if you are
asking for patches you have to ask those who did the work, not those who
might receive it.)

Regards,
Mathias

Re: OOO and LibreOffice.

[Ian Lynch <ia...@gmail.com>]

On 7 July 2011 12:09, Ross Gardler <rg...@opendirective.com> wrote:

> On 6 July 2011 23:51, Andrew Rist <an...@oracle.com> wrote:
> >
> > To date the LibreOffice crew has taken the effort to merge in changes
> from
> > the OOo code line, for each release.
> > The most obvious and best way to collaborate in the future is to write
> good
> > code, and make it worth their while to integrate it into LO.
> > The more compelling the development effort at Apache, the more likely it
> is
> > reused by LO.
> > This also leads to the situation where they have an interest in pushing
> > changes into the AOOo code line, to simplify their future merges.
>
> I agree 100% with this.
>
> My question, as someone who does not know the OOo code, is are there
> any obvious places in the code where this is likely to happen?
>
> A strong Apache project has the broadest possible community of users.
> Some of these users become contributors and some of those become
> committers.
>
> I wonder if there are any units of code that can be separately
> packaged in order to allow them to be included in downstream projects
> without "merging cnhanges" into a separate code tree?
>
> I'm a Java weenie, so I think in terms of JARs that can be reused
> easily. Is there any scope in the OOo project for similar library
> reuse? If so where is the low hanging fruit?
>

One thing would be to collaborate to remove any redundant code. I have heard
that the LibO people have already worked on this so removing code should be
something that is not too controversial license-wise and could filter up
stream from LibO to OOo. (hi guys we removed this this and this, you might
like to do the same as it hasn't broken anything) Same with identifying
inefficient stuff that is more a matter of reorganisation or replacing
existing code with something better. Such revisions could be less of a
license problem even if not completely resolving the issue.

-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: OOO and LibreOffice.

[Ross Gardler <rg...@opendirective.com>]

On 6 July 2011 23:51, Andrew Rist <an...@oracle.com> wrote:
>
> To date the LibreOffice crew has taken the effort to merge in changes from
> the OOo code line, for each release.
> The most obvious and best way to collaborate in the future is to write good
> code, and make it worth their while to integrate it into LO.
> The more compelling the development effort at Apache, the more likely it is
> reused by LO.
> This also leads to the situation where they have an interest in pushing
> changes into the AOOo code line, to simplify their future merges.

I agree 100% with this.

My question, as someone who does not know the OOo code, is are there
any obvious places in the code where this is likely to happen?

A strong Apache project has the broadest possible community of users.
Some of these users become contributors and some of those become
committers.

I wonder if there are any units of code that can be separately
packaged in order to allow them to be included in downstream projects
without "merging cnhanges" into a separate code tree?

I'm a Java weenie, so I think in terms of JARs that can be reused
easily. Is there any scope in the OOo project for similar library
reuse? If so where is the low hanging fruit?

Ross

>
> Andrew
>
> On 7/2/2011 9:16 PM, Graham Lauder wrote:
>>
>> On Sat, 2011-07-02 at 23:39 -0400, Ted Rolle, Jr. wrote:
>>>
>>> Perhaps I'm jaded, but when you have data in two places, you can be sure
>>> of one thing:  they're both wrong.
>>
>> Conversely, they are both right for their respective supporters and the
>> reasons that each cite are also right, for each respective audience
>>
>>> I fear that the *Office camps will be in some sort of competition.
>>> Competition means that there is a winner, and a loser.
>>
>> Not always true, if each iteration serves a unique market.  They can
>> still be in competition for bragging rights but at the same time only
>> competing for a common set of the market that is smaller than their main
>> market, in this case I believe it will be Consumer on one hand (LO) and
>> Enterprise on the other (OOo), IMO, MSO will be the big loser.
>>
>>> The good thing is that one will survive and become the de-facto
>>> standard.
>>>
>>> Prove me wrong!
>>
>> I'm hoping we will, either way we live in interesting times
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: OOO and LibreOffice.

[Andrew Rist <an...@oracle.com>]

To date the LibreOffice crew has taken the effort to merge in changes 
from the OOo code line, for each release.
The most obvious and best way to collaborate in the future is to write 
good code, and make it worth their while to integrate it into LO.
The more compelling the development effort at Apache, the more likely it 
is reused by LO.
This also leads to the situation where they have an interest in pushing 
changes into the AOOo code line, to simplify their future merges.

Andrew

On 7/2/2011 9:16 PM, Graham Lauder wrote:
> On Sat, 2011-07-02 at 23:39 -0400, Ted Rolle, Jr. wrote:
>> Perhaps I'm jaded, but when you have data in two places, you can be sure
>> of one thing:  they're both wrong.
> Conversely, they are both right for their respective supporters and the
> reasons that each cite are also right, for each respective audience
>
>> I fear that the *Office camps will be in some sort of competition.
>> Competition means that there is a winner, and a loser.
> Not always true, if each iteration serves a unique market.  They can
> still be in competition for bragging rights but at the same time only
> competing for a common set of the market that is smaller than their main
> market, in this case I believe it will be Consumer on one hand (LO) and
> Enterprise on the other (OOo), IMO, MSO will be the big loser.
>
>> The good thing is that one will survive and become the de-facto
>> standard.
>>
>> Prove me wrong!
> I'm hoping we will, either way we live in interesting times

Re: OOO and LibreOffice.

[Graham Lauder <yo...@openoffice.org>]

On Sat, 2011-07-02 at 23:39 -0400, Ted Rolle, Jr. wrote:
> Perhaps I'm jaded, but when you have data in two places, you can be sure
> of one thing:  they're both wrong.

Conversely, they are both right for their respective supporters and the
reasons that each cite are also right, for each respective audience  

> 
> I fear that the *Office camps will be in some sort of competition.
> Competition means that there is a winner, and a loser.

Not always true, if each iteration serves a unique market.  They can
still be in competition for bragging rights but at the same time only
competing for a common set of the market that is smaller than their main
market, in this case I believe it will be Consumer on one hand (LO) and
Enterprise on the other (OOo), IMO, MSO will be the big loser. 

> 
> The good thing is that one will survive and become the de-facto
> standard.
> 
> Prove me wrong!

I'm hoping we will, either way we live in interesting times
-- 
Graham Lauder,
OpenOffice.org MarCon (Marketing Contact) NZ
http://marketing.openoffice.org/contacts.html

OpenOffice.org Migration and training Consultant.