Summary

Against the backdrop of a number of companies getting ‘cute’ with licensing, to attempt to encourage companies who use their software to re-invest into the product; vendor neutral non-profits that steward the project, trademark and other assets while allowing many parties to invest - seem increasingly attractive to sustain software beyond its (often) VC fuelled birth. LibreOffice is hosted by just such a project The Document Foundation (TDF) – and this is a huge strength.

Unfortunately, there are also very significant impacts on how a commercial ecosystem can be grown and sustained around such vendor neutral projects – particularly as relates to encouraging ongoing corporate investment into such projects. This paper (which I will serialize into several sections and re-aggregate here) – examines this space and I’ll try to keep it somewhat alive by incorporating feedback. This also exists to inform a wider discussion in the LibreOffice community along these lines.

Let me start with a quote from “Open Sources”: from a section by Bob Young (founder of RedHat) entitled “How Do You Make Money in Free Software”:

"No one expects it to be easy to make money in free software. While making money with free software is a challenge, the challenge is not necessarily greater than with proprietary software. In fact you make money in free software exactly the same way you do it in proprietary software: by building a great product, marketing it with skill and imagination, looking after your customers, and thereby building a brand that stands for quality and customer service."

It is hard not to subscribe to this view, seeing RedHat’s extraordinary success over many years. Unfortunately – when this is applied to a vendor neutral project such as LibreOffice – encouraging companies to invest in TDF’s brand and project, if marketed unhelpfully, can achieve the opposite – of obscuring the brand of those investing into the project - damaging everyone involved.

This paper is written from my perspective both from running Collabora Productivity (whereby I have a clear interest in growing our piece of the ecosystem) and also as a long standing Director of The Document Foundation (with an interest in growing the whole ecosystem), and as a long term FLOSS contributor (with an interest in nurturing a sustainable ecosystem around all Free Software). With lots of hats - things can become unclear; I try to talk here with my TDF hat on here; so 'our' means 'TDF & the LibreOffice project'. Of course, I speak only for myself – not for TDF.

While this may have wider application, and is presented in the hope that it will be more generally useful, this paper will argue that the way LibreOffice is positioned by The Document Foundation (TDF) is at times counter-productive to its mission, and that its focus needs to change. A new focus should be to give significantly more emphasis to growing and crediting the community and ecosystem – both volunteer and commercial, and away from product marketing.

Do we really need to make money / get investment ?

One of the exciting things about working in LibreOffice is the abundance of genuinely good ideas from lots of eager contributors for ways to improve the software with interesting new features, better interoperability or quality, as well as good ideas of new market segments to target, and even new top-level applications.

While there is no particular reason why any of these ideas needs to be funded by monetary investment from a corporate ecosystem – they do need significant investment from somewhere. Large numbers of Volunteers make a very significant and much appreciated contribution to LibreOffice in very many areas – eg. the vast majority of translations are from volunteers, and around a third of code commits for example. However, for larger, more heavy-lifting pieces of functionality, very significant investment in architecture, design, mentoring as well as lots of sustained implementation time is required – and without this many of these ideas simply do not make it.

It will be argued that by shaping our ecosystem carefully – we can encourage the behaviors we most want: particularly that of encouraging companies to invest into FLOSS product improvement, and thus of maximizing user freedom.

One of these shapings is to have an explicit, crisp and clear delineation between TDF’s provision of a product for consumers, and the ecosystem’s provision of products for larger organizations and enterprises. It will be argued that by shaping this sensibly – we can build confidence in an ecosystem that can attract significant (re-)investment from the commercial ecosystem.

Rather than focusing on the negatives, and/or fixed investment necessary to keep LibreOffice alive and improving, I will take it as read that we need to encourage further significant investment to improve things.

No substantial changes will ultimately be proposed for the existing LibreOffice development and release process, mostly tweaks to marketing. This is a lengthy paper – please bear with it; hopefully it provides a useful basis for discussing the ultimate conclusions.

How LibreOffice is currently made

This article focuses heavily on code contribution – as the primary, and most difficult form of contribution to attract, motivate and encourage. This is where Sun/Oracle and many other corporately owned & driven projects failed. Building a large, diverse, and vendor neutral set of code contributors is critical to the sustainability of LibreOffice. The interest in code contribution is also based on it being reasonably easy to measure. Clearly the project has hugely valuable development contributions elsewhere in the form of UX, QA, documentation, translation and of course non-development contributions such as answering questions, marketing, board work and much more. Nevertheless – it is useful to consider how LibreOffice is created today, along with some of the underlying economics that drive that - with a picture of the economic and code contribution flows in our ecosystem:

A poor alternative – TDF as a business

