Some thoughts on the LibreOffice ecosystem, and the future of the LibreOffice project

WARNING: The text is long, but not because I have dwelt unnecessarily on certain points, but because I have tried to go through all the points in such a way that the explanation leaves no room for misunderstanding. Furthermore, I have avoided stirring up controversy by glossing over the causes of some of the problems (but I am, of course, prepared to give a private explanation to those who feel it appropriate to know my point of view).

The LibreOffice ecosystem is one of the core components of the project. It consists of companies that add value to the source code by developing new features or providing consulting and training services. In most cases, these activities are paid for by an organisation wishing to adopt or migrate to LibreOffice.

When the project was born, the companies in the ecosystem, especially those focused on development, played a key role. Their developers did most of the work, while helping newcomers get up to speed with the source code.

At that time, the enthusiasm for the new project and the presence of numerous migrations to LibreOffice encouraged the growth of the number of companies, which even doubled within a few years. In those years, desktop investments were still very important and the first investments in the cloud were looking for open source code as a basis for their own development activities.

At that time, Collabora Productivity was born from a group of SUSE developers. After some time, CIB - a German company based in Munich - opened the LibreOffice division, which later became allotropia in 2020.

From 2014, the growth of the ecosystem slowed and then stopped, and within a few years only Collabora Productivity and allotropia remained as companies 100% focused on LibreOffice in the development area.

In my view, this development is mainly due to exogenous factors:

  1. The evolution of the market towards cloud solutions and the increased presence of office suites such as OnlyOffice and WPS Office, which use the similarity with Microsoft 365 to attract users. These suites are developed by companies, allowing them to have a more coherent marketing strategy (more on this later).

  2. The inevitable consolidation of a market, that of office suites, which has now entered its second phase of maturity and has therefore already gone through two cycles: growth and consolidation on the desktop, growth and consolidation in the cloud. There will probably be a third phase of growth, but it is not possible to predict when.

  3. The declining attractiveness of C++ as a development language, especially for the younger generation who are attracted to other languages such as Rust. I have no development expertise, but that does not mean that I do not read criticisms of C++, such as those in the area of memory management.

  4. The decline in LibreOffice implementation projects at the government level, which is the result of Microsoftā€™s long-term strategies using a combination of lobbying and targeted marketing strategies (more on this later).

Of course, this reduction in the number of companies in the ecosystem is also reflected in The Document Foundationā€™s ability to entrust paid development activities - on the basis of calls for tenders that are theoretically open to all, but in reality limited by the concentration of skills - to a large and diversified number of companies, as should be the case if the competitive scenario were characteristic of an open market.

Since both Collabora and Allotropia are direct or indirect ā€œdaughtersā€ of the original Star Division, which means that the relationships between their managers and employees almost always go back to the years before the birth of LibreOffice, it is quite natural that there is an exchange of labour between them, paid of course, when the size of the project or the proximity of deadlines require it.

In addition, members of both companies have been active in the LibreOffice project since its inception, serving on both the Engineering Steering Committee and almost all of the Board and Membership Committees, as well as volunteering in various areas of the project.

At this point, the contours of the problem should be quite clear: in a market situation where concentration is the result of exogenous factors, the length and number of relationships at all levels within the project, not only between Collabora and allotropia but also with independent members such as myself, create a situation in which conflicts of interest are almost always present and the risk of falling into the trap of excess of power of representation is very high.

What the authorities require, through the opinions of lawyers

The Document Foundation is a charitable foundation, and as such it must comply with a number of rules laid down by German law. As I have already written, it is not enough to use common sense or the ā€œdiligence of a good family manā€ to have a clear conscience. That is what the Steering Committee and the first Board of Directors, of which I was a member, did, mistakenly and out of overconfidence.

The ā€œdiligence of a good family manā€ refers to the way in which contractual and non-contractual obligations are fulfilled. It is a private law concept dating back to Roman law and is widely used in the Italian Civil Code to describe the average diligence of an ordinary person. The image of the ā€œgood family manā€ is, of course, figurative.

The opinions of lawyers that the Document Foundation has received over the years, confirmed by the results of the 2023 audit, reflect the dictates of the law and do not leave much room for creativity (generally speaking, the law never leaves room for creativity). It is now time to establish clear rules that will avoid the deadlock in decision-making of the last four years and allow everyone to work calmly, in the knowledge that the law is being respected.

Rules are therefore needed that, on the one hand, avoid the risk of falling into the trap of excess of power of representation and, on the other hand, protect against the effects of conflicts of interest. On the other hand, the governance of The Document Foundation cannot disregard the presence of all stakeholders and must therefore include both independent volunteers and employees or affiliates of companies in the ecosystem.

