Thanks for sharing your journey and process with us Roger. I hope this will give users out there a better understanding of how we got here.
Gary On Wed, Oct 19, 2022, 17:03 Roger Leigh <rle...@codelibre.net> wrote: > Hi Scott, > > > > > > We can all “hope” for maintenance but ultimately someone needs to commit > to doing the work. That needs paying for, be it in time donated or money > to pay for someone else to do it. In my previous job I maintained an > application which was critically dependent upon Xerces-C/Xalan-C, and when > we found deficiencies and faults in it, in particular portability defects, > my employer graciously permitted me to work on both codebases and provide > the necessary fixes, including signing off the Corporate CLA. So the cost > for me to contribute to these projects was ultimately paid for by my > employer, because it benefitted them to have supported libraries that > worked on all of the platforms and compiler versions we cared about, plus > any needed security fixes being applied. After leaving that position, I > continued to contribute, but at this point in time I’m no longer actively > involved in working on codebases which use either Xerces-C or Xalan-C, and > in fact I was contracted to replace their use with other libraries by one > of my end users (which is reflective of people’s concern over the risk of > using abandoned and unsupported libraries). So while altruism can go some > way, I’m afraid my time is limited and I work on other projects from which > I derive more benefit. I’m afraid to say that continuing to work on both > projects costs me a great deal of time, for which I derive zero personal > benefit, which is why it is time for me to cease participating in these > projects and to work on others. > > > > None of this is “right” or “wrong”, it’s just the reality of where the > project is at this point in its life. All software projects have a > lifecycle, a beginning when they are actively developed, a plateau during > which they are maintained and stable and an end when they are wound down. > Xalan-C is at the end. Xerces-C isn’t far behind. > > > > One of the reasons for moving Xalan-C to the Attic is to make the true > maintenance status of the project abundantly clear to everyone using it and > distributing it. Including provoking discussions such as this one—it’s > important that everyone understands the consequences of the change in > status (even if that status is what was effectively the status quo for the > best part of a decade). If the result of the discussion is that we end up > with some new maintainers who make a genuine commitment to carrying the > project forward, then I would be more than happy. If there are businesses > or individuals who are dependent upon it for the continuation of their > products and business continuity, then perhaps this discussion will prompt > some consideration of whether or not they need to contribute actively to > keep the project going. > > > > However, while it would be nice to hope for such actions, I’m afraid as I > said in my original email on the subject, that overall interest in XML and > XSLT is waning, and there is much less demand for libraries and tools for > performing XSLT transforms. So the lack of interest in Xalan is not > unique. It also applies to libxslt, and it also applies to QtXmlPatterns. > Look at > https://gitlab.gnome.org/GNOME/libxslt/-/merge_requests?scope=all&state=merged > to see how active libxslt is—it’s primarily sporadic churn to fix the CI > and some minor portability issues and one or two bugfixes; there’s no > actual development going on there either. Basically what I was doing with > Xalan-C for the 1.12 release. QtXmlPatterns has been dropped entirely. To > be frank, if a company really needs to use XSLT, then paying for Saxon is > probably the best choice—you’ll be paying for having a library which is > actually maintained and which also has the best XSLT support of all of the > XSLT libraries available. If you are basing your business on this, then > there isn’t really much of a choice to make here, the answer is obvious. > > > > I’m not sure I really buy the point about the cathedral and the bazaar. > Xerces-C and Xalan-C benefitted from huge contributions from corporations, > IBM in particular. I could be wrong (I came in much later), but it looks > like the vast majority of all of the development of these projects was done > by developers working for IBM. I’m not sure that the projects ever had > many significant contributions outside this effort from independent > individual contributors for anything more substantial than small fixes. > Individual volunteers generally want to work on interesting and fun stuff. > Working on Xerces-C and Xalan-C has been little more than hour after hour > of boring maintenance work. Hundreds of man-hours keeping the CI going, > testing the build system on multiple platforms, debugging and testing, > reviewing, testing and applying patches applied to the various Linux and > other distributions, plus GitHub PRs. Necessary, but not particularly fun > or rewarding, and extremely time consuming. But the project needs someone > to be doing this on an ongoing basis as a basic prerequisite to be able to > test changes and make releases, and generally provide the basic > infrastructure one would expect from a healthy and active project as a > viable ongoing concern. > > > > There’s a limit to what an individual can do. I used to work a full-time > job and then spend another 6-8 hours every day writing free software and > being a Debian developer, with a lot of unwritten obligations to satisfy. > That worked until I hit my 30s and I ended up with crippling RSI and > massively burnt out. Today in my 40s I work my day job and tinker with > some free software stuff on the side. Making a commitment to work on a > project like Xalan-C or Xerces-C brings with it ongoing obligations to do a > lot of work on an ongoing basis and in a timely manner. I can’t continue > to do that. Everyone using Xalan-C today has benefitted from the work I’ve > done, without needing to contribute anything back. If users of Xalan-C > want the project to continue, then they will need to step up to do all this > stuff themselves. > > > > > > Regards, > > Roger > > > > *From:* Scott Furry <scott.wl.fu...@gmail.com> > *Sent:* 19 October 2022 08:13 > *To:* c-users@xalan.apache.org; d...@xalan.apache.org > *Subject:* Re: [VOTE] Moving Xalan-C to the Attic > > > > I'm only an occasional user of Xerces-C/Xalan-C libraries but retirement > seems wrong to me. Understandable. Lamentable. Still wrong. > > Reading the suggestion of placing Xalan-C into 'the attic', I dove online > to plan a migration strategy should it become necessary. I was not pleased > with what I found: > - Saxon has a `community edition` but is only interested in selling > licenses. > - Folks over at libxml2/libxslt go to great lengths to stipulate that > Gnome is not required - but library has its 'C' quirks. C++ wrappers of > various type and quality abound. > > The previous move by Oracle to 'abandoned' the Netbeans IDE to the Apache > Foundation was not pleasant for me. After seven release iterations the IDE > still doesn't have a decent C/C++ setup comparable to the Netbeans 8.2 > plugin. Everyone in the Apache Netbeans project seems focused on Java. I > have an overall negative impression of Apache projects as a result. > > I can appreciate that few have the time and resources to commit to > maintain code. We've gone from "The Cathedral and The Bazaar" to silos > ("Big Box Stores") of companies - Ubuntu, Gnome, Red Hat, et al. The notion > of the dedicated developer toiling away doing incredible work in obscurity > is becoming quaint. XKCD pretty much nailed it with the 'Dependency' comic ( > https://xkcd.com/2347/). > > Given the long history of the Xerces-C/Xalan-C, as well as few decent > compatible replacements, I would hope the code could be maintained in the > future. > > >
