> On 9 Jan 2016, at 5:48 AM, Slow Joe <slow.joe....@gmail.com> 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 > https://lastbytes.wordpress.com/2013/01/15/a-postmortem-template/) > > 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 http://www.apache.org/legal/resolved.html (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 products.” 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: http://www.futurealoof.com/posts/apache-considered-harmful.html 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 (http://corinthia.io). [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 pmke...@apache.org http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