At the moment, the Board is working - painstakingly, and perhaps more slowly than expected - to get there. Unfortunately, there is a lot of work to be done, because there are many unresolved issues, and there are many areas where it is necessary to create clear and universally understood rules that prevent any interpretation other than the original one.

How to face the problems in this situation and how to solve them

My management experience and the management schools I attended first in Italy and then in the United States (GEā€™s Corporate University in Crotonville) taught me to solve every problem with a solution. Unfortunately, I did not see the same approach in the Board of Directors of The Document Foundation, where the tendency was to solve problems with other problems (as many do).

When I was elected, I did what I would have done in any other management position: first, I tried to analyse the problems, based on the huge amount of documents - lawyersā€™ opinions, email discussions and other documents - that we received after taking office, to get my, and only my, idea of what solutions were needed to solve them.

And because I did not want to be influenced in any way, I refused all offers of ā€œhelpā€ that I received, because I was sure that they were trying to steer my opinions in a particular direction. It probably took me longer - because the documents I had to read were many and almost always difficult to understand - but I now have the certainty that I can express my opinions with conviction, confident that my interpretation is correct.

I have already explained how this approach led, on the one hand, to the proposal of a strategy to tackle each problem individually in order to reach a solution within a reasonable timeframe and, on the other hand, to the drafting of all the documents you have read, are reading and will read.

In the case of the procurement policy that is currently being approved, it is clear that this is a document that will need to be discussed in order to arrive at a final version in 2025. However, by approving this first version, we can show the authorities that we are working to solve this problem.

In particular, the document addresses the problem of conflict of interest without taking into account the peculiarities of the LibreOffice project and ecosystem that I wrote about in the first part of this document. History tells us that in most cases the resources available to us for defining tenders are the same ones that will later participate in the same tenders, so the solution must be different from the one proposed.

In particular, there are two issues that are addressed in the first version of the Procurement Policy, but have not been completely resolved:

  1. The ā€œarmā€™s lengthā€ concept, which is used to resolve conflicts of interest, clashes with the exogenous concentration of high-level skills in the development field to such an extent that in most cases it invalidates it. In fact, if I cannot use the skills to produce a good tender, I will have a qualitatively inadequate tender, which will be matched by an equally inadequate development. On the other hand, if I do use the skills to produce a good tender, I will not have a development commensurate with the quality of the tender itself, because those who helped to write the tender will not be able to participate in the tender.

In fact, according to the first version of the Procurement Policy, those who participate in the first phase - the definition of the tender - cannot participate in the second phase - the actual tender - and vice versa.

This is what is commonly referred to as a ā€˜lose-loseā€™ situation, where everyone loses: The Document Foundation, which spends without getting the expected return, and the companies in the ecosystem, which have fewer opportunities.

  1. The expansion of the ecosystem cannot be defined by edict, because the conditions are not managed by the Document Foundation. The solution to this problem is also complex, because the entry of new companies able to participate in the tenders can only happen if LibreOffice grows and expands its market share and presence in migration projects to the point where it represents a business opportunity.

This can only be done in the context of a marketing and development strategy that sees the synergetic participation of all elements of the project. In 2020, with the definition of a marketing plan focused on these objectives and the introduction of the LibreOffice Technology concept, there was a first attempt to set up this kind of strategy, but it was rendered useless by the Board of Directors, which first approved the plan and then ignored it.

Probably the rules I wrote for using the terms LibreOffice Technology, LibreOffice Enterprise and LibreOffice Ecosystem were not clear enough because they were misinterpreted. Therefore, one of my next tasks is to rewrite these rules so that they cannot be interpreted in a way that contradicts the definition.

Why marketing can benefit the project

It was to this topic that I dedicated the presentation that closed the Milan 2022 conference, in which I took up some of the themes of the marketing plan, expanded them with a series of market data and placed them in the context of the sustainability of open source software. A topic that has become highly topical with the growth of the sector and its strategic importance.

During this presentation, I quoted Dries Buytaert, founder of Drupal and CEO of Acquia, and his post: ā€˜Balancing Makers and Takers to scale and sustain Open Sourceā€™ (Balancing Makers and Takers to scale and sustain Open Source | Dries Buytaert), a reading which I highly recommend.

On 2 October 2024, Dries returned to the topic with another post: ā€˜Solving the Maker-Taker problemā€™ (Solving the Maker-Taker problem | Dries Buytaert). I highly recommend reading it as well.

The Drupal ecosystem is very different from the LibreOffice ecosystem because the market is different, the projects are different (and they are hardly ever migration projects), and the target users are also different. It is therefore not possible to make a comparison, but it is possible to draw inspiration from the strategies used to address the issue of sustainability, which is very similar because, as with all open source projects, it is linked to growth.

