One can always create an independent entity. It hasn't happened. By now, the odds are clearly that it will not. I suspect that folks who would pursue that avenue do not see a meaningful opportunity.
My considered opinion is that the greatest barrier is lack of a meaningful business/operation/funding model. In addition, there is an insufficient supply of developers having the capacity, capability, and will to provide material improvements to Apache OpenOffice. Whatever the pool might be, it is aging and shrinking for many reasons. The affliction that Apache OpenOffice suffers under in that respect also besets any organization set up to support the code, even with paid developers. I also don't think working on Apache OpenOffice is much of a resume builder, since there is no other project like it and probably will never be. There are far easier projects to build an open-source reputation with, ones that build developer skills in areas where there is a growing and future demand. Having suggested this much, I don't think it is meaningful to address how an external entity could "ensure they work on the AOO codebase using the ASF way." If my appraisal is sound, that leaves us with the question about sustainability of the Apache OpenOffice project itself, and what the consequences of unsustainability are. - Dennis > -----Original Message----- > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Monday, July 11, 2016 14:04 > To: dev@openoffice.apache.org > Subject: RE: Independent Entity to Develop and Further AOO > > There is a bit to discuss about how "The entity should ensure they work > on the AOO codebase using the ASF way" is workable or not. In > particular, no such entity can direct the project at Apache or otherwise > effectively govern it. More about that later. > > There is another option, summarized below. One might also consider this > as a reality check. That is, if that is not feasible, it may be that no > other arrangement is. > > > -----Original Message----- > > From: Suminda Dharmasena [mailto:sirinath19...@gmail.com] > > Sent: Monday, July 11, 2016 00:23 > > To: market...@openoffice.apache.org; dev@openoffice.apache.org > > Subject: Independent Entity to Develop and Further AOO > > > > Hello, > > > > I am writing to see if the current AOO Dev team would like to create > an > > independent entity which can: > > > > - Do trainings > > - Accept funds and have pay developers > > - Write commercial books / online tutorials with sponsorship > > > > This can be used have paid developers working on the project. Maybe > > initial > > sponsorship can come from an organisation like Redhat, Pivotal or > Micro > > Focus if they are interested. Perhaps companies which used the code > base > > in > > the past like IBM or Oracle. > > > > The entity should ensure they work on the AOO codebase using the ASF > > way. > > > > Suminda > [orcmid] > > AN ALTERNATIVE APPROACH > > Another way to interact and support Apache OpenOffice in terms of > collaborative contributions is as follows. > > 1. Establish a downstream producer, TeamX (for example), that provides > releases of derivative software based on Apache OpenOffice. > > 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the > use of Apache OpenOffice source code. Apache trademark requirements are > satisfied in any use as part of the branding of the downstream product. > > 3. Assumption #2: New code and modifications to the TeamX derivative > are also under ALv2. > > 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs > are contributed back upstream to Apache OpenOffice. Components from > other sources would, of course, be contributed upstream to those > sources. Contributions and joint concerns might lead to use of the > OpenOffice bugzilla as a coordination point. > > 5. Opportunity. The business model, organization, and governance of > TeamX is not of concern to the ASF. > > 6. Opportunity. The Apache Software Foundation requirements beyond > honoring of the ALv2 that govern Apache projects serving the public > interest do not apply, although TeamX could operate in a harmonious > manner. > > 7. Opportunity. So long as there is clear separation and no comingling > in source-code files, TeamX is not constrained from also using code or > components from other projects, such as those using licenses such as the > MPL or, under appropriate conditions, something like LGPL2, with > appropriate honoring of those licenses too. However, to avoid tainting > of upstream source-code contributions back to Apache OpenOffice, there > must be careful management of IP and reliance on code (source or binary) > under non-ALv2 license (and ALv2 code which is not the original work of > TeamX). > > 8. Opportunity. Depending on how close the operation of TeamX releases > remains to that of Apache OpenOffice, especially at the beginning, one > can rely on the Apache OpenOffice mediawiki and openoffice.org site in > large measure, so long as there is no confusion. Also, the Apache > OpenOffice Community Forums are more ecumenical in how they can provide > forum support to OpenOffice.org-lineage ODF-supporting products. How > confusion is avoided would need to be worked out, but this provides > TeamX time to develop its own support as that ends up having unique > requirements. > > This is not unlike how downstream organizations rely on Apache > OpenOffice for specialized distributions (e.g., FreeBSD, OS/2, and > Solaris). There are other Apache projects where the downstream > ecosystem is quite robust and the key Apache project deliverable is the > source-code release and not so much any end-user binary distributions. > > - Dennis > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
