Tuesday, September 22, 2026

Break Free from Digital Rent: How a Family Can Reclaim Its Everyday Digital Infrastructure

Digital sovereignty does not begin in a data centre. It begins at home.

We have become accustomed to renting almost everything digital.

Our photographs live on someone else's servers. Our documents sit in someone else's cloud. Our calendars, notes, contacts and files are synchronised through infrastructure we do not own. Our entertainment depends on remote servers. Our knowledge disappears when the connection disappears. Increasingly, even our computing intelligence is rented by the request from somebody else's artificial intelligence service.

None of this is inherently bad.

The cloud is useful. Subscription services are useful. Large technology companies provide infrastructure that would be absurd for an ordinary household to reproduce independently.

But somewhere along the way, we allowed an important distinction to disappear.

There is a difference between using the cloud because it is useful and depending on the cloud because we have no alternative.

That distinction is the beginning of digital sovereignty.

The goal is not to eliminate the cloud.

The goal is to make the cloud optional.

What Is "Digital Rent"?

Digital rent is not simply a monthly subscription.

It is the recurring dependence on somebody else's infrastructure for capabilities that a household could reasonably own itself.

Consider the modern family.

One family member uses Google Drive. Another uses OneDrive. Photographs are stored in Google Photos or iCloud. Important documents are scattered across email accounts, WhatsApp conversations, USB drives and cloud folders. Bills are PDFs somewhere. Insurance documents are somewhere else. The children's photographs are on several phones. Old family videos are sitting on an ageing laptop. Nobody quite knows where the important documents are.

Then there are subscriptions for entertainment, productivity, backups, passwords, AI and other services.

Individually, these services may cost very little.

Together, they create a different kind of infrastructure: a subscription stack.

Every month, money leaves the household in exchange for continued access to pieces of its own digital life.

Again, there is nothing inherently wrong with paying for useful services.

The question is:

Which parts of this infrastructure should a family actually own?

The Family Cloud

We tend to think of "the cloud" as something that exists in enormous corporate data centres somewhere far away.

But technically, a cloud is simply computing and storage made available over a network.

There is no reason why a small version of that concept cannot exist inside a home.

Imagine a quiet computer sitting in a cupboard or a small utility room.

It does not need flashing lights. It does not need a rack. It does not need to look like a data centre.

It simply provides the family's everyday digital infrastructure.

                         FAMILY CLOUD
                              |
          +-------------------+-------------------+
          |                   |                   |
        FILES              PHOTOS            DOCUMENTS
          |                   |                   |
      Nextcloud       Nextcloud Photos       Paperless-ngx
          |             / Memories                |
          |                   |                   |
          +-------------------+-------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
       KNOWLEDGE            MEDIA              BACKUP
          |                   |                   |
        Kiwix              Jellyfin          Versioned
                                               backups
                              |
                         PRIVATE ACCESS
                              |
                       VPN / Tailscale
                              |
                      Family, anywhere

This is not science fiction.

Most of the software required already exists, and much of it is open source.

Nextcloud, for example, is designed as a self-hosted platform for files and collaboration and can hold documents, photos, contacts and calendars on infrastructure controlled by the user.

The interesting question is therefore no longer "Can a family have its own cloud?"

The question is "How much of the family's everyday digital life should live there?"

Start With the Things That Matter Most

A family does not need to reproduce every service offered by Google, Microsoft or Amazon.

That would miss the point.

The sensible approach is to begin with the services where ownership provides the greatest benefit.

1. Files: Your Family's Digital Filing Cabinet

The first and most obvious component is shared storage.

Nextcloud can provide a central location for:

  • family documents
  • school material
  • tax records
  • travel documents
  • household spreadsheets
  • personal files
  • shared folders
  • contacts and calendars
  • photos and videos

The important difference is not simply that the files are stored locally.

It is that the family controls the underlying infrastructure.

A phone can synchronise with the server. A laptop can access the same files. A family member travelling to another city can connect remotely. Multiple people can have separate accounts and permissions.

Instead of asking, "Which cloud account contains that file?" the question becomes:

"Which folder in our family cloud contains it?"

2. Photos: Turn the Family Server Into Family Memory

Photographs may be the most emotionally valuable data a household owns.

Yet photographs are increasingly treated as disposable cloud data.

We take thousands of photographs every year, upload them automatically, and assume that somebody else's servers will preserve them forever.

A family-owned server changes the relationship.

Nextcloud already provides photo and video functionality, and its ecosystem includes applications such as Memories and Recognize that can add more advanced photo organisation, tagging and on-premises machine learning capabilities.

That means a household does not necessarily need a separate dedicated photo platform from the beginning.

Start with Nextcloud.

If the family's photographic collection eventually becomes large or demanding enough to justify a specialist platform such as Immich, it can be added later.

This is an important principle:

Do not install another system merely because another system exists.

Install it when the additional capability is actually useful.

3. Documents: From Paper Mountain to Searchable Archive

Documents are slightly different.

Nextcloud is excellent as a file platform, but a household with years of bills, insurance documents, receipts, certificates and scanned paperwork may eventually want something more specialised.

This is where Paperless-ngx becomes interesting.

Paperless-ngx is designed specifically to transform physical documents into a searchable digital archive. It can OCR documents, classify them by tags, correspondents and types, retain original files and create archival PDF/A versions.