TDF currently avoids competing with its commercial ecosystem. However, in some other projects there is a monolithic single commercial entity (such as Mozilla) that applies its brand and assets to selling services. While the existing TDF structures for awarding contracts, managing tenders, risk profile and staffing are committee based and far from fast, or efficient – (and also selling services may conflict with TDF’s mission) - it might be possible to imagine TDF selling LibreOffice professional services or long term support – and effectively using its brand to sterilize and/or absorb the ecosystem completely.

While a centrally planned, monolithic entity may be attractive to some, it is unclear that its cost and organizational structures will be able to exploit and meet all of the needs of an extremely diverse, global potential customer base at many price-points, and re-invest that into LibreOffice.

In this eventuality it is clear that few-to-no companies will invest significantly in growing a high risk consultancy business that serves a single customer: TDF. As such, there will be no investment beyond what TDF can itself bring in, and the ecosystem will rapidly collapse into TDF significantly expanding its staff and exposing it to the many risks and down-sides of consultancy as business discussed below.

Revenue flows are presented as static and just re-directed – while it is likely that proprietary use of the LibreOffice brand to drive a TDF business may clarify the need for enterprises to pay and significantly increase revenue, the challenges of hiring, motivating and engaging a sales and technical management team may prove insuperable.

A poor alternative - Free as in beer

This scenario imagines a world where TDF provides everything from source code to a Long Term Supported release for free – where ‘Support’ means essentially fixing critical, security bug fixes. That involves incremental cost - currently the creation of such security fixes is done by companies funded by their enterprise customers.

This approach – of TDF producing, and sharing a “LibreOffice LTS” release and giving something labelled ‘support’ away for free has a number of other problems. A few of these are:

Timing

LibreOffice has hugely benefited from its predictable, time-based release train. This combined with monthly patch updates provides a great base-line for anyone to build their product from and a good support horizon for consumers of around six months. Our distributors and users can choose a version to package and deploy and then provide versions supported for around thirty-six to sixty months. For TDF to support every release as LTS – would require significant incremental TDF release engineering staff to build and update six to ten branches in place of two. The obvious solution to this is then to follow eg. the Ubuntu candence and do an LTS release every two years or so reducing the cost to an extra one or two version. However – the scheduling question then becomes: which of our valued contributors gets to have the latest LTS freeeze closest to their timeline ? Pragmatically – currently it is the case that freshness of version at release seems to trump all other concerns of sharing development work. Picking an old tree for your LTS potentially increases costs significantly by extending the period that you’re significantly behind the community’s shared development on the latest version.

Risk management / patch inclusion

Assuming the scheduling problem can be solved – there is still the problem of managing risk. Since each party has a different risk profile and set of requirements – it will be necessary to forge some compromise. For example one party may want writer layout changes for a critical business feature, while another may want significant main-loop changes, another new custom toolkit work, and another COM integration. These scheduling problems become even more acute when it is realized that if a feature is not included into the “TDF LTS” - the binaries of which are what is marketed to and recommended for use in enterprises, then the feature will not be available in an LTS for another (say) 2years. Existing compromise mechanisms work reasonably well in the ESC for managing conflicting views here, in theory large back-ports are possible with triple review from diverse entities, however a TDF LTS version would inevitably introduce significant conflict.

Justifying staff investment

Aligning LTS release schedules, and creating the idea that Enterprise LTS versions are available for free would have at least two perverse impacts that harm the project.

Firstly it would drastically reduce the perceived value of distribution packagers who provide a critical support and editorial role (and also do the security work for the whole project). There would be an increase in the practice of doing no significant investment in LibreOffice capacity while pretending you can support the project, and relying on TDF or the community to do that for you putting at risk a couple of our remaining core distribution developers.

Secondly schedule mis-alignment provides an incentive to compete and to invest – in (at least transient) differentiating value that then gets folded back into LibreOffice. Not only shipping community features first, but improving on them. Removing this by co-ordinating release schedules reduces the incentive to invest.

Thus producing a free, commodity LibreOffice branded LTS distribution by trying to align everyone doing support onto the same LTS branch, is likely to create significant conflict, and create further risk for investment.

Donors intentions

Lastly – it is highly unclear why the large number of consumers each donating a small sum should have their donations invested in producing a free enterprise version of LibreOffice which (in turn) enables enterprise users (who donate almost nothing) to avoid contributing anything to LibreOffice themselves.

Unfortunately our current download page strays into portraying the TDF provided ‘stable’ release as suitable for enterprise use (albeit in press releases the requirement for adding support is mentioned). The current text is: “If you deploy LibreOffice in an enterprise or corporate environment or are a conservative user, please choose this version.” This is rather unhelpful.

to be continued ...

To make this more digestible the next sections will be serialized later, and built up into a reference-able whole here: https://people.gnome.org/~michael/data/vendor-neutral-marketing.html adding more flesh to the problem space