LibreOffice – Designed by Committee

By Eric Bright

---

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.

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!