As we like to make our statements using various communication
channels/media it becomes pretty hard to respond to anything.
Yes, guilty of that too. So not claiming any superiority here. And every
medium has it own public. And everybody has it own preference
However makes it also hard to find 'the right' place. Anyhow more or
less responding to https://twitter.com/Sweet5hark/status/1303065894533427201
In my perceptions it about the perspective. From internal perspective
(so within the organization of TDF) LibreOffice is viewed, managed, and
functioning as a project.
There is a community. There are volunteers at QA, translation,
marketing, support (ask) and number of volunteering developers.
How the developers at the eco-system partners are prioritizing bugs and
refactors is outside my sight. However I assume most of the bugs are
picked by the developers themselves.
So the got quite a lot of freedom related to the work on LibreOffice. So
also a project approach. Not sure if there is also more commercial
product breach with dictated projects; strict deadlines and such.
LibreOffice for the end-user is pretty often associated with a product.
What do I mean with product. There quite a lot of dimensions to unwind here.
* From marketing perspective. What are you selling. In the SaaS model
customers don't get a product, but more service. However they software
is still the product the company is selling. And there are maybe still
binaries to be installed.
* A product in end-user perspective. The product is what you paid fore.
If it tooth paste of license to a certain software. With SaaS this get
sore complicated. It's product (say Office Suite) is wrapped into service.
Except you aren't the end owner anymore. That part of buying a product
and owning it (or the license to use it for ever) is stripped out.
* The results of a hobby (software) project; they application itself it
the product of the coding effort.
They end-user uses LibreOffice as a tool to get his job done. They use
LibreOffice as product to get certain things done. Linguistically he
can't even 'use LibreOffice as a project'; it simply sounds weird.
So the result of a successful (community/hobby) project is a certain
product. And this product is also seen as product by others. So
LibreOffice being a project is an internal view; but not necessarily for
the outside world.
It's a project for those whole are involved. And it managed, organized
in a (hobby) project manner. So no commercial drive to get certain
things fixed or the need to for new version with new features (to sell)
And even this isn't black/white. We are release a new version every 6
months, with release notes promoting new features. Somewhat odd for an
organization not being product driven.
So an organization who doesn't need to squeeze out something new every 6
months or year (to get people to pay again for the upgrade)
So there is no binary distinction between Project/Product. However it's
true that LibreOffice is less product focused in commercial terms.
Which means bug stay open longer which commercially might be a no go.
Introduced or revamped features don't always match expectations (as the
are releases somewhat unfinished).
And the product/feature owner (the developer who build it) might have
moved on to something else
The issue I see with going 'commercial' with paid a Product (they
software that say quality expectations of customers going up. I paid, so
I might assume X/Y working properly.
So with paying customers that responsibility is taken for bugs. And
those get solved within a certain time frame. And regressions being less
tolerated (pressure at QA and DEV).
You can extend the Product (software) with services. Special features,
special support for very specific bugs, consultancy etc. However this is
an extension of the main Product (Software).
They main product (Software) needs to be in good shape. I don't see
customers paying for extended services (derived products) to solve
self-inflected regressions in the main Product.
Even if they main Product (software) is being shipped free. Extended
services are simply addition to core product no a replacement.
Say A has to use extended service to repair a regressions caused a
change made by developer Z to solve an issue of paying customer (B).
This must be calculated into they price of B or in the price of the core
Product.
And for the record. A product stays a product even being free. If I get
beer for free from the brewery, it's still get product (beer). Even a
free product can sometimes not meet the expected quality standards.
Say brewery gives a way beer for free but it's spoiled. You might not go
back and request something better (because it was for free). However
doesn't go well for the brand reputation.
The brewery could also give creates of beer away for free. And extend
his Product with insurance that each pipe of beer will taste well. You
have to pay for that of course. And if not OK you have to fill a form.
Bring it back to certain location.
Waiting for approval. Ultimately it will be resolved. Do you want to
take the risk when hosting a party? Or do you prefer to pay upfront with
a quality guarantee in advance (where normally out of the question of
the taste will be OK).
So what should the brewery do; go for better product or giving beer away
for free with insurance? And what would the customer do. Would he prefer
free beer with uncertainty if it taste well? Possibly ruining his
party.. Or go for save.
Again this whole topic is fluid. So you Product could be pretty cheap;
with some warranties about quality. And some extended services. Which is
actually the case. Something called Product Warranty.
The insurance premium (for broken product) is calculated withing the
price of the core product. So minimum quality warranty; if not return
you get something new. Or in software terms.. we fix it ASAP (and for free).
Regards,
Telesto
--
To unsubscribe e-mail to: [email protected]
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
