About the Editor

Roberto has over 25 years experience in the IT field, and has spent the last 12 years working in the intersection of open source software and business development. Roberto has taken an active interest in different open source projects and organizations, he has served on advisory boards, and helped large IT vendors, open source vendors and customers to design and deploy their open source strategies. After serving as Senior Director of Business Development at SourceForge for over 4 years, in 2016 he started a new company called Business Follows, whose mission is to is to help developers, companies and organizations to make Open Source development a key part of their business strategies. He is the editor of commercial open source blog.

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.

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 manydifferent opinionsamong 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.

”
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.

1115 giorni con OpenOffice (eng.: 1115 days with OpenOffice) – The latest version of OpenOffice 3 Soluzioni a raccolta – an Italian OpenOffice.org FAQ built with the help of the community – is available for download. It covers 2089 different topic (only Italian).

New Toy or Best Friend? (talkback on Linpus) – Useful tips from a reader. Linpus servers are too slow and software, OpenOffice.org included, is not updated unfortunately.

Savio Rodrigues points out that top 2000 companies will likely end up closing a deal with Microsoft, but out of that niche he sees a business opportunity for ISVs, System Integrators and also Microsoft’s partners. Leif Lodahal, project coordinator in the Danish OpenOffice.org project, sees Sun’s absence from the Danish market as an opportunity.

Back in 2006, when we started counting OOo downloads, 800,000 downloads per year was an astonishing result to us. At that stage we couldn’t even imagine that the number would have grown to 1.780.000 in 2007, and beyond five millions in 2008.

Even if the number of downloads is not an accurate measure of the market share, it definitely shows the trend.

I agree that there is a future business in migration. We surely need better integration to OpenOffice.org from other systems, but I don’t see SUN as the major problem here. SUN (as in conjuction with IBM and others) are working hard to develop tools (e.g. ODF-Toolkit etc). I more see the various vendors of properitary business software as the big problem. We need integration from ERP, CRM and other critical business software.

I would rather point my fingers of those Microsoft Business Partners, that provide customers with no choise (as to select Microsoft Office).

First step will be the customers to ask their business software providers if they can deliver a solution without vendor lock-in.