Kim Rader

What if the answer to the open source software maintenance problem is not just money? The Rust Foundation Maintainers Fund, announced earlier this month, is a great initiative, but funding is only part of the answer. For sub-infrastructure projects where there are few direct users, and for functionally mature projects, recruiting and retaining maintainers has additional challenges. I got interested in the problem of maintaining small, mature library projects because of XML, particularly libxml2. After a little digging around, I discovered that it’s not just libxml2, it’s not even just the C and C++ XML projects, a lot of XML libraries have few or no maintainers. XML libraries were an exciting area to work in 26 or 28 years ago, when libxml2 and libexpat were released. What felt like the future then feels very much like the past now. In the present, XML is still very much with us, and written into a whole lot of standards. SQL/XML is part of the SQL:2003 standard, and various financial reporting standards specify XML schemas. This is software which still needs to be maintained, and its maintenance is currently precarious. What’s to be done? Ideally a project would have multiple maintainers. For a project that’s “done” feature-wise, the maintainer role generally won’t take a lot of time. The ideal next maintainer of a project is someone who uses it. This has played out in the succession of maintainers on some Rust XML libraries, where active users in the project took over. So if I was creating an XML library today and wanted it to stay maintained long term, the ideal collaborators would be people who build stuff with XML and can find a bit of time here and there. Companies can support the important but unloved bits of open source through giving engineers time to engage upstream. With this idea in mind, I set off to stir the pot. Because the issues with lbxml2 affect Postgres, Percona gave me some space to explore. The financial services industry and its regulators use a lot of XML through data exchange and reporting standards. In FINOS, there’s a community of world’s largest financial services companies, collaborating on a wide range of open-source projects. So I pitched my idea to FINOS and found some collaborators. The InterchangeKit project in FINOS labs was born. This is where you, dear reader, get involved. We need more collaborators. If you build applications on top of any of the C / C++ XML libraries like libxml2, libexpat, Xerces C++ and would like to get involved in building a memory-safe alternative, please get in touch. Add the list of functions you use to the catalog in the repository at https://lnkd.in/eg2ydksQ , so we can figure out what to build first. Read the FAQs and ask some questions, so it can begin to stand for “Frequently Asked”. IT Brief UK have have more on this at https://lnkd.in/e3hR-ubx

28

1 Comment