Imagine being able to search your household's documents for:

  • "car insurance"
  • "electricity bill March 2025"
  • "washing machine warranty"
  • "property tax"
  • "passport"
  • "school certificate"
  • "bank statement"

That is much more useful than simply having a folder called Documents.

Nextcloud becomes the family's general-purpose cloud.

Paperless-ngx becomes the family's specialised records archive.

And if a household does not need that level of document management, it can simply use Nextcloud.

4. Knowledge: Put Wikipedia in the House

This is where Kiwix becomes particularly beautiful.

We normally think of knowledge as something we retrieve from the Internet.

Kiwix reverses the relationship.

It lets users download knowledge archives in the ZIM format and access them without an Internet connection. Wikipedia is the best-known example, but Kiwix also distributes archives covering resources such as Wiktionary, Wikivoyage, Project Gutenberg, Stack Exchange and other collections.

Instead of every family member downloading the same enormous archive independently, a household server can store the ZIM files once.

Kiwix Server can then make that content available to everyone on the local network through an ordinary web browser. Kiwix explicitly supports this central-server model and can run on Linux and Raspberry Pi as well.

The result is surprisingly powerful.

Your children can browse Wikipedia even when the Internet connection is unavailable.

You can keep reference material locally.

You can preserve knowledge that you consider important.

And the family's access to that knowledge no longer depends entirely on whether an external service happens to be reachable.

Kiwix is therefore more than an offline Wikipedia reader.

It represents a different philosophy:

Some knowledge should be portable enough to own.

5. Media: Your Own Household Library

Media is another area where the local-server concept can become useful.

Jellyfin, for example, can provide a household media server for content that the family legally owns or has permission to store and stream.

Modern hardware can also make local media serving surprisingly efficient.

Jellyfin supports hardware-accelerated transcoding using Intel Quick Sync, NVIDIA NVENC/NVDEC and AMD hardware acceleration among other platforms. Direct Play, where the client's device can play the original file without transcoding, places very little load on the server.

This is one reason the eventual family server does not need to be a monster.

If everybody in the household can directly play the original media format, the server mostly serves files.

The heavier work happens when a device requires transcoding.

That is also why choosing hardware with a capable integrated media engine can sometimes be more valuable for a family server than choosing the fastest CPU available.

6. Synchronisation Without a Central Cloud

There is another important category: synchronisation.

Sometimes the requirement is not "store everything centrally."

Sometimes the requirement is:

"Keep these devices in sync."

That is where tools such as Syncthing become interesting.

A laptop can synchronise a folder with the family server. A second computer can maintain another copy. A family member can have selected folders replicated to another location.

This changes the architecture from:

Device -> Cloud -> Device

to:

Device <------> Family infrastructure <------> Device

And for some data, it can become:

Device A <------> Device B
     \              /
      \            /
       Family Server

The infrastructure becomes a coordination point rather than an unavoidable intermediary.

7. Remote Access: The VPN Is the Private Road Home

This is the part that makes the entire concept practical for a modern family.

A home server would be of limited value if it only worked when everybody was sitting inside the house.

Fortunately, it does not have to.

A VPN can create an encrypted connection between a travelling family member and the home network.

        Family member in another city
                    |
                 Phone
                    |
               VPN tunnel
                    |
                Internet
                    |
                    v
               Home network
                    |
                    v
              Family server
                    |
          +---------+---------+
          |         |         |
       Nextcloud  Kiwix   Documents

Technologies such as WireGuard provide the underlying VPN capability, while services such as Tailscale make private-network management easier.

Tailscale's subnet-router model is particularly useful for a household because a remote device can reach services and devices on the home subnet even when those devices themselves do not run Tailscale.

That means the VPN does not have to be limited to Nextcloud.

It can eventually become the private entrance to the household network.

A family member travelling to Delhi, Pune, Bengaluru or anywhere else could connect their phone or laptop to the family's private network and access authorised resources back home.

There is also an important distinction between a subnet router and an exit node.

A subnet router provides access to specific private resources on the home network. An exit node, by contrast, can route a device's general Internet traffic through the home connection. Tailscale documents these as separate functions.

For our family cloud, the first model is usually what we want.

We want:

Phone -> VPN -> Home -> Family Server

not necessarily:

Phone -> VPN -> Home -> Entire Internet

This is a subtle but important distinction.

The Family Server Does Not Need to Be Exposed to the Internet

There is another advantage to this approach.

Without a private networking layer, a household might be tempted to expose several individual services directly to the public Internet.

Internet
   |
   +-- Nextcloud
   +-- Paperless
   +-- Kiwix
   +-- Home Assistant
   +-- Admin interface
   +-- Other services

That creates unnecessary exposure.

A more disciplined architecture is:

Internet
   |
VPN / secure private network
   |
Home network
   |
Family server
   |
+----------+----------+----------+
|          |          |          |
Nextcloud  Kiwix   Paperless  Other services

That does not eliminate the need for strong authentication, updates, backups and sensible network security.

It simply reduces the number of services that need to be publicly reachable.

Local First, Not Cloud Never

This distinction is essential.

The argument for family-owned infrastructure is not an argument against cloud computing.

There are many things a household should rent.

