This continues a series of items on Vendor Neutral FLOSS projects and how they do marketing which you can read here.

The shape of our ecosystem - what is sold ?

In order to understand how we can best shape the ecosystem to drive LibreOffice’s success – it is helpful to understand first what products and services companies currently sell, and then consider how we want to shape the environment that they adapt to to encourage behaviors that we want.

Consultancy / Professional Services

Perhaps the most obvious contribution to LibreOffice is that of consultancy. A user has a problem, a budget, finds someone to fix it for them, contracts with them to address this issue, and then to contribute this back to LibreOffice.

A consultancy model at first glance appears to fit well with FLOSS development, and indeed there are several successful FLOSS consultancies in the market (of which Collabora is one). However there are a number of significant problems with the consultancy business model:

• Investment & Scaling – the creation and scaling of new consultancies is extremely tricky and risky, which has an impact on investment. Try to find a Venture Capitalist who wants to start a new, risky, low-margin consultancy.
• Margins – typical margins on consultancy are low with net margins in the region of 15-20% (cf. 2018 Professional Services Maturity Benchmark). This makes re-investment, and future investment problematic. Margins are significantly smaller when tendering – good for the purchaser, but providing less money for LibreOffice.
• Estimation - the literature on the trials of estimation, project management and so on is extremely extensive. Newspapers are littered with examples of projects overruns and failures by vast blue-chip consultancies. Even an excellent consultancy that delivers on time & to budget, has a challenging task - particularly when considering the previous point on margin. Can you estimate to within 20% how much resource a software project takes ? how about 50% ?
• Timelines – a typical consultancy timeline is outlined below. Frequently a very small amount of work takes an inordinate amount of sales, business development, and contractual time compared with the amount of work done. This is particularly true for smaller contracts of a few weeks of work.
• Overruns – Fixed Cost projects even those estimated and managed by extremely experienced consultants have a very significant risk of over-running (costing more than expected to deliver on time), eating into already thin margins.
• Pipelining – due to the long sales cycle, it is necessary to have a large number of consultancy projects on the go at once to fill gaps. This is familiar to many people who have ever hired a builder.

• Tail maintenance – due to the long cycle time of releases, and community feedback it is normal to find regression bugs long after the work is performed, paid for and the next (of many) projects commenced. Finding time & resource to manage to address these is often a challenge particularly when they do not affect the original customer.
• Staffing – the consultancy pipeline is highly cyclical moving from feast to famine rapidly. This makes it hard to staff and start projects at some times, and with an excess of staff at other times. In addition aggressive deadlines, overlapping projects, handling cost overruns and so on can be very hard on staff involved making hiring and retention interesting.
• Risk – trying to scale a consultancy has been likened to driving faster in the fog. You still have a similar visibility into your sales pipeline (of a few weeks) – but a much larger salary bill to pay each month. Doing larger, longer-term projects sounds good - but can substantially increase estimation risk.
• Late Payment – after signing it is often the case that the work is substantially done, sometimes having been started at-risk in advance to meet a customers deadline. That means that the pre-payment (invoice + thirty days) is often paid after the work is complete (as shown above). Furthermore, even when the work is complete to everyone’s satisfaction, and the work validated and invoiced correctly – customers frequently substantially fail to meet their own payment deadlines through no fault of the consultant. Excuses range from the honest: “we’d prefer to pay you next quarter” to the more contrived “we’re just changing our payment software” and are rather common. When to publish the source code under a FLOSS license vs. that timeline is also an interesting risk factor.

The above timeline is reasonably accurate for a government procurement cycle, although these can be distended by framework tendering, followed by separate individual contract tendering – as well as extended validation periods (‘A’). Interestingly, this is not dissimilar to TDF’s own contracting cycle. It also omits a common “Try to get it done for free by filing up-stream without a corporate address” latency of some months.

For these and other reasons (it already being quite exciting enough to hire, motivate and manage creative developers) - many consultancies desire a product based business, where a product is sold and paid for in advance. This gives the luxury of a considered and deliberate view of improving the product in partnership with a customer over a horizon of years, blended of course with some bespoke development as/when necessary.

On the plus side, some consulting relationships are more like a product relationship with a committed and predictable volume of work, and staffing over a long duration. These however are rather rare and special.

Product – with Product Management & Long term support

For many of the reasons outlined, TDF has traditionally left space for the ecosystem to provide the (relatively tedious) job of providing Long Term Supported versions. This frees the volunteer community up to focus on developing new feature, and also creates a scarcity. Distributors then meet provide a solution for this scarcity by selling access to branded versions of LTS support and manintenance services – with various licensing, often on a per-seat basis. This money can then be re-invested into product development.

Selling a product (such as an LTS version) provides the ability to sell a branded bundle of software and services, with a Service Level Agreement (SLA). It allows an open source company to aggregate the pre-payments of many customers, solicit their input on the product, and prioritize investing into relevant areas for them. Critically products are usually pre-purchased up-front for a duration of small integer multiples of years. As such a degree of stability, and strategic planning can enter the product development process. In addition – the consultant’s dream of doing the same work to serve multiple customers concurrently can finally be realized:

Supported product / Level 3 (code-fix) SLA

An elaboration on providing a generic supported product is to provide an SLA for fixing customer bugs – this can be used as a special case of the above to contrast vs. the consultancy approach. It allows you to having specific problems addressed to your timeline:

Proprietary extensions / Open Core

Some companies sell a LibreOffice augmented with proprietary extensions in an open-core type model. These companies can then re-invest that revenue, however the temptation and incentive is always to invest substantially in improving the proprietary pieces and not into the open core: since doing so provides the highest Return On Investment (ROI). While this model may improve awareness of LibreOffice as an option it does little to improve LibreOffice itself. It has been tried extensively by IBM, Sun, RedFlag and a number of other players past and present - without notable success. The open core approach tends to focus the community's work on duplicating the proprietary pieces - and is not a behavior we want to encourage in our ecosystem.

Why companies (and individuals invest)

Having explained the ways that FLOSS friendly companies build and sell products and services around the LibreOffice ecosystem – it is perhaps useful to consider why companies (or individuals) invest in anything. This might be thought obvious, but in a world where the evils of “Profits” are called out combined in the same breath as calls for more “Investment” perhaps this is a helpful thing to consider.

All of us when putting money into a bank consider the interest rate provided. We are interested[sic] in getting more money back than we put in, and even with low rates – you expect to get your money back, plus something. Investing in LibreOffice (or any vendor neutral project) however is a substantially riskier proposition – the easy part is paying developers to implement cool new features. The hard part is seeing your original money back – nevermind any extra return (profit) to re-invest.

Clearly TDF is interested in having many vendors invest into LibreOffice – so we need to have well thought through answers ahead of time on how that results in a return. That return has to be larger than what went in, those who lose money (path B) will after time simply not invest any more: to do otherwise would be the definition of madness (or an altruism we can’t expect in a normal business). The upper feedback loop via path ‘A’ has a doubly virtuous appeal. Having got their money back, with some additional compensation for the risk, it is likely that this money will be re-invested and encourage further additional investment with it – in expectation of future returns. The ideal is that this leads to a virtuous circle of significant and growing investment into LibreOffice and other vendor neutral projects - something we want to see.

As a footnote – with existing rather marginal returns – questions such as “Why are you not investing in my great idea for LibreOffice?” often seem to be based on some mis-apprehensions about the balance between A. and B. and companies ability to re-investment into their product.

Anyhow – next time we will look at the magic linkage between the easy bit: investing into LibreOffice, the hard bit: making some money back symbolized by the green arrows above.

to be continued ...

To make this more digestible following 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