Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

On 27 April 2012 10:19, Robert Ryley <> wrote:


First, thank you for answering my question without being defensive.
These are valid concerns on all sides of the issue.

So this is a problem of vendors not being able to generate trust among
clients.  This isn't unusual.  That is the challenge of trying to
catch up to a perceived market leader.

Again, it begs the question; if a client does not trust a vendor, why
should it trust some anonymous "certifying" body?

They might if the certification body has a reputation for independence and
objectivity. The evidence is in the hundreds of millions of certifications
that take place from licenses to practice to partnership endorsements.

  These are things
that people say to make salespeople go away.

Certification doesn't really solve this issue.  Finding what the
hidden objections are, developing an unambiguous specification
that satisfy these objections, and providing proof of correct
implementation, do address them.

At least in Europe -but I also know it took place in other parts of the
world such as Asia- you had IT companies pretending to be experts in migrations that were able to win tenders and actually
never executed on the parts relevant to the expertise around

At the same time there was a clear call from smaller IT companies to
gain some status and transparence on who in the business was doing what.
Some modest attempts to that happened during these years, but they were
clearly insufficient. But anyway you looked at this, the feedback from
customers and suppliers was clear: the ecosystem just was not able to
grow despite clear (and growing) demand and vendor/service provider
certification was requested.

Were these vendors actual contributors to the codebase, market
research, or documentation?  I still don't see how
"certification" will make dishonest people honest.

Certification makes it more likely that the person you are dealing with is
honest because the certification can be removed - that implies having a
robust complaints procedure and systems for dealing with them.

LO is a *free* product.  Buyers can have technically competent staff
install and test the product for themselves.  Part of the value added
strategy is to develop the specification *with* the buyer, and address
needs they do not see.

And someone certificated would give a third party more confidence that they
are able to do that. If the third part is going to be say IBM it probably
doesn't matter. For a small business it probably will make more difference.

Now to your other question: should TDF focus on code development and
extensions?  Well it could and it is essentially what it is doing these
days. But honestly  we need to grow our reach and fix the mess that
years of interaction with business was not able to deal
with. You  seem to be wary of TDF making a profit here;

Absolutely not.  I have *no* problems with anyone making a profit.

We have had this from some quarters. There is a lot of risk involved and it
is difficult to "break even" - better to have a surplus than a loss and
then the surplus can be put into code development, marketing etc.

For all my complaints on this issue, the TDF does good work, and I
want to see it succeed.  It could make more money with less effort by
raising cash to incentivize other developers to open source their
extensions into the codebase.

That could well be true. OTOH where is the evidence? Our business sustains
some FOSS development and a lot of FOSS advocacy with good prospects of
significant growth. I guess a lot depends on using expertise to its best

Ie. Suppose I develop a voice activated, context editor for LO.  I can
sell the extension to those who want it, and keep the source private.
I could also sell the extension, keep the source private until some
threshhold amount is raised, and the TDF gets a percentage of it, I
get the rest, and release the source code.

We already have the infrastructure well developed for certification. It
seems to me that on this one TDF wants to do it themselves which is fair
enough. Would TDF philosophy fit with closing source code even for a fixed
period? Not sure.

There are other ways to raise revenue from vendors of LO extensions
and support that do not suffer from the drawbacks of the certification

Why not do both? The certification model if implemented properly has the
potential to fund the entire project. I did the research and convinced some
pretty hard nosed financial backers. Maybe you could do the same for

This particular aspect of the plan galls me:

"Certification will be attributed to individuals who have demonstrated
their skills by participating to the community, or who have followed a
certification training and have passed the final test. Certification
will last for 24 calendar months from the time of the test, and will
be renewed for another 24 months by following another certification
training and passing the relevant test before (three months) or after
(three months) the expiration date.

The fee for the certification renewal will be 25% lower than the full
certification fee. Individuals who will not follow the training or who
will fail the test will lose the certified status, and will have to go
through the entire certification process (including the payment of the
full certification fee)"

I will provide support via code, documentation, marketing, promotion,
and fund raising OR I will provide money.  I *will not* pay to work
for free.

Hm, sort of see your point but this is similar to an internship model where
the future benefits outweigh the investment in costs and time. I'm not
saying I think this is a good model, just that it has some track record.
Personally, I think the volume is in end users, not developer or systems
integrators. On volume you can make it very low cost and still get a decent
return. Niches mean you have to charge more and so there is a significant
barrier to entry, particularly for those already competent who are likely
to just say who cares? It might even discourage developer participation. So
bit of a risky strategy.  High volume, low cost so people don't mind paying
a small amount to get their skills recognised. Bottom of the pyramid stuff
rather than top. Read up on the principles of disruptive innovation.

TDF is indeed  not for profit -but does it mean it is for loss? Clearly,
if we ever
make profits from certification (something I'm not sure of) it will at
least create resources we are in dire need of. We need funds for
infrastructure, marketing on a global level and many other things.

I agree with this, but it is rather self-defeating to go around and
spread a marketing message that implies people who are not "certified"
in LO, but actively help develop and contribute to it, are

Some arguments against certifications:

IT Certifications are Worthless

Do Certifications Matter

License My Dog, but not Me

Top 10 Problems with IT Certifications

But equally, ECDL/ICDL (Not for profit :-) ) probably makes 100 million
Euros a year. Think what LO could be with that sort of revenue.
Unfortunately, it won't come from a model of certificating coders.


Ofqual Accredited IT Qualifications (The Schools ITQ) +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.