4 ms·

At the time of the donation, The Document Foundation had an (understandably) antagonistic relationship with Oracle and legal foundations which were firming up b

by rectang 10y ago

At the time of the donation, The Document Foundation had an (understandably) antagonistic relationship with Oracle and legal foundations which were firming up but not yet solid. The assets were not going to TDF from Oracle directly. In accepting the proposal for a new Apache OpenOffice project, the ASF accepted not only the assets from Oracle but also a community, distinct from the LibreOffice community, that wanted to work with those assets. That community had to be given a chance. Without all those things, the deal could not have been completed.

ISV_Damocles 10y ago
What community? The only community around OpenOffice.org were the Sun/Oracle devs + the Go-OO devs getting it to work on Linux. The Go-OO devs forked it into LibreOffice and then Oracle shuttered their own work and reassigned their devs to other projects. Only a tiny handful of devs not part of Go-OO remained, and they had not been instrumental in actually maintaining the codebase as these other two groups had. There was no community around Apache OpenOffice.
- rectang 10y ago
  There were enough people on the "Initial Committers" list here to persuade the Apache Incubator PMC to adopt the project: http://wiki.apache.org/incubator/OpenOfficeProposal http://wiki.apache.org/incubator/OpenOfficeProposal Subsequently, there were enough people to vet and prepare multiple releases over the next couple years after that.
- davidgerard 10y ago
  In fact, Oracle didn't even have many committers on OOo at the time - they'd reassigned most of the StarDivision devs to the abortive CloudOffice. At the time of the fork, LO had more dev resources on the codebase than Oracle did.
arglwarg 10y ago
Even at the time of donation, LibreOffice had already gained a substantial set of the former Sun/Oracle developers: Stephan Bergmann (to Red Hat), Bjoern Michaelsen (to Canonical), Eike Rathke (to RedHat), Michael Stahl (to Red Hat). Together with other former Sun developers like e.g. Thorsten Behrens and Caolán McNamara, LibreOffice had more of the old Sun developers than Apache OpenOffice had at any point in time. Incidentally, they also made a lot of contributions that allowed LibreOffice to strife past other derivatives: like build system cleanup, static code analysis and fuzzing, bibisecting.

by rectang 10y ago

ISV_Damocles 10y ago

What community? The only community around OpenOffice.org were the Sun/Oracle devs + the Go-OO devs getting it to work on Linux. The Go-OO devs forked it into LibreOffice and then Oracle shuttered their own work and reassigned their devs to other projects. Only a tiny handful of devs not part of Go-OO remained, and they had not been instrumental in actually maintaining the codebase as these other two groups had. There was no community around Apache OpenOffice.

rectang 10y ago
There were enough people on the "Initial Committers" list here to persuade the Apache Incubator PMC to adopt the project: http://wiki.apache.org/incubator/OpenOfficeProposal http://wiki.apache.org/incubator/OpenOfficeProposal Subsequently, there were enough people to vet and prepare multiple releases over the next couple years after that.
davidgerard 10y ago
In fact, Oracle didn't even have many committers on OOo at the time - they'd reassigned most of the StarDivision devs to the abortive CloudOffice. At the time of the fork, LO had more dev resources on the codebase than Oracle did.

arglwarg 10y ago

Even at the time of donation, LibreOffice had already gained a substantial set of the former Sun/Oracle developers: Stephan Bergmann (to Red Hat), Bjoern Michaelsen (to Canonical), Eike Rathke (to RedHat), Michael Stahl (to Red Hat). Together with other former Sun developers like e.g. Thorsten Behrens and Caolán McNamara, LibreOffice had more of the old Sun developers than Apache OpenOffice had at any point in time. Incidentally, they also made a lot of contributions that allowed LibreOffice to strife past other derivatives: like build system cleanup, static code analysis and fuzzing, bibisecting.