User:Gurukasi/sandbox

Software not value neutral
Software has often been seen as a value neutral 'technology' issue and its procurement akin to that of purchasing furniture or such office or infrastructural item. However we are living in an increasingly digital world and the role of software, which is at the core of new ICTs, is becoming critical in our lives. Whether it is in using search engines, accessing public services over the internet or through tele-centers, communicating with colleagues and friends, participating in virtual professional and social networks, banking, use of the net for by political parties and NGOs for campaigns; computers and the internet have become critical to our lives. Software is thus a basic building block of our increasingly digital world and its nature has important implications for public interest. Its procurement thus has important implications far beyond that of procuring office equipment etc and hence it cannot be treated as being 'value neutral'.

Public Sector ethos
In the case of the public sector, which has clear principles that underlie its own work, the choice of software needs to be aligned with these principles. Public Sector guiding principles include:

1. Working towards ensuring universal access to basic facilities and resources such as public education, public health provisions, employment nets etc, to address structural issues of poverty, illiteracy,  malnutrition / ill health, unemployment etc. With the goal of providing access to water resources, governments design policies and programs to create and maintain with public funding, public water bodies. Likewise governments set up schools and primary health centres across geographies, and especially in remote areas and especially to marginalized groups in the interest of social justice and equity. In these cases – water, health education services constitute 'public goods' which is essential to all but does not provide provide sufficient incentive for markets to provide1 and hence becomes a public sector responsibility to ensure universal provision.

2. Promote a culture of transparency, as well as public participation in its working, with accountability for its work and decisions to larger society. Structures such as Community water user groups or School Development Committees, processes of social audits of government programs or the increasing use of RTI is a characteristic of participation and transparency needs of public systems. Public Sector Principles2 and implications for software architecture 5. ICTs are also beginning to play an important role in the information and communication processes within governance systems, and e- governance is acknowledged as having the potential to transform governance through greater transparency, accountability and participation.

Software developed for public service, and especially in government, has a unique context and objectives deriving from those of public service; with its imperative of providing public goods and ensuring equity and social justice. It is well known that private and commercial actions have very different context, motives and considerations than public actions. For instance, the largest possible reach and diffusion as well as transparency of actions are basic to public service, which are not necessarily values espoused by private and commercial players.

Generic issues faced in the public software arena
There has largely been a complete lack of distinction between the software needs of the private and public sectors, and the private sector software principles and methods have largely been adopted in the public sector as well, with its attendant drawbacks. In addition, the issues faced in attempting to implement public software include 1. Proliferation of proprietary software in some domains 2. Lack of readily available solutions conforming to public software requirements (also lack of awareness of existing applications that do) 3. Lack of adequate commitment to Open Source solutions 4. There is no common database on Public Softwares and also there is often a lack of willingness to share public software applications and content. There are few or no mechanisms for providing suggestions for software improvement / updation 5. Lack of support and maintenance infrastructure in the public sector arena 6. Testing, Maintenance and support (maintenance) aspects are traditionally neglected in the public sector and in the case of software, which continuously evolves to meet current and future requirements, treating a software as available in its current state for posterity (as furniture would) can create huge difficulties. 7. The private sector technology companies largely promote licensed and priced softwares 8. Public sector software requirements need to cater to often complex and dynamic socio-political-economic contexts and the software application cycle needs to cater to this complexity. The domain expertise of the public sector is often not recognized or catered to in applications developed for the private sector 9. Software developing agencies do not adhere to established standards

Based on these underlying principles of Public sector and their implications for Public Software, a set of principles that can guide decision makers in the procurement, development and use of Public Software, and which can help address some of the identified challenges can be drawn up covering following areas

Guidelines for public software
Ownership and sharing (nature of social contract) 8. Anything developed using public money should be available widely to everyone for furthering wider public interest. This is even truer of digital products where the marginal cost of replication is nearly zero. It is also important that all such digital products – software, applications and content – are widely available to citizens to use – including through modifying – for various useful societal purposes.

