Notes from discussion on "Policy on Adoption of OSS for Govt. of India"

At the first FOSS x Policy virtual reading group, we discussed the 2014 Govt. of India Policy on Adoption of OSS for Govt. of India. There were roughly 10 participants in the virtual call, and here are the notes from the call. I’m not attributing notes most of the notes, but the participants are free to respond in the thread if they want to. Please also note that this isn’t a thorough minute-by-minute play of the call, but instead summarizes conversations around the points of interest from the policy doc. We briefly touched upon Framework for Adoption of OSS in e-Governance Systems, but we weren’t able to discuss it meaningfully.

TL; DR

It was interesting that every participant found a different section of the policy document interesting. Some focused on the “6. How to comply” where others focused on “8.1 and 8.2 Implementation Mechanism”. One highlighted “9. Review of the Policy” while another focused on “8.4 and 8.5 Implementation Mechanism”. Some discussed what we could immediately do, e.g., file RTIs with respective agencies, dig up and analyze tenders, while others commented on what our approach should be, e.g., using a few large tenders that were won by Closed Source Software providers demonstrate the amount of money govt. could have been saved had they actually enforced the policy. It’s surprising that even in an 8-page document, there was such a difference in the lens with which people looked at the policy document.

Outline

We started the call by asking people to share their thoughts about the policy and what aspects of the policy they found interesting. It came up that more than a few people had already read the policy before this virtual call, but a few people on the call had read it for the first time before this reading group session.

9 Review of the Policy

GoI shall have the right to review the Policy as and when required.

Multiple times during the discussion, we talked about how the policy is more than 10 years old, and how we could update it, how we could understand how well the Govt. complied with the policy.

On the point of compliance with policy, we discussed at length the possibility of digging information out of publicly available tenders, RFPs (request for proposal), service providers that won the tenders, the price quoted by the winning service provider, and more. One of the participants alluded to a failed effort from many moons ago (Documenting Proprietary Software Tenders in Govt Services), but there seems to be growing interest in picking up this work now. Tender description, the Govt. department that put out the tender, who won the tender and the Point of Contact information is available publicly on the Govt. websites. We discussed how RTIs might be useful to seek information from Union and State Govt. Departments about the instances where the Govt. adhered to this policy, i.e., a service provider used OSS to build an e-Governance system. For instance, is mygov built using OSS or Closed-Source Software? What were the exceptions where Closed-Source Software was used instead of OSS? There was a brief discussion about whether such information is also available on GeM, with back and forth about whether GeM is appropriate for such tenders.

One of the participants also pointed out that State Govts might be interesting targets for such RTI requests. He personally knows of a State Govt. that is using Closed Source Software and we could point out the cost savings using similar projects at other State Govts. that rely on Open Source Software.

6 How to comply

All Government Organizations, while implementing e-Governance
applications and systems must include a specific requirement in Request
for Proposal (RFP) for all suppliers to consider OSS along with CSS
while responding. Suppliers shall provide justification for exclusion of
OSS in their response, as the case may be. Government Organizations
shall ensure compliance with this requirement and decide by comparing
both OSS and CSS options with respect to capability, strategic control,
scalability, security, life-time costs and support requirements.

One of the participants kicked off the discussion by highlighting how service providers seem to have ZERO incentive to adhere to the policy and provide services/products that are OSS instead of Closed-Source Software (CSS). After some discussion, we came back to this point to discuss what incentives a vendor has to provide services/products that are OSS-backed instead of Closed-source. One of the participants highlighted that the same incentives that drive a service provider for the private sector also drive a public sector service provider - access to source code, distributed code maintenance burden. We came back to understand what incentivizes a vendor to adhere to the FOSS principles/philosophy, what disincentivizes them against openwashing. Similarly, what disincentivized a vendor from providing closed-source software services that are primarily built on OSS, after getting a leg in. We discussed how feedback loops are necessary to reinforce expected behavior - positive and negative - e.g., mandating the creation and publishing of SBOMs, an OSS statement of compliance.

Personal comment - I believe this is the most important part of the bill, and I’d like to point out that we cannot treat service providers in the public sector can’t be compared to private sector service providers. Even in India, market forces drive private sector service providers, and smaller providers could go toe-to-toe with larger providers on appropriate projects. This is not the case with the public sector service providers - existing service providers are deeply entrenched and have significant influence in the drafting of tenders, tenders that they eventually bid for. Lack of technical capacity within the public sector drives govt. officials to seek advice from the private sector to draft tenders and set expectations. Because of this, entrenched public sector service providers have an incentive to maintain the status quo and continue using Closed-source software, instead of facing market forces and provide services using Open Source Software. In addition to this, public sector tendoring process also places archaic requirements on potential vendors that rule out a majority of smaller service providers who work with OSS, e.g., annual turnover of N Crore INR, total headcount of X000s, specific academic and work experience requirements from individual team members of a service provider. This ties in with a larger conversation in the policy space to overhaul govt. procurement. One of the participants noted that OSS service providers need an industry body to lobby the Govt. A few participants added examples from their personal experience that reinforced the aforementioned points.

