On 08/31/2016 09:26 AM, Dennis E. Hamilton wrote: > 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.
I think this all depends on what one's interests consists of. If you're a C++ programmer looking for a challenging opportunity, Apache OpenOffice might be just what you had in mind for a resume builder. 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 > -- ---------------------------------------- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
