LibreOffice – Designed by Committee

By Eric Bright

Tree Swing graphic by S Hogh 1993
Designed by Committee

Update 3 2020-10-10:
  1- Typo corrected (thank you einpoklum for pointing that out)
Update 2 2020-09-07:
I stand corrected:
  1- “ungraceful,” I am told I was, not “ungrateful”
  2- The LO forked happened before AOO. That is true. Duly noted and corrected
  3- There were many more reasons that lead to the eventual LO fork. Absolutely true
Update 1 2020-09-07:
I was informed by people involved with TDF that:
  1- LO is based on “an extremely old, complex C++ codebase full of legacy stuff” [I knew that]
  2- I was blaming the programmers for the issues the code has [not true. Read the post again]
  3- I was being “ungrateful” [not true. Read the post again]
  4- The LO does have some serious issues [🤷🏽‍♂️]
  5- The contributors have been trying to help and fix them [absolutely true]
  6- I am “blaming developers for not doing more” and hence am getting in the way of those who are trying to help [really? 🤨]
  7- I “mis-informed” my friend from whom I asked for insights [read the post and see if that is true]
  8- I am advocating for more “committee” to fix the problem of something being “designed by a committee.” [conflating concepts, sarcastic, a red-herring/straw-man cocktail, playing with words. Read the ... 🤦🏽‍♂️]

What a wild-goose chase! This is exactly how the AOO’s BoD were reacting to all criticisms back in the days. I came to the same conclusion as those critics of AOO once did: There is no point in all these, since history repeats itself.

This is a post I wished I never had to write.

LibreOffice has a lot of issues with its public image, marketing strategies, management, long-term vision, major code contributors, volunteer programmers, and code quality, in case you haven’t noticed by now. I will try to explain a few of those here.

Word processors are commodities

There is commodity and there is commodity. Some are absolutely essential, cannot be ignored, cannot be replaced, are must-haves, and are everywhere. E.g. water, coal, iron, and the like. These might happen to be cheap, or not. Nevertheless, they are absolutely essential. You cannot imagine any human population without them these days. Where there is a shortage of these, there are fewer or no humans.

Some commodities are so abundant that we tend not to think of them as commodities. E.g. clean air. They are so available that it would be hard to find ways to sell them. People have tried to sell air and you can find cans of pressured air here in Toronto, Ontario everywhere in Dollarama stores. What is it used for? Pressured air in spray cans are used to clean up electronics such as keyboards. It is a hard sell though. You cannot easily imagine a thriving and expanding business around selling those spray cans of air.

In that picture, LibreOffice is the latter. There are simply so many solutions around with comparable or better performance, support, value-added, etc., perceived or real. That makes a word processor a hard sell. Now, package that hard sell in a free bundle, give it away for many years, and then try to make money off of it, directly or indirectly. It is not going to happen.

Whoever comes towards LibreOffice, large organizations or government, the less than 1% users of LibreOffice, do so only because they did not want to pay anything in the first place. Ask them to pay, and they will easily move back to greener pastures. If they wanted, could, or were motivated to pay anything for a commodity, they would have picked one with a perceived quality and support with the least bugs and frictions.

Collabora et al., which I will call “eco-partners” in the rest of this post, picked an already established, free, open source, and known software that already had a mandate to stay open and free for all, no matter what, then they tried to make a business around it. It didn’t work. Now, the eco-partners are complaining that their business model is not working unless the software they chose does some marketing for them.

Apparently, LibreOffice would not have been what it is today without the eco-partners and their contributions (or so I am told). One would be tempted to say that it would be LO’s moral duty to return the favour. There are a few issues with such an idea:

  1. LO already had a mandate when it was founded by its founders (inherited from the time of Go-OO, ooo-build, and OOo before it). Even if the eco-partners’ employees were amongst the founders. The mandate was, and still is, clear. Any such mandate might technically damn any project to an inevitable death due to its flawed economical assumptions (a “permissive licence” seem to have such tendencies; but, LO re-based its code anyway; “under an MPLv2 / LGPLv3 licence”). Nevertheless, that is what we have right now. Unless LO’s legally-binding statutes are changed, the LO community cannot be held responsible for any system failure of an “ecosystem partner”
  2. If any attempt is made to market anything, it must be put into marketing LO, not other legal entities. Even if this method, i.e. advertising for the eco-partners, is being used as a means to a greater objective, it is not necessarily in line with the spirit of the larger project. That is to say, the end must be put in focus, and not all means are justified
  3. A few eco-partners made an unsound business decision. It was unsound at its inception, and it is unsound today. LO must not be pushed (or as some might think, “coerced”) into doing thing that are sure to fail anyway. There are plenty of good evidence to show that selling after-market support for a word processor is close to impossible (Michael Meeks argued that point beautifully in many occasions, and Thorsten agreed (the URL to the conversation is moved since I started writing this post without a proper redirect 🤦🏽‍♂️). Also look at MS Office). While it would be absolutely nice to help the eco-partners survive, it must not be LO’s burden to do so. If LO has any time or potential, they must use it to improve the code and advocate for LO; period

You might say that in that case and when the eco-partners go bankrupt all at once (🤔), then LO’s development will be hugely impacted. That might be true, sad, and real (later, I will attempt to explain why it might not be true after all). No one in the LO community wishes them to go bankrupt. Nevertheless, the eco-partners have chosen a losing battle. You cannot successfully sell support for a “free” word processors these days (will talk about “free” later). That is destined to fail. In the same vein, you cannot sell pressured air in large scale. You can, however, have a very small side-product that sells air sprays for exotic uses in case you have a factory that makes different kinds of sprays. That, however, will not become your main product any time soon (by the time we all need to buy air, I guess we will face far more serious problems).

Firstly, most eco-partners will not go bankrupt, if any of them at all, if they do not get business from LO directly. LO is not Red Hat’s core business, nor is it openSUSE’s, Debian’s, Dataport’s, or NISZ’s core business to name a few contributors (so far as I could gather). So, they will be just fine with or without TDF advocacy for them.

Secondly, if all the eco-partners stopped all of their contributions today, then we will have our baseline LO contributors. That would be 30% or 20% of what we have right now (depending on how you count). Obviously, that looks like a blow to the software development’s community as a whole. Whether such a blow to the head happens or not, what will be left would be the purely-volunteer LibreOffice community. If you cannot do anything good with that 30% remaining forces, you actually do not have whatever you imagined you had in the first place: a community of volunteers.

LO has a problem and has to solve its own problem instead of forever being at the merci of ecosystem commercial partners. If we don’t have what it takes, or have not attracted enough high-quality volunteer contributors to have a viable open-source project, then meet that challenge, instead of plugging a sinking ship with bee wax.

If we think that LO cannot survive on its own, let us try and see that for ourselves. Let us see what we have. Let us see what LO is made of on its own. If it is nothing on its own, knowing it earlier than later would be beneficial to all of us, to the “community.”

What about other open-source projects?

I saw people mentioning Blender, GIMP, and a few other brands here and there. I haven’t seen a meaningful analysis of how they have been managing their affairs. Blender Cloud was brought up, but quickly buried under a hundred other conversations on the official LO mailing list.

Building sustainable ecosystems are rejected by… a few ppl.

In case you offer a solution such as an “app store,” or in our case a plug-in store, or any such store for developers to build stuff around the core code for sale, a few people in the community fiercely reject the idea. They argue that doing any such thing will take away dev resources from the core code and relocate them into the money-making store instead. Then my questions are these:

  1. How can Automattic Inc. do it with WordPress? Why could they pull it off and LibreOffice cannot?
  2. How could Simple Machine Forum do it with all of its mods?
  3. How could MeWe do it with its store?
  4. How is Android ecosystem working?
  5. Do you pay a penny when you download and use the Uber app on your phone? Where does the money in their business model come from?
  6. Do you have a shopfront on Etsy? Did you pay anything upfront to use the platform? How is that business model working?
  7. Have you ever used PayPal before? Did you pay PayPal anything the last time you bought a hair dryer on eBay?
  8. Who pays eBay by the way? Or Amazon for that matter?

These are all many examples of usable services, software, and platforms that are freely available to the end-users. They are developed either by corporations or volunteers (or both). They each make their operations money not by selling the app, software, code, service, or the platform to end-users, but through vendors who use those things to sell products.

If The Document Foundation, TDF, creates a store for LO so vendors can sell their code and TDF gets a percentage of their sales, then it would be okay if those vendors choose not to contribute code to LO. LO will not be at the merci of their code-contribution. Those vendors would have already contributed to LO via sharing a percentage of their profit with TDF anyway. And that would be good enough.

Those who oppose this option claim that that strategy will eventually attracts all the coders to the money-making segment of the ecosystem and the code contribution to the core will be greatly diminished.

