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