Contributing a modern frontend and ERPNext integration to improve UniTime adoption

[consultifyit]

Hi UniTime community,

I'm reaching out on behalf of ConsultifyIT Technology Services, a technology consultancy based in India. We recently began working with an Indian government university as a pro bono pilot to help digitalize their academic operations — covering class scheduling, exam management, faculty workload tracking, and compliance reporting for NAAC accreditation.

During our evaluation of scheduling tools, UniTime stood out as clearly the strongest open source solution available. The constraint solver is genuinely world-class, and seeing institutions from Purdue to University of Nairobi running it in production gave us confidence it could serve our context well.

That said, like many in the community, we found the current UI a significant barrier — particularly for non-technical administrative staff in institutions where digital adoption is still early. Rather than building something in isolation and walking away, we'd like to contribute a modern frontend back upstream so the entire global community benefits.

As a consultancy working across higher education in India and the broader Global South, we see a large unmet need: hundreds of government universities that lack the budget for commercial scheduling tools but have the infrastructure to self-host something like UniTime — if only the setup and day-to-day use were more accessible.

We're proposing to contribute the following:

1. A modern React-based UI — covering timetable building, drag-and-drop scheduling, real-time conflict detection, faculty workload views, and exam hall allocation, all talking to UniTime's existing APIs
2. REST API extensions — filling gaps where operations currently require XML import rather than direct API calls, submitted as PRs to the core repo
3. An ERPNext integration connector — ERPNext is the most widely deployed open source ERP across Indian and African universities; a documented, maintained connector would significantly lower the barrier to UniTime adoption in these regions
4. Internationalization groundwork — UI scaffolding for multilingual support, starting with Hindi, to support non-English-speaking institutions
5. Deployment documentation — a practical setup guide specifically for institutions in India and similar contexts, covering ERPNext integration, government compliance requirements, and low-resource server environments

Before writing any code, we wanted to ask the core team directly:

• Is there active work on any of these areas we should be aware of or join?
• Which contributions would be most valuable to the project right now?
• What is the preferred contribution path — PRs to the main repo, or a maintained companion package?
• Are there architectural decisions or constraints we should understand before starting?

We are using Claude (Anthropic's AI assistant) as a development accelerator — particularly for navigating the existing Java codebase, designing API extensions, and accelerating frontend development. We're transparent about this because we believe it's relevant context for how quickly we can move and the quality of output we can sustain.

Our commitment is long-term. This is not a short engagement — we're invested in the pilot university's success, and that means being invested in UniTime's success. We'd rather do this properly in collaboration with the core team than ship something that doesn't get merged.

Thank you for two decades of work on this project. UniTime is genuinely serving institutions that couldn't otherwise afford robust scheduling infrastructure, and we'd be proud to contribute to that mission.

Warm regards,
ConsultifyIT Technology Services
Hyderabad, India
https://github.com/consultifyit | www.consultifyit.com

[tomas-muller]

Hello,

Thank you for your interest in the UnITime project and for being upfront about your intentions.

While a more modern UI could be beneficial, I don't believe this is the barrier to adopting UniTime. The complexity of the timetabling process is. Every institution is different and may have different needs, constraints, and timetabling processes. Creating a tool that can be used by universities around the world, both large and small, and including all sorts of possible exceptions, has led us to a fairly complex data model that may seem overwhelming at first, especially for someone not familiar with the timetabling process and its related requirements. So, yes, there is a significant learning curve, further amplified by the fact that most data needs to be entered or imported for the first timetabling cycle. Later on, the process becomes easier, as much of the data can be reused from one semester to the next.

That said, I would prioritize the ERPNext integration, providing translations into Hindi and institution/region-specific setup guides and tutorials, over implementing a new user interface, at least until you build up enough expertise to understand the UniTime data model, inner workings, and the reasoning behind the current user interface (e.g., there are multiple reasons why we have chosen to implement a solver-supported Suggestions instead of a simple drag-and-drop).

As for your questions:

Is there active work on any of these areas we should be aware of or join?

We are currently working to replace the remaining Struts-based pages with GWT and using the command pattern for accessing the server. While GWT may not seem modern enough to some, it has worked well for us, allowing us to support different browsers with most of the code written in Java. This also allows for modern (or custom) versions of our pages to be developed in the future, as they can rely on the same backend calls, e.g., using our JSON RPC API.

See help.unitime.org/localization for more details about translations of UniTime to Hindi.

Which contributions would be most valuable to the project right now?

Integration and documentation, perhaps. I am not familiar with ERPNext. For an institutional-specific integration, UniTime's scripting capabilities (see the Scripts page) are often used. These can also be called programmatically using our Scripts API.

What is the preferred contribution path — PRs to the main repo, or a maintained companion package?

This would depend on the changes and their applicability to a wider audience. A companion package with only the necessary changes to the core UniTime project (e.g., new interface classes) is likely the best option for integrating with a specific student information system or even for a new UI, especially if it covers only a subset of the existing functionality. For example, please see the unitime-addons project, which we maintain for the integrations with Ellucian Banner and Ellucian Colleague.

That said, due to unresolved legal issues surrounding the use of AI-generated code in open source, especially regarding authorship and attribution, we currently do not accept AI-generated code in our codebase. At least for now.

Are there architectural decisions or constraints we should understand before starting?

Our model reflects 25+ years of experience with university timetabling, so UniTime can be used in many scenarios at institutions of higher education worldwide. We have always strived to use proven technologies that have the potential to stay around for some time, and our goal is to develop code that can be maintained by a small team, despite its complexity.