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.
I owe a great debt of gratitude to those who (whatever their personal position on the content) actually read to the end and provided excellent feedback - including: Marina Latini, Thorsten Behrens, Eike Rathke, Cor Nouws, Björn Michaelsen, Franklin Weng, Kendy, Simon Phipps, Uwe Altmann, Ilmari Lauhakangas, Sam Tuke, Laszlo Nemeth, Foad, Justin Luth, many who attended my session in Tirana, and of course to Mike Saunders and Italo Vignoli for their good grace and patience - thank you all.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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:
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.
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:
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:
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.
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 we will look at the magic linkage between the easy bit: investing into LibreOffice and the hard bit: making some money back symbolized by the green arrows above.
In order for companies to sell products based on LibreOffice, it is vital that they find customers to whom they can sell (or that customers find them). Here is a picture of how the process of an enterprise customer finding a product might work:
People who have expressed an interest in your product are called leads - there are many ways in today’s world to get people to be aware of your products and register an interest (ie. to generate leads). Leads are the people that are focused on by the sales team to encourage them to enjoy the great results from using a LibreOffice based product. Here are some examples:
Clearly generating as many, relevant high quality leads to feed the sales pipeline is vital for any FLOSS business. If LibreOffice wants to build a successful ecosystem it needs to be deeply interested in the life-blood of sales: leads, how we can gently steer enterprises who visit us towards being interested in support and services, and encourage them towards companies who can serve them, and in doing so significantly improve LibreOffice ? Expecting companies to generate their own leads – particularly without having strong independent brands is extremely difficult, there are few, cost-effective pro-active marketing strategies available in today’s world for small companies.
One of the particular pathologies of the FLOSS world is that where marketing and investment get out of step. This was particularly obvious around the Linux Desktop and contributed to the tragic commercial failure not only of individual desktop Linux distributions (remember Mandriva?), but also to the significant pruning of both SUSE, and ultimately RedHat’s desktop investment – before finally claiming much of Canonical’s desktop investment too.
Setting a price expectation in a market of zero (or below), forever and for everyone – is ultimately toxic to building a thriving commercial ecosystem. Therefore, ensuring that marketing and engineering investment are well aligned is in this area is something that TDF must be focused on. Those subsidizing marketing and a zero-price-point by getting others to do the engineering for them - tend to talk about their virtuous investment in growing the pie / market size for all; however driving an unhelpful price expectation for enterprises in an un-sustainable way is ultimately self-defeating.
It is vitally important that returns are correlated with investments – ie. if one company invests heavily, that its return is reasonably correlated with its investment vs. non-investors, otherwise – the tragedy of the commons yields a set of passive parties eagerly waiting for the returns generated by others’ engineering investment.
In individual projects this should be addressed through various qualitative and quantitative investment metrics, clearly presenting the realities of what has been contributed, while retaining a neutrality to vendors and investors, and advertising our model to new entrants.
When TDF was founded we deliberately positioned LibreOffice as a product of TDF, which was the right choice at the time. However this strategy no longer serves the market in its current form or scale. There is a risk that TDF (via it’s donors’) investment in the product itself can be mis-portrayed, creating an analogous situation, where TDF presents itself (perhaps with the help of some volunteers) as the creators of LibreOffice – ignoring the formidable contributions of Sun/Oracle, volunteers and present day corporate contributors.
An extremely popular model used to drive lead generation is visible in many open source projects which have single corporate stewards, for example Nextcloud, ownCloud, pydio, seafile and many many more. We are reasonably familiar with this approach from the OpenOffice days – and when done well – it can yield a flow of leads, and user interest in support and services around an open source project – but only to one company.
In this model – there are many advantages, not least from cheap or free conference attendance representing the (often identically named) open source project and widespread free advertising of your brand. The easy answer to the question “Why give all this away for free” is that every eyeball, every user will come to the owners, creators & authors to get support and services – by following the brand. This is why you see ‘Buy’, ‘Pricing’, ‘Enterprise Version’ and other such critical lead generating links prominently placed on brand sharing open source companies project pages.
TDF in contrast is a vendor-neutral project – and as such, directing all LibreOffice leads to a single company is neither desirable, nor sensible. We look in more detail at how TDF's current marketing works in practice next:
If we want to grow our community, and to drive this with marketing – we need to position our brands to make this easy and ideally unconscious. Currently we have two brands, taking the descriptions from their websites:
Unfortunately – it seems we have two brands, and neither of these means “The community”, or “The people who do most of the hard work”. These are the people we need to be encouraging, recruiting, building up, and talking about. The degree to which TDF’s paid staff represent ‘the community’ is unclear. The board is elected to represent the community, and oversees TDF but is also not itself the community (but the board). When TDF says “our software” - how can we ensure that everyone feels included in that ‘our’ ?
It seems clear that we need to solve this dis-connection with some formulation, strap-line, brand or form of words that we use to highlight and emphasize our contributor’s input – and use this repeatedly.
Branding is really important as we have seen: shipping identical software, at the same price in the Mac app store with just the LibreOffice vs. Collabora Office brand changed shows – that the LibreOffice brand is simply far better known & sought after gathering the overwhelming majority of interest. This however brings a problem – if development work is funded by leads generated from brands then TDF promoting eg. LibreOffice Online under its own brand can easily radically impair leads, investment and thus code-flows into LibreOffice Online without any offsetting advantage. The picture below compares two branding approaches for the 95%+ of commits that Collabora has put into LibreOffice Online. The 0.05% is the proportion of visitors to LibreOffice that discover that they should fund development buying professional services (from anyone) – as we shall see below.
How does LibreOffice get marketed from this perspective ? How do companies get leads from TDF so that they can sell to some fraction of them their products, support & services thus allowing re-investment back into LibreOffice ? Answer: very poorly. Recently we’ve done a better job of telling people about LibreOffice, a recent release announcement says:
"LibreOffice 6.1’s new features have been developed by a large community of code contributors: 72% of commits are from developers employed by companies sitting in the Advisory Board like Collabora, Red Hat and CIB and by other contributors such as SIL and Pardus, and 28% are from individual volunteers."
and also encourages people to use an LTS version – which is not itself provided by TDF – which is a major improvement:
"For any enterprise class deployment, TDF maintains the more mature LibreOffice 6.0, which should be sourced from a company providing a Long Term Supported version of the suite (they are all members of TDF Advisory Board, and are listed here: http://www.documentfoundation.org/governance/advisory-board/)."
However the website still has a large number of issues in this area, investing nominal fees into Advisory Board membership is a marginal contribution vs. the substantial investments into the software & community. A better approach is the single page that educates users about the availability of professional services – which is the get-help/professional-support/ page which highlights certified competent migraators, trainers and developers. So how does this hero list of contributors to LibreOffice's success fare when people visit our site, lets see by checking out the metrics on page visits:
It is interesting to see that those interested in professional support – only around 4700 this year (1/3rd of 13000) exited to either close the session, or visit a supported version provider. The bounce rate suggests that the majority of people arrive on the professional support page from elsewhere, and not TDF’s own properties. This matches with what is seen by vendors analyzing what arrives from TDF. Compared with the total visits as of (2018-09-07):
the number of people exiting to find professional service from that page is 0.05% of our 9.5 million visitors so far.
The contrast between the "Economic and code contribution flows in today's ecosystem" and even the helpful description in the 6.1 release marketing acknowledging 72% of commits, compared with the 0.05% actual click-through rate is extraordinarily stark. It seems clear that our users are not being educated as to the importance of supporting the certified ecosystem - certainly in the area of code, but almost certainly also in other certified areas such as training & migration.
This is rather a tricky task – it rapidly turns into something like visualizing the geometry and distances of the solar system. Two charts are shown – a pie chart with the corporate contribution to the code in commits – and a crop to the center of another showing the flow of people clicking through the page to find professional services which go to 1improve LibreOffice (in blue) and others in red:
It is of course unclear what %age of our visitors are enterprises and thus should be encouraged to seek professional help, however 0.05% seems an implausibly low fraction by perhaps two orders of magnitude.
Another side-effect of majoring on LibreOffice as a free, always and forever and for everyone free, no catches, product – is creating mistaken expectations in our users around how the relationship works. Here is a simple example mail from 2018-04-19:
“Please help me to installLibreOffice at Lubuntu17 my donation number via PayPal is 1TV07632F2376242R”
Apparently the donor believes there is some connection between his donation and installation support, despite our donate page being quite explicit that this is not so. This is buttressed by rather regular E-mails of the form I made my donation, but still can't download it - apparently people love to miss the LibreOffice is Free Software and is made available free of charge. Your donation, which is purely optional, supports our worldwide community. text there.
This example is relatively friendly. Some chunk of user interactions are much less friendly – criticizing the product, attacking the project for not fixing their particular issue on their timeline, or investing in their particular problem. A peripheral, but amusing pathology is of users from time to time augmenting the urgency of a request by generously offering a $50 donation to TDF to cover the (often) multiple-person-week of (pet) feature work needed.
By setting a more realistic expectation around support, enterprise suitability , and particularly by encouraging people on our main properties to contribute – it is possible to build a consumer, community brand – rather than a pure product brand. This may have a positive impact on reducing the feeling of entitlement that some of our users have.
Similarly enterprises deploy the wrong software, without support, fail to keep it up-to-date, and then believe that we are responsible for helping them, a recent mail to the security list highlights this, names removed to protect the mislead:
Subject: Security issues within Libre Office My Company, XXXXX, uses the latest ( I think ) version of Libre Office. We also use the Qualys tool for security Compliance. It has found a vulnerability with Libre Office. Are you familiar with this, And how do I remediate your application? ... signature reads ... FORTUNE Magazine World's Most Admired Companies® 2014|2015|2016|2017|2018
A kind reply, funded by RedHat’s formidable security investment:
It might be that its already fixed in the latest stable release, or its a false positive, or even something that remains to be fixed, but we'd need more information to judge.
And then we find out:
The version we have is: C:\Program Files (x86)\LibreOffice 4\program\soffice.exe Version is 126.96.36.199 Have you found similar vulnerabilites? Is there a newer version that we can download and test against the above reported vulnerabilities.
They use a version that is four years old today, and this is from a significant company, saving plenty of money and apparently investing nothing – instead, consuming time from those who are. Far from an isolated example, some of them are ruder with a more explicit sense of entitlement.
The software industry is an industry typically driven by hype, where software startup marketing has this rather ‘visionary’ approach, something like:
|"Look at this awesome product (demo), come and buy it !"
|“so when you bought it we can fund actually delivering the product.”
This could be called the Sagrada Familia model, as long as people know this is what they’re buying it has a certain logic. Arguably TDF’s current marketing has a leaning towards:
|“Look at this awesome product, come get it for free !”
|“we’ll work out how to get people to contribute to fully
deliver on our promise of awesomeness sometime later”
Almost certainly a more helpful marketing approach might be:
|“Join our awesome project and contributors to improve our great product”
|“community should be fun, and we need to grow it, we’re here to promote you if you contribute.”
Against this – the experience of selling a supported version of LibreOffice is hard. LibreOffice has a powerful brand, and it is associated with everything being free as in beer. Some small subset of our community appear to believe that building product brands and businesses around LibreOffice is non-ideal, and that we should focus on providing ever more services free to enterprises. The perception that the ‘genuine’ version is LibreOffice from TDF is real one, and stoked by the lack of systematic acknowledgment of the great benefits provided by the ecosystem.
Contributors are sometimes deeply emotionally attached to the project, and the LibreOffice brand and feel that to promote an alternative brand, even if in doing so that helps fund the work, is some sort of betrayal – or lack of neutrality. This sometimes extends to being eager to duplicate functionality, packaging, documentation etc. simply to re-brand it to LibreOffice.
This too is profoundly unfortunate. Others believe that FLOSS is fundamentally identified with a zero per-seat cost – perhaps plus some consultancy (perhaps installation, or some migration support), and that having no SLA, and letting others fund long term product investment is the only sensible approach to choose: maximising their apparent saving. Discussions with such parties are quite interesting – often oscillating between variants of: “I should pay nothing per seat because its FLOSS”, and “The product is not yet quite good enough for us – you must fix it for free before we [don't] buy your product”.
It would be good to have TDF’s explicit support for selling branded support services and versions around LibreOffice to make this more socially obvious to those who are not members of our community.
The commercial ecosystem around LibreOffice is an un-necessarily tough environment to operate in. Companies contribute a large proportion of the work, and yet get very little acknowledgement – which in turn makes it hard for them to invest. This also creates an un-necessary tension with companies marketing – which has to focus on building their own brands. Companies should not fear the arrival of the LibreOffice brand to squash, claim credit for, and present their work as created by someone else – thus effectively depriving them of leads. This is unsustainable.
The LibreOffice project should give a new focus to promoting and celebrating all participants in its community – including ecosystem companies. This is far from a problem unique to companies. It is routinely the case that individual community members feel under-appreciated – they would like more recognition of their work, and promotion of their own personal public brands as valued contributors. This is something that TDF should re-balance its marketing resource into, in preference to product marketing.
The LibreOffice project should explicitly create space for enterprise distributions by explicitly pointing out the weaknesses of LibreOffice for enterprises on its hot marketing properties. This would have a positive effect of encouraging companies to acknowledge and build the LibreOffice brand safe in the knowledge that anyone visiting LibreOffice will get an accurate and balanced picture of their skills and contribution.
We badly need to increase diverse investment into our ecosystem by building an environment where deep investment into LibreOffice is a sound economic choice: economics ultimately drives ecosystem behavior. By creating the right environment – often not by acting, but by clearly and deliberately not acting in a space – we can build a virtuous circle of investment that produces ever better software that meets TDF’s mission.
It has been said that in life - "You can either achieve things, or get the credit". Unfortunately, in the world of FLOSS – in order to sustainably achieve things you need to get the credit (and associated leads and hence sales). During the early creation of the project it was strategically necessary to under-emphasize corporate involvement, particularly of SUSE heavy lifting – but these days are long past. Similarly, we need to build a brand or formulation that stands for all volunteer contributors to LibreOffice and acknowledge these fulsomely.
This is the state of play today in the LibreOffice world, but the good news is, this is just the background for a series of positive discussions and suggested actions to re-balance TDF's marketing. No significant change is proposed to our development process, timeline, branching etc. I believe most of these are common-sense, and should be supported by the majority of the outside community, as well as those involved with the project - who have a more intuitive feel of the balance here. Some suggestions may be relevant to vendor neutral non-profits; but most are specific to LibreOffice. My plan is to post those suggestions to our public Marketing list and to have an open discussion there of how best to balance this. Potentially I'll add a summary here later.
Thanks for reading - perhaps this may help some other communities improve their ecosystems too. For those interested in the source for my drawings they are available
This paper has focused heavily on ways to improve our marketing and messaging. If you read this far – thank you ! It should in no way be read as a personal critique of people doing our marketing. Our existing positioning and approach and direction is something that has accumulated over many years, and all in leadership in the project are responsible for where we are at now. If you work in marketiing – thank-you for all you do, and the many positive messages that get out. Hopefully with some adjustments we can grow the project in exciting new directions at some large multiple of its current trajectory for the benefit of all.
This way – I hope we can meet the dream of gaining wider acceptance in the enterprise market.