India has no shortage of engineers, entrepreneurs or ambition. But a large amount of engineering effort can disappear into the same foundational problems, solved again and again by different companies. What if India treated foundational software as shared economic infrastructure — built once, maintained properly, and reused everywhere?
The Question Nobody Seems to Ask
India has built one of the world's largest startup ecosystems.
There are fintech companies, food-delivery companies, e-commerce companies, logistics platforms, consumer brands, software-as-a-service companies and thousands of businesses solving increasingly specialised problems.
There is nothing inherently wrong with any of these businesses.
But another question deserves to be asked.
Why does it remain so difficult for a small Indian team to move from building an application to building a genuinely new technological system?
Why should a startup that wants to build a robot, a smart camera, smart glasses, an autonomous machine, an intelligent appliance or a new class of industrial device have to spend so much of its limited engineering time solving the same low-level problems that hundreds of other companies have already encountered?
The problem may not simply be a shortage of capital.
It may not simply be a shortage of talent.
It may not even be a shortage of ideas.
There is another possibility:
India may be paying a hidden engineering tax.
That tax is the enormous amount of duplicated effort spent rebuilding the foundations of technology instead of building on top of them.
The Hidden Cost of Reinventing the Plumbing
Imagine 200 companies building connected devices.
Company A needs Bluetooth.
Company B needs Bluetooth.
Company C needs Bluetooth.
Company D needs Bluetooth.
All of them need Wi-Fi.
All of them need storage.
All of them need device updates.
All of them need diagnostics.
All of them need security.
All of them need hardware abstraction.
All of them need networking.
All of them need some form of operating-system integration.
All of them need drivers.
All of them need logging.
All of them need power management.
Increasingly, all of them need access to GPUs, NPUs, cameras, sensors and specialised accelerators.
None of these things necessarily constitutes the company's actual innovation.
Yet engineers have to make them work.
And if the available software is poorly documented, proprietary, difficult to modify, tied to one vendor or simply immature, the company has little choice but to invest its own engineering resources.
This is where duplication becomes expensive.
Suppose 100 companies each spend 20 engineers for one year solving broadly similar infrastructure problems.
That represents 2,000 engineer-years.
Those engineers are not necessarily creating 2,000 engineer-years of differentiated innovation.
Much of that effort may be reproducing the same basic capabilities.
Now imagine that a well-funded open engineering organisation spends 200 engineer-years creating, documenting, testing and maintaining a common foundation.
The other companies can potentially build on it.
The calculation is not simply about salaries.
It is about what those engineers could have built instead.
Engineering Time Is a National Resource
We often discuss national resources in terms of land, energy, water, capital and raw materials.
Engineering time deserves similar treatment.
A skilled engineer can spend a year solving a problem that enables thousands of other engineers.
Or that engineer can spend a year solving a problem that another company solved two years ago.
Both activities generate software.
But they do not generate the same economic leverage.
This is the crucial distinction.
Not every piece of software needs to be differentiated.
Some software exists primarily to make other software possible.
That software is infrastructure.
And infrastructure becomes dramatically more valuable when it can be reused.
India already understands this principle in physical infrastructure.
We do not expect every automobile manufacturer to build its own roads.
We do not expect every factory to construct its own electricity grid.
We do not expect every company to manufacture its own cement before building an office.
We build common infrastructure because its value increases when many participants use it.
Software can work the same way.
Build Once, Use Everywhere
This is the basic philosophy:
Build once. Maintain properly. Document thoroughly. Test continuously. Let everyone build on top of it.
That does not mean literally writing every piece of software once and never touching it again.
Quite the opposite.
The common layer should receive continuous investment.
It should have maintainers.
It should have security reviews.
It should have automated testing.
It should have documentation.
It should have compatibility testing.
It should have hardware laboratories.
It should have developers who actually use the software on real products.
The principle is therefore better expressed as:
Concentrate engineering effort where reuse is high, then distribute the resulting capability across the economy.
The DOCX Example
One of the simplest examples is the humble Word document.
The .docx format is associated strongly with Microsoft's Office ecosystem, but Microsoft Office is not the only software capable of working with DOCX files.
LibreOffice, WPS Office, SoftMaker Office, ONLYOFFICE, Zoho and numerous other products can work with Word documents in various ways.
There are also programming libraries that allow software developers to generate and manipulate DOCX files without building an entire office suite.
One particularly useful example is python-docx, an open-source Python library designed to create and update Microsoft Word documents.
The significance of python-docx is not that it competes with Microsoft Word.
It does something more interesting.
It turns document manipulation into a programmable capability.
An engineer building an automated reporting system does not need to create a complete word processor.
An AI workflow does not need to build Microsoft Word.
An enterprise application does not need to recreate an office suite simply because it needs to produce a report.
A developer can use an existing library and concentrate on the application that actually matters.
That is the power of a common software layer.
The existence of reusable infrastructure creates room for implementations that nobody had to imagine in advance.
And this is where the analogy becomes much bigger than DOCX.
The Foundation Does Not Kill Competition. It Creates Competition.
It is easy to make a mistake when discussing shared infrastructure.
One might imagine that if everybody uses the same foundation, everybody will produce the same product.
That is not what happens.
A common foundation can actually increase differentiation.
Consider the automobile.
Cars share thousands of common technologies.
That does not mean every car is identical.
The common foundation allows manufacturers to concentrate on design, engines, batteries, safety systems, interiors, software, manufacturing processes and customer experience.
The same principle applies to software.
Linux does not prevent companies from creating different products.
LLVM does not prevent different programming languages and compilers.
Vulkan does not prevent different games.
Bluetooth does not prevent different headphones.
USB does not prevent different peripherals.
RISC-V does not prescribe a single processor.
In fact, RISC-V is specifically designed as an open instruction-set architecture that allows different implementations and customisation. The RISC-V ecosystem itself increasingly emphasises the importance of software, tooling and ecosystem support around the architecture.
The important distinction is:
Standardise the interface. Do not standardise the innovation.
The Startup Problem
This becomes particularly important when we look at startups.
A large corporation may be able to spend tens or hundreds of millions of rupees building internal infrastructure before its product reaches customers.
A startup usually cannot.
Consider a four-person startup that wants to build an agricultural robot.
Their real idea might be extraordinary.
Perhaps they have developed a computer-vision system capable of identifying crop stress.
Perhaps their innovation is a low-cost mechanism for precision spraying.
Perhaps they have created an AI model that can distinguish weeds from crops.
Perhaps their competitive advantage is an autonomous navigation system designed specifically for Indian farms.
That is the thing they should be working on.
But the engineering reality may look very different.
RISC-V/ARM SoC
↓
Board Support Package
↓
Bootloader
↓
Linux/RTOS
↓
Camera Drivers
↓
GPU
↓
NPU
↓
Motor Controllers
↓
CAN / Ethernet / Wi-Fi
↓
Storage
↓
Security
↓
OTA Updates
↓
Diagnostics
↓
Cloud/API integration
↓
Finally: the agricultural robot
Suddenly, the four-person startup is not simply building a robot.
It is becoming a low-level systems company.
That may be necessary in some cases.
But it should not be necessary every time.
Let the Startup Dream About the Product
Imagine instead that the startup receives a mature reference platform.
The platform already provides:
- camera APIs
- GPU acceleration
- NPU access
- motor-control interfaces
- sensor interfaces
- networking
- storage
- security
- OTA infrastructure
- diagnostics
- logging
- power-management interfaces
- documentation
- automated tests
The startup can now begin much closer to its actual innovation.
COMMON PLATFORM
↓
Hardware APIs
↓
Drivers
↓
Security
↓
Networking
↓
GPU/NPU
↓
Development Tools
↓
STARTUP
↓
Crop Intelligence
Navigation
Robotic Manipulation
AI Models
Business Model
That changes the economics of experimentation.
A four-person startup can attempt something that previously required forty people.
A university laboratory can prototype something without building an entire platform first.
An engineer leaving a large company can create a product instead of spending two years rebuilding infrastructure.
A small manufacturer can integrate intelligent electronics without becoming a software-platform company.
This is what foundational software can do for entrepreneurship.
It lowers the cost of attempting difficult things.
What About Robots, Smart Glasses and Cameras?
Consider some of the technologies that India will increasingly need to develop.
- industrial robots
- agricultural robots
- warehouse robots
- autonomous inspection systems
- smart glasses
- advanced cameras
- drones
- medical devices
- intelligent vehicles
- smart appliances
- industrial IoT equipment
- wearables
- edge-AI devices
- specialised machines
These products are radically different.
Yet underneath them are surprisingly similar requirements.
They need processors.
They need operating systems.
They need drivers.
They need networking.
They need storage.
They need security.
They need update mechanisms.
They need graphics and multimedia.
They need sensor interfaces.
They increasingly need AI acceleration.
They need development tools.
They need diagnostics.
They need testing.
They need documentation.
Why should every company build these things independently?
The Common Layer Could Become India's Startup Multiplier
This is where the idea of an industry-backed open technology consortium becomes economically interesting.
The consortium would not build the robot.
It would build the road on which the robot company travels.
It would not build every smart television.
It would make the underlying hardware and software easier for television companies to use.
It would not build every car.
It would help create reusable software infrastructure for automotive systems.
It would not build every pair of smart glasses.
It would make cameras, displays, sensors, graphics, AI accelerators and connectivity easier to access from software.
It would not compete with startups.
It would make more startups economically viable.
The 80 Percent Nobody Wants to Talk About
Most products have some highly differentiated component.
But a large portion of the underlying technology may be common.
Imagine a smart refrigerator.
The manufacturer's differentiation could involve refrigeration algorithms, energy optimisation, food recognition, user experience and industrial design.
It probably does not need a proprietary implementation of every networking primitive.
A washing-machine company might differentiate through washing algorithms, sensors and mechanical design.
It does not need to invent an entirely new OTA mechanism.
A robot company should differentiate through perception, navigation and manipulation.
It should not need to create its own implementation of every low-level device interface.
A smartphone manufacturer should differentiate through hardware, camera systems, industrial design, software experience and services.
It does not necessarily gain strategic advantage by independently reinventing basic drivers that thousands of engineers elsewhere have already solved.
This leads to a simple principle:
Own the parts that make your product unique. Share the parts that make the ecosystem work.
FLOSS Is More Than Free Software
This is why the conversation about FLOSS is often too narrow.
People frequently discuss open-source software in terms of licensing cost.
That is important, but it is not the deepest benefit.
The more strategic advantage is the ability to:
- inspect the implementation
- modify it
- fix it
- port it
- integrate it
- test it
- document it
- teach it
- maintain it
- improve it
- contribute improvements upstream
That turns software from something a company merely consumes into something an ecosystem can develop.
And that distinction matters enormously for technological sovereignty.
India does not need to replace every foreign software project with an Indian clone.
It needs enough engineering capability that critical foundations are understandable, maintainable and replaceable.
Foreign Software Is Not Automatically the Problem
There is also a temptation to frame this as a simple contest between Indian and foreign software.
That would miss the point.
The world already has extraordinary open-source projects developed by people from many countries.
India should use them.
India should contribute to them.
Indian companies should employ their maintainers where appropriate.
Indian universities should teach them.
Indian startups should build products on them.
Indian engineers should become important contributors to them.
The strategic objective should not be:
"Replace everything foreign."
It should be:
"Reduce situations where India has no practical ability to understand, maintain or replace a critical dependency."
That is a much more useful definition of technological sovereignty.
The DOCX Lesson Again
Return to the document example.
Microsoft can continue developing Microsoft 365.
LibreOffice can continue developing LibreOffice.
WPS can continue developing WPS Office.
ONLYOFFICE can continue developing ONLYOFFICE.
SoftMaker can continue developing its products.
Zoho can continue developing its services.
And developers can build specialised applications that manipulate documents without building a complete office suite.
The existence of reusable libraries does not eliminate competition.
It multiplies the number of things that can be built.
That is the point.
The common layer should make the number of possible products larger, not smaller.
The Browser Lesson: Open Does Not Automatically Mean Decentralised
There is an important warning here.
Open source does not magically eliminate concentration.
The web browser ecosystem demonstrates this.
Browser engines require enormous investment, compatibility work, security engineering and constant maintenance. Chromium/Blink has become highly influential, while other major engines such as Firefox's Gecko and Apple's WebKit remain important.
The lesson is not that open source failed.
The lesson is that common infrastructure naturally tends to concentrate expertise.
That concentration can be useful because a small number of highly capable teams can maintain extremely complex software.
But concentration also creates a governance question:
Who controls the layer everyone else depends upon?
That is why India's open technology strategy should care about governance as much as licensing.
Open code is valuable.
Open standards are valuable.
Multiple implementations can be valuable.
Transparent technical governance is valuable.
Independent maintainers are valuable.
Reproducible builds are valuable.
Documented APIs are valuable.
Migration paths are valuable.
The objective should not be to eliminate concentration of expertise.
Centralisation of expertise is inevitable. Centralisation of control does not have to be.
The Steam Lesson: Integration Is a Technology
There is another useful example in gaming.
Linux gaming did not become substantially more practical simply because someone created a single "Linux game."
The ecosystem improved through layers of integration: compatibility work, Proton and Wine, graphics support, controller integration, SDL and cooperation across the Linux gaming stack.
The broader lesson is important.
Sometimes the most valuable technology company is not the company that invents every underlying component.
It is the company or organisation that makes many components work together.
That is precisely the role an Indian open technology consortium could play.
RISC-V provides an open ISA.
Linux provides an operating-system foundation.
LLVM and GCC provide toolchains.
Mesa and Vulkan provide important graphics infrastructure.
Zephyr and other projects serve embedded and real-time use cases.
Open-source multimedia, networking, security and AI projects provide further pieces.
The consortium's job would be to help make these pieces work together on real hardware.
Integration itself is infrastructure.
RISC-V Makes the Argument More Urgent
RISC-V is an especially useful example because the processor ISA is only one part of a usable computing platform.
A processor can exist without having a mature ecosystem around it.
A chip can boot without being pleasant to develop for.
A development board can run a demonstration without being ready for thousands of commercial products.
Software support must exist across the stack.
This is not merely theoretical.
RISC-V International's ecosystem programs explicitly recognise the importance of software development, CI testing, hardware access and upstream software work. Its RISE project exists specifically to pool engineering effort and funding around critical open-source software so that RISC-V hardware and software can evolve together.
That is almost exactly the problem this article is describing.
The hardware ecosystem cannot simply wait for the software ecosystem to appear afterward.
Hardware and software need to mature together.
India already has meaningful RISC-V activity. IIT Madras's SHAKTI program is an open-source processor initiative, while the national Digital India RISC-V programme has sought to develop indigenous processor capabilities.
The next question is therefore not simply:
"Can India design a processor?"
It is:
"Can India build the software ecosystem that makes many companies want to build products around that processor?"
Start With Existing Hardware
The answer does not need to wait for a perfect Indian chip.
This is perhaps the most important practical part of the proposal.
Start with hardware that already exists.
Take existing RISC-V development boards and SoCs.
Document them.
Test them.
Identify what works.
Identify what does not.
Write missing drivers.
Improve boot support.
Improve Linux and RTOS support.
Build HALs.
Build APIs.
Create reference implementations.
Build automated test suites.
Create compatibility matrices.
Write documentation.
Make it easy for an engineer to go from:
"I bought this board."
to:
"I have a working application."
That sounds boring.
It is not.
That is how ecosystems are built.
From Boards to Platforms
The progression could look something like this:
Existing hardware
↓
Board support
↓
Drivers
↓
HAL
↓
Common APIs
↓
SDKs
↓
Reference platforms
↓
Test suites
↓
Documentation
↓
Commercial platforms
↓
Products
The consortium does not need to own every layer.
It needs to make the transition between layers easier.
Once a common platform becomes reliable, manufacturers can compete above it.
The 80 Percent and the 20 Percent
Perhaps the easiest way to describe the model is the 80/20 principle.
The common ecosystem should try to solve the boring 80 percent.
Manufacturers should compete fiercely over the valuable 20 percent.
The exact percentages will obviously vary by product.
The point is conceptual.
Common:
- boot
- drivers
- connectivity
- security primitives
- storage
- graphics APIs
- AI runtimes
- device management
- OTA
- diagnostics
- testing
- documentation
Differentiate:
- robotics algorithms
- camera algorithms
- AI models
- industrial processes
- mechanical systems
- user experience
- energy efficiency
- navigation
- computer vision
- product design
- business model
The common layer becomes the foundation.
The companies compete above it.
This Could Change What a Startup Looks Like
Imagine a future Indian startup ecosystem in which a team of six engineers can obtain an open reference platform and immediately begin experimenting with:
- a robot
- a drone
- a smart camera
- a wearable
- a medical device
- a smart appliance
- an industrial controller
- a vehicle subsystem
- an edge-AI device
Their initial capital requirement is lower.
Their development time is shorter.
Their ability to experiment is higher.
Their dependence on a single vendor is lower.
Their ability to hire engineers is easier because the underlying tools are familiar.
Their ability to contribute improvements upstream is greater.
And most importantly, their engineers spend more time on the thing that makes the company valuable.
That is a startup multiplier.
Five Engineers Should Be Able to Build What Previously Required Fifty
This may be the most ambitious promise of the entire idea.
Not because five engineers are magically more productive.
Because five engineers should not have to recreate everything that fifty engineers have already built elsewhere.
Open infrastructure effectively allows engineering effort to be pooled across companies.
One team works on a driver.
Another improves the compiler.
Another improves the NPU runtime.
Another fixes a security problem.
Another improves documentation.
Another creates tests.
Another validates the software on new hardware.
Thousands of companies can potentially benefit from the accumulated work.
This is one of the great economic characteristics of open-source development:
the cost of producing the common layer can be shared, while the value created above it can be multiplied.
Robustness Through Many Implementations
There is another benefit.
A common open layer can become more robust precisely because many different products use it.
One company may discover a memory-management problem.
Another may uncover an unusual Bluetooth edge case.
A third may discover a security vulnerability.
A fourth may identify a power-management problem.
A fifth may expose a hardware compatibility issue.
If the improvements are upstreamed properly, the entire ecosystem benefits.
Instead of five companies independently fixing five variations of the same problem, the ecosystem can progressively improve one shared implementation.
That creates a virtuous cycle:
More users
↓
More real-world testing
↓
More bugs discovered
↓
More fixes
↓
Better documentation
↓
Better compatibility
↓
More users
This is why the common layer should not be treated as a static software package.
It should be treated as living infrastructure.
But Someone Has to Pay for It
There is an uncomfortable truth about open infrastructure.
Open source does not mean that engineering is free.
Someone has to pay the engineers.
Someone has to maintain the build systems.
Someone has to operate the test laboratories.
Someone has to perform security reviews.
Someone has to write the documentation.
Someone has to fix bugs at two in the morning when a new chip breaks the build.
Someone has to keep old hardware working.
Someone has to review patches.
This is why India needs to think beyond "open-source adoption."
It needs to think about an open-source maintainer economy.
The Indian Open Technology Consortium
This is where the proposed consortium enters the picture.
The model could be relatively simple:
Industry provides money.
The foundation provides infrastructure.
Engineers provide maintenance.
Universities provide talent and research.
Startups provide real-world use cases.
Government provides incentives, procurement opportunities and enabling infrastructure.
Open-source communities retain technical authority.
The consortium should not become a government software department.
It should not become a giant outsourcing company.
It should not build proprietary products and call them open.
It should not fork the world.
It should strengthen the world that already exists.
Do Not Build an Indian Copy of the Internet
This distinction matters.
India does not need an Indian version of every global open-source project.
It needs Indian engineers contributing significantly to global projects.
If Linux needs work, contribute to Linux.
If LLVM needs work, contribute to LLVM.
If Mesa needs work, contribute to Mesa.
If a RISC-V toolchain needs work, contribute upstream.
If an AI runtime needs optimisation, contribute upstream where appropriate.
If an open protocol needs better implementation, improve it.
If India needs a missing component that genuinely does not exist, build it.
The principle should be:
Do not fork the world. Strengthen the world.
The Consortium Should Own the Glue, Not the Product
This may be the simplest description of the whole proposal.
The consortium should own or steward the glue.
The companies should own their products.
The consortium can maintain:
- drivers
- HALs
- SDKs
- reference implementations
- test frameworks
- documentation
- compatibility layers
- common APIs
- security infrastructure
- development tools
- hardware validation
- upstream contributions
The companies can build:
- phones
- cars
- robots
- cameras
- smart glasses
- appliances
- drones
- industrial machines
- medical devices
- wearables
The consortium builds the plinth. Companies build the statues.
The Startup Does Not Need to Reinvent the Wheel
This sounds almost trivial.
But it is not.
A startup ecosystem becomes powerful when a new company can enter at a higher level of abstraction.
In the early years of computing, building a computer required extraordinary amounts of specialised knowledge.
Today, a programmer can write an application without designing a CPU.
That happened because layers of abstraction were created underneath.
The same process needs to happen for robotics, intelligent appliances, autonomous systems and edge AI.
A robotics entrepreneur should eventually be able to think about robotics at a high level.
A smart-camera entrepreneur should be able to think about computer vision.
A smart-glasses entrepreneur should be able to think about spatial computing.
An industrial-AI startup should be able to think about industrial intelligence.
They should not have to begin by asking:
"How do I write the driver for this sensor?"
This Is How Startups Can Dream Bigger
Perhaps this is ultimately the biggest economic argument.
When the foundation is weak, startups dream within the limits of what they can afford to build.
When the foundation is strong, startups can dream closer to the limits of what technology itself permits.
That difference matters.
The first generation of entrepreneurs may say:
"We can build an app."
The next generation might say:
"We can build a device."
The generation after that might say:
"We can build a machine."
Eventually:
"We can build a new category."
A strong foundational technology ecosystem does not guarantee that those companies will succeed.
But it makes attempting them cheaper, faster and more realistic.
India Does Not Need Fewer Startups. It Needs Cheaper Experiments.
This may be a more useful way to think about startup policy.
The objective should not simply be to increase the number of startups.
It should be to lower the cost of experimentation.
If building a prototype costs ₹10 crore, only a relatively small number of teams can try.
If common infrastructure reduces the cost dramatically, many more teams can experiment.
Most experiments will fail.
That is normal.
But a few will succeed.
And the ecosystem learns from all of them.
That is how technological capability compounds.
From Consumer Startup to Technology Ecosystem
India's consumer startup boom demonstrated that Indian entrepreneurs can build companies at enormous scale.
The next challenge is different.
Can India create an ecosystem in which thousands of engineers can attempt difficult physical technologies without first having to build every software foundation themselves?
Can a university laboratory move from an interesting prototype to a supported platform?
Can a startup take an existing RISC-V board and turn it into a product?
Can a small manufacturer integrate an NPU without hiring an entire AI-systems team?
Can an appliance company share common software infrastructure while competing aggressively on the appliance itself?
Can an Indian robotics startup spend its engineering budget on robotics rather than reinventing Linux drivers?
These are not merely software questions.
They are questions about the productivity of the entire engineering economy.
The Opportunity Around India's Semiconductor Ambition
This becomes even more important as India expands semiconductor manufacturing and design capabilities.
A semiconductor fab by itself does not create a computing ecosystem.
A chip does not automatically become a product.
A product does not automatically become a platform.
A platform does not automatically become an ecosystem.
There are layers between all of these.
Semiconductor
↓
SoC
↓
Board
↓
Firmware
↓
Drivers
↓
OS
↓
Runtime
↓
SDK
↓
Reference Platform
↓
Product
↓
Startup
↓
Industry
↓
Ecosystem
Every missing layer increases the cost of moving upward.
Every mature reusable layer lowers it.
This is why software infrastructure should be developed before the next generation of hardware becomes widespread, not afterward.
RISC-V ecosystem initiatives around upstream software, CI and physical hardware testing make the same broad point: hardware and software readiness have to progress together.
The Most Valuable Output May Not Be Software
There is an even deeper consequence.
The consortium's most valuable output might ultimately be neither code nor hardware.
It might be people who know how to build technology.
An engineer working on a common driver learns about hardware.
An engineer working on a compiler learns about architectures.
An engineer working on an NPU runtime learns about AI acceleration.
An engineer working on power management learns about systems engineering.
An engineer working on security learns about trusted computing.
An engineer working on a board-support package learns how hardware actually becomes usable software.
And then those engineers move into startups.
Some start companies.
Some join manufacturers.
Some join universities.
Some become maintainers.
Some build new standards.
The common infrastructure becomes a training ground for systems engineers.
Do Not Teach FLOSS. Put Engineers Inside FLOSS.
This is why a future Open Technology Academy should not primarily be a classroom.
Give an engineer a RISC-V board.
Give them a broken driver.
Ask them to make it work.
Ask them to write the test.
Ask them to document the solution.
Ask them to submit the patch upstream.
Ask someone else to review it.
Then let them maintain it.
That is education.
It produces engineers who have actually built things.
And those engineers become precisely the people India's deep-tech startups need.
The Long-Term Economic Flywheel
The model can eventually become self-reinforcing.
Shared open infrastructure
↓
Lower development cost
↓
More prototypes
↓
More startups
↓
More products
↓
More hardware adoption
↓
More engineering investment
↓
More contributions upstream
↓
Better infrastructure
↓
Lower development cost
This is an innovation flywheel.
And unlike a single product company, the foundation can benefit competitors simultaneously.
That is precisely why industry may need to fund it collectively.
Why Would Companies Pay?
A reasonable question follows:
Why would a company spend money improving software that its competitors can also use?
Because the alternative may be worse.
If every company independently employs 20 engineers to maintain similar infrastructure, the industry may spend far more collectively while getting inconsistent results.
A shared foundation allows companies to pool part of that cost.
Companies can then redirect more of their internal engineering budget toward differentiation.
The shared layer becomes a kind of pre-competitive infrastructure.
Companies compete above it.
They cooperate below it.
That is not anti-competition.
It is often what makes competition more productive.
The Government's Role Should Be Different
The government does not necessarily need to own the software.
It can create the conditions for the ecosystem to exist.
That could include:
- tax incentives for industry contributions
- procurement preferences for open standards
- research grants
- shared testing laboratories
- university partnerships
- hardware-access programmes
- security-audit support
- open-source procurement policies
- funding for critical infrastructure projects
- support for international collaboration
India already has experience with public-sector open collaboration. MeitY's OpenForge platform, for example, was established to promote collaborative development and reuse of government software and explicitly identifies reuse, sharing, transparency and lower total cost of ownership as objectives.
The next step would be to apply the same thinking much more broadly to the technology foundations used by Indian industry.
Paid People. Open Code. Independent Governance.
That could become the operating philosophy.
Engineers should be paid properly.
Projects should have professional maintainers.
Infrastructure should be professionally operated.
Security should be funded.
Testing should be funded.
Documentation should be funded.
But the resulting software should remain open under appropriate FLOSS licences.
Technical governance should remain independent from any single company.
And the organisation should strongly prefer upstream contribution over maintaining private forks.
The Real Competition Is Not India Versus Another Country
There is another mistake India should avoid.
The objective should not be to create an isolated Indian technology universe.
Technology develops globally.
India should collaborate with Europe, Japan, South Korea, the United States, Taiwan and other technology ecosystems where cooperation makes sense.
Indian engineers should participate in international open-source communities.
Indian companies should become serious members of global technical organisations.
And India should bring its own engineering capability back into the global commons.
The strongest model is therefore not technological isolation.
It is technological participation with the ability to remain independent when necessary.
Build the Foundation, Then Let a Thousand Companies Compete
This is perhaps the most important idea in this entire discussion.
India should not ask:
"How do we build one Indian company that does everything?"
It should ask:
"How do we create the foundations upon which a thousand Indian companies can build different things?"
One company builds a camera.
Another builds smart glasses.
Another builds a drone.
Another builds an agricultural robot.
Another builds an industrial robot.
Another builds a medical device.
Another builds an intelligent appliance.
Another builds a vehicle system.
Another builds an AI accelerator.
Another builds software for all of them.
And many of them share the same underlying infrastructure.
That is how a technology ecosystem becomes larger than the sum of its companies.
The Hidden Engineering Tax Can Become an Innovation Dividend
For decades, we have talked about reducing costs in manufacturing.
We talk about reducing logistics costs.
We talk about reducing transaction costs.
We talk about reducing the cost of capital.
Perhaps India should also think about reducing the cost of beginning technological innovation.
If a startup can reuse a mature foundation, it needs fewer engineers to reach its first prototype.
If a university can access the same platform, research can move faster.
If a manufacturer can reuse the same APIs, product development becomes easier.
If a new semiconductor can arrive with an ecosystem already waiting for it, hardware adoption accelerates.
If thousands of engineers contribute improvements to the same foundational projects, quality can rise faster than isolated teams could achieve individually.
The hidden engineering tax can therefore become an innovation dividend.
Build Once. Improve Continuously. Use Everywhere.
The phrase "build once" should not be interpreted literally.
Good infrastructure is never finished.
It evolves.
It needs maintenance.
It needs new hardware support.
It needs new security fixes.
It needs performance improvements.
It needs better APIs.
It needs better documentation.
It needs new developers.
It needs new tests.
It needs new ideas.
The real principle is:
Build the foundation once as a shared responsibility, then improve it continuously so that everyone does not have to rebuild it independently.
India's Opportunity
India has millions of engineers.
It has a huge domestic market.
It has an expanding electronics ecosystem.
It has growing semiconductor ambitions.
It has a substantial software industry.
It has universities producing technically capable graduates.
It has startups willing to experiment.
What is missing is not necessarily another product.
It may be the connective tissue between all these capabilities.
That connective tissue is the software plumbing.
Drivers.
APIs.
SDKs.
Runtimes.
Toolchains.
Testing.
Security.
Documentation.
Reference implementations.
Standards.
Integration.
Maintenance.
And people who know how to keep all of it working.
The Bigger Idea
There is a temptation to think that India's technological future will be determined by who builds the biggest chip, the fastest processor, the largest AI model or the most advanced robot.
Those things matter.
But ecosystems are rarely built from one spectacular component.
They are built from thousands of seemingly boring components that work together reliably.
The difference between a laboratory demonstration and a mass-market product is often not a single breakthrough.
It is the accumulated quality of the infrastructure underneath it.
That is why the boring work matters.
The driver matters.
The API matters.
The documentation matters.
The test suite matters.
The compiler matters.
The firmware matters.
The security update matters.
The developer tools matter.
The person answering the bug report matters.
And if those things are shared openly and maintained professionally, they can become enormously powerful economic infrastructure.
From Import to Innovation
India's technological journey has often been described in terms of importing technology, assembling products and gradually developing domestic capability.
The next stage should be more ambitious.
India should increasingly be able to:
Use → Understand → Maintain → Improve → Integrate → Build → Export.
That applies to hardware.
It applies to software.
It applies to AI.
It applies to robotics.
It applies to the entire technology ecosystem.
The objective is not to build everything ourselves.
The objective is to ensure that we can participate meaningfully in the layers that matter.
Conclusion: Build the Infrastructure That Makes Companies Possible
India does not need another organisation whose primary purpose is to build products that existing companies could already build.
It needs organisations that make it easier for existing and future companies to build those products.
That means investing in the foundations.
It means taking duplicated engineering effort seriously.
It means recognising engineering hours as a national resource.
It means funding maintainers.
It means supporting FLOSS.
It means contributing upstream instead of endlessly creating private forks.
It means building common APIs and reference implementations.
It means testing software on real hardware.
It means making documentation a first-class engineering output.
It means creating an environment in which a small startup can take a mature platform and immediately begin working on its own idea.
And it means understanding that foundational software is not the enemy of competition.
It is often what makes competition possible.
A company should not need to build an operating system to build a robot.
A startup should not need to build a driver stack to build smart glasses.
An appliance manufacturer should not need to reinvent networking.
A camera company should not need to reinvent every multimedia component.
A university should not need to create an entire platform before testing one new idea.
The foundational layer should be there, ready to use.
Open enough to inspect.
Stable enough to trust.
Well maintained enough to depend upon.
Flexible enough to modify.
And broad enough to support many different products.
Then let the startups compete.
Let the engineers experiment.
Let the manufacturers differentiate.
Let the researchers discover.
Let the entrepreneurs dream.
Let a thousand companies build a thousand different things on top of the same foundations.
Because the ultimate purpose of foundational technology is not to create one great product.
It is to make great products easier for everyone else to create.
Build once. Improve continuously. Use everywhere.
Don't make every startup rebuild the plumbing.
Build the infrastructure that makes more Indian companies possible.
