Tagged: TDF Toggle Comment Threads | Keyboard Shortcuts

  • Roberto Galoppini 8:04 pm on November 12, 2010 Permalink | Reply
    Tags: LibO, , TDF   

    The Unsaid Document Foundation (more talkbacks) 

    “The  Unsaid Document Foundation” series is disappointingly considered “fud” from LibreOffice developers, and Michael Meeks saying (again) that I made some  good points, calls me a non-developer, probably  to infer that I am not the best person to make programming suggestions.

    Commercial open source blog readers care little to know about my computer science degree, or how much code I have been writing on a PDP-11 system. Therefore I would rather spend the rest of this blog entry sharing more thoughts about LibreOffice future.

    (More …)

    • Brad 1:27 am on November 19, 2010 Permalink

      Volunteers working on easy-hacks will hardly turn into code hackers able to make this kind of changes. Full-time developers are needed, especially now that LibreOffice is meant to be something different.

      This shows a lack of understanding of how free and open-source software works. How to do community-building and create a sustainable environment.

      Did you ever get involved deeply into the development of an open-source project?

    • Roberto Galoppini 11:35 am on November 19, 2010 Permalink

      Brad, I am regularly helping companies and organizations to interact with open source communities, either with commensalistic or symbiotic approaches.

      What I learned is that every project has its own characteristics, and things like code modularity, comments, etc strongly affect participation.

      Train someone to run a grep command it is a start, but I it will hardly make him or her able to write *Office code. Time will tell if those 90 new contributors will ever become real *office programmers.

  • Roberto Galoppini 12:20 pm on November 2, 2010 Permalink | Reply
    Tags: LibreOffice, , , TDF, The Document Foundation   

    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.

    (More …)

    • Simo 4:35 pm on November 6, 2010 Permalink

      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.

    • Norbert 6:13 am on November 8, 2010 Permalink

      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.

    • Roberto Galoppini 1:49 pm on November 8, 2010 Permalink

      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.

    • Giuseppe 10:09 am on November 12, 2010 Permalink

      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.

    • Roberto Galoppini 2:34 pm on November 12, 2010 Permalink

      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.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc