Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

[board-discuss] FLOSS software money ecosystem, in general [was Personal: and software freedom.]


On Fri, Jul 10, 2020 at 03:40:05AM +0200, Lionel Élie Mamane wrote:
On Thu, Jul 09, 2020 at 02:28:51PM +0100, Michael Meeks wrote:

     Many things are legal, but many fewer are moral.

     Steering people towards things that help to build the
community and codebase is extremely useful.

it is also an industry standard for successful ecosystems:

     Fedora vs. RedHat Enterprise Linux vs. CentOS.
or
     SUSE vs openSUSE

Redhat will sell you a yearly subscription for a single workstation,
as low as 180 USD. So will SuSE for 32 GBP.

Closer to home, Microsoft will sell you a single licence for their
office suite, either as "perpetual" or "subscription" starting at 5
USD/month or 8.25 USD/month (...).


INTRODUCTION
============

In general economic terms, what all these systems do, and what the
LibreOffice ecosystem is trying to achieve, is to spread the cost of
making, maintaining and improving LibreOffice over multiple users. The
spread is (nearly) never equal; all those systems extract more money
from some users than others. Typically business users, or different
markets: The exact same software for business will "cost" more for
"business use" than for "family use", or more in "high cost of living"
countries that in "low cost of living" countries.

For most software, no single user will fund it all. While it may work
for some FLOSS software (where "developer" and "user" are very
overlapping categories), the pure, money-less, model of "the commons",
where everyone/most contributes 1 to 10 units of development work, and
everyone gets back the result 1000 units of development work, does not
work for LibreOffice.

So the need for a money flow.

I'm going to speak about individuals and small teams (SMEs etc); I do
understand this is not the short-term focus now, but it what I know
and it is close to my heart; most of a country's GDP is made by SMEs;
that's where, in the aggregate, most of the money is, but it is there
by many small streams, not as a few big rivers (English doesn't use a
different name for small and big (Rhine or Danube size) rivers, so the
French expression doesn't translate well...).


INDIVIDUALS AND SMEs: (half-)voluntary
======================================

I want to believe in the goodness of humanity, and that a
non-negligible percentage (suitably educated / made aware of) people
and SMEs will voluntarily, or half-voluntarily, contribute in money
when not contributing otherwise, if and when that is easy and low in
non-monetary costs (such as _time_ and effort to jump through the
hoops to do it, and to figure out to whom send money and how). This
can only work for "user visible" software (it will not work for
OpenSSL), but LibreOffice is highly "user visible" (funding OpenSSL in
that model requires that other FLOSS developers relying on OpenSSL and
that get money for their FLOSS "voluntarily" send some money to
OpenSSL). The disadvantage that LibreOffice has is that, except for
the TDF, which doesn't fund development to a sustainable level, it
doesn't have an easily identifiable "target".

The "on the Apple/Microsoft stores" angle being pursued is more or
less part of this "aim for the small guys" thing.

I've already made these points abundantly clear in previous emails, so
I'll stop that here.


INDIVIDUALS AND SMEs: directly useful services
==============================================

Another angle, maybe more "real world realistic", is to offer directly
useful services, in small chunks so that the "sticker price" is low.

Individual support
------------------

I'm convinced that many people would pay for personal "user support",
here and now, at an appropriate price point; even if the answer to
their question is teaching them to use a particular feature of the
software. In the 1990s, pay-per-seat closed source software from
anyone smaller than Microsoft actually included that; it was called a
"hotline". You phoned and you were helped. Games had that, WordPerfect
had that. I think even Microsoft included some of that at the time,
very limited in scope and time, and useless in terms of competence of
the person one got on the phone; I think Apple actually sold that
service as a subscription... and didn't Microsoft do it at some "pay
per incident" rate which seemed not worth for me as a teenager, but
would make sense for an SME, or some individual doing their family's
birthday party invitations or such? I think it was something like 30
USD to 50 USD per incident at the time, so with inflation maybe closer
to 75 to 100 EUR/USD/GBP now?

Either the development companies double as "user support" companies
(yes, get in another line of business... but they have unique
credibility to sell such services, especially if they escalate thorny
cases to the developers... for some capped percentage of their time?),
or the "user support" companies (and migration companies, etc)
"voluntarily" send money to the developer companies.

Maybe that can be packaged as a "sale" of a branded binary of
"Collabora Office Desktop" or "LibreOffice by CIB" or "LibreOffice by
Red Hat", where some level of user support is included like with closed
source software by anyone smaller than Microsoft?


Crowdfunded bugfixes and improvements
-------------------------------------

Another angle of directly useful services (and one close to my heart)
is bug fixes and improvements. I really, really, really, would like to
see a good system to spread the cost of these over several
people. While I don't believe much in this for not-completely
specified and big stuff like "make a web application out of
LibreOffice" (or "make LibreOffice online"), if a good system can be
found, I believe in it for smaller and well-defined stuff. IMHO any
such system needs to be run by a trusted organisation, and people see
their money get out of their bank account only (at the earliest) when
a credible person commits to developing the fix (enough money has been
raised) and (at the latest) when the fix is made. If the likes of
Kickstarter, IndieGoGo and other "fixed goal crowdfunding where
nothing is charged if the goal is not reached" platforms can take
people's credit card info, NOT CHARGE THEM until the "goal is reached"
and then charge everyone, then maybe we can do the same? Maybe TDF
could run such a program? And maybe keep the money in escrow in the
time from "I take this job" to "here's the fix, committed in the TDF
repo"? Or maybe people listed on
https://www.libreoffice.org/get-help/professional-support/
are trusted enough to get the money upfront and for others it stays in
escrow?


 * And if some of the cards don't go through (e.g. expired between
   pledge and acceptance of job)? Well, a certain percentage will hit
   that. Plan for some spillage. If the spillage on one particular
   bounty is too big, either the job is still accepted for the reduced
   amount or refund people (either minus card fees, or covering the
   fees from the general budget as a service to the ecosystem).

   To minimise that:

   1) Email (automatically) people whose charge has failed and invite
      them to make a payment now.

   2) Proactively (but automatically) email people whose
      card is about to expire and invite them to enter a new
      one. Preferably once for their whole account, not for each
      pledge.

If such a system is prominently endorsed on the libreoffice.org
website, I want to believe it would work. Maybe TDF can use an
existing crowdfunding platform for that? Open a new "crowdfunding
project" for each requested bugfix?


Or maybe Collabora and/or CIB and/or Redhat will try that "on their own" and
prominently offer that on their website? Then the process can even be:

1) Someone requests opening a "pledge jar", with an initial pledge
   (insufficient to cover the whole development effort).

2) They screen the request, and if they are able to meet the request,
   make an offer of what their price will be, and duration of validity
   of the offer.

   Plus points for credibility for the crowdfunding. Concretely,
   someone credible has already said they will do it, for that
   money. Concrete goal, the solution is in sight.

3) They can use an existing crowdfunding platform for that, and
   not implement that on their own.

4) People contribute to the pledge. Pledge is reached, development
   company delivers.


SOME GENERAL / PERSONAL REMARKS
===============================

In my experience, most closed-source, "single development provider"
software provides a path to getting bugfixes and improvements. You use
the included support (personal or semi-community forums actively read
and participated on by representatives), and ask for it. It is not
perfect, sometimes they are interested, sometimes not, they make their
business decision to invest in your idea or not. This works to varying
degrees with https://www.sdna.lu/, Jeppesen, Foreflight, Garmin
Aviation, SkyDemon, RocketRoute, etc (most examples are from aviation,
since that's nearly the only field where I actually use closed-source
software...). Not at all with the likes of Microsoft, Apple, Google,
etc.

But by and large, the ones in the first list are interested to improve
their program, and delighted to hear from the trenches of real users;
if one asks for it, many more would like it. Sometimes their vision of
the software collides with yours, and they more-or-less stubbornly
dismiss some user requests (Tim Dawson of SkyDemon comes to mind);
that's not necessarily a bad thing; software needs a direction, and a
"general architectural design". Some (e.g. Nokia in Maemo)
were... actively deaf to the needs of the users. Not very surprised
that didn't have the success it could have...


I'm convinced that strategically, FLOSS needs a mechanism for that,
too. One such mechanism is "contribute the patch yourself". That has
worked... when I have time, when it is in a field where I have
sufficient expertise. I'm starting to realise that the "do yourself"
does not scale enough, and leaves me long term with unmet needs. As
far as I know, I can't exchange some contributions in one field for my
need in another field. E.g. I've never been aware of a GCC / binutils
developer fixing the pet bug of a LibreOffice developer (let's say
https://sourceware.org/bugzilla/show_bug.cgi?id=13406) out of
appreciation for some LibreOffice work; we don't have "social capital"
as a currency in our FLOSS world. Or a Mozilla developer (let's say
https://bugzilla.mozilla.org/52821
https://bugzilla.mozilla.org/230887
https://bugzilla.mozilla.org/564168
https://bugzilla.mozilla.org/309720
https://bugzilla.mozilla.org/1325692)

I would like for FLOSS to have a "mostly" working (not requesting
perfect) mechanism for getting bugfixes and improvements. Hoping that
some "bigger fish" than me will agree with me and fund it completely
does not work well enough. We need a working "pooling" mechanism, and
we need it bad. Not only LibreOffice, but FLOSS in general. I like the
principle that there isn't a single developer (like MySQL had before
the MariaDB split), but I must admit I haven't seen a working (for
"small guys"), "pooling" way to get fixes and enhancements outside of
the "single developer" model...

-- 
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.