8 things the Government can do about FOSS

The Takshashila Institution taught us last weekend that the various types of government action can be roughly split into 8 categories. Let's look at the categories in the context of Free and Open Source Software (FOSS).

Do Nothing

The government can choose to do nothing about FOSS and leave it up to the various public and private entities to decide what each of them want to do with FOSS i.e. whether or not they want to integrate FOSS into their IT systems, how deeply integrated FOSS is in their IT systems, etc. For example, most big public and private players have Enterprise Resource Planning (ERP) software as part of their IT operations. And when deciding an ERP software to use, they can either choose to go with a provider like Oracle ERP, which isn't FOSS, or they can choose to go with a provider like ERPNext, which is FOSS and home-grown in India.

It might sound like doing nothing would mean the government doesn't incur any costs. Alas, that isn't really the case. All software has bugs and from time to time, critical bugs that threaten the security of the IT system. And parts of the software industry is notorious for not disclosing critical bugs and security lapses, for fear of market or government backlash. Doing Nothing means no upfront cost to the government but it also means incurring a heavy penalty when the inevitable security breach occurs.

Engage in rhetoric

One step above Doing Nothing would be to Engage in rhetoric. This might look like the government (specifically the actors within the government) talking publicly about their use of FOSS. In the end, I guess the idea is to signal the fact that the government is open to the use of FOSS.

At the moment, I am unable to see what the downside of engaging in such rhetoric would be. On the other hand, an upside is the recognition for the people who contribute to the FOSS projects being used in the government. I don't know about you but I would be incredibly proud if FOSS I contribute to is being used within the government. GitHub, for example, engaged in rhetoric by highlighting FOSS that was used in the 2020 Mars Helicopter mission and I for one was incredibly proud that I contributed, however little.

Nudge-Change

One step ahead of Engaging in Rhetoric is Nudge-Change i.e. change perception without changing the incentives. I'm not a 100 percent sure what this might look like. Maybe running an ad campaigns "Open Source Sahi Hai" like the "Mutual Funds Sahi Hai" campaign that the AMFI with the accompanying disclaimer to please read the source code for FOSS carefully before investing (time) in it.

Update: One of the faculty at the Takshashila pointed out to me that such ads wouldn't be Nudge-Change, they'd fall under "Engage in rhetoric".

Again, I'm unable to see at the moment what the downside of engaging in such nudge-change would be. And the previous GitHub 2020 Mars helicopter mission falls somewhere in between "Engage in Rhetoric" and "Nudge-change" - because it's both engaging in the rhetoric around FOSS and at the same time changing perception around FOSS.

Umpire

This is a tricky one. I have no idea whatsoever the existing rules and regulations in India around the use of FOSS so I don't know what rules the government isn't enforcing at the moment which it should. Moving on.

One downside of having to umpire the use of FOSS is the need to develop intellectual capacity to understand FOSS. The government should be able to tap into the growing base of FOSS experts in the country for help.

Marginally change incentives

I still don't fully understand what "Shifting behavior at the margin" exactly means in this case. Maybe it means the government weights FOSS software differently than closed-source software when it comes to decisions around procurement. Maybe it means the government incentivizes public (and private) players to explore and experiment with FOSS software, in an attempt to replace internal use of closed-source software. Taking the earlier example, maybe the government provides grants to public and private players to evaluate the feasibility of switching from Oracle ERP (closed-source) to ERPNext (FOSS).

Like I mentioned earlier, a downside here is the need to develop the intellectual capacity to understand and evaluate FOSS. Personally, I believe that the upfront cost of developing the necessary intellectual capacity will pay for itself in the long run through lower IT procurement and maintenance costs. An additional downside might be the need to strictly enforce copyright law when it comes to FOSS. There are a number of companies that deliver SaaS services around FOSS that they built and maintained. While other private players can also choose to provide SaaS services around the same FOSS, they should do so while strictly honoring the copyright under which the FOSS is released to the public.

Drastically change incentives

Completely banning the use of closed-source software would look like a drastic change in incentives. For example, the government of Munich, Germany "banned" the use of Microsoft Windows.

"Where it is technologically and financially possible, the city will put emphasis on open standards and free open-source licensed software"

Taking on such a hard-line stance requires strong conviction and a lot of political capital, which might or might not be available depending on the IT systems within you're trying to implement and enforce the ban. Understandably, there would be a lot of opposition and lobbying from private (and potentially public) players against such a ban. Personally, implementing and enforcing such a ban might be feasible if mature FOSS projects exist. FOSS, by nature, might not have a consistent funding source so not all FOSS is mature enough for heavy use.

Change or reassign ownership

In the context of FOSS, I am not sure what this might mean. FOSS, by its nature, has no ownership. It is already a public good and privatizing it would, by definition, make it not FOSS.

On the other hand, if a closed-source software is deemed important to national security, the government might intervene and make it public. Similar to how a bank might be nationalized, a software company might be nationalized, and the closed-source software could be converted into FOSS.

This sounds nice because IT companies, like other private players, should also be afraid that the government might intervene at any time and nationalize them if they become too successful and important to the security and success of the nation.

But in all seriousness, forcing a company to convert its closed-source software into FOSS fundamentally removes any incentive the company might have to develop and maintain it. It changes the entire value proposition around the software for the company where it was originally created. Unless the government is invested in DIY-ing the software (the next and final step) after it is nationalized, this is a recipe for failure.

Do-It-Yourself

This is the final step of the ladder when it comes to what a government can do. The government can choose to DIY FOSS. They might decide to develop and publish FOSS software instead of relying on FOSS software developed by other private or public players. This is slowly gaining popularity in the Western world. Take for example the U.S. Digital Service, 18F, U.K. Government Digital Service. This might be the natural culmination of the governments efforts to develop intellectual capacity around FOSS.

A big con here would be the government picking winners and losers. With FOSS, projects that have greater public good and are easier to use naturally gain popularity and developer mind share. Not all FOSS projects are made equal and the industry naturally moves from one project to the next as newer technologies are developed and older ones are trashed. With the DIY approach, given the sheer scale of any government, they run the risk of sticking to an outdated technology or FOSS project simply because of the large user base. New FOSS projects constantly come up and replace older projects simply because they cost less i.e. they take less time to understand, they take less time to implement, they take less time to maintain and they take less time to upgrade. Interfering in this by DIY-ing FOSS and mandating its use within the government feels like a recipe for long term failure. The farther a government stays away from this specific course of action, the better it is for the software ecosystem as a whole.

What do you think? Which courses of action make the most sense to you?