One of the participants pointed out that it would be interesting to understand the justification provided, by a service provider or the Government department, to adopt Closed-Source Software over OSS. He pointed out that participation in the vendor process by a vendor well-versed in OSS would inevitably lead to a lower bid than a vendor that relies on Closed-source software. There is likely a skill gap between service providers of Closed-source software vs OSS. But because the Closed-Source Software vendor might be entrenched, they might be able to justify their way out of OSS usage. This is especially possible if the appropriate Govt. authority isn’t sufficiently tech literate to understand whether the points raised by the vendor are valid or baseless.

Another participant pointed out that the Govt. perceives software maintenance from a different lens than we might. She pointed out the need to provide maintenance guarantees, which an unskilled OSS vendor might be unable to provide, when compared to a large vendor of Closed-Source Software. She also points out that the policy document doesn’t account for sustainability of OSS. She pointed out that the Munich experiment of replacing windows with linux is worth studying.

We briefly discussed whether there is legal recourse for tenders that don’t require suppliers to consider OSS or tender winners that supply Closed-Source Software instead of OSS. While decisions taken by the Govt. might be difficult (or futile) to fight in court, tenders can be challenged if they don’t the requirement for all suppliers to consider OSS. Tenders without such language could be challenged as illegal, although going the legal route might not be the best course of action.

3 Policy Statement

Government of India shall endeavour to adopt Open Source Software in
all e-Governance systems implemented by various Government
organizations, as a preferred option in comparison to Closed Source
Software (CSS).

The Open Source Software shall have the following characteristics:
3.1 The source code shall be available for the community / adopter / end-user to study and modify the software and to redistribute copies of either the original or modified software.
3.2 Source code shall be free from any royalty.

On the topic of licenses, it was important to understand if the characteristics laid out by the policy document adhere with the Open Source Software definition by Debian or Open Source Initiative. One of the participants mentioned that it’d be important to understand which licenses fall under the policy description of OSS. I pointed out that the “Framework for Adoption of OSS in e-Governance Systems” has a section on “OSS Licenses” that might answer this question

Preamble


To meet this objective, there is a need to set up a commensurate hardware and software infrastructure, which may require significant resources.

One of the participants pointed out that the policy is surprisingly silent on “open hardware” after a brief mention of the importance of “hardware” to achieve the overall vision of “Digital India”.

Personal thought - “Right to Repair” might be as important to discuss here as “open hardware”, given the cost of maintaining and repairing physical hardware that is vendor-locked, e.g., printers that mandate the use of first-party ink cartridges and refuse to work if third-party ink cartridges are used to refill them.

8 Implementation Mechanism


iv) GoI shall establish suitable support mechanism for the available OSS that includes Institutional Mechanism, Partnership with Industry, Academia and OSS Community.
v) GoI shall actively collaborate with OSS communities in India as well as at the International level and contribute wherever appropriate.

One of the participants found this particularly interesting. We all pondered for a few minutes to come up with instances where the Govt. established support mechanisms for OSS and/or Govt. actively collaborating with OSS communities in India. One of the participants remembered a few instances where Govt. participated/supported Unicode, ISO, IETF. After a long time, we discussed whether FOSSEE, under the Ministry of Education, counts under 8 iv). Similarly, we wondered if conference and hackathon sponsorship by CDAC and other Govt. departments counts as 8 v). There aren’t a lot of instances, but a few software/tech conferences were sponsored by agencies like CDAC. Two participants mentioned ICFOSS and NRCFOSS as instances, but ICFOSS is a Kerala State initiative that predates the policy, and NRCFOSS was defunded rather abruptly after the policy was passed (citation needed).

9 Review of the Policy

GoI shall have the right to review the Policy as and when required.

One of the participants pointed out that this was interesting and wondered if regular review of policy implementation was a practice of the Govt. We discussed the possibility of nudging someone within MeiTY to review the policy implementation and understand the financial impact that policy implementation (or lack thereof) had on software procurement over the past decade. Another participant pointed out that this + messaging around “Atmanirbharata”/technology self-sufficiency might be helpful to nudge OSS adoption. Given that reduction of the TCO (Total Cost of Ownership) is an explicit goal of the policy document, nudging someone at MeiTY to conduct an internal study might be beneficial. A few participants pointed out that Secretaries and Joint Secretaries are especially sensitive about department budgets.

Framework for Adoption of OSS in e-Governance Systems

Annexure-I Typical OSS Stacks for Java, PHP and Open Web Technologies

One of the participants highlighted that working to update the typical OSS stacks might be a regular and meaningful contribution from the OSS community to the Govt. of India.

What do you think?

Have you read the policy or the framework? What do you think about the policy? What can we do about it?

2 Likes

Interesting viewpoints by various participants.

I think I might check out the Munich experiment. Cost is a huge factor. I don’t understand why vendors cannot offer OSS to customers(govt) and charge them lesser. It is a no-brainer if one thinks about it. Maybe there is something else preventing this from happening such as the entrenched nature of existing Closed SS providers and the onerous requirements placed upon the vendors by the Govt.