The will be Document Foundation is out from a month, and it is now time to share some thoughts about past, present and future actions taken around subjects like copyright, the legal and governance structure and the code development process.
Roberto said:
“How to contribute is well explained, but unfortunately some not-so-innocent requests for contributions are not without risks.”
No change is without risk. That been said, a clean code reduce the risk of changes. So these ‘cosmetic’ changes are in fine lowering the overall risk by removing unnecessary complexity, inconsistencies, that accumulated over time.
If you want an illustration of that phenomena, I invite you to browse some source files in the binfilter module. That illustrate how unloved decade-old code end-up looking like. and a lot of it is indeed cosmetic, but cosmetic matter when one try to parse a multi-millions-line code-base to figure out how to fix a multi-year old bug…
Roberto said:
“Discussing and elaborating development guidelines should be a priority, probably more important than enabling people to make cosmetic changes.”
One doesn’t preclude the other.
And bear in mind that these ‘cosmetics’ change:
1/ Are low-risk and accessible way for new people to get used to the process
2/ Are an excellent way to gain some familiarity with the code, it’s structure, it’s quirks
3/ Allow the more senior developer to benefit from the clean-up without having to spend the significant amount of man-power that some of these clean-up require (that is why most of these haven’t been done. not because they are not important, but because the cost/benefit ratio was not perceived to be high enough to percolate on the top of the priority list, and because quite a few of these changes are dull hard work that more senior dev can escape by finding more technically challenging things to do)
4/ Allow the project to detect and groom new contributors…
Roberto said:
“While individuals may prefer to avoid the burden of copyright agreements, corporations and companies tend to like them more.”
Of course they do. Copyright assignment is a way for corporation to turn ‘volunteers’ work’ into ‘developers’ work for free’. In other words converting ‘free as in freedom’ into ‘free as in beer’.
And – as far as I am concerned – it is not a problem of ‘burden of assignment’, it is a matter of principle: I will share my work, but if you want to own it, you need to pay for it.
And finally an editorial detail:
Roberto said:
“Other decisions are considered even riskier by expert developers,”
Blind quotes are not very productive. Unnamed experts referencing unspecified risks is indeed very hard to address or refute.
Hi Norbert,
thank you to join the conversation. As I clarified later cutting bridges with the upstream project is a very sensitive decisions, something in my opinion should be discussed and agreed by stakeholders before it is implemented. That’s why I called it a priority.
In fact these non functional changes are not a way to get people acquainted with the code – that is something that require time and dedication – but maybe a way to make more complex integrating upstream contributions.
About copyright there are many different opinions among LibreOffice developers, and I firmly believe that potential corporate sponsors may have an opinion on this. Taking similar decision without a public and transparent process (Ã la GPLv3) is a choice, only time will tell if it was the right one, though.
About your editorial notes, if you followed all the links you know I have been pointing to few existing public sources, everytime it was appliable. As soon as I’ll get a public reference for that I’ll be happy to share it.
Hi Norbert,
a very short comment:
Norbert said:
”
And finally an editorial detail:
Roberto said:
‘Other decisions are considered even riskier by expert developers,’
Blind quotes are not very productive. Unnamed experts referencing unspecified risks is indeed very hard to address or refute.
”
It was me that around the middle of October, in a private mail, exchanged some thoughts with Roberto on the matter.
At that time I noted that changing the code will end in some difficulty in keeping it in sync with OOo that at the
time I thought of as a sort of “upstream”.
That was the ‘risk’ I thought about.
Then I was referring to this change as an example:
But now, after three weeks, I believe OOo will be no longer the “upstream” version of LibO, it’s just a starting point.
So, in the future, merging OOo code into LibO will matter less, being LibO something different.
Thank you Giuseppe for having joined this conversation. You are the second person here talking about LibO as something different, wondering if it is sustainable to consider merging OOo code into LibO a minor issue, though. Apparently 90 code hackers already joined Libo, let’s see in six months from now what this would mean to end users.
Roberto Galoppini, 
Mettila così: openoffice non stava andando da nessuna parte, da qualche anno a questa parte il tasso di innovazione, che in un software opensource dovrebbe doppiare il corrispondente commerciale, era pari a zero. In più Oracle sembra tutto tranne che os friendly.
Un cambiamento era necessario. Quelli di DF saranno anche dei casinisti ma almeno sono volenterosi.