Isn't this related to certification programs? Speaking of which, does
anyone have a brief explanation and some links to any existing official
OOo certification or training or similar programs?
This is a major area for end users (and trainers, consultants, and the
like) that we need to figure out how to effectively transition to the ASF.
As a non-profit public charity, the mission of the ASF is to produce
software for the public good, given away freely. The way that the ASF
does this is loosely known as the Apache Way, which is mostly about
meritocratic communities making consensus based decisions on project
directions, leading to high quality software that everyone can use.
Along with our software, our projects also offer basic community-led
support and help, through our mailing lists and bugtrackers. However
the ASF does not directly offer support contracts, trainings,
certification, or other services about our products. This is because of
our volunteer nature, and the fact that we do not charge for any of the
software (or services) that we provide.
I'm sure we can provide sufficiently documented licensing procedures for
trainers who want to provide certifications in Apache OO, although it
may take a little while to get it right, and to ensure the Apache folk
here understand what's important to the broader and pre-existing OOo
community.
- Shane
On 6/30/2011 4:56 AM, Ian Lynch wrote:
On 30 June 2011 07:10, Dennis E. Hamilton<dennis.hamil...@acm.org> wrote:
Umm, 100% fidelity to/of what? I would love to understand the
qualifications that attach to that statement, and how whatever that is can
be demonstrated/verified.
"[T]hey both operate on odf files with 100% fidelity."
If I save an odf file from OOo it will open exactly the same in LibO. If
that isn't true than I would be interested to know where things break.
(Fonts I think are a different issue) If it isn't 100% true it is pretty
likely to be more true than filtering to either other applications that use
odf or .doc etc. From an end user point of view all they will be concerned
about is that files produced in OOo don't break in any way if imported into
LibO or vice versa. Of course product divergence might make this less likely
but at the moment I don't think there is a significant problem but I'm
willing to be corrected. So do we scare the end user or give them more
confidence?
In terms of verification or otherwise, give me a file created in OOo that
will not open correctly in LibO other than because the fonts are different
on the two systems creating the files. If you prefer to say that OOo/LibO
use the same file format so you are safe exchanging files between OOo and
LibO, Ok, better to get rid of all mentions of technical stuff for end users
in any case. What we need is to give reasonable confidence to the end user
rather than obscure (to them) technical reasons why that might on some
almost impossibly rare occasion not be the case.