It would be absurd to operate our own global content-delivery network simply to avoid paying a CDN.

It would be absurd to build a hyperscale GPU cluster because we want to experiment with one large AI model.

It would be absurd to reproduce the infrastructure required to run a global search engine inside a home.

The cloud is extraordinarily good at handling workloads that are enormous, temporary, specialised or geographically distributed.

Use it.

The problem is allowing the cloud to become the only place where our digital lives can exist.

A better model is:

                    LOCAL FIRST
                        |
          +-------------+-------------+
          |             |             |
       Own data     Own services   Own backups
          |             |             |
          +-------------+-------------+
                        |
                  CLOUD WHEN USEFUL
                        |
          +-------------+-------------+
          |             |             |
      Frontier AI   Large compute   Off-site backup

That leads to a simple principle:

Own the everyday. Rent the extraordinary.

The Economics of Ownership

At first glance, self-hosting can look expensive.

A decent server costs money.

Storage costs money.

Electricity costs money.

Backup storage costs money.

Eventually something will fail and need replacement.

So it would be dishonest to claim that a family server automatically saves money compared with every possible collection of subscriptions.

That is not the strongest argument anyway.

The stronger argument is optionality.

Suppose a cloud provider changes its pricing.

You have options.

Suppose a service disappears.

You have your data.

Suppose the Internet connection fails.

Your locally stored files and knowledge remain available.

Suppose a family member changes cities.

The family infrastructure does not have to move with them.

Suppose you decide that a particular cloud AI service is no longer worth paying for.

Your local machine can still perform smaller AI workloads.

Ownership therefore provides something that a subscription cannot:

the ability to change your mind.

But There Is One Rule: RAID Is Not Backup

This deserves to be written in large letters because it is one of the easiest mistakes to make.

RAID IS NOT BACKUP.

RAID can protect availability when a drive fails.

It does not protect you from accidental deletion.

If ransomware encrypts your files, RAID can faithfully preserve the encrypted files across the array.

If somebody accidentally deletes a folder, the deletion can be replicated.

If the computer is stolen, the RAID disappears with it.

If the house floods or burns, the RAID does not help.

A sensible family infrastructure should therefore separate:

  1. Working storage — the main data the family uses every day.
  2. Historical backup — versioned backups that allow older versions to be recovered.
  3. Off-site backup — another copy protected from a disaster affecting the house.

The familiar 3-2-1 backup principle remains useful:

3 copies of important data, on 2 types of media, with 1 copy off-site.

Ironically, this is another place where digital sovereignty does not mean doing everything yourself. An encrypted off-site backup can still be an excellent use of cloud infrastructure.

The objective is not ideological purity.

The objective is resilience.

What About Local AI?

Once the family owns a capable computer, another possibility appears.

Artificial intelligence no longer has to mean sending every question and every document to a remote server.

A household computer can potentially run smaller language models, speech recognition, OCR, embeddings, image analysis and other AI workloads locally.

The important word is smaller.

A family server does not need to run the largest model available on Earth.

It may simply need to answer questions such as:

  • "Find the insurance documents for the car."
  • "Which folder contains our house documents?"
  • "Summarise the warranty information for the washing machine."
  • "Find photographs from our 2024 holiday."
  • "Search the family archive for documents mentioning this address."

That is a very different problem from running a frontier model.

And the more capable the local hardware becomes, the more interesting this possibility gets.

The local AI does not have to replace cloud AI.

It can handle the tasks where local ownership makes sense, while the household continues to use external AI for workloads that require much larger models.

The Hardware Is Surprisingly Ordinary

The hardware required for all of this is not exotic.

A small ARM computer can be enough for a modest household.

A mini-PC can provide considerably more CPU capacity.

A conventional desktop can provide large amounts of RAM, multiple NVMe drives, several hard drives, PCIe expansion and eventually a discrete GPU.

A sensible family server might eventually have:

  • a modern multi-core processor
  • 32–64GB or more of RAM
  • NVMe storage for the operating system and applications
  • several terabytes of bulk storage
  • Gigabit or faster Ethernet
  • an independent backup system
  • a UPS for resilience
  • optional GPU acceleration for AI or media

The exact processor matters much less than the overall architecture.

The important question is whether the machine is adequate, expandable, efficient and supportable.

That word — adequate — is worth remembering.

We do not need every household computer to be a datacentre.

We need ordinary computers to be extraordinarily adequate.

The Missing Hardware Platform

And this brings us back to a subject explored in earlier Sovereign Pulse articles.

Today, somebody building such a family server has to choose among platforms developed by companies such as AMD, Intel, Apple, Qualcomm, MediaTek, Rockchip and others.

There is nothing wrong with that.

In fact, using excellent existing hardware is precisely what should happen today.

But imagine a future generation of open or more locally controllable computing platforms designed around this kind of workload.

Not a chip designed solely to win a benchmark.

Not a processor designed solely for a datacentre.

Not an enormous GPU intended for frontier AI.

Instead:

                    ADEQUATE GEN4 SoC
                           |
          +----------------+----------------+
          |                |                |
         CPU              GPU              NPU
          |                |                |
      general work      graphics &       efficient
                        parallel AI        AI
          |                |                |
          +----------------+----------------+
                           |
                     Memory controller
                           |
                    DDR4 / DDR5 class
                           |
          +----------------+----------------+
          |                |                |
         PCIe           Ethernet       USB / I/O
          |
       NVMe / expansion