According to Dries, open source projects need to address two challenges:

  1. The imbalance between major contributors and those who contribute minimally, and how this harms open source communities.

  2. The lack of an environment that supports the fair coexistence of open source businesses.

In the case of LibreOffice, where more than 90% of donations come from individual users, the first challenge is the imbalance between business users who use LibreOffice and contribute in some way to its development, and business users who use LibreOffice and contribute nothing to the project, which are the majority (possibly, over 95% of business users).

The second challenge, which affects LibreOffice and its ecosystem, is common to all open source projects.

The solution proposed by Dries is probably suitable for the Drupal ecosystem, but not for the LibreOffice ecosystem, although there are some interesting ideas, such as the rewards, which could be adapted (e.g. to invite volunteers to conferences).

On the other hand, and I said this in 2022, what is clear from the post is the cooperation between the different components of the project, at all levels. What our project has lacked and still lacks is cohesion, especially in terms of communication.

LibreOffice has a number of competitive advantages over other office suites that should be the focus of attention at every opportunity (press releases, presentations, articles, sales picthes, you name it):

  1. The robust and flexible software platform called LibreOffice Technology, which enables the development of desktop, cloud and mobile versions. This ensures consistency between applications and interoperability at all levels.

  2. The standard document format Open Document Format, also robust and flexible, and the ability to ensure interoperability with documents in the proprietary OOXML Transitional format (the only one that exists).

  3. The use of a copyleft licence, both for versions released by the Foundation and for versions released by companies in the ecosystem, which protects users from a mix of open source licences (in some cases modified to be incompatible with the open source definition) and proprietary licences from other office suites.

  4. The privacy-oriented features of the software, which not only does not track usersā€™ activities to collect their behavioural data and content to create an ever more precise profile, as Microsoft 365 and Google Apps do, but even allows all user-related data to be removed from documents.

These messages must become the common thread in the product communication of all project components. And with it, the use of the terms LibreOffice Technology, LibreOffice Ecosystem and LibreOffice Enterprise, based on clear and precise rules that allow for medium and long-term investment by all stakeholders.

Only by working together and joining forces - not even comparable to those of Microsoft and Google, and certainly less cohesive than those of open source competitors who always have a corporation behind them - will we be able to grow LibreOffice as software and as a project, and attract new companies in the development and professional services areas.

Closing rant

I devote all my energy and free time to The Document Foundation because I believe that the project I helped to create still has great potential. Unfortunately, I do not see the same kind of commitment, if not in terms of time, at least in terms of goodwill, from other people (I use a generic term because I am not addressing a group of people or a particular person, but all members of the project).

We all have a bit of rust on us, myself included. Over the years I have been told that I am useless because I am in marketing, that I am verbose, that I am not trustworthy because I am Italian, that I am a liar, that I should be ashamed of my actions (which ones?) and perhaps I am forgetting something because I have learnt that it is better to forget these kinds of ā€œinsultsā€ because they only serve to waste energy that could be put to better use.

Letā€™s shake off the rust and get back to working together as we did in the early years of the project. The scenario around us has changed, but that does not justify any kind of action against cooperation - one way or the other. Someone has understood, but I prefer not to reveal his name for the time being. Letā€™s just say that this is a very important step forward (and I respect the person enough to say that I somehow expected it), and it raises my hopes.

At this point, I hope that others will also take a step forward. This would make life easier for everyone and allow us to get out of the current situation in a reasonable amount of time (I do not use the word ā€œshortā€ to avoid raising expectations that we will not be able to meet).

POST SCRIPTUM - If you want to send me a private message, please use italo@vignoli.org.

1 Like

Thanks Italo. Iā€™d like to share a few additional thoughts on this useful text.

About the currently two ecosystem companies contributing significantly to development of our code base. Looking around in open source land, there is a huge variety of projects, ownership, and communities. Also quite a number with open core (ā€¦) and one single company as owner. So from that perspective TDF is doing quite a good job and for sure better than in the time of OpenOffice.org (although we owe Sun Microsystems et all much gratitude for paving the path).

Chances for companies joining our community as new code contributor are - we have to be honest - indeed low, as Italo explains.
I expect that, might it happen, it will be either in a completely different geographical territory or in an area differing from the traditional office document, or even some real innovation.
Of course it also depends on one/few people active in open source seeing opportunities and taking the risk to make that step. Lets see!

