The Unsaid Document Foundation

The Document FoundationThe 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.

How did we know about the TDF?

The TDF announce, as the community itself  happened to know later, is the result of about 10 months of work, a period of time during which the self-selected group of the OpenOffice.org members – now known as the “TDF Steering Committee” – took some important decisions.

TDF Fast Start, not without complications.

The TDF Steering Committee (SC) invited Oracle to join, asking them to give away the OpenOffice.org mark. Inviting a corporation to join a will-be foundation without a document describing a draft legal and governance structure sounds a bit naïve, though.

Why the SC gave such a short notice is unclear. OpenOffice.org community members have been treated like second citizens, while TDF first-hour supporters have been giving all the time to provide feedback and quotes.

As a long time member of the OpenOffice.org community and as a founding member of one the oldiest OpenOffice.org associations ( PLIO), I found odd myself being noticed only two days in advance. Knowing about the decision to go without Oracle, some of us would have asked time for a second thought, maybe coming up with better alternatives.

Community members didn’t get a chance to give any advice, though.

Code contributions: are they all good?

How to contribute is well explained, but unfortunately some not-so-innocent requests for contributions are not without risks.

In fact fixing German mispelling in internal APIs could bring to future problems, since additional upstream modifications will keep using the old APIs names. Other decisions are considered even riskier by expert developers, so that “easy hacks” may easily turn into complicated issues to cope with in the future.

“Easy hacks” let new contributors feel part of something that looks thing, but coding it is good only if it doesn’t increment project’s “technical debt“.

Including dictionaries in language packs is not the default, but OpenOffice.org users were used to them.

Also QA processes should be relevant to the LibreOffice project.

Discussing and elaborating development guidelines should be a priority, probably more important than enabling people to make cosmetic changes.

Contributor agreements: are they bad?

SC members have been promoting the idea that copyright assignment is bad from the very first day, while eminent members of our community asked to reconsider this position. While individuals may prefer to avoid the burden of copyright agreements, corporations and companies tend to like them more.

Looking for possible solutions to balance different interests in play should be a priority. Take Joomla! (draft) contributor agreement, or the OpenNMS approach – both derived from Sun Contributor Agreement -  are both some of the many available sources which would worth to be investigated further.

Viable open source projects must be sustainable, and LibreOffice is no exception to the rule. OpenOffice.org has always been a single vendor sponsored open source community, and until now it missed the opportunity to become a corporate dominated development community. Novell+Red Hat developers’ involvment with LibreOffice is a confirmation of such possibility.

Having on board corporations should be a priority, and to get there the way to go is truly open process (à la GPLv3) – to discuss about all above mentioned issues.

Be Sociable, Share!

14 thoughts on “The Unsaid Document Foundation

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

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

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

  4. 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:

    http://wiki.documentfoundation.org/Development/Easy_Hacks#Removal.2FReplacement_of_the_String.2FUniString.2FByteString_with_OUString.2FOString_once_and_for_all

    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.

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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>