If the source code is owned by a private vendor, dependence on this vendor for support and maintenance can be both expensive and dangerous. This 'vendor lock-in' can create dangerous dependencies of public system on a private vendor. If the vendor keeps increasing the price of the software and associated services, the public system will have little option but to pay. Switching to a new system would impose huge and duplicate costs. If the vendor shuts shop, the application will run the risk of becoming non-operational, since software is usually perennially in need of being upgraded, either to fix defects or to add new functionality arising from new requirements and new environments.

This means that the source code for any software used by the government cannot be proprietary. In case of desktop/client software, this guideline is easy to follow, since there are several client based software applications for operating system, document processing, video/image editing etc that can be used by the public sector. Already many states in India are preferring public software applications on the desktops and this needs to be mandated by policy.

In case of larger applications which require back-end application development, it is important that the software be purchased outright at the time of its development by the vendor. In most cases, the person making the RFP does not specify the ownership of the application and there is a danger that though public monies are paid to the vendor, the ownership remains with the private vendor. This means that the public sector entity does not have the right to make changes or corrections to the applications3

There may be cases where the software on an outright purchase basis may seem too expensive. In most cases such applications are likely to be usable across many state governments. In such a case a larger contract with multiple states can be considered, in which the application can be multi-lingual interface to begin with.

To this end, it must therefore be ensured that: 1. The public agency commissioning a software take up complete ownership with full rights on it. This ownership should be real and not merely nominal providing the concerned public agency with full ability to share and modify the software as required. 2. These rights should be shared with public to enable further development of software and applications for different societal uses, including through collaborative work.

Specific operational issues
1. There needs be an agency, which could be part of the state eGovernance department or DPAR if there is no eGovernance department at the state level and at the central government level, which needs to take custody of the software developed and plan for its maintenance, either in-house or through vendors. This will create 'internal ownership' of the application and help create 'substantial ownership' and not just 'token ownership'. 2. The code should be made available on a GPL kind of licensing which permits software enterprises to be able to modify and enhance the applications and release it again under GPL, which would further public welfare. This will also allow the government department having custody of the application to work with a number of FOSS enterprises to maintain and enhance the application. 3. In exceptional cases, when proprietary application (closed code, royalty based) is required to be procurred, the bid process should provide clear and adequate justification for the same and this would also need to be verified as a part of the audit checklist/processes.

Ensuring highest public interest and realization of citizen's right (purpose)
Public or governance software and applications are nothing but a new set of governance processes and systems. These should be developed with general larger canons of public service in mind, as they serve specific purposes of imperative and action etc of a particular agency developing the software of application. Very often new digital possibilities enable higher realization of public interest and citizen's rights than was possible in pre-digital processes. This is especially true with regard to transparency, accountability and monitoring of governance processes and active ongoing participation, including through co-creation and collaboration. It is important that all software and applications specifically take note of these imperatives of governance reform in India and include all possible features that enable them. There should a clear process of ensuring that all such new possibilities are incorporated in any software and application that is developed as one of its central design principles, and any exception is duly noted with clear reasons thereof.

Universal access to government services requires universal access to software required to access those services, specially as more and more such services would be provided through digital processes.

The concept of social audit of government programs/processes is seen as a critical component of transparency and is already being implemented things like socio-political pre-audit, inviting comments from the community etc. Such processes of social audit are required to be part of public software design and development, to ensure that requirements of transparency, accountability and participation are catered to the maximum extent in the design, development and implementation

Specific operational issues
18. Typically, governments invite comments/participation of the public in any new measures they undertake, which can be in terms of accepting written representations, public hearings etc. In case of software applications (which in a sense implements government policy), too, such public processes are required to ensure that the requirements of the community are also catered to in the design. This will help applications to not just incorporate 'Management Information System' but also 'Public Information System' or 'Janatha Information System'. Such public processes must be a part of the user requirement phase and documented in an appropriate manner. In addition, representatives of the public should be invited to beta test applications to ensure that important community needs have been incorporated.