Imagine an efficient 22nm FD-SOI-based platform with enough CPU performance for Linux, enough integrated graphics for ordinary workloads, a useful NPU for supported AI tasks, hardware video acceleration, modern memory and I/O, and an ecosystem of open drivers and development tools.

It would not need to beat every contemporary flagship processor.

It would need to be good enough.

Why "Good Enough" Could Be a Powerful Strategy

This is where the idea of adequate hardware becomes economically interesting.

If a processor is designed to chase the absolute peak of performance, its development and manufacturing requirements become increasingly demanding.

But most households do not need the absolute peak.

They need a machine that can run:

  • Linux
  • Nextcloud
  • photo management
  • document management
  • Kiwix
  • media serving
  • VPN
  • backup systems
  • home automation
  • small local AI models

If an integrated Gen4 platform can perform those tasks reliably and efficiently, it has already created enormous value.

The same platform could then appear in:

  • family servers
  • mini-PCs
  • desktops
  • laptops
  • NAS systems
  • routers
  • industrial computers
  • edge-AI devices
  • embedded systems

One computing platform could support an entire ecosystem.

That is much more important than producing one impressive processor.

Build the Platform, Not Just the Chip

This is also where our earlier argument about open technology becomes relevant.

A CPU alone does not create an ecosystem.

You need:

  • compilers
  • Linux support
  • GPU drivers
  • NPU runtimes
  • media codecs
  • firmware
  • development boards
  • debugging tools
  • documentation
  • libraries
  • container support
  • application frameworks

In other words:

The silicon is only the beginning.

This is exactly why the "build once, use everywhere" principle matters.

Developers should not have to reinvent the software stack every time a new piece of hardware appears.

The common layer should be built once and improved continuously.

Then hundreds of companies can build products above it.

The Family Server Could Be a Real Test of Sovereign Computing

This may sound like a surprisingly small application for a national technology strategy.

It is not.

The family server is an unusually good test because it combines almost everything:

CPU
GPU
NPU
Storage
Networking
Security
Linux
Databases
AI
Media
Backup
User interfaces
Mobile applications
Remote access

If a computing platform can make a genuinely good family server, it already has many of the components required for much larger markets.

The family server is therefore not merely a hobby project.

It can be a reference workload.

It asks a simple question:

Can ordinary people use this technology to own useful computing?

From the Household to the Ecosystem

Now consider what happens if one family server becomes ten thousand.

Ten thousand becomes one hundred thousand.

Hardware manufacturers have a larger market.

Linux developers have more users.

Application developers have more targets.

AI developers have more hardware on which to optimise.

Support communities grow.

Documentation improves.

Component suppliers gain volume.

Eventually, the platform becomes easier to build on because more people are building on it.

This is the same feedback loop we have discussed in the context of open silicon and FLOSS.

Infrastructure creates markets.

The market does not always have to appear first.

Sometimes the infrastructure creates the conditions under which the market becomes possible.

We Do Not Need to Reject the Cloud

There is a temptation whenever digital sovereignty is discussed to turn the argument into a battle between "local" and "foreign", or "open" and "proprietary".

That is unnecessary.

A family server can happily use an external cloud provider for off-site backup.

It can use a commercial AI service when a larger model is useful.

It can stream a service that the family does not want to host.

It can use commercial email.

It can use a CDN.

It can use a payment service.

There is nothing sovereign about rebuilding infrastructure that somebody else can provide far more efficiently.

The sensible objective is different:

Own what is ordinary, personal and persistent. Rent what is extraordinary, temporary or uneconomic to reproduce.

The Real Goal: Optionality

That may be the most important word in this entire discussion.

Optionality.

If all your photographs exist only in one company's cloud, you have little choice.

If your documents exist only inside a proprietary service, you have little choice.

If your knowledge disappears when your Internet connection disappears, you have little choice.

If every AI interaction requires a remote service, you have little choice.

But if a significant portion of your digital life exists on infrastructure you control, the relationship changes.

You can still use the cloud.

You can still subscribe to services.

You can still use commercial software.

But you can leave.

And the ability to leave is a form of freedom.

Sovereignty Starts at Home

Digital sovereignty is often discussed at the level of governments, national infrastructure and strategic industries.

Those questions matter.

But sovereignty has a smaller and more immediate starting point.

The home.

A family server will not change geopolitics.

It will not replace hyperscale cloud infrastructure.

It will not make every digital service open source.

It does something much simpler.

It puts a small but meaningful portion of digital life back under the family's control.

Your files can live in your house.

Your photographs can live in your house.

Your documents can live in your house.

Your knowledge can live in your house.

Your backups can exist under your control.

Your private services can be reachable through your own private network.

And eventually, some of your computing intelligence can live there too.

That is not a rejection of the modern Internet.

It is a more mature relationship with it.

Build the Family Cloud First

The beauty of this idea is that it does not require a giant project.

Start with one machine.

Install Linux.

Put your files in Nextcloud.

Back up your photographs.

Put important documents into a searchable archive.

Download the knowledge that you want available offline.

Set up proper backups.

Add a VPN.

Then stop.

Use it.

