Hi Svante, I think that it is time for the ODF Toolkit to move on. This is not looking like an Apache project as no community has been present for the several years since IBM dropped out.
I think your efforts are great and with the sponsorship you are getting you can continue however you think best. If becoming a project within the TDF is the result there are no concerns. On retirement the Apache svn and GitHub repositories will go read only and you can continue from your fork. We can also workout the transfer of odftoolkit.org <http://odftoolkit.org/> in any way that is proposed. If at a later time a community forms around the code that is diverse then the project could be proposed for Incubation again. Regards, Dave > On Oct 2, 2018, at 8:21 AM, Svante Schubert <[email protected]> wrote: > > Dear all, > > In one thing I have to agree with Dave. Some wake-up was required and I > believe at least I heard it. > Independent, how the Apache Foundation board will decide, if they allow the > continuation of our project, one thing became clear to me: we need some > replacement for Sun/Oracle and IBM our initial main contributors, who left > us. > It seems certain to me that this project needs companies to provide > full-time developers and the financial capacities to make larger steps in > moving forward. > > Therefore, I have put more efforts in the advertisement of new business > features of the ODFDOM module from the ODF Toolkit, especially in an > office collaboration prototype: > https://github.com/svanteschubert/odftoolkit/blob/odf-changes/README.md > The reason for this feature and its high-level technical overview were > explained earlier on this list > <https://lists.apache.org/thread.html/ed1cec77f998bc9f6136b9da792d48b6778cfe4d38556aa6360448d8@%3Codf-dev.incubator.apache.org%3E> > . > In addition, I gave a presentation last week at the LibreOffice conference > in Tirana (linked from above), which had the main purpose to me to distil > the ideas of the past years and cover all the basics of collaboration by > easy pictures in case a bus might hit me ;-) > > In the next weeks, I will continue working on the change feature. Its > documentation, further refactoring and if I get some assistance on > performance tests <https://issues.apache.org/jira/browse/ODFTOOLKIT-479>, > might be able to merge the project into our main trunk. > With this feature, existing web based editors could become quite easily an > ODF application, when exchanging user changes to the new ODFDOM module - > see LibreOffice presentation for further details (PDF 1.4MB) > <https://github.com/svanteschubert/odftoolkit/blob/odf-changes/LibOCon2018%20%20-%20Interoperable%20Office%20Collaboration.pdf> > . > In the upcoming winter, I am again sponsored by the PrototypeFund > <https://prototypefund.de> and aim to work on the improvement of the source > code generator of the ODF Toolkit. > Today, was the first larger patch resulting from that funding: > https://issues.apache.org/jira/browse/ODFTOOLKIT-478 > > I have updated today our podling report, see > https://wiki.apache.org/incubator/October2018 and I am curious how this > works out. > Be reassured, The Document Foundation (TDF) LibreOffice does see value in > the Toolkit as you already may see by their provided online validator: > https://odfvalidator.org/ > We would receive the required infrastructure at the TDF if we require it. > > What worries me a bit is our Apache website. The site seems to be based on > a proprietary CMS from Apache, which is interleaved with Subversion and > using proprietary Pearl scripts to create a single HTML page from multiple > MarkDown files and keeping references across pages up-to-date. If all went > south, we likely need to continue to work on HTML, solely. > > Finally, to be honest I am unhappy with the existence of Simple API. It was > once a fork from IBM, which was once also contributed to Apache along with > the donations of Oracle. Unfortunately, a fork is far easier than a merge. > Therefore my aim is to improve source code generation in ODFDOM and get an > alternative to the Simple API, dropping redundancy and boilerplate. > > What do you think? > > Cheers, > Svante > > PS: Tomorrow is a German public holiday and it is quite likely that I will > not be able to respond to an email before Thursday, likely Friday. > ᐧ
