corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)
Date Fri, 15 Jan 2016 14:55:53 GMT
> On 9 Jan 2016, at 5:48 AM, Slow Joe <> wrote:
>> Forming a podling is difficult as if often starts with a team  that
>> hasn't necessarily chosen to work together. I bet the situation > would
>> have been very different if you guys had been able to meet in
>> person,
>> but in email that's quite hard.
>> -Bertrand
> Hi Bertrand
> I observed the meltdown of the Corinthia podling from a distance with some
> regret.
> Since the project is now on the verge of withdrawal from the incubator,
> could you and Dennis consider whether it would be valuable to collaborate
> on a blame-free post-mortem describing the events which lead to the end of
> Corinthia.
> (A template for a postmortem document is at
> I would suggest that there are lessons for the Apache Project to learn from
> this event.
> Regards
> Joe

I just realised I’m still subscribed to the dev list for Apache Corinthia. After we left
ASF, I decided not to comment further on the situation (feeling it was easiest just to walk
away) - but since there’s been a request for a post-portem, and it’s been a few months
now and I’ve had a chance to calm down a bit, I figured I’d offer my thoughts.

(Disclaimer: I am not a lawyer; what I’ve written below regarding licenses and ASF policies
is my own understanding, which may or may not be accurate. I welcome corrections or clarifications)

There were a number of issues that lead to the project’s exit from Incubator, mostly relating
to personal disagreements between project members, which I have no desire to revisit, especially
not in public. Ultimately it was those issues which triggered our exit (when I say “our”
or “we” here, i refer to the subset of project members who were actively involved in development).
However, one important factor which really killed things for us was the inability to use Qt.

Corinthia was envisaged as a combination of libraries for translating and editing word processing
& office documents (the first 50% of the project), and a desktop + web application providing
an editor usable by end-users (the second 50% of the project). We planned to produce two different
editors - one which ran as a regular native desktop app on Windows, Linux, and OS X - and
the other which could operate in the browser. The desktop app was the main priority, however.

To do a cross-platform desktop app, and to do it properly, it’s necessary to use a suitable
UI toolkit which provides all the necessary functionality. As it turns out, the only viable
candidates we were able to identify (Qt and GTK, with wxWidgets and fltk as less desirable
fallback options) are all licensed under the LGPL. For most open source projects, this would
be no problem - LGPL and ASLv2 are compatible with each other, in the sense that you can distribute
software combining the code from the two licenses without problems; doing so just means that
users of the software are bounds by the terms of both licenses.

We very quickly settled on Qt as the toolkit of choice, on technical grounds. It seemed to
us to be the most mature, feature-rich, and best designed library of the available choices,
and some of us had already used it on other projects in the past. However, even if we had
chosen one of the other libraries, the outcome would have been the same.

The ticking time bomb, as we discovered several months in, was the disconcertingly-named “Category
X list”, described at (under "Which licenses may
not be included within apache products?”). This lists several licenses, including the LGPL,
regarding which it states:

"The LGPL is ineligible primarily due to the restrictions it places on larger works, violating
the third license criterion. Therefore, LGPL-licensed works must not be included in Apache

When I (and some others) on the project read this, we did not see it as a problem. We were
not distributing any LGPL-licensed code, but merely writing an application conforming to an
API whose only currently-existing implementation is licensed under the LGPL (there are commercially-licened
versions of the library as well, for those who want them).

It all hinges on the phrase “included within” - I do not consider a third-party library,
that is not distributed as part of an ASF release, to fit within that definition, according
to my understanding of the English language (and I’m a native speaker). However, the relevant
ASF policy makers have a different interpretation. It’s extremely subtle - basically the
policy equivalent of an OpenSSL bug.

So once we learnt about this, 50% of the project was basically off the cards. We were told
that not only can source code for an app that uses the Qt APIs not be included in an official
Apache release, but that it should not even exist in the git repository as a piece of example
code demonstrating how to use our other libraries.

One somewhat unsettling aspect of discussions I observed was that they were predicated on
the assumption that the project should be done as an ASF project, and thus following ASF rules.
Anything that deviated from the rules was immediately rejected on this basis. Now, that’s
fair enough - we agreed to be part of the organisation, and rules should be followed. But
one thing that was never seriously considered, until fairly late in the piece, was whether
the project really belonged at ASF in the first place. Eventually, we concluded the answer
was no.

For what we were trying to achieve, and the ways in which we were going about it, it turned
out that ASF was not an appropriate choice of venue. There were several other things I felt
were unreasonable - the inability to accept pull requests from anyone without first asking
them to sign a CLA, the prohibition against binary distributions of support libraries for
convenience of building, and the constant deference to the pseudo-religious “Apache Way”
(which I still haven’t seen a coherent explanation of, despite the very long “What is
the Apache Way?” thread on this list just a few months ago).

The big takeaway from my experience, in terms of suggestions, is to make it *very* clear on
both the incubator website, and impressed upon anyone considering joining incubator, exactly
what can and cannot be done in within the context of an ASF projects. Without this, I expect
there to be more people coming away from incubator with really bad experiences, and disliking
ASF as a result, such as the author of this article:

I would make priority #1 clarifying what “included within” actually means, closely followed
by more generally revising the rules surrounding license restrictions and others, so they
don’t require extensive study and debate before it can be determined whether or not a given
project is possible to do within ASF. While “You cannot write cross-platform desktop apps
at ASF” is probably a little too strong (technically speaking, you could use your own dedicated
cross-platform toolkit like OpenOffice does, or a web app wrapper like Electron), stuff like
this needs to be made really, really clear right from the beginning, before large amounts
of time are invested in podlings that later discover themselves doomed to fail from the start.

The most important lesson I learnt is to not get attached to any one particular organisation
for a project. GitHub is a popular choice for many projects, and I don’t consider there
to be anything wrong with moving a project there if it turns out to not fit within ASF’s
rules and policies. That’s what we did with Corinthia (

[Unfortunately, there hasn’t been any further progress on the project since the move, but
that’s due to unrelated reasons (some people left, others like myself have been to busy
with other things to devote time to it). I’ve recently finished up a contract though and
now have some spare time on my hands, so I hope to try and get it re-started soon.]

Most importantly, working on GitHub or a similar hosting site gives a project team complete
freedom to operate how they want. ASF espouses the mantra “community over code”, but in
reality it’s “restrictive policies over community over code”. My experience has been
that if it’s necessary to destroy (or rather “jettison”) a community or project in order
to ensure such a policy is enforced, then the tradeoff is worth it.

I don’t think that’s a healthy way of doing open source in 2016.

Dr. Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message