Whilst I tend to agree with Dave, it would be a shame to kick the ODF Toolkit out without some thinking. One thought I did have was would it be possible to migrate ODF Toolkit from Incubator to Labs to keep the development going but also lessen the burden on the incubator?
On 11 September 2018 at 10:50:04, Svante Schubert (svante.schub...@gmail.com) wrote: Hello Dave, Everyone! A natural place to move this project is TDF (The Document Foundation) <https://www.documentfoundation.org/>. Both LibreOffice and OpenOffice are of course heavy users of the ODF file format and in need of tools and validators. There should be no problem to move to TDF and let them take over the domain. A more interesting question IMO would be, what progress does this project have to make and what costs do we generate to Apache and/or can we lower them? Allow me to draft some viable future for our project: What we can be certain is, that there does not exist any interoperable office document collaboration in the world so far and people are longing for it. Office 365 & Google Docs are closed source and breaking often the structure of business office documents, e.g. EU funding application templates. Therefore, I have created a prototype for the Toolkit enabled for Collaboration <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>, which was sponsored by PrototypeFund <https://prototypefund.de/project/documents-for-democracy/> / German Ministry of Research <https://www.bmbf.de/de/software-sprint-freie-programmierer-unterstuetzen-3512.html> last winter. Why is this important? Because sending office documents by email / Dropbox / etc. for collaboration is as clever as if software developer would zip their source code repositories and sending these via email / Dropbox / etc. The major question you ask your coworkers to be able to merge their changes back is: What have you changed? For this reason, this prototype module is switching the paradigm from the document file format (full state) to an equivalent list of user changes (creating in sum the same full state). This Toolkit prototype on collaboration <https://github.com/svanteschubert/odftoolkit/tree/odf-changes> transforms any OpenDocument Text into an equivalent sequence of user changes (in JSON - see attachments) and in addition, is able to apply any new user change (similar in JSON) to the document by merging the change into it. By doing so, the module is taking away the complexity of knowledge about the ODF documents and is a perfect fit as a back-end when office documents entering the realm of a business domain. Why am I telling you this? As I am confident that we need more than a group of individuals that work on this project in their spare time. We need companies, which consider this toolkit as a backbone of their business case. To make it more obvious to managers (and to the Apache board members) to believe in the importance of this project, I am working on a showcase where we attach an existing open-source web editor as front-end, where we could view and edit ODT documents. For this reason, I have been travelling recently to Warschau and visited CKSource <https://cksource.com/> to investigate if the "Toolkit Collaboration prototype <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>" could be attached to their new flagship CKEdit5 <https://ckeditor.com/ckeditor-5/> based on operations & changes <https://github.com/ckeditor/ckeditor5-engine/tree/master/src/model/operation> . You know, in extreme even a Microsoft Office (MSO) user could collaborate with a user using VI text editor by exchanging user changes. While the MSO user would see and edit the full-featured document, the VI user would only see and edit text and paragraphs (the latter emulated as lines). Still, all VI text & paragraph edits could be merged back into the original document using Operational Transformation (OT) <http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation>. If this works for VI, it will work for CKEdit5 for sure and using a web-based editor embeddable into any web page is far more attractive to the masses than VI - please, no discussions on this assumption ;-) End of the month, on the 26th of September I will be in Tirana (Albania) and give a talk about Interoperable Document Collaboration <https://libocon.org/2018/the-program/sept-26th-wednesday/> and hopefully, I have the front-end running by then. I will keep you informed... In the end, we would like to provide a setup-up using an open office application that allows receiving "pull requests" consisting of changes only from other users. For instance useable when a famous author publishes his book read-only and some readers provide feedback by those "pull requests", allowing the author to merge only the changes, neglecting the risk to loose or receiving compromised information by overtaking the full document. A wonderful obvious business case for lawyers... As you see, there's a ton of good stuff coming or in the queue, with a lot of potential for good press & new developers. >From where I stand, it would be a terrible moment to shut down. Sincerely, Svante ᐧ Am Mo., 10. Sep. 2018 um 21:42 Uhr schrieb Dave Fisher < dave2w...@comcast.net>: > Hi - > > It seems that the number of developers actively working on the ODF Toolkit > has never grown large enough to be sustainable as an Apache Top Level > Project. After nearly 7 years in the Incubator it is time for the ODF > Toolkit community to move on. > > I think retirement would consist of the following steps. > > (1) Decide if the project will move elsewhere - perhaps to its own GitHub > repository. > (2) Decide what entity or person should take over odftoolkit.org domain > name. > > Once those are decided then we can do a VOTE. > > Regards, > Dave > -- Spicule Limited is registered in England & Wales. Company Number: 09954122. Registered office: First Floor, Telecom House, 125-135 Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891. All engagements are subject to Spicule Terms and Conditions of Business. This email and its contents are intended solely for the individual to whom it is addressed and may contain information that is confidential, privileged or otherwise protected from disclosure, distributing or copying. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Spicule Limited. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this message in error, please notify us immediately by reply email before deleting it from your system. Service of legal notice cannot be effected on Spicule Limited by email.