Wrt procurement: the German legal external expert whom was asked for advice, mentioned various prerequisites to do tendering properly. Vital is the arms-length nature of the contractual relationship, whereby all terms and conditions must stand up to an armā€™s length comparison. The most complicated thing for TDF/LibreOffice is the specific technical knowledge of the code base. That knowledge is important to set up tendering projects - that all serve our LibreOffice project - properly. That knowledge however, is almost all present in the developing ecosystem companies. Simple since the knowledge only grows when you do a lot of the the hard work yourself.
TDF tendering procedures have always prevented CoI decisions. The new procedure brings improvements in the area of preparing the tenders. That does come, and Florian already referred to that, with the need for TDF to make some extra miles in the procurement process.
The expert also mentioned that tenders should be done either in public, or with at least three bidders, of which one not closely related to the foundation.
Of course all the relevant information for the projects must be available to all bidders, which to my best knowledge has always been the case in TDF. So the improvements in the procurement are relatively few, and e.g. a master contract can be a useful tool to make the work simpler.
All in all - despite the fixes needed in the just approved procedure and contract, that were reported also on this forum - I am very positive on TDFā€™s opportunities in this area.

Cheers,
Cor

But says a number of rather sensible things, including some great plans to improve marketing and positioning - as well as some things I disagree with.

This is a less well-known fact. Thanks for stating it. In those days it is/was only true to say: ā€œthe community created LibreOfficeā€ - if you heavily included all of the ecosystem developers firmly in your meaning of ā€œthe communityā€. That FWIW is something I would like everyone to continue consciously doing. If we take a contemporary mis-framing of the word: community - itā€™s possible to hear: ā€œvolunteers created LibreOfficeā€ which is very misleading. Some perhaps under-appreciated details of the history of that in my FOSDEM LibreOffice turns 10 talk.

The Linux-Desktop was a ā€˜thingā€™ and investment into it funded almost all of LibreOfficeā€™s development work for many years; until investment stopped primarily for basic economic and market reasons. This factor was by far more important than anything else to LibreOfficeā€™s history I think.

I think we missed some interesting and useful stories here:

Lanedo - was one of the first companies TDF contracted to do development work IIRC run by a friend of mine Tim Janik (I still wear their T-shirt) and taken over from Imendio IIRC. 123 commits in core from @lanedo addresses. Unfortunately it went bankrupt IIRC due to a drop in business (including from TDF).

I encouraged Igalia to apply to TDF tenders and they also contributed to interop., accessibility, Android mobile development - 300+ commits - but IIRC there was not a reliable enough stream of funding (including from TDF) to sustain their LibreOffice practice.

Against this background (crazily) I rescued some of the SUSE developers to start a product company and consultancy in the area: despite the obviously insane market conditions - it seemed the right thing to do. Thank God we survived and did well to date. There is a large degree of providence and incredibly hard work behind that though that is perhaps invisible to many.

Sometime later - Gulsah in Turkey saw a demand for LibreOffice work. She says: ā€œWe received such a demand and decided to establish a company. We carried out projects that we were successful in. But our business model failed. We went bankrupt at our first mistake in development tender estimation.ā€ - and Collabora welcomed Mert & Gulsah to keep them in the community.

And of course there were more individuals and companies winning tenders and contributing some consistently, some intermittently when paid, and others: KACST, CloudOn, Synerzip, Ericsson, Munich etc.

A couple of things worth noticing here for consultancies is that - intermittency in income destroys consultancies; having a predictable stream of work is vital. Also tendering is a very mixed blessing even when you win - fixed cost projects are extremely risky even before trying to pile on liabilities.

I find this very hard to believe. The TIOBE rankings suggest C++ is the #2 programming language by popularity and becoming more popular (cf. Rust at #14). Clearly attracting developers to a project requires lots of hard work, outreach & extremely skilled community mentoring; Iā€™m far from convinced that language is a decisive element - though Iā€™m sure someone will claim that.

Probably the best way to grow the ecosystem is to actively listen to, and not trivialize the concerns of ecosystem participants. It is best not to assume their concerns are purely self-interested (although its possible that even self-interested concerns also apply to other potential ecosystem participants), and to work hard to include them. Iā€™m always pleased when I see sincere movement in this direction.

One thing TDF had early in its life - was a somewhat(?) winsome advocate for the goodness of contributing to LibreOffice in the form of myself, who had time and budget to plug us into networks of old friends and colleagues in the wider FLOSS ecosystem - to encourage them to engage, bid, participate, pre-emptively invest and so on.

Finally for those that want a more numerical and detailed write-up of the history here you could do a lot worse than reading the bottom of these TDF board meeting minutes helpfully included in a LWN Post.

I hope that adds something useful.

As a mentor, I agree. During the course of mentoring, I am introducing C++ even to contributors who originally arrived to do bug testing. Much more relevant is a code base that is pleasant to work with, adding more code comments, enriching readmes, wiki articles, making the build setup as painless as possible etc. Thereā€™s a lot of room for improvement in our dev experience.