On 25.02.22 15:43, Paolo Vecchi wrote:
Hi Michael,
thanks for your feedback.
On 25/02/2022 10:22, Michael Meeks wrote:
> In the graph above the committers have been grouped in Commercial
> (companies specialised in selling LibreOffice development and
> products), Corporate (companies and institutions contributing
> voluntarily)
I'm intrigued by this distinction; can you specify which entities
are in which bucket and why ?
The macro categories can be easily worked out but here they are:
Commercial contributors:
* Collabora
* CIB->Allotropia
Corporate contributors:
* RedHat
last i worked there, LibreOffice was a fully supported part of Red Hat
Enterprise Linux that customers could and did file enhancement requests for.
* Assigned (a bit of a mix but volumes don't change much the result)
err, no: these are people who are not contributing as part of their
employment, although they *may* be paid Google Summer of Code interns.
the way it works is that or people who contribute at different times
with different employers, their contributions for their employer are
counted for their employer, while their contributions with no employer
are counted as "Assigned".
* NISZ
* SIL
* Munich
Volunteers:
* Unknown (no official affiliation)
and TDF own contributions.
> TDF has to develop a strategy which includes the employment
> of internal developers which will both increase the speed of
> development and will help with the on-boarding of new external
> commercial, corporate and volunteer contributors.
Why do you believe that in-house developers (vs. say mentors) will
help with on-boarding new contributors if that is not their focus? My
suspicion is that mentoring is hard and "doing it yourself" is
superficially easy in the short term.
As from previous answer:
"Learning by doing (fixing bugs) will help those developers in helping
others following the same path while getting rid of issues that
commercial contributors and volunteers have overlooked."
i think what Michael meant is: how do you get an experienced developer
to spend 3 hours discussing a problem with a newbie spread across a
longer time period and giving them hints to fix it and review their
work, instead of simply fixing it themselves in a single session in half
the time, if their job title is "developer" and not "mentor".
> and the quantity of bugs, features and updates that may require
> tendering or paid for services by the commercial contributors is
> still so vast that it will not affect noticeably their income
While it is true that there may be an inexhaustible amount of work
and TDF will never reduce that by doing some of it, I'm not sure that
is really relevant.
Tendering has been used by TDF to help stimulate, diversify and
sustain the commercial ecosystem around LibreOffice since the
beginning. TDF has a fairly fixed amount of cash - if there is less of
that to spend, that will have a non-trivial impact.
The methods tested up to now to stimulate and diversify the number of
more commercial contributors haven't brought the desired result as it
seems like mostly 2 companies bid for those tenders so we'll have to
work harder on it.
how do you expect to grow the number of companies who bid for tenders if
there are not more tenders? N companies bidding for a tender means that
N companies spend significant time doing estimations, but N-1 companies
get 0 income for that effort.
Worse than that though is the possible for TDF to significantly
harm the market for bug-fixing far in excess of any work it can do -
by creating the idea that there is a "free" way to have issues
addressed through political machination at TDF.
I'm concerned by your comment as you seem to put in doubt the neutrality
and the dedication to the wider community of TDF's team.
Reading it in another way someone may even think that "political
machination" tried to stop TDF to fully express its potential for
serving the wider community.
Naturally not many people came up with those thoughts so I guess they
really aren't an area of concern for most.
i guess you aren't familiar with the history of this project, but this
was very common in OpenOffice.org times: when a beta was released,
suddenly a bunch of people came out of the woodwork to complain very
loudly on public lists why bug X or bug Y had not been fixed and how
this could possibly be given that this bug is obviously so severe that
the product is unusable.
in many cases what happened then is that Sun fixed the bug before the
release - a bug which was actually found by some enterprise user who
deployed "free" OOo and paid a consultant to file the bug in IssueZilla
and then make a noise about it, without paying any developer to actually
fix the bug.
--
To unsubscribe e-mail to: board-discuss+unsubscr...@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
