Re: [libreoffice-marketing] Re: Of "business ready use" and bugs in LibreOffice and a LibreOffice LTS

["Charles-H. Schulz" <charles.schulz@documentfoundation.org>]

Hello Marc,

2012/6/5 Marc Paré <marc@marcpare.com>

> Hi Charles,
>
> Le 2012-06-05 09:12, Charles-H. Schulz a écrit :
>
>  Thank you for bringing that up, it's an interesting discussion. Here's
>> what I think reading your message. You're asking in fact two questions.
>> One of which might already have been answered by a few of our corporate
>> members/sponsors.
>> * LTS obviously means long term support. Both "support" and "long term"
>>   deserve careful consideration. I will in this email first focus on
>>   the term "support". If we speak of support, we must think of a
>>   support provider. In this case, does this mean we should think -as
>>   TDF, as a project- of providing professional support to users
>>   (obviously for a fee)? I don't think it's your idea, but I thought I
>>   would highlight the implications of such a matter.
>> * Have we studied what some of the existing support/service providers
>>   on LibreOffice already offer? I am not so sure but I'm under the
>>   impression that you can order support (and in this case a "LTS" kind
>>   of support) from Suse and Canonical (there are others) on one
>>   specific version of LibreOffice. That is, these vendors have one
>>   reference version of LibreOffice, say the 3.4.5, and they provide
>>   support and services on it making it their de facto LTS version.
>>
>
> Yes, this is fine as they will guarantee that LibreOffice will work on
> their systems and they will take care of any dependencies and
> network-ability. But I don't think they would undertake any code revision
> and code features into their LTS versions, not unless they have a large
> team of coders, which in this case would make them "competitors" to our
> work/product (read "fork"). This would take us back to the days of the many
> different versions of OOo -- the same situation that drew all of these
> different groups into one LibreOffice community.
>
> Leaving support/service providers to develop an LTS version, in my
> opinion, is not the right strategy to adopt.
>
>
>
>> Back to your suggestion: do you mean we should relabel the older branch
>> "LTS", knowing that each of our releases in one branch really works
>> like a "service pack"? If we had the ability to provide incremental
>> updates (we will one day) we would have the feelings we have two
>> versions, and sometimes "maintenance updates". So at some point, say
>> the 3.5.4, we label it LTS, because we're close to open a new branch,
>> the 3.6, and we can suggest service providers to base their support
>> offers on this one for the time being. Did I get you right?
>>
>
> No. I suggest that at some point, the TDF/LibreOffice should designate an
> LTS version for large/small organizations/businesses. These would have
> developers oversee the fixing of bugs for a fixed term (let's say a 3 year
> period) after which time another LTS version would be designated. The LTS
> maintenance would NOT introduce any new functions to the distro but only
> service bug correction. IMO, if any business entity would like to add any
> new functionality, then this is where a support/service provider would step
> in and, hopefully, contribute any development of code back to the community.
>
> I don't really think this is a new concept as even Mozilla-Firefox offers
> its own "Extended Support Release (ESR)" version for corporate users[1].
> When critical software packages are installed in large corporations, a lot
> of energy in investment of time, training and documentation is expended in
> order to get employees up to speed. LibreOffice certainly falls into this
> category (critical software -- wordprocessing software). While Firefox ESR
> is being released initially for a period of approximately 1 year, IMO, I
> believe they will ultimately find that a longer term will be necessary for
> these large organizations. As for a version of LibreOffice LTS (or ESR),
> the impact of change for large organizations is even larger due to the
> amount of training of staff of new features (even more so in the
> educational field with the training of younger students).
>
> If we are looking to supplant MSO in the office place, we need to realize
> and accept the simple fact that the amount of software/network testing as
> well as (and even more importantly) the training of staff for large
> orgainizations is considerable. I sincerely doubt that a "one year"-term
> LTS for LibreOffice would suffice; one year is just about enough time to
> test out the suite before it is even installed; most organizations simply
> do not have the manpower to move any quicker.
>
> If we wish to compete in the large business market place we need to plan
> and develop more strategically with our releases. Developing an LTS version
> will fix this. Otherwise, the choice will remain MSO for office use, where
> MSO has a longer term of support with incremental changes for bugfixes and
> where LibreOffice will remain marginalized as an office suite.



Interesting ideas here... I wonder how we could plot this with respect to
our existing resources.  The key issue here is resources . LTS only makes
sense if you derive revenue from it.I think we could  relabel one branch as
LTS, the older one if it brings more clarity. It will work for one year. I
don' think working on a branch for 5 years makes sense for a FOSS project,
as -again- the examples pointed out stem from commercial offerings (even
Mozilla with all its resources only provide a one year support and
Canonical or Red Hat offer paid-for support for customers paying each year))

BTW, as some people were wondering what an unstable release might look
like: you are all aware of course, that we released an Alpha version of
LibreOffice 3.6, that you can download it and test it? :-)

Best,
Charles.


>
>
>
>> Best,
>>
>> -- Charles-H. Schulz Co-founder & Director, The Document Foundation,
>> Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des
>> bürgerlichen Rechts Legal details:
>> http://www.documentfoundation.**org/imprint<http://www.documentfoundation.org/imprint>Mobile Number: +33 (0)6 98 65
>> 54 24.
>>
>
> Cheers,
>
> Marc
>
> [1] https://wiki.mozilla.org/**Enterprise/Firefox/**
> ExtendedSupport:Proposal#**Benefits<https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal#Benefits>
>
>
>
> --
> Unsubscribe instructions: E-mail to marketing+help@global.**
> libreoffice.org <marketing%2Bhelp@global.libreoffice.org>
> Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
> unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/>
> Posting guidelines + more: http://wiki.**documentfoundation.org/**
> Netiquette <http://wiki.documentfoundation.org/Netiquette>
> List archive: http://listarchives.**libreoffice.org/global/**marketing/<http://listarchives.libreoffice.org/global/marketing/>
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

-- 
Unsubscribe instructions: E-mail to marketing+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/marketing/
All messages sent to this list will be publicly archived and cannot be deleted