What is often being ignored is that if the eco-partners are marketed by TDF instead, exactly the same thing might happen. What guarantees does anyone have that the eco-partners will not focus all of their attention on their own money-making business, as they logically should, and reduce/stop contributing code to the core LO? Besides, what the eco-partners are producing, can be very hard to integrate into the core anyway since they are offering different products such as cloud services and such. The LO licence would require them to provide the source code of anything they built using any of the LO code, and they will. But, as you can see in many similar cases, they will do it in a non-compiled, source code as the licence asked them to do without any binary.

Now, how many end-users do you know who would grab those source codes and compile it into the final product to get the same features of what the eco-partners are offering? Almost zero? Don’t count the seasoned programmer. Count, me instead. I will never do that. I technically cannot.

Companies are already doing exactly that. There is an open-source, community version and there is an open-source enterprise version. Both have their source code available. The community version, with its plain features (read “crippled”), also has binaries compiled for end users. The enterprise version with tons of improvements and extra features do not.

There is nothing morally, economically, or technically wrong with that. Also, there is nothing in the dual-licenced LO code that prohibits anyone from doing that. But, there is also nothing in there that says an eco-partner is obliged to compile their code or merge any of the code they wrote into the upstream. All the eco-partner needs to do to be in compliance is to share alike the code itself.

So, marketing the eco-partners does not automatically mean more contributions from them to the LO code, nor does it automatically mean a better, higher quality code, or anything in that vein.

A TDF Store for service vendors

If you think you can sell service for LO by any stretch of imagination, the right way to do it is to open a TDF store for vetted vendors. They will showcase their services and whenever someone buys hours of service from those vendors, the TDF will get a few percentages of the profit (think of Fiverr or similar platforms). If no one is selling nothing there, then no one is getting any money. However, such a store will allow many other, smaller players to join the party too. It might not work at the end (and I doubt if it would), but that is the right way to do it. TDF must be able to get a share of the referrals for the traffic it sends to those vendors.

Such store can easily be part of the app/plug-in/template store. A well-designed store can easily direct everyone to the right section of the store.

Then all the marketing materials everywhere on TDF’s properties must refer prospective customers of service, plug-ins, or templates to the store. End of story. If you don’t have the money to buy the gigs offered via the store, you will have to put up with the slow, maybe-works ’n’ maybe-doesn’t volunteer-run forums. You don’t like what you can extract via those free forums? We have good news for you. There are many vendors in our store ready to help. Period.

All of those vendors will focus on their own code and on ways to make more money. The more money they make, the better it would be for TDF. Because, TDF will get a small share of their profit.

With the money gained, TDF will be able to commission code developments that are needed all over its code base.

What about our mandates?

TDF must develop LO as a free and open source software to empower all humans regardless of their situations, I guess. That does not mean TDF is mandated not to make money under any circumstance. TDF will focus on the core code, the advocacy, and the economical means of making money to boost the first two items in that list.

Then, if the eco-partners can survive in that marketplace or store, so the better. If not, then they might fade away like the rest of us when we cannot make our ends meet.

The myth (?) of quality contribution by all eco-partners

If you have time, read this long thread. You will see the Apache OpenOffice struggle in late 2016 to even retire their failed project. Later in the same thread, there is something that resonates with me:

Arguably at this point in time ( if it ever had an opportunity to do so ) open source desktop will never succeed since

a) They dont have the financial and marketing backing to compete with likes of Microsoft, Apple and Google
b) […]
c) […]
e) All the effort has been too little to late these 20 years or so they have had to properly develop one so since the world is evolving away from the traditional desktop as we grew up with and know it.

I would say open source desktop environments will never succeed beyond being anything more than like minded people creating desktop environment to satisfy their own need to create one and the open source community to run one for the sake of it being open source ( idealism ) but I’m happy to be proven wrong thou I think that’s highly unlikely since the desktop environments have been doing this for close to twenty years now without any remote signs of success compared to the other desktop environments and their OS on the market.

Source: https://lwn.net/Articles/699760/

Unfortunately, that is exactly what a top Intel programmer told me when I discussed it with them a couple of days ago. I asked them what their opinion were regarding this recent conundrum (see this, this, and this). They already knew my love affairs with LO, my deep enthusiasm, my advocacies everywhere I go, and so on. They didn’t want to hurt my feelings by saying what comes next, but I asked them for their unfiltered opinion and this is what they said. This was roughly our conversation:


Eric: So, given what I have explained to you so far, what do you think?

Them: How many quality coders does LO have, in the past 10 years let’s say?

Eric: There are 1800 contributors to the project, but they, all together, contributed almost 30 percent to the project, I am told. The rest is contributed by a handful commercial entities [a few of them were mentioned earlier]. So, almost 80 percent of the programming is done by 40 or 50 programmers.

Them: And how long did you say it has been going like this?

Eric: Since Go-OO, at least; if not earlier. But, to LibreOffice as such, since its inception in 2011.

Them: And how many open tickets did you say there are still? Bugs and such?

Eric: It depends on what you count. Since feature requests are also included in the tickets, a couple of thousands, I would say. Let’s say a thousand. And some of them are pretty old indeed.

Them: Not fixed yet?

Eric: Yup!

Them: So, how many person-hour would that 80% contribution you mentioned would be? Let’s not bother with the maths. Let’s say 160 years of work. Would that be fair?

Eric: I don’t know how much work the eco-partners actually put into the commits.

Them: Well, sometimes one line of code is all it takes to fix a huge, annoying, and dangerous bug. Or even a change in a plus or minus. So, it won’t be fair to look at the amount of code committed on an individual basis. Let’s stick with the rough estimate of 160 years of programming, contributed by those eco-partners in the course of the past ten years. 160 person-years! Do you see where I am going with this?

Eric: Holy cow! I got your point! 🤦‍♂️

Them: If this is what they could do after 160 person-years of code contribution, then how good do you think those coders are? If those eco-partners tell the truth and they actually, really contributed that much to the code, then they might be pretty sloppy programmers.

But, if they are just exaggerating their contribution, which I think they most likely are, then LO does not have top-notch coders to begin with. There are a bunch of interns, enthusiasts, code-kitties, and you who play with the code just to feel good. The rest of the “ecosystem partners” fix one thing here or there every other day, watch some YouTube videos, answer a few emails, drink coffee, exaggerate their roles, and attend responsibly to their own bread-winner of their lives. It might be a hobby to those people as much as it is a hubby for you.

They perhaps thought they could turn it into profit, they tried, as a side project, and it didn’t work. Now they are upset about it.

It is going to be super hard to attract high-quality programmers to work for 160 person-years on a project that pays zero. Any such programmer would already be hired in Silicone Valley for hundreds of thousands of dollars, and would be fully booked. Most probably, your beloved LO project does not have any good coder. Cry as much as you want, but writing codes for a word processor is not exciting. You get to write a word processor in most 400-level university courses as your class project. Totally boring and is not cutting edge. You are not solving new problems. There are known methods, design patterns, and architectures to use to solve the involved challenges.

If such a boring code-base, with millions of lines of code as you said, is still heavily plagued with open bugs, no matter how trivial the bugs might be, then there is a red flag right there.

LO, as I can see it from distance, needs ten or more full-time, high-quality, top-notch coders to refactor its code base in six to ten months to pay back the code rot and the technical debt it has been accumulating. You said there are memory leaks all over the code, still. C++ is bad when it gets to memory bugs. It’s notoriously hard to avoid memory-related bugs in C++, and trivially easy to make them. Also, a word processor reaches its peak efficiency and feature set pretty quickly. There are not much left to do in terms of new features (look at MS Office 2007 vs. 2010 vs. 2013 vs. 2016 vs. 2019, and even 365. To an average user, they are almost exactly the same (minus silly cosmetics)). Bug-fixing, code clean-ups, code stability, security patches, and code refactoring are not attractive games and no programmer worth their salt will be too enthusiastic about such boring and thankless chores. Those who do, do it based on principle, passion, and integrity, and mostly a dedicated hubby.

The amount of contributions by the eco-partners cannot possibly be as significant as they claim it to be. It is low-priority work to them at best. Either that, or else, if they didn’t exaggerate, then they might be pretty sloppy coders. It’s also possible that it is both.

If that is the number of open tickets with 160 person-years of work the eco-partners poured into the project so far, then don’t waste your time. Nothing will change. Add “Personal Edition” to the Welcome Screen or not. Market for the eco-partners or don’t. It will be all the same. Just relax and enjoy the game and don’t forget to bring some popcorns.


Totally depressing, if you ask me. Nevertheless, nothing makes sense in the current context. The claims and the reality do not match. The numbers do not make any sense to a top programmer who works for Intel with years of coding experience. They do not make any sense to me, now, who teach more than a dozen business courses in college. Depressingly, only a variation of the given explanation seems likely thus far.

If you go to LO’s “Read-only” GitHub repository and navigate to the ‘Contributors’ section under the ‘Insights’ tab, then you will get a better, more solid, picture of what was discussed above.

