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
