Key Points
- Proposal calls for a National Public Software Exchange to help ministries reuse publicly funded code
- Exchange would list documentation, licence terms, maintenance contacts and adaptation costs
- Pilot programme recommended involving a ministry, state department and research organisation
Suppose a Union ministry commissions a portal for applications under a public scheme. Later, a state department needs to track applications of its own. The rules and forms may differ, but both systems may need the same basic functions: receiving documents, showing applicants what happens next, routing files to officials and keeping an audit trail. If the first system’s code and documentation are hard to find or reuse, the second team may pay to build those parts again.
India needs a practical way for public institutions to learn from software projects already paid for. A National Public Software Exchange could help ministries, government departments, universities and public research organisations discover systems, assess whether they fit and find people who can adapt or support them. It should operate as a service for reuse, not simply as a website where code is uploaded and left unexplained.
The opportunity extends across government. A ministry running a grant programme may need to receive proposals and track reviews. A state department may need to handle licences, inspections or public complaints. A district office may need to route applications and tell citizens where a case stands. These processes are not identical, and an exchange should not prescribe one system for every office. It can, however, make useful components and the lessons behind them easier to locate.
What an Exchange Should Provide
For an institution looking for software, a code repository is only the beginning. It needs to know what the system does, which process it supports, what technology it depends on, which version is maintained, what it costs to install and adapt, and who can answer questions. Listings should include usable documentation, licence terms, accessibility and language information, integration requirements and the limits of any security review. Without those details, a catalogue can be large and still leave a department unable to make a decision.
Open source should mean that, where rights permit, an adopting institution can inspect, use, modify and share the source code under a clear licence. A useful listing should provide the code along with installation and deployment instructions, dependencies, data models and APIs, version history, test information, known limitations and a maintainer contact. A code dump without this context is difficult to assess or reuse. If a system cannot be released in full, the exchange should explain what can be shared and why.
Institutions should be able to pursue two routes. Where software is openly licensed, they can access the code, adapt it and build on it under the licence terms; access may be free or subject to a nominal, clearly disclosed fee. Where they need specialist help, or the software cannot be shared openly, the exchange could connect them with the originating institution or development team for adaptation, installation, training or maintenance, for a modest and transparent licence or service fee. Listings should explain what the fee covers, any recurring costs, the support period and the adopter’s rights to use and maintain the resulting system.
Both routes can help institutions avoid rebuilding useful software from scratch. Their value should be assessed against the full lifecycle cost, including adaptation, integration, hosting, security, training, support and maintenance. Fees and contracts should be clear, and procurement terms should preserve appropriate public rights in publicly funded work. This matters to government departments, universities and laboratories that need dependable software but may not have the time or budget to duplicate every development effort.
From Problem to Solution
The exchange should also help institutions describe the problem before they commission a solution. “Build a portal” is not a useful specification. A department needs to set out who will use the service, what steps they follow, what decisions officials must record and what information an applicant should receive. With that brief in hand, a technical team can check whether an existing system is suitable, identify the parts that need changing and define how the finished work will be tested.
Different rules across ministries and states make adaptation essential. A system used by one department may need new approval stages elsewhere. Forms may need translation; a service may have to work on a slow connection or with assistive technology. The exchange should make these requirements visible so that institutions can budget for them before adopting a system. Reuse should reduce avoidable work, while leaving each government body responsible for its own process.
Public software also needs clear rules about ownership and data. A project paid for by the government is not automatically free to redistribute: contracts may assign rights to a supplier, and software may contain components with separate licence conditions. New procurement contracts can specify, where appropriate, the government’s rights to retain, modify and share the code. Before any system is listed, its owner should confirm what can be shared and under which licence.
Sharing code does not require ministries or departments to pool personal or confidential records. Each institution should keep control of its data, user access and operating decisions. Security checks should reflect what the system does and the sensitivity of the information it handles. The listing should explain what was tested and what was not; an adopting department would still need to assess the software in its own environment and keep it updated.
Maintenance and Research Applications
Maintenance must be planned along with development. Every listed system should identify the supported version, its maintainer, available installation and update instructions and the period for which support is expected. The budget should cover training, integration, migration and ongoing fixes, not only the first release. Universities and student teams can contribute, but an essential public service should not depend on a student project or on a single developer who may leave.
The exchange should include research software as well as administrative applications. Public laboratories and universities use software to operate instruments, manage shared facilities and analyse data. Such tools may need to work with particular equipment or produce results that other researchers can reproduce. Researchers and technical specialists should help assess them, while the same exchange can connect institutions with teams able to adapt or maintain the code.
A careful pilot would show whether the idea works. A ministry, a state department and a public research organisation could each bring a real software need. The pilot should document which existing tools were useful, the cost of adapting and supporting them, how long adoption took and where reuse failed. Those results would help set standards for future listings and procurement. The number of projects in the catalogue would be a poor measure of success; the useful question is whether another institution can put a listed system to work and keep it running.
Public institutions will still need to commission new software. But each new project can leave behind more than a one-off service if the rights, documentation and maintenance plan allow others to build on it. A National Public Software Exchange would give ministries and departments a place to find that work, judge its limits and adapt what fits. Public investment would then be easier to carry forward from one institution to the next.
The author is Chief Operating Officer and National Coordinator of I-STEM, under the Office of the Principal Scientific Adviser to the Government of India. Views are personal.