There are several legendary contributors on top of that list such as Miklos V from Collabora, stbergmann (I don’t know the company he is working for. My guess is Red Hat, but I can be wrong), Markus Mohrhard (couldn’t find any affiliation. Here is his awesome blog, and so on. When you look into the contributions of those contributors to LibreOffice core, it is just huge, and almost constant. So, you cannot question their dedication to the core code-base. Besides, the point here is not judging anyone or pointing finger at anyone anyway; just looking at some statistics. Look at Miklos’ huge count for instance.

As you scroll down, however, the numbers drop sharply. The decline is consistent with the hypothesis that LO code contribution might be merely a side-project for some eco-partner contributors, even if it used to be a lot more serious in previous years. Here is an example, not far down the first page of the list:

Here is an example from another kind contributor (don’t know the affiliation):

And please don’t get me wrong. I absolutely adore and admire those and any other contributor, even if they only contributed one line of code/translation/documentation/etc. to anything related to TDF and LO in their entire life. Under no circumstance am I blaming anyone or trying to belittle, humiliate, or disrespect any of our contributors.

My point is categorically different:

  • All contributions are not coming from one eco-partner who might go out of business due to LO not marketing for them
  • Although the eco-partners are major contributors, not all of them contribute the same
  • LO core does not seem to be as serious for some vocal eco-partners as it once used to be. Even if all the listed contributors on the GitHub list are top-notch contributors, you won’t be able to achieve much by occasional contributions of a few programmers (insignificant many) while most of the work is done only by a handful number of programmers (significant few) over a few million lines of code. It’s a simple maths problem
  • There seems to be a lot of other reasons why eco-partners are contributed to the LO core code-base. Looking through the history and background of several of the individuals involved, it seems that LO is their “baby,” “passion,” and deeply significant “love” or hubby. With or without TDF marketing for this company or that, those individuals will do what they have always been doing: loving LO and contributing to it
  • Those eco-partners who worry a lot right now and might be in trouble for their unsound business move, i.e. to somehow sell service for a “free” office suit, seem to contribute as much as 20% to 30% of the total contribution (I have to find the stats. For the life of me, I couldn’t find the charts I keep seeing on the TDF properties that explains the percentages of each major contributors’ input), and as such are not good representatives of the whole eco-partners
  • LO’s life might not be in as much danger as it is proposed to be

At any rate, the numbers tell a different story. I wished I had more wits, time, and access to more details, stats, and data to properly analyse the situation. One way or another, the claims that are made here and there must be analysed better, and their context must be more fully understood before crying that the skies are falling.

In addition to all that, if you read the above-mentioned, long thread about retiring AOO in year 2016, you will see a thick cloud of cognitive dissonance shown by the AOO Board of Directors (or whoever was in the role of the leadership). They couldn’t see, or didn’t want to see, what was right in front of their eyes. I sadly believe that the same might be happening to my beloved TDF and the LO community. It might not come to a full swing this week or this month, but it looks like a swing in the making.

The sad part is that looking at other similar projects tells almost similar stories: Calligra Suit, OxygenOffice, Apache OpenOffice, etc. The code-base too big, too bloated, too complex, and the truly-significant manpower is too insignificant, that they are almost destined to fail as free projects. Generally speaking, those projects without any means to hire excellent, full-time coders, amongst other things, will not make it with a code-base that large.

And please don’t sweat the 160 person-years estimate. Make up your own numbers. Any way you estimate that contribution, you will have one or the other serious problem. If you say, ‘Oh, it was only 5 person-years, and not 160’, then you have an astonishingly poor and lazy programmer base, including the eco-partners. If you say, ‘Oh, no! It was 380 person-years of contribution’, then you have a terrible set of programmers who have no idea what they are doing, whom you can safely discard and still be the same. Make up your own calculation and see if you get a better mileage!

Management issues

I know a few people at TDF in person. They are contributors in one way or another. I respect and admire them. I have had a few correspondences with a few other key members at TDF. They are wonderful people who have done admirable work. I cannot see myself being able to do one-tenth of what they have done. The rest of the thousand+ contributors, I don’t know. I have read about a few of them in our PR interviews. They seem like lovely, enthusiastic, smart, dedicated, and hard-working people. I love them all. The people at TDF are all wonderful, kind, warm-hearted, considerate, and hard-working. I have absolutely no doubt about that.

In addition to that fact, I have to admit that the management system at TDF is broken. It might work for a small project. It is showing its limits for our mammoth project at TDF though. Here are a few reasons why.

Conflict of interest

This one seems like the least serious issue at hand. There are members of the BoDs who can also potentially profit, one way or the other, from decisions that are made at the board. That, in itself, is not a problem. The issue is that the whole project, i.e. TDF, is a non-profit organization (so far as I understand). This fact creates a conflict of interest.

The solution to this, also foresaw in the statute, is to limit the number of people who can get on the BoD who might have potential conflict of interest. This is what the statute mandated.

The other solution is to change the statute. I don’t know how that might be worked out in Germany.

The last thing that comes to mind is for those who have potential conflict of interest to recuse themselves from those decisions that might have something to do with financial gains of those members (short of resigning from the BoD roles).

I assume the reader is well aware of the issues that conflict of interest can cause to any decision-making process. Therefore, I will not elaborate any further on this issue.

Designed by committee

This problem and the next, i.e. feature creep, are the most urgent of TDF’s problems. The main issues that we are facing today are mostly the result of the managerial style of TDF in general.

Designed by committee:
The term is used to refer to suboptimal traits that such a process may produce as a result of having to compromise between the requirements and viewpoints of the participants, particularly in the presence of poor leadership or poor technical knowledge, such as needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision. This democratic design process is in contrast to autocratic design, or design by dictator, where the project leader decides on the design. The difference is that in an autocratic style, members of the organizations are not included and the final outcome is the responsibility of the leader.

Wikipedia contributors. (2020, May 28). Design by committee. In Wikipedia, The Free Encyclopedia. Retrieved 20:51, September 5, 2020, from https://en.wikipedia.org/w/index.php?title=Design_by_committee&oldid=959474491

No disrespect to elephants, but LO looks like it is designed by the same committee who designed elephants. Full to the brim with pet projects, personal preferences, and total lack of a coherent and consistent vision. Every part and corner of the code is designed not in line with a vision, a design guideline, or a unifying mission, oh no, but by what feels good at someone’s whim.

We have a Google Summer of Code everyone! Any idea what we should do next? Oh! You want to add a piece of code to squeeze limes over an ice cream cone? No problem! Come on in! Oh! You want to integrate Unreal Engine with the LO Presenter code so it would be able to do ray tracing? What a brilliant idea! Why don’t you come in? LO needs a kitchen sink, you think? Wonderful! Please code away a kitchen sink.

That is being with no leadership and having no plan means. If I say, “Uhhh… you know that we still have thousands of open tickets, right?” I will be told, immediately, that, “Why don’t you go ahead and fix them yourself? We are all unpaid volunteers here, you know. Stop whining and start contributing.”

I am beyond the point to call those responses juvenile or ridiculous. Those responses are not the cause of our problem. They are the symptoms. When there is not a standard guideline and no roadmap aside from telling the world when our next version of the elephant will come out, then things will get, well, elephanty!

No one knows where this ship is heading, what should be focused on and what must be totally and unequivocally rejected, what our priorities should be, and where we want to be in 2, 5, or 10 years. No plan!

Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.

Lewis Carroll – Alice in Wonderland

Feature creep

This total lack of vision and leadership brings up yet another problem: feature creep.

Feature creep is the excessive ongoing expansion or addition of new features in a product, especially in computer software, videogames and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.

Wikipedia contributors. (2020, July 28). Feature creep. In Wikipedia, The Free Encyclopedia. Retrieved 21:13, September 5, 2020, from https://en.wikipedia.org/w/index.php?title=Feature_creep&oldid=970033330

Every intern, every Google Summer of Code proposal, every junior computer science student who contributes code to LO for a few days, weeks, or months and then disappears, will add another feature to the elephant that is guaranteed to be neglected at best. There are a few new features that are added that way and suddenly became so popular that are being maintained way beyond their initial programmer. Nevertheless, most of the “features” that are added to the core code will end up being abandoned and collecting code rot.

Abandoned code equals technical debt. Sooner or later someone will find a new bug in the system that will have something to do with the code that the “feature” is based on. And since the original programmer is nowhere to be found and the corresponding code is no one’s child to be taken care of, the bug tickets pile up.

The solution to this problem is not fewer features. The solution is a focused development agenda with best-in-the-class practices and a vision.

Anyone should be free to propose any feature they like. And none will be implemented unless they are put on a list of other features that are already approved to be added. It would be okay for such a to-do list to get a kilometre long. A kilometre-long list of wanted features would not make a bloated code, nor will it reduce the quality of the code. However, having no vision, no plan, no standard, as to what needs urgent attention now and what should wait for later, can damage the quality of the code.

If I were on the Board as a dictator to dictate the path LO must travel through, I would have put an immediate freeze on all new feature requests and implementations. Then I would have put a committee together [here, for those who love to play word-games (see one of the comment below), “committee” means a group of people tasked to do what I tell them to do, i.e. a “taskforce.” Please don’t conflate the notion of “Designed by Committee” with a ‘taskforce’] to sift through all the hundreds of proposed features and those that are half-baked, as well as those that are already implemented. The goal would have been to:

  1. Compile a list of top 5 features LO will need to work on in the next 6 months
  2. Compile a list of top 10 features LO will focus on in the next 1.5 years
  3. Compile a list of top 3 features LO will work on in the next 5 years
  4. Compile a list of top 10 features LO will deprecate and will remove from LO in the next year
  5. Compile a list of top 20 feature LO will never implement in the next 5 years
  6. etc.

And I would have put those lists up in front of the development portal. All those who would want to propose a feature, report a bug, and so on would have been made to see that list first before being able to load the page to file a ticket.

I hear people talk about LO having “millions of lines of code” as if that is something to be proud of. It is not. It is a very unfortunate fact of a complex project. The goal, in this context, is not to keep it this way. The goal is not to make this 1-mllion-line-of-code project into a 2-million-line-of-code project. If anything, the goal must be this: Try as best as you can to control the growth of the code base. Remove as much unnecessary, old, obsolete, or simply poorly-designed code out of the code base as possible. Clean up the code. Don’t let it grow any bigger than it absolutely have to.

The more lines of code your project has, the more bugs you potentially cultivate. The larger your code base gets, the harder it gets to created a high-quality product. It is not a virtue to have millions of lines of code. It is not a vice either, but a curse? It certainly is.

It is not a virtue to have millions of lines of code. It is not a vice either, but a curse? It certainly is.

If I were the dictator, I would have ordered a full year of code refactoring, code clean-up, and bug fixes. During that year, no new change, beyond the ones mentioned in the lists above, would have been considered. I needed to bring the total number of open tickets down to a double-digits figure.

I can go on and on talking about what I would be doing had I been the dictator of the project, but you got my point. Aside from feeling that what I am doing right now in this blog post would be all in vain, I am sure none of these are going to be done the way I am proposing them to be done. So, “I have spoken!” as one would say.

“I have spoken!” ― Kuiil – The Mandalorian

Free Office Suite – false advertisement

It is not possible to deploy LibreOffice, or any other office suite for that matter, in large scale without proper support, which will certainly cost any organization. Nevertheless, as Thorsten said, it is hard to convince enterprise users that a FLOSS piece of code is not zero-cost after all. Now, add to it the perpetual value-proposition put forward by most, if not all, open source projects, and boom! You will get where LO has got to. LO, like many other open source projects, boast about being all open (which is true) and free (which is not true).

Nothing is free in this universe; specially not in business, computing, science, and society as a whole. This has been already brought up so many times that it almost sounds trivial. Unfortunately, not fully recognizing this fact is exactly like sitting in a car for a long drive without having any money in your pocket or gas in your tank. You will learn that hard truth when your car stops after using the last drop of gas in the tank.

We hail those companies and countries, here at TDF, when they adopt LO in their organizations, schools, and offices. Then, when those organizations come face to face with the reality, i.e. when the crap hits the fan and they learn that it actually costs them money to maintain and improve LO as much as any other piece of code, and then they abandon LO or roll back, we, at TDF point our finger at them and call them cowards.

The fact of the matter is that the open source as a whole has this PR problem. It is not only LO’s or TDF’s. Most of the people who work on open source projects are coders and such. They are not business people. They cannot be. Most of us can only be good at a few things at a time. To be great at coding, you will not have a lot of free time on your hand to become great at business too. It’s just not easily doable. There are a few exceptions in the world of geniuses, such as Stephen Wolfram, who can do them both, and some. So, one should not be surprised if the stewards of most open source project have a blind spot in their managerial visions.

The result is this: most of those in open source communities, left to their own devices, are extremely poor in business, in making ends meet for a large project, and so on. They are mostly coders, not CEOs and business people. They know coding well enough to contribute, but they don’t have good-enough understanding of how a large, living, complex organism can stay alive and keep going in an economic context; hence the “free” value-proposition in most PR announcements.

Nothing is free. Adopting a piece of code in your organization that someone gave you for free, will not be free. As you can see, there are two or more notions of free in play in this context. One “free” refers to how much you will pay to obtain the code. In the case of LO, that price is small. You will pay for the electricity, the computer devices you used to download the installer, the bandwidth you purchased from your ISP, the time you spent finding the installer, downloading it, and installing LO, and so on. All in all, the cost of obtaining the LO code is small, probably a few dollars. It is not free though.

The other notion, that is the source of the grave confusion with the users of open source code, is the mistaken belief that using a cheaply obtained piece of code is also free. If ordinary high-school kids were making this error, I would have excused them. Programmers, contributors to open source projects, CEOs and managers of companies, mayors of cities, ministers and members of parliaments, and presidents of universities make this mistake.

They falsely believe that once you got your hand on a piece of code, for free, then all of your problems are solved and you will not need to worry about any other cost. If you look at the ridiculously low budgets that universities, government bodies, and ministers of this and that ministry allocate to the deployment and the maintenance of open source codes, you will see that they almost don’t understand anything about what it means to deploy, maintain, update, and improve those software.

These entities go from paying Microsoft several millions of dollars in licence fees per year to what? To the salaries of their IT personnel that they would have needed to pay anyway for other reasons? From $350,000,000 USD in licence fee to less than $100,000 after installing LO? Isn’t that $100,000 per year, the salary of your two or three IT people in the company anyway, with or without LO? So, do they assume that their cost is now only $100,000 per year? Good luck with that!

Neither The Document Foundation nor any other branch of it helps to correct this myth in any way that I am aware of. It is a given, as it seems, that “You get to use LibreOffice for free!” Period! That, unfortunately, is called false advertising.

False advertising is the use of false, misleading, or unproven information to advertise products to consumers. […] One form of false advertising is to claim that a product has a health benefit or contains vitamins or minerals that it in fact does not. Many governments use regulations to control false advertising. A false advertisement can further be classified as deceptive if the advertiser deliberately misleads the consumer, as opposed to making an honest mistake.

Wikipedia contributors. (2020, September 4). False advertising. In Wikipedia, The Free Encyclopedia. Retrieved 22:52, September 5, 2020, from https://en.wikipedia.org/w/index.php?title=False_advertising&oldid=976727939

Well, I can tell, by looking at our past marketing materials, that it has been an honest mistake. It seems that our marketing department has a lot of room to improve.

There are many discussions on the Board of Directors where very sensible people such as Telesto are already raising some significant flags related to our marketing strategies (see this and this).

Our marketing mistakes bring us to a notion that is known very well in business: Total Cost of Ownership.

What is the Total Cost of Ownership?

In business, there is a notion called Total Cost of Ownership.

The total cost of ownership (TCO) is the purchase price of an asset plus the costs of operation. Assessing the total cost of ownership represents taking a bigger picture look at what the product is and what its value is over time.

When choosing among alternatives in a purchasing decision, buyers should look not just at an item’s short-term price, known as its purchase price, but also at its long-term price, which is its total cost of ownership. The item with the lower total cost of ownership is the better value in the long run.

Alexandra Twin. (2020, July 28). Investopedia. Retrieved September 5, 2020, from https://www.investopedia.com/terms/t/totalcostofownership.asp

Then, why do we say that LO is a free product? “free” in what sense exactly?

Of course it is not the job of TDF to educate the public about business and what the total cost of ownership is. Nevertheless, it is TDF’s responsibility to inform the public and the users of LO that:

  1. You are obtaining the source code as well as the binaries of LO at no fee
  2. You are 100%, totally, fully on your own after that point
  3. If you need extra service, that’s for a fee and can be purchased through our store from several hand-picked vendor [had we had a store]
  4. If you don’t want to pay anything for anything, then you will not get anything else beyond the source code and the binaries
  5. There are forums and other places that TDF’s volunteers hang around. If you have a problem, have a bug, have a request, etc., then you would be lucky if you find someone there who might be able to help you for free. The chances are that you wouldn’t. So, don’t bet on that
  6. Do not deploy LO in any work place unless you fully understand what the above-mentioned items in this list mean. Nothing is free in this universe!

As soon as someone talks about money at TDF in almost any context, someone from outside writes an online article and cries that: “Oh! No! Now LibreOffice is not free anymore! 😱” and the marketing ppl roll back into their caves.

What will happen if we shout, loud and clear, that “LibreOffice source code and its binaries are free to obtain now and forever. Everything else is for a fee”? Will we lose a few diehards? And then what happens?

Taking care of the community is important. Making sure that everyone on this planet is happy, however, is not part of the TDF’s mandates. We are not required to make people happy. That is not part of the TDF statute. If it is, please kindly show me the part in the binding German mandate that says: LO is required to keep every single online journal, all journalists on earth, and everyone who knows that LO exist happy forever. Something similar to that will also do.

We don’t have to keep everyone happy, and we should not. Those who never contribute to the code or the community in any way, do not matter (in the context of this project of course). Those who matter, are not confused anyway. If the ‘upset and vocal’ minority do not like LO, they are welcome to use Abiword, or something else. If they are so confused as to what we meant by our marketing message, they need to learn a bit better. That is easier to fix in a long term.

If a country changes its mind and not adopt LO after learning about the facts, that is alright. The policy makers in countries have the right to get upset and change their minds. They would have been upset after learning the fact that LO is, indeed, not free to use anyway. Those are the not-so-valuable-to-the-community customers anyway. They will roll back and buy MS Office licence in a year or two of struggling with LO and going nowhere with no budget, anyway.

Telling the customer what they are signing up for in the beginning, is the moral thing to do. We might lose a few customers, big or small. Hard life! “This is the way!” as some would say. The other option, now that we know our mistakes, is to deceive the users.

Is it time to fork?

I just learned that I was not alone thinking about this topic: To fork or not to fork!

I am not a known voice at TDF. I don’t have followers who might follow me anywhere I might go. I don’t know how to code. So, to me, the answer is clear: I will never be able to fork a project such as LibreOffice.

But, not everyone is like me. There are code contributors at TDF who have been contemplating this option for a much longer time than I.

To fork this project a few stars must align:

  1. Someone known in the community must initiate the fork who also is a main contributor to the code
  2. Many major contributors must follow that person
  3. It has to hosted on GitHub instead of other obscure places
  4. The licence needs to be exactly the same as the upstream LO code
  5. It needs to be supported by contributors who really believe in the cause and are not going to have cold feet after taking a few steps
  6. The way the code needs to be governed must be based on standards and clear guidelines and roadmaps, instead of doing it in a Brownian-motion fashion
  7. There needs to be one or a few dictators who decide where the code has to go, which pull requests can merge into the main code, which feature requests can be added to a to-do-list and which one will never be added to that list, and so on
  8. The initiators of this fork must have nerves of steel, because they will be attacked from left and right, by friends and foes, and even contributions to the main code might be very slow and low for a long time. They must be able to weather all of these
  9. The split must be large enough so that it creates enough gravity to attract new programmers
  10. The code base must be slimmed down, new technologies must be introduced, and lot of old structures must be deprecated and removed as fast as possible
  11. The code repo and the building mechanism must be reworked and simplified even further for new developers to be able to join even easier
  12. Large framework dependencies must be re-evaluated and possibly eliminated. Including a gigantic library to do a simple task is never a good thing
  13. The web site front must be kept nice, modern, and tidy with enough information for visitors as to why the fork happened, who is in charge, what the new philosophy is, what the possible benefits would be, who can join, and such

This list is by no means complete. Any group of programmers worth their salt would be able to think of a lot more improvements and changes that can go into such a fork.

In my opinion, a fork is inevitable. It is not the matter of if though. It is the matter of when and by whom. Time will tell!

Please cite this article as: Bright, Eric. (2020) LibreOffice – Designed by Committee. BlogSophy. https://sophy.ca/blog/2020/09/libreoffice-designed-by-committee/

20 thoughts on “LibreOffice – Designed by Committee”

  1. > There are simply so many solutions around with comparable or better performance, support, value-added, etc., perceived or real.

    I don’t know of any word processor (let alone, wp+presentations+spreadsheet+etc. suite) with comparable or better functionality to LibreOffice other than Microsoft Office. Perhaps you are only thinking of LTR languages?

  2. I agree with some of the problems you identify, but not necessarily with your conclusions. I’m not involved enough in the project to develop my own broad perspective, though. Instead, here are some concrete issues or arguments of yours with which I take issue:

    > … how many open tickets did you say there are still? Bugs and such? … Let’s say a thousand.

    Just 1,000? That’s really impressive! Well, either that or people doren’t report bugs enough. Thunderbird has over 10,000, for example, and it’s just a mail & messaging client.

    > … 160 person-years! Do you see where I am going with this? If this is what they could do after 160 person-years of code contribution, then how good do you think those coders are?

    They may suck, or they may be pretty good.

    > It is going to be super hard to attract high-quality programmers to work for 160 person-years on a project that pays zero.

    A Full-time programmer, yes, but occasional programmers, not so much. Specifically, people are often drawn to fix the bugs that annoy them personally. However – for that to pbe possible, the path to making changes to the code must be made _very_ straightforward, if not actually easy. There should be extensive introduction/training material fo potential code contributors

    > Any such programmer would already be hired in Silicone Valley for hundreds of thousands of dollars, and would be fully booked.

    No. Most people don’t live nor work in Silicon Valley, nor in the US. Most people who program have other jobs already.

    > Most probably, your beloved LO project does not have any good coder. Cry as much as you want, but writing codes for a word processor is not exciting.

    What? That’s patently false. Naturally, fixing obscure bugs is not exciting, but implementing features or improving response time for an application used by millions of people is plenty exciting!

    > You get to write a word processor in most 400-level university courses as your class project.

    Not really. Probably not even a text editor. But – if you do get to write a text editor, then:

    1. It’s extremely simplistic and rudimentary. Not even close to what a powerful text editor would be like.
    2. This makes you realize it is a _fascinating_, complex world of algorithms and data structures, with innumerably many challenges and trade-offs.

    That aside – a word processor is just one of the apps in LO.

    > Totally boring and is not cutting edge.

    No, and _no_.

    > You are not solving new problems.

    You are, because older problems get combined as the application matures. Also, many older problems don’t have just “one appropriate solution”, or – are simply unsolved and usually been worked around in scheme.

    > There are known methods, design patterns, and architectures to use to solve the involved challenges.

    And yet, word processors don’t even get line-breaking within a paragraph right…

    > LO, as I can see it from distance, needs ten or more full-time, high-quality, top-notch coders to refactor its code base … to pay back the code rot and the technical debt

    Definitely agree with this.

    > memory leaks all over the code … C++ is bad when it gets to memory bugs

    Not for a while now. This used to be the case, for sure. These days, proper C++ sees little use of pointers, and essentially no use for raw allocation and deallocation (`new` and `delete`)

    > It’s notoriously hard to avoid memory-related bugs in C++, and trivially easy to make them

    The person who said this has not been using C++ for nearly a decade (or has been maintaining older code).

    > There are not much left to do in terms of new features

    The existing features are really not there yet – and I don’t mean just the technical debt. 10 years in and there’s still a whole lot of stuff that doesn’t work the way it’s supposed to.

    > MS Office 2007 vs. 2010 vs. 2013 vs. 2016 vs. 2019

    There are important, even if not earth-shattering, features introduced over these versions.

    > The code-base too big, too bloated, too complex, and the truly-significant manpower is too insignificant, that they are almost destined to fail as free projects.

    This is an important point. For a large FOSS software project, I believe a significant part of the effort should be in modularization and the building up of libraries which are of potential use to thers. And no less than this – finding opportunities to use code from other projects and reinventing less wheels.

    > The people at TDF are all wonderful, kind, warm-hearted, considerate, and hard-working. I have absolutely no doubt about that.

    You should have strong doubts. I don’t know the TDF at all, but power does tend to corrupt – and personal character is lees significant in this respect than organizational circumstances.

    > potentially prof

    missing the “it” in “profit”.

    > Designed by committee

    What you describe is design by a committee which mishandles the design. Committees can do decent jobs and certainly don’t necessarily end up managing a kitchen-sink kind of an app.

    > Abandoned code

    One option is to mandate the existence of maintainers, or otherwise retire. Brutal, but might be effective.

    > Then I would have put a committee together

    Don’t forget that this committee must publish a call for input from throughout the contributor community. Not in order to accept everything that everyone asks for, but to understand the pain points, expectations and desires. Also, some sort of userbase-wide input, although that is always tricky.

    > If I were on the Board as a dictator to dictate the path LO must travel through, I would have …

    … devoted developers’ time to create a training program which would let newbies get to the point of ability to contribute code (subject to review of course) much much faster and easier than is the case today.

    If you ever played Sid Meyer’s “Civilization”, you know that the best strategy is not to build up your existing cities, but to invest first and foremost in expansion.

    > left to their own devices, are extremely poor in business, in making ends meet for a large project, and so on.

    So, second training program (perhaps with the help of other NGOs which train activists in managing organizations) – training contributors in how to run an organiation like the TDF, how to plan an annual budget, how to manage and meetings, how to record activities, various units and positions within organizations and their benefits and detriments, formal correspondence, laws of corporations / organizational entities in Germany and other relevant countries, etc.

    > Is it time to fork?

    Not really:

    * You’ve described problems, not forking justifications – which is not the same thing.
    * Similar problems will arise with a fork, unless things are done different.
    * One can fork the _organization entity_ rather than the code.

    1. Very many excellent points! Thank you for your feedback. I am the first to admit that I know very little about programming, so my point regarding programming aspects are, inevitable, off. As for the management part, I also do not have the full picture. However, in many cases, it is not he full picture that determines the conclusions, but the overall trajectory.

      As to the use of terms such as “boring,” “unexciting,” “not cutting edge,” etc., they are matters of perspective. The person I was talking to found a lot of “problems” in the code boring. It certainly might not look the same to many others.

      I am not sure if forking would be necessary or even useful for the same reasons. I didn’t try to justify forking either. Still, it looks like some sort of forking, maybe the kind you suggested, i.e. forking the organization rather than the code, might be in the cards. I have no idea how that might work though, and if that is any different from what we casually call forking.

      Your points on NGOs, their training, management, coordination, and organization were very interesting. I which I knew more about them and about how they pull off their activities.

      I think it would be fruitful to study successful open source projects, the most actively maintained and healthy, to learn about their recipes. Any such study would be a multi-months, if not multi-years, project. Nevertheless, I am not aware of such systematic studies and have reasons to believe that they might enlighten a great many other operations in the open source community. Do you happened to know such a study being published anywhere? Maybe a recent book? A peer-reviewed article? ?

      At the end, “designing by committee” as a concept, works like a double-edged sword. Due to its complexities, they are usually not done properly and create many issues in some professions such as software programming. Not all operations or projects can be successfully managed by a committee. In our case, it seems the misalignments and the chaos it is causing are on the higher end of the spectrum. Of course, others might have a different opinion on this.

      Again, thank you for the great point you made! True understanding can only come through discussions and significant feedback such as yours.

  3. Native-English speaking people tend to fall into this trap:

    “LO, like many other open source projects, boast about being all open (which is true) and free (which is not true).”

    Free as in freedom is a beautiful idea, even if unrealistic in its pure form. Free as in zero-cost is not what LO boasts about in most other languages. The name even emphasizes this difference; “Libre” is not the same as “Gratis”.

  4. I have been mostly out of the loop wrt LibreOffice since ca. 2014 but damn, your analysis is terrible. Before you publish more of these underinformed posts full of misunderstoodings, ask someone who actually knows the project, developer workflows, and even the overall computing world to read and annotate.

    I have not read the entire post. I read until you claimed that Uber is making money — which is neither a relevant example nor remotely true (Uber manages to lose something like 40c on every 1$ even as it is exploring legal limits and exploiting their employees misclassified as non-employees; VC funding and the faint hope of becoming a autonomous-car monopolist keep them afloat).
    The post is also way too long in any case.

    I’ll say that:

    * you grossly underestimate the work done by ecosystem companies (and mmeeks’s blog has graphs on that; using data from the GitHub mirror repo is not a good idea)

    * you seem to think that development processes only involve making commits (as examples, there is code review, mentorship, general discussions of direction, triaging bugs to some extent, etc.)

    * you seem to underestimate the value presented by continued maintainership and mentorship which is largely provided by ecosystem companies (except for the Base component).

    * you seem to completely neglect the wide gap in knowledge and interest between the average user and developer of LibreOffice; meaning there are few users who later become developers (unlike with more developer-focused projects)

    * you seem to ignorant of the business models of Red Hat, SUSE, and Canonical that are all selling free stuff and making money off it (hint, they actually charge you for timely updates and for support)

    * you seem to assign no value to the existence of software not entirely controlled by Google or Microsoft

    * you hint at a crude understanding of product vs. complement (which is good), except you don’t seem to see that support/updates/migration assistance can be the product — and that is what all/most(?) of the ecosystem companies are founded on

    … :/

    1. Yup! Interesting opinions of yours, of course after NOT reading the whole post by your own admission (“I have not read the entire post. I read until you claimed that Uber is making money […]”. I am suddenly very “informed” by your input! Thank you! :)

  5. I don’t think that forking is the answer to all of our problems. I merely speculated what it would look like when that happens (perhaps wishful-thinking?), and suggested that it most probably will, at some point. I agree that either the main team, the fork, or both might even end up dead. That is always possible, and perhaps likely in the case of a large project such as LO. Nevertheless, a fork is very likely to happen. LO is big, but is not as big as most Linux distros. And how many Linux distros do we have today? That’s the idea.

    1. “Nevertheless, a fork is very likely to happen. LO is big, but is not as big as most Linux distros. And how many Linux distros do we have today? That’s the idea.”

      I thought the Linux kernel would be a better example.
      I looked at Wikipedia to check what I thought: Linux distribution (often abbreviated as distro) is an operating system made from a software collection that is based upon the Linux kernel and, often, a package management system.

      This may sound obvious but any fork of Linux probably will be less successful than the original.
      I think that the leader of linux (Linus) is what makes the project successful. The code could be copied and forked but the leader cannot. Without going into details about leaders etc. Leadership is what makes a difference and the rest is not as relevant.
      That applies to everything of course.

      I wish for TDF to have a strong leader that takes the project (more than the product) forward with a clear vision and becomes an models for other small Open Source projects.

    2. “Nevertheless, a fork is very likely to happen. LO is big, but is not as big as most Linux distros. And how many Linux distros do we have today? That’s the idea.”

      Answer: way to many, if you ask me. Somehow everybody knows better what to do. Never have seen such waste of resources. Instead of polishing more, we fork. With often a mediocre quality. So never reaching ‘mainstream’ quality. It’s a a project for enthusiasts (desktop).

      Maybe it’s they destiny. Build by engineers for (software) and ICT infra engineers.

      Instead of ironing out issues we fork. However forks do sometimes produce results. Including codecs was always hot debated topic. Until Linux Mint came along (I think). Where this was build in.. The success made others to see the light. Making the distro less needed again. Linux Mint evolved in this case without that advantage.

      Knoppix was the first bootable CD/DVD Linux. Or I do remember so (didn’t do a fact check). Does somebody use it nowadays? Every Linux can boot from CD/DVD/USB.

      It’s more that the vision is lacking. If you ask me. Or not truly communicated. Or everybody is divided everywhere. Or the communication process got stuck. Board is staffed with engineers; who like building. And making progress.

      Instead of explaining, repeat explaining (so hard to convince), building business cases etc. The meritocratic community. is maybe an advantage but also lovely pitfall. To many different vision.
      So board should display more leadership (& prominence). In the sense of having clear vision/plan/roadmap. Being the captain. There are now only many voices without direction. And the board is doesn’t seem to have a plan (business case). Except some idea of an economic approach.

      With the Board I mean the full board. The Board of Directors. Not persons within the Board on their own account. They may have spokes person, but he/she sends the message of the BoD as a whole.

      And it should start with the history of TDF, the development to TDF today. The mistakes of the past. The challenges/ issues currently seen. The possible solutions (directions). Scenario thinking..

    3. I agree with you on all of those accounts.

      Forking should not be seen as the first option. It is way too risky. Nonetheless, it should not be totally dismissed either if the main organization is parallelized for whatever reason. I think forking LO would be even more difficult, because LO is a lot less critical to people’s lives that a Linux distro might be.

      I completed a draft last night related to the vision we all talk about. I might post it today. I am waiting for a friend of mine to advice me on my “rambling” writing, because I don’t want to end up like John Wick with the whole city after running my head. :D

  6. “What a wild-goose chase! This is exactly how the AOO’s BoD were reacting to all criticisms back in the days leading to the LO fork. I came to the same conclusion as those critics of AOO once did: There is no point in all these, since history repeats itself.”

    When LO was forked:

    a. there was no AOO. Just OO.o

    b. That OO.o project was controlled by Sun / Oracle, not the community (there are some rules at TDF so that no company can “own” more than 30% of the TDF board)

    c. It required a Contributor License Agreement for external contributors, giving Sun / Oracle more power over others, something that normally copyleft licenses prevent

    d. Even if someone signed the CLA and tried to submit patches, it was not certain if these would be accepted.

    Let me tell you about the first time I personally gave attention to LO. It was due to this bug: https://bz.apache.org/ooo/show_bug.cgi?id=91143
    Patch submitted to OO.o in 2009-07, nothing happened for two years, still unsolved 11 years later.
    Patch submitted to LO in 2011-03-11, pushed 3 days later: https://www.mail-archive.com/[email protected]/msg07731.html
    That was when I thought “Hey, this fork seems interesting, there may be something more to it than I believed”

    e. There was already a fork (Go-OO), supported by a company (Novell) that compiled useful patches that were not accepted to OO.o. Merging this with LO seemed obvious and gave the new project paid programmers to work on it from the beginning (I’m a bit blurry at the details and dates, but that’s effectively what happened).

    What I mean to say is that there were more underlying reasons for the previous fork that your post doesn’t mention. All these problems are solved in LO, making any potential fork a lot less needed or wanted.

    P.S.: I said “ungraceful”, not “ungrateful”, there’s a slight difference.

    1. Fair points! Thank you! Duly noted and corrected.

      I know the history and have read most of the materials mentioned here and elsewhere. I have been following OO, Go-oo, AOO, and LO since they came to be, kept reading their mailing-lists, blog posts, and all that. At this moment, I am too exhausted and began to make silly mistakes. I should stop writing before I mess up everything. :D

      BTW, my spam-control filter holds all comments back. I have to approve them manually. Thank you for being patient with me.

  7. It is interesting the credence you give to a top programmer at Intel
    with “years of coding experience”. Lets we forget, Intel processors
    are written in TCL which is a linguistic abomination, and have had
    some extraordinarily expensive and fundamental problems that have been
    widely publicized in recent times. You write: “Most probably, your
    beloved LO project does not have any good coder.” – I’m willing to
    admit I’m probably a terrible coder: with only 30 years of experience,
    but I’ve programmed alongside many of our industry’s excellent
    programmers, and (in my view) the ability to handle complexity that is
    needed to effectively contribute to LibreOffice -ensures- that anyone
    with significant code included is an outstanding developer who would
    be welcome on any sort of project, and I salute them.

    When it comes down to who contributes what – there are a lot of
    different factors, but it doesn’t surprise me to see a long tail,
    or a Price’s law https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price#Scientific_contributions or Pareto principle https://en.wikipedia.org/wiki/Pareto_principle type behavior at work.

    For far more accurate economic numbers checkout:
    https://people.gnome.org/~michael/data/vendor-neutral-marketing.html

    There are some amazingly amusing gems in your article, let me do
    a large ellipsisis; you write:

    “The main issues that we are facing today are mostly the
    result of the managerial style of TDF in general.
    Designed by committee:”

    “If I were on the Board as a dictator … immediate freeze
    on all new feature requests and implementations. Then I would
    have put a committee together ”

    Apparently this new committee would set a technical direction that
    made sense.

    Ultimately – some of what you write seems sensible to me, but my
    problem is sorting the truth from the confabulation.

    My thesis is that LibreOffice’s problems are fundamentally economic.
    You seem to agree – your perscription seems to be enabling widespread
    creation and sale of proprietary plugins, templates etc. Mine is to
    building marketing incentives for those who really contribute to the
    core.

    You speak of forking; but without any clear motivation for that: is it
    to fix the code ? How can that code fixing be done without finding,
    and hiring these amazing, (expensive) missing developers you seek ?
    how can that be done without getting the economics right ?

    Ultimately – I fear this whole article is a great example of the
    typical approach here: loading yet more blame and criticism on those
    who are trying to solve the problems in the code and the project.
    Perhaps it is our fault for caring.

    1. -> My thesis is that LibreOffice’s problems are fundamentally economic.
      They economics certainly a big point. However keep in mind that the profit orientated organization does require a different mindset. Which comes with different culture and/or attitude.
      They whole project culture, where everybody can do what (s)he likes, pick whatever you like, mentality isn’t matching commercial reality. There is no room for unfinished features, partly done refactors with lose ends, or non-maintained features. And we will fix that when they time comes mentality.

      You will be accountable, hold responsible, for incomplete stuff, regressions etc. You can’t make people pay solving self-inflected regressions for the greater cause.

      This are ‘costs’ which are calculated within the price of the product. You really expect people paying for servicing contracts for self inflected bugs to be repaired. You can calculate those costs in advance in the price.

      Another point is there are slipping way to many bugs though they net. There are even regressions in the super stable releases. Partly because of lack of automatic testing. However not sure how many man years it would take to get that at a level where most stuff simply get cached in advance. Not a short term project :-(

      So if you want commercial, the whole project attitude has to change. Developers need to responsible, accountable for bugs. They need to be sorted out. Quality control has to go up. Features must be finished. Table styles if for example more prominent accessible but simply unfinished since LibreOffice 5.3. This can’t be they case in a commercial product.

      The whole problem is; lower quality lower price. In a commodity market. If you where in a niche market. You can simply ask sky high price for mediocre product. But we are talking about replaceable product. And even being open source isn’t unique anymore (yes, still license difference so maybe some ‘marketing room’).

      Solutions can be sold (custom made stuff) or consultancy or specific fixes (outside the scope of what can be considered normal)

      I already pointed some devs to the lovely Kohei presentation (https://www.slideshare.net/kohei101/life-after-calc-core-change), sheet 26, but that’s end up in a do it yourself argument. Or answers like “Or say do you know how the writer a easily write a unit test checking for unforeseen performance regression with a rather corner-case document.”

      As easy as it is to complain/criticize about things, is the opposite shooting every critic/messenger (or the full message) if you dislike the message of some of it. It’s appealingly a kind of automatic reflex. Certainly at QA/DEV departments. Yes, there is certainly some undeserved negativity around. And you might feel sometimes out of control.

      There really a stung by a wasp attitude is really tiresome. Dev’s going into defense mode why they ‘regression’ keyword was unwarranted. They also could simply said so + removing they keyword. I assume the developers themselves are trustworthy & know best.

      Sometimes I wonder how the working culture is. The community sometimes feels like group of grumpy old very frustrated people. Ran against countless walls, so the gave up. Idea’s will be fend off or answered with go ahead (and you will notice). You simply point to a suggestion/idea idea board (read: wiki). So there at least the impression something is done with it (or thought about).

      Related to “Or say do you know how the writer a easily write a unit test checking for unforeseen performance regression with a rather corner-case document.”

      Acknowledges the need for unit tests; except not easy; which sounds like flaw in the testing framework. They person who wrote this is certainly capable of writing code.
      Unforeseen performance regression: most regressions are unforeseen I hope; are are we sneaking in foreseen perf issues too. To be discovered by QA or user? Instead of self-reporting it? Or is this paranoia?
      Also unforseen in combination with “a rather corner-case document” suggests that I blamed the person I question. I didn’t or didn’t intend to do. Nor I intended to be the educating tone (However somehow UX beliefs UX flaws to be cured by teaching)
      I “only” asked for a united test for preventing this in the future. As this bug more or less re-appeared within 3 months (for whatever technical reason)

      Corner-case: A beloved wording.. I’m developing an allergy here. At some point I lose track where they corner case ends and normal area starts. As the code goes in detail rather often nearly everything become are corner case. At with a large user base the probably of experiencing a so called corner case increases. And with they number of so called corner cases around, it’s likely every user will hit one; if they truly use LibreOffice (instead of only typing a few lines).
      And the definition of corner case depends also from perspective. If you’re using LibreOffice exclusively from command-line, command-line bugs a pretty nasty. If you have to do some action and you always have do additional steps, it’s becomes an annoyance. Even if they rest of the world doesn’t care. Which ultimately ends what defined as priority. Which isn’t static but could also interval based. One month focus on spell checker, one month focus on dialog. Or whatever.

      Product quality-wise LibreOffice certainly lacking behind. Partly because developers are unaware of those as they simply don’t land in the bug tracker. As they general public not being the qualified to report those. Not able to tell what happened. Don’t have time; Don’t care. Partly because stuck in QA. For example QA only confirmed the bug without testing previous editions (so a possible bi-bisect got missed). Volunteers…
      If it’s inherited bug, there is simply nobody to attach to a bug.. So reach the depths of the bug tracker pretty quick.
      If a bug is bibisectable and finally gets bibisected (which can take while), it lands on developers plate. There are developers who fix stuff pretty quick; there are developers who hardly respond, while being “active”. Whatever reason there might be for that. So if it’s really urgent you might ask polity and they might look at it.
      However the rest will linger in the bug tracker.

      I did think about ‘measuring’ how quick developers responded to regressions. Simply to have some stats. However those stats can be (partly) misleading. Some cause more regressions because of tricky area. Some have simply more time to look at it. (There are of course even more factors) So those will be skewed (certainly not suitable for public). And not sure if it will be liked at they dev-departement either. As everybody is starting to clean behind them. No it wasn’t me, I only uncovered a bug etc.

      ———
      -> Ultimately – I fear this whole article is a great example of the
      typical approach here: loading yet more blame and criticism on those
      who are trying to solve the problems in the code and the project.
      Perhaps it is our fault for caring.

      A) You need to read through the lines. I don’t think Eric is out to play the blame or criticize game. I don’t think he is saying he can do better; nor can I. I see it more as an indication he cares.. Else I won’t take the time to write such an article.
      So read through/ignore the possible offensive stuff (don’t read it as (personal) attack or attack at BoD or TDF). Would love to see a red/orange/green highlighting of the text. To know what you dislike/ like or being neutral on. Things look differently from outside knowledge compared to inside knowledge. It’s more a impression from a philosopher.

      B) “Blame and criticism on those who are trying to solve the problems in the code and the project.”.

      What do you expect from others? Everybody has it own view based on the information available. . I assume Eric is only sharing what is on his mind. Leaving in the middle if everything he says being accurate.

      However, every input is input. It must not be ‘I don’t want to hear this or that’. More why is he saying this or that. Or how does he come to that conclusions. Or make him say this or that. Yes, sometimes it can be pointless/waste of time. However is a philosopher, so might be reasonable. Even if he said some painful things; or utterly mistaken stuff.

      However they outside has also no idea what’s playing. Everything at TDF is a black box. There is no analysis of the current situation. They issues. Not helping either is that eco-system partners being separate business. So no insight in marketing strategy, number of customers, results etc. Or even the time developers spend on LibreOffice.

      Which at some point starts again with trust. Being director at BoD and at the eco-system partner has the advantage of company knowledge being on board without having to be ‘shared’ officially. At the same it’s hard to tell which information is being used.

      Their is certainly sometimes some distrust about what they eco-system partners, members of BoD, about communicating the full story or only sharing certain information based on selective shopping (intended or unintended). Or presenting it certain way. At least got that impression. Of people saying, say : X claimed..

      They BoD can be replaced; which might solve the direct conflict of interest or the silently shared information. However their is still information asymmetry. Eco-system partner company figures etc being secret. As lots of the actually work is being done outside TDF.

      They commercial route route won’t be magic bullet/ holy grail and certainly a bumpy ride. It’s necessary I think, but will involve much more compared simply running a appstore. And will require a cultural change. Less project, more product driven. Quality up. Less freedom. Less fun GSoC projects. Yes, have argued about that with Heiko already. It wouldn’t sell.
      So you get enemy’s at the core (members) and maybe also enthusiast (disliking paying). People refusing to contribute any longer (commercial interest). Less new contributors.

      So this will need lots lots of communicating and explaining. Consideration, reconsideration. And they BoD/ MC needs to regulate/ control the process. You need to govern the crowd, not being governed by the crowd. Their will be lots of critics. From the inner circles to the outer ones. At they one hand you need to listen; on the other you need to ignore them (in a polite way).

      Their a so many analogy’s with governing/politics here. Politicians do media trainings/ learn communication techniques sending their message. And defending their position against critics without attacking. The have to cope with voter with different backgrounds different interest, priorities. Lobbyist proposing their stance. Journalist writing articles. Being able to burn you down to ground. Or even get you to resign. Simply because the make they mood. Mostly enlarging you’re mistake; getting it out of reasonable perspective; but it’s totally out of your control. But who doesn’t like those juicy story’s;front paper news.

      I really would advise to do a inquire for a strategic consultant. To get a grip on everything. And keeping things in control. Members ‘hobbying’ around. Trying to help. Doing their best in the spare time. Not sure if it’s enough to keep everything on the rail. To many disciplines involved, working culture, strategic, marketing, business model, transition management, law.
      You can get a master degree/ start a professional career on each of those topics. Need again next 5-10 years experience. Doing nothing else.

      TDF isn’t a amateur football club, based on the figures. So bettering working informed. Especially with a complex structure. TDF being sustained by eco-system partners. And eco-system partners relying on TDF brand
      Note: advisers are surely (again) not the magic bullet, BoD should be still in charge (advisers not always get it; so they can also come up with worthless advise), but might increase the likely hood of navigating at rough waters.

  8. Accusations of sloppy programming on an extremely old, complex C++ codebase full of legacy stuff, that has to tackle low level operating system APIs and maintain a cross-platform GUI library, certainly seem ungraceful.

    I say that as an outsider, who has never submitted a patch to the project, in part because of the sheer task this is (not because of project organisation or lack of pointers to the right direction but due to the coding difficulty it involves).

    The comparisons with blogging platforms ecosystems / forum mods seem simplistic, it’s a totally different ballpark to develop a web app than a cross-platform that has to work on multiple desktop operating systems, browsers, mobile operating systems.

    Last but not least, anyone who believes it’s easy to fork a project of the size of LibreOffice will just end with a new AOO at their hands; simply another stagnant cousin. After all, if a company / group of people find a sustainable model for the project, it would be easier to just apply it to LO and take advantage of the other contributions.

  9. Hi Telesto. Thank you for reaching out to me.

    A lot of thing I said in this article need more data to make real sense. Since I am not a programmer, not on the BoD, not looking from outside, I can see only so much.That, certainly, distorts my view.

    I totally agree with you about a fork wasting almost everything. I am not suggesting that to happen either. However, TDF cannot change by virtue of its German foundations in the German law. If any fundamental change becomes necessary for the project, TDF cannot accommodate by design. Sadly, too many stars have to align before any such fork might have the slightest chance of success.

    I agree with all of your points. I really don’t know how else we can save it. The challenges are so monumental that all of these hard-working, admirable, wonderful ppl who are currently contributing to the project have not been able to set it straight.

    Yet again, that makes me think if a different management setup, unlike designing by committee, could have had a different result.

    [Sigh]

  10. Nice article. I do agree on a quite a number of topics touched here. LibreOffice feels once in a while like a (still) walking dinosaur. With competition being fierce and Office software being commodity, keeping up will be hard.

    About they code contribution matter: dislike the stats. Those are not really representative. You really need to in depth assessment as those a distorted here an there. Blowing up they contributions of the independent.

    Argument about quality of the coders; not able to access that. Large code base, old code base (technical debt), no substantial testing frame work. So quite a number of factors next to they coders themselves. And you have to take in account the working area. If volunteers make changes to they GUI this shows up in they stats but has less impact compared to touching the machinery behind it.

    They code itself maybe not in good shape (maybe better compared to the past but still); enough developers bailing out on number of topics. To hairy/ time consuming to touch. And those are they more experienced ones. Also I do get they impression that number of old capable developers at Oracle/ OoO project moved on to different challenges. Lots of knowledge being lost. But that happened long long ago. So bringing the back in is also pointless

    Instead of speeding up development (to undo the slowdown started with OoO) it slowed down (again). New developers hard to attract (better perspectives elsewhere), so their is they ‘old guard’. Ideally/ideologically moving on, as best as they can.

    A significant part of the code (so the mechanics behind) surely comes from the eco-system partners if you ask me. Look at they bibisect results of all regressions & names attached to it. What’s touched ‘gets’ broken somewhere. And shows who is actively touching they machinery (with all risks involved).

    However not they impression that a single devs eco-partners are working full-time on LibreOffice. Mostly somewhere at the side; or working on specific project. Or having two weeks to play around. But of course developer/employees have to do spend their time in they way their boss wants them to do. And their if of course revenue part

    Feature creep; certainly. New features instead of fixing the lose ends at implemented features; sure. However somehow LibreOffice isn’t interesting anymore for GSoC without they fluff. Asked already do less fancy tasks, but doesn’t sell.
    FWIW: their is also a maintaining issues (Base/MacOS).

    Fork: waste of resources. Again losing number of developers; lose-lose situation. Both projects will end up death. The current path is unsustainable too.

    I have moments where it feels everything being a little to late. So TDF/LibreOffice does some last convulsions; like commercial edition, which will not deliver they badly needed results. Starving ultimately to death. Not being resurrected; as they code is simply to old (legacy) and the competition to fierce. Eat of being eaten. Except if their is some philanthropic person with very deep pockets (Elon Musk/Mark ShuttleWorth or lets say for the irony: Bill Gates).

  11. Nice article. I do agree on a quite a number of topics touched here. LibreOffice feels once in a while like a (still) walking dinosaur. With competition being fierce and Office software being commodity, keeping up will be hard.

    About they code contribution matter: dislike the stats. Those are not really representative. You really need to in depth assessment.

    Argument about quality of the coders; not able to access that. Large code base, old code base (technical debt), no substantial testing frame work. So quite a number of factors next to they coders themselves. And you have to take in account the working area. If volunteers make changes to they GUI this shows up in they stats but has less impact compared to touching the machinery behind it.

    They code itself maybe not in nice shape (maybe better compared to the past but still); enough developers bailing out on number of topics. To hairy/ time consuming to touch. And those are they more experienced ones. Also I do get they impression that number of old capable developers at Oracle/ OoO project moved on to different challenges. Lots of knowledge being lost. But that happened long long ago. So bringing the back in is also pointless

    Instead of speeding up development (to undo the slowdown started with OoO) it slowed down (again). New developers hard to attract (better perspectives elsewhere), so their is they ‘old guard’. Ideally/ideologically moving on, as best as they can.

    A significant part of the code (so the mechanics behind) surely comes from the eco-system partners. Look at they bibisect results of all regressions & names attached to it. What’s touched ‘gets’ broken somewhere. And shows who is actively touching they machinery (with all risks involved).

    However not they impression that a single devs eco-partners are working full-time on LibreOffice. Mostly somewhere at the side; or working on specific project. Or having two weeks to play around. Being employee & pecunia matter, I think

    Feature creep; certainly. New features instead of fixing the lose ends at implemented features; sure. Also maintaining issues (Base/MacOS).

    Fork: waste of resources. Again losing number of developers; lose-lose situation. Both projects will end up death. The current path is unsustainable too. And I have moments where it feels everything being a little to late. So few convulsions; like commercial edition, which will not deliver they badly needed results. Starving LibreOffice ultimately to death. Not being resurrected; as they code is simply to old and the competition to fierce. Eat of being eaten.

Tell me what you think below (comments are moderated)