Find out what the family actually needs.

Only then add more.

Perhaps the next step is a better photo system.

Perhaps it is Jellyfin.

Perhaps it is Home Assistant.

Perhaps it is a local AI model.

Perhaps it is simply another backup drive.

The system should grow according to actual requirements, not according to a homelab checklist.

The Bigger Picture

There is a larger lesson here.

For years, the personal computer moved in one direction.

First we owned the hardware.

Then software became increasingly dependent on online services.

Then storage moved into the cloud.

Then applications moved into subscriptions.

Then computing itself began moving into remote AI services.

There are good reasons for every step.

But there is no law of nature saying that the entire digital life of a person or family must move in the same direction.

We can choose a hybrid future.

A future in which the cloud remains enormously useful, but the home once again contains meaningful computing capability.

A future in which a family owns its digital memories.

A future in which knowledge can survive the loss of connectivity.

A future in which local AI handles private tasks while cloud AI handles extraordinary ones.

A future in which computers are appliances for ownership, not merely terminals for renting access.

Own the Everyday. Rent the Extraordinary.

This is ultimately what "breaking free from digital rent" should mean.

Not abandoning the Internet.

Not refusing every subscription.

Not pretending that every family should become a systems administrator.

And certainly not rebuilding every service that already works better at enormous scale.

It means identifying the parts of digital life that are personal, persistent, affordable to own and important enough to preserve.

Then bringing those parts home.

The family cloud is only the beginning.

Behind it is a larger idea about computing itself.

We should have computers that are powerful enough without being excessive. Efficient enough to remain switched on. Open enough to be maintained. Expandable enough to survive changing requirements. And affordable enough that ownership is not restricted to large corporations.

That is where our earlier discussion about open silicon and a future Gen4 computing platform becomes relevant.

Perhaps the goal of a future 22nm FD-SOI Gen4 system should not be to win every benchmark against the world's most advanced processors.

Perhaps its goal should be something more useful:

to be an extraordinarily adequate computer.

A computer that can run Linux.

A computer that can serve a family cloud.

A computer that can store knowledge.

A computer that can process photographs and documents.

A computer that can run useful local AI.

A computer that can sit quietly in millions of homes and do useful work for years.

That would be more than a processor.

It would be infrastructure.

And infrastructure is what makes digital independence possible.

Conclusion

We don't need to leave the cloud.

We need to stop assuming that everything has to live there.

We don't need to build a hyperscaler in our homes.

We need enough computing to own the parts of digital life that matter.

We don't need every processor to be extraordinary.

We need ordinary computers to be extraordinarily adequate.

And we don't need to build everything ourselves.

We need open, reusable infrastructure on which many people can build.

That is the same principle at every scale.

From FLOSS libraries to open hardware.

From common software infrastructure to family servers.

From a household's digital archive to an indigenous computing ecosystem.

Build once. Use everywhere.

Own the everyday. Rent the extraordinary.

And perhaps most importantly:

Digital sovereignty starts at home.

Friday, September 18, 2026

Build Once, Use Everywhere: India's Hidden Engineering Tax and the Missing Productivity Layer in Its Startup Economy

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.

Thursday, September 17, 2026

Build the Plinth, Not Every Statue: Why India Needs an Open Technology Consortium

India's next technology challenge is not simply designing more chips, writing more software or manufacturing more devices. It is making all of these pieces work together. An industry-funded, FLOSS-first technology consortium could provide the common software plumbing, APIs, standards, reference implementations and engineering infrastructure on which India's next generation of hardware and software companies can build.

The Missing Layer

India's technology conversation is increasingly moving beyond software services.

There is now serious discussion around semiconductors, RISC-V, electronics manufacturing, embedded systems, artificial intelligence, robotics, automotive electronics, IoT devices and sovereign computing.

But there is a layer between the semiconductor and the finished product that is easy to underestimate.

It is the enormous amount of software that makes hardware usable.

A processor is not a smartphone. A GPU is not a laptop. An NPU is not an AI product. A Wi-Fi chip is not a connected appliance.

Between the silicon and the application sits an enormous amount of engineering:

  • bootloaders
  • operating-system support
  • device drivers
  • hardware-abstraction layers
  • graphics frameworks
  • media frameworks
  • AI and NPU runtimes
  • networking
  • Bluetooth and Wi-Fi support
  • power management
  • security
  • secure boot
  • firmware updates
  • diagnostics
  • storage
  • developer tools
  • SDKs
  • testing infrastructure
  • documentation
  • hardware compatibility

Much of this work is not what makes a particular product special.

It is plumbing.

And India has an opportunity to build that plumbing as shared infrastructure.

The Plinth and the Statue

Imagine a giant statue.

The statue gets all the attention. It is what people see. It is what makes the structure distinctive.

But the statue needs a plinth.

The plinth does not compete with the statue. It makes the statue possible.

That is how India's open technology ecosystem should think about common software infrastructure.

The consortium should not attempt to build the next smartphone, refrigerator, automobile, robot vacuum cleaner or television.

It should build the plinth on which thousands of such products can stand.

The manufacturer builds the statue.

The startup creates the distinctive shape.

The semiconductor company builds the silicon.

The consortium makes the interfaces between them predictable, reusable and open.

This distinction is crucial.

