Since I joined the arXiv IT team as lead software architect in June, I’ve been working hard to pull back the proverbial curtain and take stock of how the sausage is made, and to synthesize the team’s aspirations and expertise for the arXiv Next Generation (arXiv-NG) project. We’ve done a considerable amount of research and soul-searching, and an architecture for NG has emerged.
The arXiv leadership team has explored a wide range of strategies for the NG process, ranging from greenfield redevelopment, evolutionary development, to adoption off-the-shelf (OTS) solutions. Recognizing the unique business processes surrounding the arXiv.org system, as well as the advanced state of the existing system (notwithstanding its limitations), and after careful review of possible OTS products in the e-print and repository space, we decided to pursue an incremental in-house re-development of the existing system. We’re calling that process Classic Renewal.
The existing arXiv system is highly stable, in that it provides a consistent set of core services with high availability. The codebase that supports that system has grown organically over a long period of time, with varying and sometimes unclear architectural visions. The technology on which arXiv is built is variously antiquated or (due to cultural changes) obscure. As a result, it is exceedingly expensive to develop the existing codebase to fix bugs, address feature requests, and keep pace with end-user expectations of quality, usability, and security. The principal challenge of the Classic Renewal process will be to progressively evolve arXiv into a modern and architecturally sound software system while maintaining the level of consistency and availability of the system as a whole.
Read the Complete Blog Post