Re: Independent Entity to Develop and Further AOO
On 31/08/2016 22:44, Dennis E. Hamilton wrote: >> As a business model, it works for most of the Apache projects that emerged >> from Incubation, and stayed out of the Attic. > I think that is the case because downstream producers, who get the support > business, contribute to their upstream framework or source-code distributor. Back when Sun was running OOo, acceptance of patches from downstream were very few and far between. Which is why Go-Oo was created. When Oracle was running OOo, patches from downstream were more or less uniformly rejected. Part of the Apache Way is for code patches to be willingly contributed by the individual or organization that wrote the patch. Code contributed to other, similar software, even if appropriately licensed, won't make the cut here. The code has to be directly submitted to the AOo code repository. Offhand,I don't know which OOo derivatives are using AOo as a baseline, and which are using LibO as a baseline, and which are using neither as a baseline, and which are using both as a baseline. > What indication is there that any of that is working for Apache OpenOffice? One issue, that was brought up back when AOo was a podling in incubation, was that it had an over-reliance on developers from a single company. As best as I can tell, it never broke out of that over-reliance box. And from https://db.apache.org/newproject.html are these telling quotes: «Orphaned products. Products which have lost their corporate sponsor (for whatever reason) do not make good candidates. These products will lack a development community and won't have the support needed to succeed under the DB umbrella» and «Reliance on salaried developers. DB has strong ties to the business community. Many of our developers are encouraged by their employers to work open source projects as part of their regular job. We feel that this is a Good Thing, and corporations should be entitled to contribute to open source, same as anyone else. However, we are wary of products which rely strongly on developers who only work on open source products when they are paid to do so. A product at DB must continue to exist beyond the participation of individual volunteers. We believe the best indicator of success is when developers volunteer their own time to work open source projects.» >Maybe if we stopped shipping binaries? >How would that work for the individuals who seem to dominate our download consumption? One major difference between AOo and the rest of the projects supported by The Apache Foundation, is that it focuses on consumers as end users, not businesses as end users. Whilst both Sun and, to much lesser extent, Oracle, sold enterprise licenses for OOo, it was the consumer version that found the bugs. It was the consumer version that drove product popularity. It was the consumer that was reviewed in the trade press. The AOo binaries are the consumer version. Right now, AOo doesn't integrate with other software from The Apache Foundation. It isn't something that an existing downstream distributor of other Apache software can add to their catalogue, as a supporting/additional feature/function/capability. No doubt somebody will start muttering, "Apache Derby, Apache Cassandra, Climate Workshop, etc." AOo is, at best, an optional client. It will take major changes in AOo, for it to be the optimal client for those projects. >> OOo derivative, are not not that scarce. Somebody is providing tech support >> for those worksites. > As far as I can tell, those downstream activities are invisible to the project. This is where having a list of OOo derivatives, and what their baseline is, would be useful. In some respects, I'm a little surprised that there aren't more AOo derivatives in the Android and iOS app stores.This is where individual developers are still able to gain marketshare. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
On 07/11/2016 09:44 PM, Suminda Dharmasena wrote: > This is exactly what I had in mind also. >From the original post of: http://mail-archives.apache.org/mod_mbox/openoffice-dev/201607.mbox/%3CCAAfFNYEBbXaTj5-qVy7V8Uj7uA3wCyo6O0fsHG7ESpmTG4qO3Q%40mail.gmail.com%3E None of the approaches listed below is what I imagined. The original post seemed like a suggestion to form basically a "foundation" to fund developers. So that seemed pretty straight forward. No one needs our blessing for that. Any contributions, paid or otherwise, need to follow the Apache Way in terms of contributions etc. Neither the current developers or PMC need to agree to that. This is mentioned in Item 5 below. If any of the existing developers wanted to join such a foundation, this would be OK too. None of this would have any bearing on the way we currently operate as a project in the Apache Software Foundation. Except for the original core "developers" that signed up for inclusion in the "OpenOffice" project back in 2011, http://wiki.apache.org/incubator/OpenOfficeProposal every commmitter/developer on this project has undergone the same initiation rites of making significant contributions to the project. > > > >> >> 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 >> >> > -- 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
Re: Independent Entity to Develop and Further AOO
On Thu, 1 Sep 2016 09:58:04 -0700 "Dennis E. Hamilton" wrote: > > > > -Original Message- > > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > > Sent: Wednesday, August 31, 2016 22:04 > > To: dev@openoffice.apache.org > > Subject: Re: Independent Entity to Develop and Further AOO > > > > Am 01.09.2016 um 00:59 schrieb Simon Phipps: > > > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < > > > dennis.hamil...@acm.org> wrote: > > > > > >> > > >> > > >>> -Original Message- > > >>> From: toki [mailto:toki.kant...@gmail.com] > > >>> Sent: Wednesday, August 31, 2016 11:30 > > >>> To: dev@openoffice.apache.org > > >>> Subject: Re: Independent Entity to Develop and Further AOO > > >>> > > >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote: > > >>> > > >> I think that is the case because downstream producers, who get the > > support > > >> business, contribute to their upstream framework or source-code > > distributor. > > >> > > >> What indication is there that any of that is working for Apache > > >> OpenOffice? Maybe if we stopped shipping binaries? How would that > > work > > >> for the individuals who seem to dominate our download consumption? > > > > > > > > > Since the "downstream" producers seem better equipped to deliver > > signed and > > > vulnerability-corrected binaries to non-specialist consumers on a > > timely > > > schedule, maybe delegating downloads to them would be a good option > > for the > > > project? > > > > Stopping shipping binaries would cause some negative effect for our > > project, so it might be an option, but not best one. > > > > Binaries made by our community are essential for our QA. > > > > Without them we stand "with empty hands" in the public with negative > > effects for our brand and image. > > > > Supporting our users by community members would break down. > > > > So the impact for the improvement of our commity would be tremendous, if > > we "delegate" this tasks to a third party. > [orcmid] > > I agree with Michael. Ceasing to provide builds from Apache OpenOffice but > having a downstream producer provide them would be retirement of Apache > OpenOffice in everything but name only. I agree emphatically. Most OO users want to download and go - they have not the time or skills to build a version, which is not as trivial task, as frequenters of the dev ML will be aware. RoryOF > > Also, the "downstream" in this thread refers to sellers of support who > apparently package their own versions. We see no contributions back to the > code base from any of those, whoever they might be. > > This is different than existence of forks and openoffice.org-descendant > cousins who operate their own code base and support it, whoever those might > be. While that might be disagreeable to some, it is in the spirit of > open-source and the commitment of the Apache Software Foundation to serving > the public interest. (The protection of the respective trademarks is a > different matter with respect to avoiding confusion about the origin of the > effort.) > > > > > > Kind regards > > Michael > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Independent Entity to Develop and Further AOO
> -Original Message- > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Sent: Wednesday, August 31, 2016 22:04 > To: dev@openoffice.apache.org > Subject: Re: Independent Entity to Develop and Further AOO > > Am 01.09.2016 um 00:59 schrieb Simon Phipps: > > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < > > dennis.hamil...@acm.org> wrote: > > > >> > >> > >>> -Original Message- > >>> From: toki [mailto:toki.kant...@gmail.com] > >>> Sent: Wednesday, August 31, 2016 11:30 > >>> To: dev@openoffice.apache.org > >>> Subject: Re: Independent Entity to Develop and Further AOO > >>> > >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote: > >>> > >> I think that is the case because downstream producers, who get the > support > >> business, contribute to their upstream framework or source-code > distributor. > >> > >> What indication is there that any of that is working for Apache > >> OpenOffice? Maybe if we stopped shipping binaries? How would that > work > >> for the individuals who seem to dominate our download consumption? > > > > > > Since the "downstream" producers seem better equipped to deliver > signed and > > vulnerability-corrected binaries to non-specialist consumers on a > timely > > schedule, maybe delegating downloads to them would be a good option > for the > > project? > > Stopping shipping binaries would cause some negative effect for our > project, so it might be an option, but not best one. > > Binaries made by our community are essential for our QA. > > Without them we stand "with empty hands" in the public with negative > effects for our brand and image. > > Supporting our users by community members would break down. > > So the impact for the improvement of our commity would be tremendous, if > we "delegate" this tasks to a third party. [orcmid] I agree with Michael. Ceasing to provide builds from Apache OpenOffice but having a downstream producer provide them would be retirement of Apache OpenOffice in everything but name only. Also, the "downstream" in this thread refers to sellers of support who apparently package their own versions. We see no contributions back to the code base from any of those, whoever they might be. This is different than existence of forks and openoffice.org-descendant cousins who operate their own code base and support it, whoever those might be. While that might be disagreeable to some, it is in the spirit of open-source and the commitment of the Apache Software Foundation to serving the public interest. (The protection of the respective trademarks is a different matter with respect to avoiding confusion about the origin of the effort.) > > Kind regards > Michael > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Am 01.09.2016 um 00:59 schrieb Simon Phipps: > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < > dennis.hamil...@acm.org> wrote: > >> >> >>> -Original Message- >>> From: toki [mailto:toki.kant...@gmail.com] >>> Sent: Wednesday, August 31, 2016 11:30 >>> To: dev@openoffice.apache.org >>> Subject: Re: Independent Entity to Develop and Further AOO >>> >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote: >>> >> I think that is the case because downstream producers, who get the support >> business, contribute to their upstream framework or source-code distributor. >> >> What indication is there that any of that is working for Apache >> OpenOffice? Maybe if we stopped shipping binaries? How would that work >> for the individuals who seem to dominate our download consumption? > > > Since the "downstream" producers seem better equipped to deliver signed and > vulnerability-corrected binaries to non-specialist consumers on a timely > schedule, maybe delegating downloads to them would be a good option for the > project? Stopping shipping binaries would cause some negative effect for our project, so it might be an option, but not best one. Binaries made by our community are essential for our QA. Without them we stand "with empty hands" in the public with negative effects for our brand and image. Supporting our users by community members would break down. So the impact for the improvement of our commity would be tremendous, if we "delegate" this tasks to a third party. Kind regards Michael signature.asc Description: OpenPGP digital signature
Re: Independent Entity to Develop and Further AOO
On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < dennis.hamil...@acm.org> wrote: > > > > -Original Message- > > From: toki [mailto:toki.kant...@gmail.com] > > Sent: Wednesday, August 31, 2016 11:30 > > To: dev@openoffice.apache.org > > Subject: Re: Independent Entity to Develop and Further AOO > > > > On 31/08/2016 16:26, Dennis E. Hamilton wrote: > > > I think that is the case because downstream producers, who get the support > business, contribute to their upstream framework or source-code distributor. > > What indication is there that any of that is working for Apache > OpenOffice? Maybe if we stopped shipping binaries? How would that work > for the individuals who seem to dominate our download consumption? Since the "downstream" producers seem better equipped to deliver signed and vulnerability-corrected binaries to non-specialist consumers on a timely schedule, maybe delegating downloads to them would be a good option for the project? S.
RE: Independent Entity to Develop and Further AOO
> -Original Message- > From: toki [mailto:toki.kant...@gmail.com] > Sent: Wednesday, August 31, 2016 11:30 > To: dev@openoffice.apache.org > Subject: Re: Independent Entity to Develop and Further AOO > > On 31/08/2016 16:26, 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. > > The Document Foundation is an independent entity, building upon the OOo > 3.x code base. > > > My considered opinion is that the greatest barrier is lack of a > meaningful business/operation/funding model. > > The business model is giving away the product, but selling support > services. Sun almost understood that model. Oracle understands that > model,but would rather throw away their product, than actually implement > that model at the SOHO, or smaller scale. > > As a business model, it works for most of the Apache projects that > emerged from Incubation, and stayed out of the Attic. [orcmid] I think that is the case because downstream producers, who get the support business, contribute to their upstream framework or source-code distributor. What indication is there that any of that is working for Apache OpenOffice? Maybe if we stopped shipping binaries? How would that work for the individuals who seem to dominate our download consumption? > > > I also don't think working on Apache OpenOffice is much of a resume > builder, > > What builds resumes is the specific contributions one makes. The > specific project, be it AOo, No Man's Sky, BLEACHER, or anything else, > is irrelevant. > > >since there is no other project like it and probably will never be. > > At least four other office suites utilize code from AOo. There are at > least a thousand office suites for Android, and iOS, for which AOo > development is a useful starting point. > > > If my appraisal is sound, that leaves us with the question about > sustainability of the Apache OpenOffice project itself, > > Go back to the revenue generation model. > > Back in the 2003-2005 time frame, there were several organizations > licensing their rebranded version of OOo for between US$20 and US$5,000 > per seat, per year. For various reasons, I quit tracking that data, and > thus don't know what the current situation is. > > A decade ago, it was fairly difficult to find worksites of more than > 1,000 that used OOo. Today, worksites of more than 5,000 users, using an > OOo derivative, are not not that scarce. Somebody is providing tech > support for those worksites. [orcmid] And how does any of that contribute to the development of Apache OpenOffice? As far as I can tell, those downstream activities are invisible to the project. - Dennis > > jonathon > > - > 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
Re: Independent Entity to Develop and Further AOO
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
Re: Independent Entity to Develop and Further AOO
On 31/08/2016 16:26, 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. The Document Foundation is an independent entity, building upon the OOo 3.x code base. > My considered opinion is that the greatest barrier is lack of a meaningful > business/operation/funding model. The business model is giving away the product, but selling support services. Sun almost understood that model. Oracle understands that model,but would rather throw away their product, than actually implement that model at the SOHO, or smaller scale. As a business model, it works for most of the Apache projects that emerged from Incubation, and stayed out of the Attic. > I also don't think working on Apache OpenOffice is much of a resume builder, What builds resumes is the specific contributions one makes. The specific project, be it AOo, No Man's Sky, BLEACHER, or anything else, is irrelevant. >since there is no other project like it and probably will never be. At least four other office suites utilize code from AOo. There are at least a thousand office suites for Android, and iOS, for which AOo development is a useful starting point. > If my appraisal is sound, that leaves us with the question about > sustainability of the Apache OpenOffice project itself, Go back to the revenue generation model. Back in the 2003-2005 time frame, there were several organizations licensing their rebranded version of OOo for between US$20 and US$5,000 per seat, per year. For various reasons, I quit tracking that data, and thus don't know what the current situation is. A decade ago, it was fairly difficult to find worksites of more than 1,000 that used OOo. Today, worksites of more than 5,000 users, using an OOo derivative, are not not that scarce. Somebody is providing tech support for those worksites. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Independent Entity to Develop and Further AOO
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 Ap
Re: Independent Entity to Develop and Further AOO
Sorry, incorrect mailing list, so repetition: Hello, > From: Suminda Dharmasena [mailto:sirinath19...@gmail.com] > This is exactly what I had in mind also. Ok, but: then (imho), this has nothing to do with Apache, and need not be discussed here, because that is the normal open source way. And let me say, for clarity: I meant in my post something different (because http://www.prooo-box.org is already a form of "TeamX"). Greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
This is exactly what I had in mind also. > > 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 > >
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
Re: Independent Entity to Develop and Further AOO
Hello, > From: Suminda Dharmasena [mailto:sirinath19...@gmail.com] > 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 you're right, but I fear that the general rules of Apache do not allow. Let me describe the practice: a problem is the inability to be able to donate directly to a particular Apache project. In the German OpenOffice community so we have activities besides the official project develop to be able to act. One example is http://www.prooo-box.org, because that is formally an entirely independent project, but we would rather were part of AOO. These things concern matters which are only central to clarify with Apache because OpenOffice is part of Apache and can not act alone, but must take into account the will of all Apache members, so all Apache projects. I'd want the very act could the local communities AOO independent, but that they can not do unilaterally, but only with the consent of all Apache members. I think we should look for solutions for this purpose, because they are for AOO equally important as good programmers. Example: Money is not the only issue, but donations are an important issue. imho it would, for example, very helpful if the local (national) communities (for example, en, de, it, it, ) could collect even donations. I can very well imagine that an integral part of these donations would then be forwarded to Apache, but over the rest of the local communities must be able to freely dispose. The specific problem is that we as could accumulate in Germany every year many thousands of euros for OpenOffice, but at the same time hardly anyone has interest in Apache generally to donate. The result of the overall situation is therefore unfortunately we practice (in Germany) have no donations for OpenOffice, nor donations for Apache. This vicious circle needs to be broken. Greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Every remaining dev / concerned user must get together a take an initiative. Things rarely workout on their own. On 11 July 2016 at 13:11, JZA wrote: > Sounds good, there have been some intention of these in the past, not sure > how open the community is right now to be honest. But is a good idea if > somehow there is some strong backing. > > On Mon, Jul 11, 2016 at 2:23 AM, Suminda Dharmasena < > sirinath19...@gmail.com > > wrote: > > > 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 > > > > > > -- > Alexandro Colorado > Apache OpenOffice Contributor > 9060 55AB FFD2 2F02 0E1A 3409 599C 14FC 9450 D3CF >
Re: Independent Entity to Develop and Further AOO
Sounds good, there have been some intention of these in the past, not sure how open the community is right now to be honest. But is a good idea if somehow there is some strong backing. On Mon, Jul 11, 2016 at 2:23 AM, Suminda Dharmasena wrote: > 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 > -- Alexandro Colorado Apache OpenOffice Contributor 9060 55AB FFD2 2F02 0E1A 3409 599C 14FC 9450 D3CF