Standardise the Plumbing, Not the Product

Consider a smart refrigerator.

Its manufacturer might have proprietary algorithms for compressor control, food preservation, energy management and temperature prediction.

Those things can remain proprietary.

But the refrigerator still needs:

  • network connectivity
  • secure boot
  • firmware updates
  • sensor interfaces
  • storage
  • power management
  • diagnostics
  • security
  • device management
  • AI acceleration, if used

There is little reason for every manufacturer to independently reinvent every one of these layers.

The same principle applies to washing machines, air conditioners, televisions, monitors, robot vacuums, industrial controllers, automobiles, smart watches, cameras and eventually smartphones.

The consortium could provide common APIs and reference implementations for the boring but essential parts.

Companies could then compete on the interesting parts.

Think of It as a Modular Stack

The architecture could look something like this:

                         PRODUCT
                           |
                 Company-specific software
                           |
                 ---------------------
                    COMMON APIs
                 ---------------------
                           |
          +----------------+----------------+
          |                |                |
       Graphics          AI/NPU          Camera
          |                |                |
       Media            Security        Sensors
          |                |                |
       Network         Storage          Power
          |                |                |
          +----------------+----------------+
                           |
                    Hardware HAL
                           |
                     Device Drivers
                           |
                Linux / RTOS / Firmware
                           |
                 RISC-V / Other CPU
                           |
                  GPU / NPU / VPU / I/O
                           |
                       SILICON

The important word is modular.

A company should be able to replace the underlying hardware without having to throw away its entire software investment.

Likewise, a semiconductor company should be able to offer a new chip without requiring every application developer to learn an entirely new software environment.

The AI Analogy Is Particularly Useful

Artificial intelligence provides an excellent analogy.

An application does not necessarily need to know every internal detail of an AI model.

It can communicate through defined interfaces.

The same principle can be applied to hardware.

An application might request an AI inference operation through a common NPU interface.

Underneath that interface could be an NPU from one semiconductor company or a completely different accelerator from another.

The application should not have to be rewritten from scratch every time the silicon changes.

The same idea can apply to:

  • GPU acceleration
  • video decoding
  • camera processing
  • audio processing
  • sensor access
  • cryptography
  • storage
  • networking
  • power management

The consortium therefore does not necessarily need to standardise the implementation.

It needs to standardise the interface.

Different companies can then compete underneath that interface.

RISC-V Needs This Layer

This becomes particularly important as India and other countries explore RISC-V.

The RISC-V instruction-set architecture provides an open foundation for processor design, but a processor ecosystem is much larger than an instruction set.

A successful hardware platform needs compilers, operating systems, drivers, debugging tools, graphics support, AI frameworks, security infrastructure, applications and developer documentation.

Without those layers, a technically impressive processor can remain a demonstration rather than becoming a mass-market platform.

India therefore should not define its RISC-V ambition merely as:

"We need an Indian RISC-V processor."

A more ambitious objective would be:

"We need an ecosystem in which RISC-V processors can become first-class computing platforms."

That requires software.

And software is where a consortium can create enormous leverage.

One Investment, Many Industries

Consider the number of industries that could potentially share portions of the same foundation.

Industry Common Infrastructure Product Differentiation
Smartphones Drivers, graphics, AI, connectivity, security, updates Camera, UI, industrial design, applications, AI features
Smart TVs Graphics, video, audio, networking, storage, OTA Display processing, UI, recommendations, brand features
Smart monitors Display, USB, networking, firmware, power management Panel features, productivity software, image processing
Automobiles Security, networking, middleware, OTA, compute abstraction ADAS, vehicle algorithms, infotainment, proprietary systems
Robot vacuums Sensors, motors, connectivity, AI runtime, device management Navigation, SLAM, cleaning algorithms and mapping
Refrigerators Connectivity, sensors, security, OTA, diagnostics Cooling, energy and food-management algorithms
Washing machines Motor interfaces, sensors, connectivity, security Wash algorithms, load detection and user experience
Air conditioners Sensors, networking, power management, OTA Thermal algorithms, energy optimisation and control
Industrial IoT Networking, security, device management, diagnostics Industrial applications and control algorithms
Robotics Motor control, sensors, compute and AI runtimes Robot intelligence, navigation and task-specific software

One common investment could therefore support many industries.

That is the economic logic behind a consortium.

It Could Lower the Barrier for Startups

This may ultimately be one of the consortium's greatest contributions.

Imagine a startup with twenty engineers wanting to build a new industrial robot.

It should not have to spend the first year writing its own basic infrastructure for networking, firmware updates, security, hardware abstraction, graphics, device management and accelerator support.

It should be able to start much higher up the stack.

Its question should be:

"What can our company do that nobody else does?"

rather than:

"How do we recreate the infrastructure that hundreds of companies have already recreated?"

This is particularly important in India because the country has an enormous base of engineers and startups but cannot afford to duplicate expensive engineering effort indefinitely.

A common open foundation allows the same engineering work to create value across many companies.

Build Once. Improve Together.

There is another advantage to the open model.

A proprietary solution maintained by one small company can become a liability if that company disappears.

An open project can potentially survive changes in individual companies because the code, documentation, issue history and technical knowledge remain available to a wider community.

