Hello all, we at Takshashila Institution, in collaboration with folks from FOSS United, IFF and others, have been working on an open-source strategy for India. We have the first version up - An Open Tech Strategy for India
We look at why open-source technologies across software, hardware and standards are in our national interest and propose recommendations to promote adoption and create a sustainable community. We would love any feedback on this. Please let us know what you think about this and how we can improve any recommendations.
This is the first draft of an open document that we would like people to contribute to. We invite contributors/authors to build on and add to the ideas in this document. Do share your feedback here.
(a) In the open hardware section, I did not see any mention of the Right to Repair. I think this will be much more crucial because it goes beyond “computing” devices and would cover things like vehicles, mfg tools and a lot more.
(b) Would also have liked to see recommendation on patent and copyrights law. Software and source code gets the unique privilege of being locked up under both of these, while still keeping the knowhow proprietary.
Overall, I felt it could be a bit more ambitious. As a “strategy” doc, it reads a bit tactical and all of its recommendations could be adopted in a year or two with very little resistance.
@Bharath_Reddy I just realised that the linked webpage doesn’t have the actual draft presentation you’d shared earlier that elaborates on points including the umbrella term “open tech”. Please share that. Without that, the points on the webpage are too broad and lack context to solicit comments from the community. Thanks!
Please do not create a vague umbrella term. Prepare 3 strategy documents if required. Or call it open source, open hardware, open standard strategy. By combining these into one ambiguous, term that’s defined with “to the maximum extent possible” we’re paving way for people to create confusion by mixing things up.
“Adopt an open-source first policy in government procurement”
Policy should build on previous policies. Refer to the previous open source policy here and say something like “Implement/extend the open-source policies for government procurement”
“Establish an open source programme office to coordinate policies, use and contribution of open source software (OSS) across government bodies”
With ICFOSS, We have seen how this can be the most counterproductive thing to do. This recommendation, if being made, should be after a case study on ICFOSS and how another organisation can be built without the weaknesses of ICFOSS. Otherwise, this recommendation leads to a national level ICFOSS - a national level waste. Please remove this recommendation.
“Inculcate OSS skills in the education curriculum”
This is good, but I think it can be made better by referring to existing examples like IT@school. But that maybe optional. Also, please give examples of what an “OSS skill” is.
“Fund existing open-source projects of interest to the government and public”
Better phrased as “Make budget allocations for open-source” because the phrase “interest to the government” needs to be defined.
“Nurture a sustainable OSS community”
Refer to the point 3 above. Nurturing an open source community is not something government can do. Please remove this point.
Mandate acknowledgement of OSS Use
Rephrase this to “Proactively bring transparency into technology stacks used by the government through RTI” which will cover OSS and proprietary and everything and brings RTI into the picture.
My understanding is that the term is the name of the document, not of the technologies or recommendations, nor a umbrella term for them. FOSS, open standards etc. are defined as separate heads in the draft. Open standards, open data, FOSS etc. are tightly interconnected in the real world. States should ideally adopt and encourage open standards and protocols rather than hosting centralised services (even if made with FOSS), so a coherent strategy highlighting the overlaps in one document seems ideal than creating separate, distinct documents. Separate documents will end up duplicating significant part of the suggestions.
What else could be a name for such a document? On similar lines, I can think of GDPR or the ePrivacy directive in the EU, which are just “nicknames” for big, broad frameworks.
+1. The existing IT procurement policy has a “soft preference” for FOSS. It should be hardened. There wouldn’t be a need for a new policy.
Agree. If such a body is created, it should have clear tangible goals, eg: ensuring FOSS procurement, ensuring funding of FOSS projects, ensuring “public money, public code”, surveying and auditing FOSS use inside govt. etc.
Using RTI as a framework for tech transparency seems like a great idea!
Summarizing some bits from the Telegram thread for context here.
“Open tech” as a name for the document/folder is fine, but its explicit definition inside the doc is, especially when FOSS, open standards, open data etc. have clear definitions and are also defined within the doc. Removing the definition which might cement a vague umbrella term and treating it just as a name for the doc may be ideal. I made the error of forgetting the explicit definition of “open tech” in the introduction in the document entirely! Edit: Given the overuse and misappropriation of the word “open” in the govt. tech policy circles, it’s probably best to avoid the word “open” leaving room for interpretations entirely. This leads to the next point:
It’s actually fine to just call it “Tech strategy” becaues the goal of the document is not to suggest the creation of a new, parallel “open tech” strategy along side the existing tech strategy, but its goal is to suggest that existing tech strategies be tweaked to adopt FOSS, open standards, open data etc., that existing FOSS frameworks and policies be strengthened and enforced.
A serious gap that needs to be addressed is tech-on-cloud and cloud procurement. When significant amounts of tech deployments and procurement are moving to cloud services, the conventional model of FOSS adoption may be insufficient. What strategy or suggestions can address this?
Sharing the context on our involvement with this draft.
Pasting a comment from the TG group below:
We’d had a casual conversation after reading this article within Nitin@Takshashila and the same talking points came up. Why are there so few FOSS projects out of India? Why does govt spend huge amounts of public money on proprietary software? Why is there a lot of data created with public money silod and closed (eg: dictionaries). Then, Takshashila proposed the idea of creating an open letter / policy doc addressing this.
@rushabh and I agreed to volunteer time to share comments provided the doc would include community input. Rushabh is skeptical of the efficacy of any tech policy effort in general, but we did volunteer time by having debates on whether it should be “OS” or “FOSS” etc that should be included in such a doc
@aparatbar@jackerhack@VenkyHariharan also shared comments with Pranay and Bharath from Takshashila. The idea was that there should be a v0.1-alpha draft that can serve as an initial draft that can shape up with community (not just the FU group) comments and public input.
I presume the draft that’s out now is v0.1-alpha.
Since this document is a draft, I recommend that it should be made clear in the post and the PDF that this is a draft.
My main problem with this document is that it does not cover any new ground. The way most of us consume state services is via software platforms. We should include a section on software platforms / cloud platforms with a recommendation that governments should be publishing only standards and maintaining registries, not running entire platforms.
Edit 1: We should also make it clear that existing platforms like CoWIN and BHIM app are not open source and caution against using “open source” for these terms because it is incorrect.
Edit 2: An (full) editable version of this document should be make available for comments and editing.
I agree with this in principle. It’s all common stuff that everyone already knows, about FOSS, about standards. There are existing FOSS policies across various govt. institutions too. However, I think the point was, many of the policies are scattered, unenforced, and weak. The common sense FOSS policies need to be coherent and actually enforced. If they were, we wouldn’t need to have a doc like this in the first place.
“Public money, public code” is a strong guiding principle
So maybe what needs to change in the doc is that it should explicitly focus on enforcing the existing FOSS related policies and bringing accountability.
We should specifically refer to the eGovernance Policy of 2015 - Chapters 2-4 shared on the TG group. It is very comprehensive and covers a lot of what we are already proposing.
The idea was to find a term that could encompass the different verticals (software, hardware, content) we wanted to cover in the report. But agree that the term open tech could lead to ambiguity and also dilutes some attributes of some of the verticals - which led us to use terms like “maximum extent possible”. We could consider retaining it for the title of the document and state that it refers to open-source software, open-source hardware and open standards. I’m not sure if “Tech strategy” conveys the focus of the document on open-source technologies.
Agree. The e-governance policy is quite comprehensive. We could make specific recommendations for sections that we would like to see changed, for example, a stronger mandate for open source in govt software procurement and acknowledgement of OSS in a software bill of materials.
Some areas the open tech report differs:
The core arguments in favour of OSS are built on techno-strategic autonomy, technology leadership, and skill development in addition to the commonly cited advantages of freedom (to use, study, modify, redistribute) and economic growth (cost savings, reducing entry barriers, interoperability). This approach could resonate with diverse stakeholders in govt.
The focus of the e-governance policy is on government software procurement; the open tech report talks about other initiatives such as education and funding open source projects which, while not radically new, are brought into a single consolidated report.
The slide doc has been uploaded to GitHub in markdown and pdf formats. The ppt version will also be made available shortly.
This will make a good addition to the open hardware section, but we will need to broaden the scope of the hardware section beyond chips. We could look at the recent announcement of the right-to-repair portal and see if we can propose any recommendations.
Not sure about the implications. We can discuss this further. On a related note, the e-governance policy recommends a preference for a liberal OSS license, such as the MIT license. Should we make any suggestions on this?
The “Overview of Existing Policies” section does touch upon some of the main govt policies in this area. The current open-source policies prefer open-source but do not mandate it. This recommendation specifically calls for mandating this soft preference. In our discussions, we feel that this could be something that could have spillover effects for the entire ecosystem. Some of the benefits are captured under the recommendation.
Agree that government efforts at FOSS, especially govt DIY projects or community-building efforts have not been successful. But there could be areas like the ones Kailash has mentioned that could be useful - ensuring funding of FOSS, coordinating FOSS use and policies, surveying and auditing.
The recommendation was specifically targeted at undergraduate and postgraduate engineering programmes. It is to inculcate open-source development practices and tools such as GitHub, Python, FreeCAD, Ngspice, etc, in the model curriculum recommended by, say, AICTE.
But the suggestion of emulating KITE and IT@school nationally is a great idea. We can include that too.
The e-governance policy 2015 talks about OSS support models in section 3.9 from a procurement perspective. It talks about operational and source code-level support.
This recommendation could build on top of the e-governance policy but with a focus on making OSS projects of “interest” to the public and government more sustainable. “Interest” is something we can define - the number of users critical nature of the project could be factors. Any other suggestions?
If government involvement does not add much value, we can drop this.
RTI is a great idea to bring transparency in govt’s use of tech. I’m not sure, but wouldn’t this already be covered under the current scope of RTI?
However, this recommendation is actually a bit different. It specifically talks about mandating a software bill of materials (SBOM) for ALL software purchases by the government and private sectors. This SBOM would require all open-source components to be listed and would bring in greater acknowledgement of FOSS in the software industry.
In the recommendation “Promote the Adoption of Open Standards”, under standards, we have captured this recommendation that for digital public infrastructure, the government should play a role in publishing standards and protocols and not run platforms. We could articulate it better if there are any suggestions.
I wonder why these counter arguments were not made by you earlier @Bharath_Reddy. I do not have time to respond now. But I disagree with many of your responses to my points.
Edit: For context. In the telegram group where this was discussed there was broad consensus that there would be a revised draft. Bharath was in that conversation as well.
I was consolidating all the comments and thought I would share them here. I’ve been a bit busy too this week with other work, so I couldn’t get to this earlier. But I had made some of these arguments on Telegram earlier. Please share your thoughts whenever you get time. Interested to hear what you think.
Edit: Yes, there will be a revised draft. This is why I am consolidating the comments so we can address them.
Are these comments solely prepared by you Bharath, or are you consolidating comments from other authors as well? If latter, I would like to know whose comments have been included.
For now, these are only my comments. For context: the process we have followed while working on this report is that we have had periodic discussions with the contributors (listed on the first page of the report); Pranay and I have authored the report, but largely based on inputs from the discussions.
While I think that retaining it as a name for the document should be okay in principle (as long as it has no new definition), after the comments from the group, I now think it has the potential to inadvertently become yet another term that might taken on connotations. A tangential example is people referring to the NFC feature on credit/debit cards as “WiFi”, thanks to that WiFi-like icon In a nuanced tech policy, it’s best to pre-empty such a possibility, especially when the word “open” has been misunderstood, co-opted, and even abused heavily in tech.
If we’re looking for a general umbrella term and also a name for the document, An open source tech strategy for India works? In the introduction, it can be introduced as FOSS, hardware, standards, protocols etc. “Open source” as a term has also become generic enough globally to refer to a model, not just code.
On A tech strategy for India, I think it’s still valid because the document’s point is to not to create a new “open” strategy, but to make (and enforce) existing implementations and practices FOSS. The eGovernance doc that’s been brought up in the discussions, if it already contains the foundations, then the point of the doc is to push for adoption and enforcement of the FOSS principles that already exist, but aren’t followed.
I am skeptical about proposals like Open Source Program Office (more bureaucracy?) and an “open source first” policy leading to poor quality FOSS being promoted (BOSS Linux?) to the inadvertent long term degradation of the public image of FOSS.
FOSS is doing fine without government help, let things remain that way? If we push too hard, it may incentivise open washing and branding everything that is not “open” as “open” just to follow a trend, as we have seen with Aarogya Setu and UPI press releases.
Agree that such an office shouldn’t end up being yet another layer of bureaucracy.
Disagree. There are barely any FOSS projects out of India despite the massive consumption, and the massive amounts of tax payer money is spent by governments on procuring proprietary software. A small change there might have multiple good outcomes including tax payer money that’s saved, and money flowing into the local tech/FOSS ecosystem, which in addition may also spawn contextually relevant FOSS.
In a nuanced tech policy, it’s best to pre-empty such a possibility, especially when the word “open” has been misunderstood, co-opted, and even abused heavily in tech.