That does not automatically make open-source software sustainable. Open projects still require maintainers, infrastructure, security work and funding.

That is precisely why the consortium needs to exist.

Open source without maintainers is an abandoned building.

Open source with sustained engineering investment becomes infrastructure.

The Apache and Eclipse Lessons

This idea would not need to be invented from scratch.

The Apache Software Foundation demonstrates one model in which individual projects retain substantial technical autonomy while operating within a common foundation and governance structure. Apache explicitly describes its projects as self-governing and driven by their communities, with Project Management Committees responsible for project governance.

The Eclipse Foundation provides another useful model. Its working groups allow companies and other participants to collaborate around shared industry problems while maintaining vendor-neutral governance. Eclipse currently operates industry collaborations across areas including automotive, IoT, edge computing, developer tooling and open hardware.

These examples suggest an important principle:

The foundation can provide the legal, financial, infrastructure and coordination layer without becoming the technical owner of everything.

That distinction should be fundamental to any Indian model.

The Indian Model: Fund the Commons

Imagine an Indian Open Technology Foundation.

It could be funded primarily by industry, with government acting as an enabler rather than the owner of the technology.

Potential members could include:

  • semiconductor companies
  • automobile manufacturers
  • electronics manufacturers
  • appliance companies
  • telecom companies
  • IT companies
  • cloud providers
  • startups
  • universities
  • research institutions
  • multinational companies operating significant engineering organisations in India

The government could support the ecosystem through appropriate incentives, research funding, procurement opportunities, testing infrastructure, university programmes and other mechanisms.

But the code should remain open and the technical governance should remain independent.

This leads to a simple division of responsibility:

  • Government: create favourable conditions.
  • Industry: provide funding and engineering resources.
  • Universities: provide research and talent.
  • Foundation: provide infrastructure, coordination and long-term stewardship.
  • Developers: build and maintain the technology.
  • Open-source communities: retain technical authority over projects.

Do Not Fork the World

This principle is particularly important.

India should not create an Indian copy of every major open-source project.

If the world already has an excellent project, India should contribute to it.

If an important project needs more maintainers, India can supply maintainers.

If it needs better documentation, India can provide documentation.

If it needs better hardware support, India can provide hardware support.

If it needs security work, India can fund security engineering.

If it needs testing infrastructure, India can build testing infrastructure.

The objective is not to create an Indian island.

The objective is to make India one of the major engineering centres of the global open technology commons.

That would be genuine technological participation rather than technological isolation.

The 10,000-Engineer Idea Looks Different in This Model

Earlier, the idea of a large publicly supported pool of software engineers might sound like an employment programme.

Within this model, it becomes something else.

It becomes strategic maintainership.

India could support a large engineering workforce dedicated to maintaining critical open infrastructure.

Some could work directly for the foundation.

Others could remain employees of member companies while contributing upstream.

Some could specialise in Linux and embedded systems.

Others could work on LLVM, graphics, AI runtimes, security, automotive software, networking, firmware, testing or documentation.

The important metric would not simply be how many lines of code they produce.

It would be:

  • how many important projects they maintain
  • how many hardware platforms they support
  • how many vulnerabilities they help resolve
  • how many companies can build on their work
  • how many Indian products become easier to develop
  • how much duplicated engineering effort disappears

Canonical India Could Become the Integration Layer

This is where the earlier idea of a hypothetical Canonical India becomes interesting.

It need not simply mean an Indian Linux distribution.

It could instead be conceived as a platform-engineering organisation responsible for making the pieces work together.

Its test laboratory could continuously test:

  • Linux
  • bootloaders
  • RISC-V processors
  • GPUs
  • NPUs
  • VPUs
  • Wi-Fi and Bluetooth
  • cameras
  • displays
  • audio
  • power management
  • storage
  • automotive hardware
  • embedded hardware

New hardware could enter the laboratory.

The platform could be tested against real workloads.

Problems could be reported upstream.

Drivers could be improved.

Documentation could be updated.

The next hardware generation could then be designed with real software experience in mind.

This creates a feedback loop between silicon and software.

Hardware Becomes a Testbed for Software

This is one of the strongest aspects of the model.

Suppose an Indian semiconductor company develops a new RISC-V SoC.

The consortium could put it through a common platform test suite.

It could measure:

  • boot time
  • power consumption
  • driver maturity
  • GPU performance
  • NPU performance
  • memory bandwidth
  • storage performance
  • video playback
  • browser performance
  • application compatibility
  • security
  • sleep and wake behaviour
  • thermal behaviour

The results could then feed back into both software and hardware engineering.

Hardware manufacturers learn what software actually needs.

Software developers learn what hardware actually does.

The ecosystem gradually becomes better at both.

Common Standards Could Create Hardware Competition

This is perhaps the most interesting economic consequence.

Imagine three companies producing different embedded SoCs.

If all three support the same open platform APIs, a product manufacturer can potentially evaluate them based on:

  • price
  • power
  • performance
  • AI capability
  • memory bandwidth
  • security
  • longevity

rather than being locked into a completely different software environment for every chip.

That makes the silicon market more contestable.

Competition shifts toward the things semiconductor companies should actually compete on.

The software layer becomes an ecosystem multiplier rather than a barrier to entry.

Open Does Not Mean Everything Must Be Open

This distinction should also be made clearly.

A company should be able to keep genuinely differentiating intellectual property proprietary.

A car manufacturer does not have to open-source its autonomous-driving algorithms simply because it uses an open operating system.

A refrigerator company can keep its energy-management algorithm proprietary.

A smartphone company can develop its own camera algorithms.

A robot manufacturer can maintain proprietary navigation technology.

The common platform should exist underneath them.

In simple terms:

Open the foundation. Compete on the innovation.

From RISC-V to the Mass Market

This is ultimately why the software consortium matters to the semiconductor programme.

A new processor does not become successful merely because it works in a laboratory.

It becomes successful when developers can build applications for it, manufacturers can integrate it, consumers can buy products using it and companies can support those products for years.

That requires an ecosystem.

And ecosystems are built through shared infrastructure.

The path could therefore look like:

Open ISA
   ↓
Open silicon
   ↓
Common drivers
   ↓
Common APIs
   ↓
Common SDKs
   ↓
Common testing
   ↓
Common security infrastructure
   ↓
Reference platforms
   ↓
Startups
   ↓
Products
   ↓
Consumers
   ↓
More hardware demand
   ↓
More semiconductor investment
   ↓
Better hardware
   ↓
Better software
   ↓
More products

This is a flywheel.

The Consortium Could Become India's Technology Pedestal

There is a temptation in national technology strategies to focus on visible objects.

The fab.

The processor.

The laptop.

The smartphone.

The robot.

The supercomputer.

Those are important.

But underneath all of them are thousands of invisible interfaces.

Those interfaces determine whether components can communicate, whether developers can reuse their work, whether hardware can be replaced, whether software survives a company disappearing and whether a new startup can enter the market without spending years rebuilding infrastructure.

That invisible layer may ultimately be one of the most strategically important parts of the ecosystem.

India does not need to build every statue.

It needs to build the plinth on which thousands of statues can stand.

A Different Definition of Technology Sovereignty

Technology sovereignty does not have to mean manufacturing everything domestically.

Nor does it mean rejecting technology developed elsewhere.

A more useful definition might be:

The ability to understand, integrate, maintain, modify and improve the technologies on which an economy depends.

Under that definition, contributing thousands of engineers to global open-source projects is itself a form of technological capability.

Maintaining critical drivers is capability.

Building open APIs is capability.

Creating compatibility test suites is capability.

Supporting RISC-V in Linux and development tools is capability.

Building NPU runtimes is capability.

Maintaining security infrastructure is capability.

Writing documentation is capability.

Making a new semiconductor usable by thousands of developers is capability.

The Bigger Vision

The most interesting outcome would not be an "Indian operating system."

It would not be an "Indian version" of every application.

It would not even necessarily be an exclusively Indian hardware stack.

It would be an ecosystem in which Indian engineers, companies, universities and startups become major contributors to the open technological infrastructure used by the world.

India could contribute silicon.

India could contribute software.

India could contribute standards.

India could contribute maintainers.

India could contribute testing infrastructure.

India could contribute documentation.

India could contribute reference designs.

And Indian companies could then build differentiated products on top of that commons.

That creates a virtuous cycle:

             FUND THE COMMONS
                    ↓
             MAINTAIN THE CODE
                    ↓
             DEFINE OPEN APIs
                    ↓
             SUPPORT HARDWARE
                    ↓
              ENABLE STARTUPS
                    ↓
             CREATE PRODUCTS
                    ↓
             REACH MASS MARKET
                    ↓
             GENERATE DEMAND
                    ↓
             FUND THE COMMONS

Build the Road, Not Every Car

India's technology ambition should not be measured by how many things it builds completely from scratch.

A mature technology ecosystem is one where thousands of companies can build on top of shared foundations without repeatedly solving the same problems.

That is what the proposed consortium could provide.

The foundation provides the conditions.

Industry provides the money.

Engineers provide the work.

Universities provide research and talent.

Open communities provide technical governance.

Startups build the differentiated products.

Consumers provide the ultimate test.

The objective is not to make every company identical.

It is precisely the opposite.

Make the underlying infrastructure common so that the products can become more different.

Make the plumbing reusable so that the innovation can become more ambitious.

Make the APIs open so that hardware can compete.

Make the software modular so that startups can enter.

Make the maintenance sustainable so that the ecosystem survives.

And make the whole thing FLOSS so that the investment does not stop at India's borders.

The Principle

India's next technology revolution may not require one giant company capable of doing everything.

It may require something more subtle:

A permanent institution capable of building and maintaining the common technological layer upon which thousands of companies can innovate.

Build the plinth.

Let the semiconductor companies build the silicon.

Let the software communities build the tools.

Let the startups build the products.

Let manufacturers build the machines.

Let consumers decide which products succeed.

And let the improvements flow back into the commons.

Fund the commons. Keep the governance open. Standardise the plumbing. Let industry compete on the product.

That could turn FLOSS from something India merely consumes into something India helps maintain as a global industrial resource.

And perhaps that is the real opportunity:

India does not have to build every statue. It can become one of the world's great builders of the plinth.

Break Free from Digital Rent: How a Family Can Reclaim Its Everyday Digital Infrastructure

Digital sovereignty does not begin in a data centre. It begins at home. We have become accustomed to renting almost everything digital. ...