The Same Package: Hair, Headgear, Faith, Family and the Moral Life Across Civilizations

Across the history of Eurasia, we repeatedly encounter people who look surprisingly similar: long or uncut hair, substantial facial hair, hair tied into a knot or covered with cloth, turbans, caps, robes, beards and other forms of distinctive dress.

It is tempting to conclude that these similarities must come from a common ancient tradition. Sometimes there may indeed have been historical contact or transmission. But often the similarity may have another explanation: different civilizations encountered similar human bodies, similar environmental conditions and similar social problems, and independently developed ways of giving those things meaning.

The more interesting question, therefore, is not simply:

“Who had long hair, beards and head coverings?”

It is:

“What was the complete package of ideas in which long hair, facial hair, clothing, ritual, family, learning, gender, spirituality and social responsibility belonged?”

This distinction is important. Two people may both have long hair, a beard and a head covering while holding radically different ideas about God, family, society and justice.

At the same time, two traditions that look very different on the surface may share remarkably similar underlying principles.

1. The “same package” principle

A human practice rarely exists in isolation.

Uncut hair may be connected to a belief about the body. A head covering may be connected to dignity or ritual. A beard may signify maturity or religious discipline. A particular garment may distinguish a community. A daily prayer may reinforce an ethical code. A martial tradition may emerge from a particular understanding of justice.

So instead of comparing hairstyles, we can compare complete packages:

• The body: hair, beard, clothing, cleanliness and physical discipline.
• The mind: learning, meditation, prayer, self-control and emotional discipline.
• The family: marriage, children, parents, ancestors and obligations.
• Gender: expected roles, equality, complementarity and historical practice.
• The divine: God, gods, Heaven, Dao, ultimate reality or another conception of transcendence.
• Learning: scripture, Guru, teacher, philosophy, ancestors or lived example.
• Ritual: prayer, meditation, initiation, pilgrimage, worship and daily discipline.
• Community: equality, hierarchy, caste, status, fraternity and service.
• Authority: scripture, Guru, priesthood, ruler, family or moral law.
• Justice: what constitutes a good society.
• Tyranny: what a person should do when authority becomes unjust.
• Martial tradition: whether fighting is forbidden, permitted, obligatory or part of religious identity.
• Ultimate purpose: salvation, liberation, enlightenment, harmony, service or realization of the Divine.

Once these dimensions are placed together, the apparent similarities and differences become much clearer.

2. The body: “Was this body given to me?”

One of the most remarkable comparisons is between the Sikh concept of kesh and the traditional Confucian understanding of the body.

The Classic of Filial Piety contains the famous statement that the body, hair and skin are received from one's parents and therefore should not be casually damaged. It describes this as the beginning of filial piety.

This creates a powerful philosophical proposition:

The body is not merely an object of personal fashion.

In the Confucian framework, the body connects the individual to parents, ancestors and the family.

In the Khalsa framework, kesh can be understood within a relationship to the Creator, Guru and Khalsa discipline. The Sikh Rehat Maryada explicitly includes unshorn hair among the five articles of faith for initiated Sikhs.

The similarity is therefore striking:

“I did not manufacture myself, so I should think carefully before altering the body I have received.”

But the direction is different.

Confucianism places the body primarily inside a chain of parents → ancestors → family → society.

The Khalsa places the disciplined body within a chain of Creator → Guru → individual → Khalsa → humanity.

These are not the same theology. But they demonstrate how two civilizations can arrive at a related intuition through different philosophical routes.

3. Hair is not necessarily about hair

This is perhaps the most important point in the entire comparison.

Uncut hair can mean:

• filial responsibility;
• acceptance of divine creation;
• asceticism;
• renunciation;
• social adulthood;
• community identity;
• religious discipline;
• resistance to imposed authority;
• or simply inherited custom.

And shaving can have equally different meanings.

A Buddhist monk may shave as an expression of renunciation. An ascetic tradition may preserve hair precisely because allowing it to grow represents another form of renunciation. A military institution may demand short hair for discipline and uniformity. A modern professional may cut hair because of fashion or workplace convention.

The same physical object — human hair — therefore becomes a symbol of completely different ideas.

4. Confucianism: the body as a bridge between generations

Traditional Confucian thought provides one of the clearest examples of a civilization in which bodily appearance, family and moral education were interconnected.

Filial piety was not simply “obey your parents.” It was part of a larger process of becoming a morally cultivated person. The Classic of Filial Piety describes filiality as the root of virtue and connects serving one's parents with establishing oneself through moral conduct.

The package therefore looks roughly like:

body → parents → ancestors → education → moral cultivation → social harmony.

Traditional Chinese society also developed elaborate rules concerning dress, ritual, age, rank and public conduct. The objective was not merely individual spiritual experience. It was the creation of a morally ordered society in which people knew their responsibilities to one another.

This is an important contrast with the Khalsa.

The Khalsa also imposes visible discipline, but it uses that discipline to create a community of people committed to a different theological and ethical order.

5. Khalsa: the body as public commitment

The Khalsa was formally institutionalized in 1699 under Guru Gobind Singh Ji. The Sikh community's development culminated in this transformation into an initiated community with a distinct discipline and visible identity.

The five articles of faith make the body itself part of the commitment. Kesh is accompanied by the kangha, kara, kachera and kirpan. The Sikh Coalition describes these articles as a public commitment to the values and ethics of the tradition, including service, compassion and honesty.

This is a crucial difference from merely having long hair because one's society happens to prefer long hair.

The Khalsa makes identity deliberately visible.

The person carries the commitment into the street, workplace, battlefield, family and marketplace.

The appearance therefore becomes a kind of continuous reminder:

“I belong to something, and that belonging imposes obligations upon me.”

The turban also acquires a particularly interesting social meaning. Sikh sources describe it as a visible assertion of dignity, equality and public commitment, rather than merely a device for managing long hair.

6. The crucial Sikh difference: Sant-Sipahi

The comparison becomes much deeper when martial responsibility is added.

The Khalsa is not simply a community of spiritually disciplined people. Sikh history develops the ideal of the Sant-Sipahi — the saint-soldier.

This creates a distinctive package:

spirituality + ethical discipline + service + courage + capacity to defend others.

The kirpan is therefore not adequately understood simply as a weapon. Within Sikh identity it belongs to a broader moral vocabulary concerning justice, responsibility and the defence of human dignity.

This is one of the places where comparing only external appearance becomes misleading.

A bearded, long-haired ascetic and a Khalsa Sikh may look superficially similar, but their social philosophies can be very different.

The ascetic may be withdrawing from worldly power.

The Khalsa ideal can instead require the spiritually disciplined person to remain inside society and accept responsibility for what happens within it.

7. Tyranny: when is obedience no longer enough?

This dimension makes the comparison especially interesting.

Confucian political thought developed the concept commonly known as the Mandate of Heaven. The legitimacy of political authority was connected to moral governance rather than merely possession of power.

That creates an important principle:

A ruler's authority carries moral obligations.

The Sikh tradition develops a different but similarly powerful concern with the relationship between authority and justice.

Guru Nanak's criticism of corrupt political and religious authority, the martyrdom tradition of the Sikh Gurus, the later militarization of the Sikh community and finally the Khalsa all belong to a historical development in which spiritual commitment becomes increasingly connected with resistance to oppression.

The two traditions should not be declared identical. Their political structures, metaphysics and historical experiences are different.

But they share an intriguing rejection of the proposition:

“Because someone possesses power, whatever they do must therefore be morally legitimate.”

8. Confucian resistance and Sikh resistance are not the same

This distinction is essential.

Confucianism generally places extraordinary emphasis on education, moral cultivation, proper relationships and good government. The ideal political response to disorder is heavily connected with restoring moral order.

The Sikh tradition, especially after the Mughal-era conflicts experienced by the Sikh Gurus and community, develops a much more explicit martial dimension.

Thus:

Confucian ideal: cultivate the person → cultivate the family → cultivate government → restore harmony.

Khalsa ideal: cultivate the person → remember the Divine → serve others → stand for justice → defend the vulnerable when necessary.

Both are concerned with moral society, but the mechanism and historical context differ.

9. Hindu traditions: one civilization, multiple answers

“Hinduism” cannot be treated as a single package for this comparison.

Indian traditions developed radically different approaches to the body.

Some ascetic traditions preserved and cultivated long hair, including jata. Other traditions emphasized shaving the head as part of renunciation. Household traditions had their own conventions concerning hair, dress, ritual and social status.

This produces an important lesson:

India demonstrates that the same civilization can produce opposing interpretations of the same body.

Hair can represent natural/divine creation.

Hair can represent asceticism.

Shaving can represent renunciation.

Hair can represent social status.

And in the Khalsa, uncut hair becomes a permanent community discipline.

Therefore, “India traditionally kept long hair” is too simplistic. The more accurate statement is that the Indian civilizational environment produced a remarkably large number of competing philosophies concerning what hair means.

10. Buddhism: the opposite answer

Buddhist monastic traditions provide an especially useful counterexample.

Where the Khalsa deliberately preserves hair, Buddhist monastic discipline traditionally involves shaving the head.

The important point is not that one practice is “more spiritual.” They are answering different questions.

The Khalsa asks, in part:

“How can I live visibly and continuously within a disciplined relationship with the Divine and my community?”

The Buddhist renunciant asks:

“How can I reduce attachment to worldly identity and cultivate liberation?”

The physical actions therefore move in opposite directions:

preserve the hair versus remove the hair.

Yet both can be forms of disciplined spirituality.

This is why comparing only outward practices can be so deceptive.

11. Daoism: harmony rather than social conformity

Daoist traditions introduce another philosophical possibility.

Instead of making the central problem either social hierarchy or renunciation, Daoist thought often emphasizes alignment with the Dao — the underlying Way or natural order.

Practices concerning body cultivation, simplicity, naturalness and longevity therefore belong to a different package from either Confucian filial order or Khalsa discipline.

Interestingly, Confucianism and Daoism developed within the same broad Chinese civilization while offering substantially different answers to the question of how a human being should live.

This is another warning against equating geography with philosophy.

12. Korea: when hair becomes social adulthood

Korean history provides another fascinating example because Confucianism became particularly influential in Joseon society.

Traditional men's long hair was commonly tied into a topknot after reaching adulthood, and formal headgear became part of the social presentation of the mature male.

The resulting appearance can look remarkably similar to other Eurasian traditions:

long hair → controlled hair → headgear → adult identity.

But the underlying package was strongly connected with family, status, ritual propriety and Confucian social order.

Compare that with the Khalsa:

kesh → dastar → initiated identity → discipline → responsibility.

The visual resemblance is real. The philosophical package is different.

13. Judaism, Christianity and Islam: another set of packages

Jewish, Christian and Islamic traditions add further variations to the comparison.

In Jewish traditions, hair, beard, side-locks, head coverings and dress can become expressions of religious law and communal identity, although practices vary considerably between communities and historical periods.

Christian traditions contain both hair-preserving and hair-removing models. The long-haired and bearded holy person appears in many Eastern Christian contexts, while monastic traditions have also developed distinctive forms of tonsure, shaving and head covering.

Islamic traditions contain strong traditions surrounding beard, modest dress and head coverings, but again the precise practices vary according to region, school and historical period.

These traditions therefore demonstrate another principle:

religious identity can be carried on the body without the body itself being the ultimate object of worship.

14. Gender changes the package

Any serious comparison has to include women.

It is not sufficient to compare “men with long hair and beards” because many traditions have entirely different expectations for male and female appearance.

The important questions are:

• Is hair uncut for everyone or primarily men?
• Are women expected to cover their hair?
• Is facial hair treated as a male marker?
• Does religious initiation apply equally to men and women?
• Are visible religious symbols available to both genders?
• Does the tradition distinguish spiritual equality from different social roles?
• What did the texts prescribe, and what did historical societies actually do?

The last question is particularly important.

Prescriptive tradition and historical practice are not the same thing.

A religion may teach spiritual equality while a particular historical society retains patriarchal customs. Conversely, a philosophical tradition may prescribe social hierarchy while individual societies implement it in many different ways.

15. Learning: where does truth come from?

This may be the deepest comparative question.

Different civilizations answer it differently.

Khalsa/Sikh tradition: Guru, Shabad, Gurbani, Naam, lived discipline and community.

Confucian tradition: classical learning, teachers, ancestors, moral cultivation and exemplary conduct.

Buddhist traditions: Dharma, teacher, meditation, ethical conduct and direct insight.

Hindu traditions: an enormous spectrum including Veda, Guru, scripture, philosophical reasoning, devotion, yoga and direct realization.

Daoist traditions: Dao, classical texts, teachers and practices of alignment/cultivation.

Abrahamic traditions: revelation, scripture, prophetic or apostolic traditions, religious law and interpretive communities.

The visible body is therefore only the outer layer of a much larger educational system.

16. Ritual: repetition as a technology of memory

Ritual is another place where these traditions unexpectedly converge.

A daily prayer, meditation, recitation, garment, head covering, hairstyle, dietary rule or physical discipline can serve as a memory technology.

It repeatedly answers the question:

“What kind of person am I trying to become?”

For a Sikh, the five Ks and daily prayers can continually bring the Khalsa commitment back into consciousness. The Sikh Rehat Maryada prescribes daily devotional practices alongside the articles of faith.

In Confucian society, ritual propriety similarly trained people to embody appropriate conduct rather than merely intellectually understand it.

In Buddhist practice, repeated meditation and ethical discipline train attention and conduct.

In many Hindu traditions, repeated mantra, puja or other practices connect everyday life with the sacred.

Ritual can therefore be understood not simply as “religious ceremony.”

It is a way of repeatedly training memory, attention and behaviour.

17. The visible person as a walking reminder

This leads to one of the strongest similarities between otherwise unrelated traditions.

A visible religious appearance can operate as a reminder both to the individual and to everyone around them.

A Sikh who maintains kesh and wears a dastar cannot easily forget that the Sikh identity is being carried publicly. Sikh sources explicitly describe the visible identity as a public commitment to the values and ethics of the tradition.

Something similar can happen with religious clothing, beads, robes, caps, sacred threads, markings or other visible practices in other civilizations.

The body becomes a kind of mnemonic device.

Instead of keeping religion entirely inside the mind, the tradition puts part of the commitment onto the body.

18. The martial question separates many traditions

Now introduce the question:

“What should a good person do when confronted by violence or tyranny?”

The answers become dramatically different.

Some traditions emphasize nonviolence or renunciation.

Some emphasize obedience to legitimate authority.

Some emphasize reform through moral education.

Some permit defensive violence.

The Khalsa develops an unusually explicit combination of spirituality and martial responsibility.

The ideal is not simply the warrior and not simply the monk.

It is the saint-soldier.

The desired person should have enough spiritual discipline to avoid becoming merely violent, but enough courage to avoid becoming merely passive.

This produces a particularly powerful ethical tension:

How do you possess power without becoming tyrannical?

and:

How do you remain peaceful without becoming helpless?

Those questions are central to understanding the Khalsa's distinctive historical package.

19. The deeper commonality: disciplined freedom

When these traditions are compared at this level, an unexpected common theme begins to appear.

They are all, in different ways, trying to solve the problem of the undisciplined human being.

The human being has desires, anger, fear, pride, greed, sexuality, ambition, attachment and the ability to harm others.

Different civilizations propose different solutions.

Confucianism: cultivate the person through education, relationships and ritual.

Buddhism: understand and overcome craving and ignorance.

Hindu traditions: use different paths of dharma, knowledge, devotion, action and disciplined practice.

Daoism: seek alignment with the Way rather than excessive forcing.

Khalsa/Sikh tradition: remember the Divine, live truthfully, serve humanity, cultivate courage and remain prepared to defend righteousness.

These are different answers to a broadly human problem.

20. And this brings us back to the “ancient look”

The long-haired, bearded, head-covered man therefore shouldn't automatically be categorized as “Asian.”

He appears repeatedly across Eurasia and in many religious and philosophical contexts.

Sometimes the appearance is simply the result of hair being allowed to grow naturally.

Sometimes it reflects adulthood.

Sometimes spirituality.

Sometimes social rank.

Sometimes family duty.

Sometimes military identity.

Sometimes resistance.

Sometimes fashion.

The modern short-haired, closely shaved male appearance is therefore only one historical solution among many.

What changed in modernity was not human biology. It was the meaning assigned to grooming.

21. Khalsa and Confucianism: perhaps the most revealing comparison

Of all the comparisons, the relationship between Confucianism and Khalsa may be especially valuable because the two traditions reveal both deep similarity and deep difference.

Both can say, in their own ways:

The human being is not an isolated consumer who can arbitrarily redesign himself without consequences.

Both emphasize disciplined conduct.

Both value learning.

Both care about family and social responsibility.

Both connect personal virtue with the condition of society.

Both reject the idea that power alone makes something morally right.

But they then take different routes.

Confucianism strongly emphasizes:

family → education → ritual → moral cultivation → social harmony.

Khalsa/Sikh thought emphasizes:

Divine remembrance → truthful living → discipline → equality → service → courage → justice.

The resemblance is therefore not that the two traditions are secretly the same.

The resemblance is that both recognized that character must be embodied.

22. The real object of comparison is therefore not the turban

A turban by itself tells us very little.

Long hair by itself tells us very little.

A beard by itself tells us very little.

Even a religious garment by itself tells us very little.

But when we place these things inside the complete package, they become extraordinarily informative.

We can ask:

What does this person believe about the body?

What does this person believe about God or ultimate reality?

What does this person owe to parents?

What does this person owe to strangers?

What should this person do with anger?

What should this person do with power?

What should this person do when a ruler becomes unjust?

What should this person teach their children?

What should this person do every day to remain the person they claim to be?

Only after answering those questions does the hair become meaningful.

23. A broader way of reading civilizations

Perhaps this is the most useful conclusion.

We often compare civilizations through their visible products:

architecture, weapons, clothing, hairstyles, scripts, food and monuments.

But beneath those visible things are packages of assumptions about human life.

The same hairstyle can arise from different assumptions.

The same head covering can represent different ideas.

The same beard can represent different virtues.

And two traditions that look completely different can sometimes share the same deeper concern: how to prevent human freedom from degenerating into selfishness, and how to turn an individual into a responsible human being.

The Khalsa is particularly interesting because it makes this philosophy unusually visible.

The body carries the commitment.

The daily discipline reinforces it.

The community recognizes it.

The martial tradition gives it a response to injustice.

And the spiritual tradition gives the power a moral direction.

That is why the Khalsa cannot be adequately understood simply as a community that “does not cut its hair.”

Kesh is one visible component of a much larger package.

And that is precisely the right level at which to compare it with Confucianism, Hindu traditions, Buddhism, Jainism, Daoism, Judaism, Christianity, Islam and the many other civilizational traditions that have asked the same fundamental question in different ways:

“What should a human being become?”

Once that question becomes the centre of the comparison, the similarities become more meaningful, the differences become clearer, and the superficial question of “who looked like whom?” becomes a much deeper investigation of how civilizations attempted to shape the human being.

Conclusion: The Package Is the Tradition

Perhaps the safest way to approach cross-cultural comparison is therefore:

Do not compare the hair. Compare the package.

Do not compare the turban. Compare what the turban means.

Do not compare the beard. Compare what the beard represents.

Do not compare the ritual. Ask what transformation the ritual is intended to produce.

Do not compare the warrior. Ask what gives the warrior legitimacy.

Do not compare the family. Ask why the family matters.

Do not compare the scripture. Ask what kind of human being the scripture is trying to create.

When we do that, the apparent similarities between distant civilizations stop being merely curious visual coincidences. They become evidence of something more interesting: human societies repeatedly encountered the same fundamental problems — mortality, desire, family, authority, injustice, violence, meaning and the search for the Divine — and developed different but sometimes surprisingly convergent packages for answering them.

The outward form is only the visible edge of the package.

The real comparison is the philosophy of the human being underneath it.

India Should Build the Foundations AI Will Need

India's next software opportunity may not be to write more applications for other people's platforms. It may be to build the open foundations that both humans and AI agents will use to create the next generation of applications.

For decades, India's software industry has demonstrated an extraordinary ability to take specifications, business requirements and existing technologies and turn them into working software at scale.

That model created an enormous industry.

But artificial intelligence is beginning to change the economics of software development.

The important question is therefore not simply whether AI will replace software engineers.

A better question is:

Which parts of software development become cheap when AI can write code, and which parts become more valuable?

The answer may be pointing toward an opportunity that India has not pursued aggressively enough: foundational software.

Instead of competing with AI to write another application, Indian engineers could increasingly build the libraries, engines, protocols, databases, media frameworks, graphics systems, APIs, developer tools and machine interfaces that AI itself will depend upon.

In other words:

Don't compete with AI at typing code. Build what AI needs underneath it.

The AI Coding Revolution Has a Hidden Limitation

The recent progress of AI coding systems is genuinely impressive.

Modern coding agents can read repositories, modify multiple files, run commands, inspect errors, write tests and iterate on implementations. AI can already produce surprisingly sophisticated applications from relatively simple instructions.

But there is an important distinction between writing software and having reliable software foundations available to build upon.

Suppose someone asks an AI:

"Create a reminder application that schedules notifications, stores reminders locally, survives a reboot and allows users to edit or delete reminders."

This is a reasonably approachable problem because modern platforms already provide many of the required building blocks.

The AI can combine a database, notification framework, scheduling system, user interface toolkit and operating-system APIs.

The result may still contain bugs. The architecture may need improvement. Dependencies may conflict. The application may require considerable debugging.

But the fundamental primitives already exist.

Now ask the AI:

"Build a reliable cross-platform video conversion engine that accepts arbitrary video files, decodes multiple codecs, handles audio and video streams, resizes frames, converts formats, encodes the result efficiently, preserves synchronization, muxes the output correctly and works across modern mobile hardware."

The problem changes completely.

The AI is no longer merely assembling mature components. It is suddenly forced to understand an enormous amount of low-level engineering.

Video processing involves codecs, containers, timestamps, buffers, hardware acceleration, pixel formats, audio pipelines, memory management, threading, synchronization and platform-specific behaviour.

Android's own MediaCodec, for example, is explicitly described by Google as a low-level interface to encoder and decoder components and is normally used together with other multimedia components such as MediaExtractor, MediaMuxer, MediaSync and Surface.

This is precisely where the difference between "AI can code" and "the ecosystem has good foundations" becomes visible.

My Own Experiments Pointed to the Same Problem

This is not merely a theoretical observation.

When I experimented with having frontier AI models build Android applications, relatively conventional applications were feasible.

A reminder application could be constructed using Android's existing scheduling, notification, database and UI infrastructure.

But when the task moved toward video conversion and media processing, things became much harder.

The problem was not necessarily that the AI could not write Kotlin or Java.

The problem was that the required abstraction was much weaker.

There was no single clean, modern, universally convenient "VideoEngine.convert(input, output, settings)" foundation that an AI could simply understand and reliably invoke.

Instead, the developer had to deal with lower-level interfaces and a large number of compatibility and implementation details.

This experience reveals something important about the future of AI-assisted programming.

AI becomes dramatically more powerful when difficult engineering problems have already been converted into reliable abstractions.

The AI can then assemble those abstractions.

This suggests that the value of software engineering will increasingly move toward the layers where those abstractions are created.

From Writing Applications to Building Digital Infrastructure

Imagine that somebody creates a mature, well-tested, open-source video foundation.

It provides:

• video decoding
• video encoding
• audio decoding and encoding
• format conversion
• resizing
• cropping
• frame extraction
• subtitle handling
• metadata handling
• hardware acceleration
• streaming
• container manipulation
• progress reporting
• error handling
• cross-platform APIs
• command-line interfaces
• language bindings
• machine-readable documentation

Suddenly, building a video application becomes much easier.

An AI agent might only need to invoke something like:

convert_video(
    input="movie.mp4",
    output="compressed.mp4",
    codec="h265",
    resolution="1080p",
    quality=75
)

The difficult engineering has not disappeared.

It has simply been moved downward into a reusable foundation.

That foundation can then support thousands of applications.

This is the economic difference between selling implementation and building infrastructure.

The New Software Stack May Have Four Layers

The software industry has traditionally been understood roughly like this:

1. hardware
2. operating systems
3. libraries and frameworks
4. applications

AI introduces another layer of interaction.

A future stack could increasingly look like:

1. Hardware — CPUs, GPUs, NPUs, storage, networking and accelerators.
2. System foundations — operating systems, drivers, compilers, databases, graphics, codecs and networking.
3. Agent-ready foundations — APIs, tools, schemas, documentation, state inspection, permissions and machine-readable interfaces.
4. Applications — products assembled increasingly by humans and AI agents.

The fourth layer may become progressively cheaper to produce.

The second and third layers could therefore become strategically more important.

AI-Controlled Software Is Different From AI-Generated Software

This distinction is particularly important.

There are at least three different things happening under the broad label of "AI coding".

1. AI-generated code

The AI writes the implementation.

This is what most people think about when they hear "AI coding".

2. AI-controlled software

The software already exists, but an AI agent can operate it through reliable commands.

For example:

create_rectangle(x, y, width, height)

create_circle(x, y, radius)

boolean_intersection(object_a, object_b)

export_image(format="png")

The AI does not need to understand how a geometric intersection algorithm works.

The graphics engine does.

The AI only needs to understand what the operation means and when to use it.

3. AI-generated content

The AI itself generates the resulting image, video, text, sound or other content.

These are very different technological models.

And the second model could become enormously important.

It means existing professional software can become agent-addressable.

The Agentic API Is Becoming a New Kind of Interface

Traditional APIs were designed primarily for programmers.

An engineer reads the documentation, understands the parameters and writes code against the interface.

AI agents introduce a new consumer for APIs.

The interface now needs to be understandable not only by humans but also by machines that reason over descriptions, schemas, examples and available operations.

This is already visible in emerging standards such as the Model Context Protocol (MCP).

MCP defines primitives including tools, resources and prompts. Tools allow models to invoke executable functions, while resources provide structured contextual information.

The significance is larger than one protocol.

It represents a shift in how software can be exposed.

A database does not necessarily have to be operated exclusively through a graphical interface.

A graphics editor does not necessarily have to be operated exclusively through menus and mouse clicks.

A spreadsheet does not necessarily have to be operated exclusively through cells.

A video editor does not necessarily have to be operated exclusively through a timeline.

The underlying capabilities can increasingly become tools that an AI agent can discover and invoke.

That makes the quality of the underlying API extremely important.

Documentation Becomes Part of the Software

This may be one of the most underestimated consequences of agentic software.

Documentation has traditionally been treated as something humans read.

In an agentic environment, documentation increasingly becomes part of the machine interface.

A good foundation should explain:

• what each operation does
• what inputs are accepted
• what outputs are returned
• what errors can occur
• what state is changed
• whether an operation is reversible
• whether an operation is destructive
• what permissions are required
• what performance characteristics exist
• what examples demonstrate correct usage
• what combinations of operations are valid
• what the agent should do when something fails

Modern MCP development is already moving in this direction. The protocol exposes tools with descriptions and schemas, while its broader ecosystem is developing ways to communicate server instructions and agent skills alongside tools and resources.

In other words:

The documentation of tomorrow may be executable knowledge.

This makes extremely detailed documentation an economic asset rather than merely a developer convenience.

What Should Indian Engineers Build?

If this thesis is correct, India should not simply ask:

"Which applications can we build using AI?"

We should also ask:

"Which difficult software capabilities could we turn into reusable foundations?"

There is an enormous list.

Tier 1: Simple Foundations

These may not sound glamorous, but they could provide excellent training grounds.

• notification engines
• scheduling engines
• document generation
• PDF creation and manipulation
• OCR
• text extraction
• speech-to-text
• text-to-speech
• file conversion
• archive management
• image resizing and transformation
• metadata extraction
• search libraries
• local indexing
• configuration management

These are not necessarily billion-dollar products individually.

That is not the point.

The point is to turn difficult recurring engineering problems into reliable reusable components.

Tier 2: Media and Data Foundations

Once engineers become comfortable with these systems, the complexity can increase.

• audio engines
• video engines
• image processing engines
• document rendering engines
• database engines
• search and indexing systems
• data transformation pipelines
• compression libraries
• streaming systems
• networking libraries
• file-system abstractions
• synchronisation engines
• local-first databases

These are much deeper engineering problems.

They require understanding memory, concurrency, algorithms, operating systems, storage, networking and hardware.

They are also exactly the kinds of foundations that thousands of applications could reuse.

Tier 3: Advanced Foundations

Then comes the genuinely difficult territory.

• graphics engines
• rendering systems
• physics engines
• simulation frameworks
• compilers
• language runtimes
• cryptographic libraries
• distributed databases
• distributed storage
• networking stacks
• virtualisation
• container infrastructure
• operating-system components
• GPU compute frameworks
• machine-learning runtimes

These are not ordinary application-development projects.

They require engineers who understand the machine underneath the abstraction.

And Then There Is Hardware

This is where the opportunity becomes particularly interesting for India.

The boundary between software and hardware is becoming increasingly important as AI workloads spread across CPUs, GPUs, NPUs and specialised accelerators.

Open hardware projects and open instruction-set architectures such as RISC-V provide another possible direction.

An engineer who understands operating systems, compilers, runtimes and hardware interfaces can eventually work much closer to the machine itself.

That could mean:

• RISC-V software stacks
• device drivers
• embedded operating systems
• accelerator runtimes
• GPU software
• NPU runtimes
• compiler backends
• hardware abstraction layers
• firmware
• verification tools
• simulation environments
• EDA tooling

This is particularly relevant to India's emerging interest in open silicon.

If India eventually wants to participate seriously in open CPUs, NPUs, GPUs and specialised accelerators, it will need software engineers who can cross the boundary between software and hardware.

The future opportunity is therefore not simply software versus hardware.

It is software deeply integrated with hardware.

The "Daily-Wage Programmer" Problem

There is an uncomfortable economic dimension to all of this.

Large parts of the global software-services economy are structured around selling engineering capacity.

A customer has a requirement.

A company assigns engineers.

The engineers implement the requirement.

The customer pays for the work.

The engineers move to the next project.

There is nothing inherently wrong with this model. It created enormous employment and helped establish India as one of the world's major technology centres.

But economically, it has a limitation.

The value is repeatedly tied to human implementation hours.

AI directly attacks the economics of repetitive implementation.

If an AI agent can produce in one hour what previously required ten engineers for a week, the market value of simply supplying those implementation hours will inevitably come under pressure.

That does not mean software engineering disappears.

It means the location of value changes.

Instead of asking:

"How many programmers can India provide?"

We should increasingly ask:

"How many foundational technologies can Indian engineers create and maintain?"

Foundational Software Is Digital Capital

A reusable software foundation behaves differently from a consulting project.

A consulting project may serve one customer.

A foundation can serve thousands.

A library written once can be integrated into hundreds of products.

A codec can be used by countless applications.

A database can support millions of users.

A graphics engine can power an entire ecosystem.

An open protocol can become infrastructure.

A compiler can support an entire hardware architecture.

This is why foundational software should be understood as digital capital.

It is not simply code.

It is accumulated engineering knowledge converted into a reusable machine.

Open Source Makes the Opportunity Even More Interesting

India does not necessarily need to own every foundation commercially.

Open source changes the equation.

An Indian engineering team could build an open-source foundation and allow companies around the world to build upon it.

Revenue could then emerge from:

• commercial support
• enterprise editions
• hosting
• integration
• certification
• hardware partnerships
• consulting
• specialised implementations
• managed services
• commercial extensions

But the underlying technical asset remains available to the ecosystem.

This creates a very different relationship between Indian engineers and global technology.

Instead of merely implementing somebody else's platform, Indian engineers can help create the platforms that others implement against.

India Already Has the Scale

The interesting thing is that India does not need to start from zero.

India already possesses an enormous technology workforce and a large software-services ecosystem.

NASSCOM's recent industry estimates put India's technology-industry workforce at millions of employees, while engineering R&D, GCCs and digital engineering have become increasingly important parts of the ecosystem. Its 2025 strategic review estimated FY2025 technology-industry revenue at more than $282 billion including hardware and projected the industry toward $300 billion in FY2026.

The question is therefore not whether India has enough engineers.

The question is what those engineers are encouraged to build.

There is a huge difference between having millions of people capable of writing software and having a large community capable of maintaining foundational software.

The second requires a different culture.

We Need More Engineers Who Understand the Machine

The foundational engineer of the future should probably be comfortable moving across multiple layers.

They should understand:

• algorithms
• data structures
• memory
• concurrency
• operating systems
• networking
• file formats
• compilers
• databases
• graphics
• hardware interfaces
• performance profiling
• testing
• security
• API design
• documentation

Languages such as C, C++ and Rust become particularly useful in this world, not because higher-level languages disappear, but because somebody eventually has to understand what is happening underneath them.

And AI itself becomes a powerful assistant for these engineers.

An engineer who understands a system can ask AI to generate implementations, explore alternatives, write tests, inspect code and produce documentation.

The engineer provides the architectural understanding.

The AI provides enormous amounts of implementation leverage.

This could actually make foundational engineering more productive, rather than less relevant.

The Goal Is Not to Eliminate Application Developers

This argument should not be misunderstood.

India should not suddenly tell millions of application developers to abandon their careers and become kernel developers.

That would be neither realistic nor desirable.

Application development will remain enormous.

People will always need products designed around particular businesses, industries, cultures and human needs.

What should change is the proportion of effort spent reinventing low-level capabilities.

If a mature open-source foundation already exists, developers should use it.

If it does not exist, that absence may represent an opportunity.

The application developer of the future may therefore become much more productive.

Instead of spending three months building an internal document engine, they might spend three days integrating a mature one.

Instead of writing a custom media pipeline, they might call a standard media foundation.

Instead of manually integrating dozens of APIs, an AI agent might orchestrate them.

This means foundational engineering does not destroy application development.

It makes application development cheaper and more powerful.

Universities Should Teach the Layers Below the App

This also suggests a change in engineering education.

Students should certainly learn Python, JavaScript, Java, Kotlin and modern AI tooling.

But they should also be encouraged to build things such as:

• a small database
• a file system
• a compiler
• a network protocol
• a simple operating-system component
• a graphics renderer
• a media pipeline
• a search engine
• a compression algorithm
• a small virtual machine
• a RISC-V emulator
• a hardware simulator

These projects teach something that framework-based application development often hides:

what the computer is actually doing.

Once an engineer understands that, AI becomes an accelerator rather than a replacement for understanding.

India Could Build a National Foundation Software Ecosystem

There is an even larger possibility.

India could deliberately identify a few hundred important open-source foundations and treat them as strategic digital infrastructure.

Not every project needs government ownership.

Not every project needs a giant company.

But India could create funding, fellowships, university programmes, industry partnerships and long-term maintenance programmes around strategically important open-source projects.

Consider a hypothetical Indian foundation stack:

Layer	Examples
Basic utilities	Files, scheduling, notifications, archives, conversion
Documents	PDF, office formats, rendering, OCR
Media	Audio, video, codecs, streaming
Data	Databases, indexing, search, synchronisation
Graphics	Rendering, 2D/3D, GPU compute
AI infrastructure	Inference runtimes, model formats, accelerator APIs
Systems	Compilers, runtimes, operating-system components
Networking	Protocols, distributed systems, secure communication
Hardware	Drivers, firmware, RISC-V, accelerators, simulation

Each layer would make the next layer easier.

That is how an ecosystem becomes self-reinforcing.

The First Foundations May Look Boring

There is another lesson here.

The first generation of Indian foundational software does not need to be spectacular.

A reliable notification library may be more useful than another flashy AI application.

A truly excellent PDF engine may quietly become part of thousands of applications.

A robust open-source video engine may save developers around the world enormous amounts of engineering effort.

A high-quality document renderer may become infrastructure for countless AI agents.

A well-designed database API may become invisible infrastructure used by applications nobody has imagined yet.

This is how foundational technologies often work.

Their success is measured by how many things can be built without thinking about them anymore.

AI May Actually Increase the Value of Good Foundations

This is perhaps the most important conclusion.

It is tempting to assume that AI makes software less valuable.

But another interpretation is possible.

AI makes well-abstracted software more valuable.

If an AI agent can discover a capability, understand its inputs and outputs, invoke it safely, inspect the result and recover from failure, that capability becomes a building block for automated software creation.

One foundation can therefore become part of thousands or millions of future AI-generated workflows.

The leverage becomes enormous.

This creates a positive feedback loop:

1. Engineers build a reliable foundation.
2. The foundation receives excellent documentation and APIs.
3. AI agents learn how to use it.
4. AI agents build applications using it.
5. More applications expose new requirements.
6. The foundation improves.
7. More developers and agents adopt it.

The foundation becomes more valuable precisely because AI makes it easier to build things on top of it.

Don't Build What AI Can Easily Assemble

This could become a useful rule for the next generation of Indian software engineers.

If an application can be assembled from ten mature open-source components in a few hours, building another copy of that application may not be the best long-term engineering opportunity.

Instead ask:

• Which component is missing?
• Which API is painful?
• Which format has poor support?
• Which low-level interface is unnecessarily difficult?
• Which library is abandoned?
• Which important project has poor documentation?
• Which capability is repeatedly rebuilt by thousands of developers?
• Which foundation could make an entire category of applications easier?

That is where the opportunity lies.

The Next Indian Software Story Could Be Deeper Than Services

India's first major software revolution was built around services.

The next could be built around products.

But there is potentially an even deeper stage:

infrastructure.

Not just SaaS products.

Not just mobile applications.

Not just AI wrappers.

Not just consulting.

But the underlying software that makes all of these things possible.

And as the AI era develops, the customer for this infrastructure will no longer be only a human developer.

It will increasingly be another piece of software.

An AI agent.

A coding agent.

A design agent.

A research agent.

A financial agent.

A manufacturing agent.

A scientific agent.

Millions of such agents may eventually need reliable software foundations.

From Software Services to Software Infrastructure

India should therefore think beyond the question:

"How many software engineers will AI replace?"

A much more productive question is:

"What foundations can Indian engineers build so that the next billion software systems can be created more easily?"

That is a completely different vision.

It does not require India to defeat Silicon Valley.

It does not require India to build the next giant consumer platform.

It does not require every engineer to become an AI researcher.

It requires something much more practical:

Build excellent software that other software can depend upon.

Start with the boring problems.

Make them reliable.

Document them obsessively.

Expose clean APIs.

Make them accessible from multiple languages.

Make them usable locally and offline where possible.

Make them friendly to automation.

Make them safe for agents.

Make them open where openness creates ecosystem value.

Then move deeper.

Into graphics.

Databases.

Networking.

Compilers.

Operating systems.

AI runtimes.

Hardware interfaces.

Open silicon.

This is not a retreat from the AI revolution.

It is a way of moving closer to its foundation.

The Opportunity Below the Application Layer

There will always be people who build applications.

There will always be people who design user experiences.

There will always be people who solve business problems.

But increasingly, AI will be able to perform more of the mechanical work involved in turning those requirements into software.

That makes the deeper layers more interesting.

The engineer who understands the machine, the operating system, the protocol, the file format, the compiler, the accelerator and the API can become the person who creates the abstraction that thousands of other engineers — and eventually millions of AI agents — use.

That is a fundamentally different position from selling another block of programming hours.

It is the difference between writing code for a project and building a piece of the digital infrastructure on which future projects will run.

India already has the people.

India already has the software culture.

India already has enormous experience operating at global scale.

What is needed is a stronger deliberate push downward — toward foundational software, open infrastructure, systems engineering and eventually hardware-software co-design.

The age of AI may reduce the value of writing repetitive code.

But it could dramatically increase the value of creating the foundations from which that code can be generated.

India should not merely become the world's largest consumer of AI coding agents.

It should help build the foundations those agents stand on.

That may be one of the most important software opportunities of the next decade.

Build the Plinth Before the Statue: Why India Needs an Open Technology Consortium Now

India is building the foundations of a semiconductor industry. It is developing RISC-V capabilities, investing in electronics manufacturing and creating a growing deep-tech ecosystem. But a chip does not become a product simply because it comes out of a fab. Between silicon and the finished product lies an enormous layer of software, tools, drivers, APIs, standards and engineering knowledge. India should start building that layer now.

The Semiconductor Clock Is Not the Only Clock That Matters

India's semiconductor story is beginning to move from policy announcements toward physical infrastructure.

The Tata Electronics semiconductor fab in Gujarat, being established in partnership with Taiwan's Powerchip Semiconductor Manufacturing Corporation (PSMC), has an approved investment of ₹91,526 crore and planned production capacity of approximately 50,000 wafer starts per month. India's semiconductor programme is also supporting OSAT facilities and a growing semiconductor-design ecosystem.

But there is another clock running in parallel.

The software clock.

A semiconductor fab can eventually produce chips. A design company can eventually produce a RISC-V processor. An NPU company can eventually produce an accelerator.

But when those chips arrive, someone has to make them useful.

Someone needs to make them boot.

Someone needs to write the drivers.

Someone needs to make Linux or an RTOS understand the hardware.

Someone needs to make the compiler generate good code.

Someone needs to make the GPU work.

Someone needs to make the NPU accessible to AI frameworks.

Someone needs to make cameras, displays, storage, Wi-Fi, Bluetooth, USB, sensors and power management work.

Someone needs to build the SDK.

Someone needs to test it.

Someone needs to document it.

Someone needs to maintain it five years later.

The time to begin doing that work is before the hardware arrives.

India should not wait for its semiconductor ecosystem to become mature before building the software ecosystem that makes that semiconductor ecosystem useful.

It should build the software ecosystem while the hardware ecosystem is still learning.

The Missing Institution

India already has companies, universities, semiconductor programmes, startups, open-source developers and individual RISC-V initiatives.

What is missing is a large institution whose primary purpose is to connect these efforts at the common infrastructure layer.

Call it, for now, the Indian Open Technology Consortium.

The name is less important than the function.

Its mission should be simple:

Build and maintain the open software, APIs, tools, reference implementations, testing infrastructure and standards required to make modern hardware easy to develop products on.

There is an important distinction in that sentence.

The consortium should not primarily make end-user products.

It should make the tools used to make end-user products.

Build the Plinth, Not Every Statue

Imagine a giant statue.

The statue is what everyone notices. It is the smartphone, automobile, robot, television, refrigerator, industrial machine or computer.

But underneath the statue is the plinth.

The plinth doesn't determine what the statue looks like. It gives the statue a stable foundation.

This is the role the consortium should play.

It should build the plinth.

A smartphone company can build its smartphone.

An automobile company can build its vehicle.

An appliance company can build its refrigerator.

A robotics startup can build its robot.

A semiconductor company can build its processor.

The consortium should make it easier for all of them to build.

That means standardising and maintaining the common layers that do not need to be reinvented by every company.

What Is the Common Layer?

Consider a smart washing machine.

The manufacturer may have proprietary algorithms for determining washing cycles, water consumption, detergent use, vibration and load characteristics.

Those are legitimate areas of differentiation.

But the machine also needs:

• sensor interfaces
• motor interfaces
• networking
• security
• firmware updates
• diagnostics
• power management
• storage
• Bluetooth or Wi-Fi
• device management

Why should every washing-machine company independently reinvent all of that?

Now consider a smart TV.

It needs:

• GPU support
• video decoding
• audio
• display drivers
• HDMI
• USB
• networking
• storage
• security
• OTA updates

Again, much of this is plumbing.

The same pattern appears in cars, smart watches, robot vacuums, industrial IoT devices, cameras, medical devices and smartphones.

The opportunity is to make the plumbing reusable.

Standardise the Interface, Not the Innovation

This is perhaps the most important design principle for the consortium.

It should not attempt to standardise the product.

It should standardise the interfaces between the components.

Imagine three different NPU manufacturers.

They have completely different internal architectures.

That is fine.

The application should be able to communicate with them through a common software interface.

                    AI APPLICATION
                          |
                    Common NPU API
                          |
                    AI Runtime
                          |
          +---------------+---------------+
          |               |               |
        NPU A           NPU B           NPU C
          |               |               |
       Vendor A        Vendor B        Vendor C

The same principle can apply to GPUs, cameras, displays, sensors, audio systems, storage, security engines and other hardware.

The consortium's job is not to tell semiconductor companies how to design their chips.

Its job is to ensure that software developers have a predictable way to use those chips.

That is how competition underneath an open interface becomes possible.

RISC-V Makes This Particularly Important

RISC-V is an open standard instruction-set architecture rather than a single processor design. RISC-V International describes its role as maintaining the open standard and related specifications, while implementations and software are developed by the wider ecosystem. The organisation explicitly describes interoperability and shared standards as mechanisms that allow different vendors to compete while building on a common foundation.

That distinction is critical.

RISC-V gives hardware designers freedom.

But freedom at the instruction-set level is only the beginning.

A commercially successful computing ecosystem still needs:

• compilers
• debuggers
• bootloaders
• operating systems
• device drivers
• graphics
• AI runtimes
• multimedia
• security
• networking
• development tools
• documentation
• testing

This is why RISC-V should not be viewed simply as a processor project.

It is an ecosystem project.

Where Should the Consortium Start?

It should not start by designing a new operating system.

It should not start by building a new smartphone.

It should not start by designing another processor.

It should start with something much less glamorous.

Existing hardware.

There are already RISC-V development boards, SoCs, processors and accelerator projects available to developers.

The first task should be to map the ecosystem.

Which boards are available?

Which chips are supported?

Which peripherals work?

Which drivers are missing?

Which Linux subsystems require improvement?

Which RTOS implementations need support?

Where are the documentation gaps?

Which GPUs have usable open drivers?

Which NPUs have usable runtimes?

Which development boards are painful to bring up?

Which interfaces appear repeatedly across different chips?

That produces a list of actual engineering problems.

And those problems become the consortium's first projects.

Start With the Boring 80 Percent

The first engineering teams could concentrate on common interfaces:

• GPIO
• I²C
• SPI
• UART
• PWM
• ADC and DAC
• USB
• Ethernet
• Wi-Fi
• Bluetooth
• SD and eMMC
• NVMe
• display interfaces
• touchscreens
• camera interfaces
• audio
• sensors
• motor controllers
• power-management ICs
• watchdogs
• real-time clocks
• secure elements
• hardware cryptography

These things are not glamorous.

That is precisely why they are valuable.

If five different RISC-V boards require the same kind of support, improving that support once can benefit all five.

If fifty future products can use the same API, the return on that engineering effort becomes enormous.

Then Move Up the Stack

Once the low-level foundation becomes stronger, the consortium can move upward:

LEVEL 1
Drivers / firmware / BSP
        |
LEVEL 2
Hardware abstraction
        |
LEVEL 3
Common APIs
        |
LEVEL 4
SDKs and developer tools
        |
LEVEL 5
Reference platforms
        |
LEVEL 6
Industry platforms
        |
LEVEL 7
Commercial products

The consortium should primarily operate through Levels 1–5.

Industry should dominate Levels 6 and 7.

That boundary is important.

If the consortium begins building commercial end-user products, it starts competing with the very companies it is supposed to enable.

Its purpose is to make those companies stronger.

The Steam Lesson

There is a useful analogy in the gaming world.

Valve's work around Steam on Linux demonstrates what can happen when a company invests heavily in the layers required to make a fragmented technical environment practical for mainstream users.

Proton/Wine, SDL, controller support, graphics compatibility, anti-cheat work, hardware integration and the wider Linux gaming ecosystem did not all originate as a single Valve-owned technology stack.

The important contribution was sustained engineering, integration, investment and upstream collaboration.

Valve didn't need to replace Linux.

It helped make Linux substantially more useful for a particular class of applications.

That is the lesson worth borrowing.

The Indian consortium should not attempt to replace the global open-source ecosystem.

It should make the global open-source ecosystem work exceptionally well with the hardware and industries India is trying to develop.

Do not fork the world. Strengthen the world.

India's First Objective Should Be Hardware Enablement

Imagine an Indian semiconductor company releases a new RISC-V SoC.

Today, the company may have to answer dozens of questions before an OEM can seriously consider it:

• Does Linux boot?
• Are the drivers upstream?
• Does the GPU work?
• Does the NPU have an SDK?
• Can common AI frameworks use it?
• Does video decoding work?
• Does suspend/resume work?
• How good is power management?
• Does Wi-Fi work?
• How do we perform secure OTA updates?
• Where is the documentation?
• Who maintains the software five years from now?

The consortium could turn a large part of that list into a platform service.

The semiconductor company could say:

"This chip is supported by the Open Technology Platform."

That changes the conversation.

The Consortium Becomes a Test Laboratory for Silicon

The organisation could establish shared hardware laboratories.

New chips could be tested against common workloads.

Measurements could include:

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

This creates an unusually valuable feedback loop.

Software engineers learn what the silicon actually needs.

Silicon engineers learn what real software actually demands.

Future chips can then be designed with that knowledge.

It is a learning machine connecting software and hardware.

The Consortium Should Be Industry-Funded

The most sustainable model is unlikely to be a conventional government software programme.

The government can be an important enabler, but the consortium should ideally have substantial industry funding.

Potential members could include:

• semiconductor companies
• automobile manufacturers
• electronics manufacturers
• appliance manufacturers
• telecommunications companies
• cloud companies
• IT companies
• startups
• universities
• research institutions
• multinational companies with significant engineering operations in India

The government could support the ecosystem through appropriate incentives, research programmes, infrastructure, procurement and university partnerships.

But the foundation should not become a government-owned software company.

A simple division of responsibility would be:

• Government: create favourable conditions.
• Industry: provide funding and engineering participation.
• Universities: provide research and talent.
• Foundation: provide infrastructure and stewardship.
• Engineers: build and maintain the technology.
• Open communities: retain technical authority.

Talent Before Headcount

One of the biggest mistakes would be to define the organisation's success by how many programmers it employs.

FLOSS requires a particular temperament.

Some engineers love the work of maintaining infrastructure for years.

They enjoy debugging obscure problems.

They enjoy reading specifications.

They enjoy reviewing patches.

They are willing to respond to upstream feedback.

They care about documentation and compatibility.

They enjoy understanding systems from silicon to application.

Those people are extraordinarily valuable.

The consortium should find them.

It should not try to force every software engineer into that role.

Start with talent and motivation, not headcount.

Perhaps the first engineering organisation has 100 people.

Perhaps later it becomes 500.

Perhaps eventually it becomes several thousand.

The growth should follow the work.

The Open Technology Academy

There should, however, be a deliberate path for new people to enter this ecosystem.

This is where a training and learning vertical becomes extremely valuable.

But it should not look like a conventional training institute.

It should be an Open Technology Academy.

Its purpose would be to turn interested engineers into contributors, developers, maintainers and eventually systems architects.

And the most important principle should be:

Don't teach people FLOSS. Put them inside FLOSS.

Learning by Contribution

Instead of spending months simply watching courses, an apprentice might receive a RISC-V development board.

The first assignment could be:

Make it boot.

Then:

Find something that doesn't work.

Then:

Debug it.

Then:

Fix it.

Then:

Submit the patch upstream.

Then:

Respond to the review.

Then:

Get it merged.

At that point the person hasn't merely completed a course.

They have become an open-source contributor.

A possible progression could be:

Explorer
   |
Contributor
   |
Developer
   |
Maintainer
   |
Senior Maintainer
   |
Technical Architect

Not everyone needs to reach the top.

Someone may discover that they love documentation.

Another may become an exceptional kernel developer.

Another may specialise in compiler technology.

Another may discover a talent for hardware validation.

Another may become a security engineer.

The Academy should help people discover where they belong.

Talent Should Select Itself

This also solves the problem of identifying people with the necessary drive.

Do not try to identify every future maintainer during recruitment.

Give interested people access to real projects.

Let contribution reveal the talent.

Perhaps 1,000 people enter an introductory programme.

Perhaps 300 become regular contributors.

Perhaps 100 become serious developers.

Perhaps 30 become excellent maintainers.

Perhaps five eventually become world-class subsystem experts.

That is not failure.

That is how a technical culture develops.

AI Makes Systems Engineering More Important

The emergence of increasingly capable AI coding tools makes this model even more interesting.

AI can increasingly help generate code, tests, documentation and debugging hypotheses.

But someone still needs to understand whether the resulting system is correct.

Does the driver break another subsystem?

Does the compiler produce incorrect machine code?

Does the firmware introduce a security vulnerability?

Does the NPU runtime actually exploit the hardware?

Does the power-management implementation work across different boards?

Can the software still be maintained five years later?

These are systems questions.

The consortium should therefore cultivate people who understand the complete chain:

silicon → firmware → kernel → driver → compiler → runtime → application.

That is a particularly valuable form of engineering knowledge.

India Should Not Keep the Consortium Indian

The institution may be founded and substantially funded in India.

But the technology should be globally open.

An engineer in Bengaluru should be able to work with an engineer in Munich.

A university in Chennai should be able to collaborate with a research group in Helsinki.

An Indian startup should be able to work with a European automotive company.

An engineer living in the United States, Japan, Brazil or Africa should be able to contribute to a project simply because they have something valuable to contribute.

Indian-origin engineers around the world could become an important source of talent, mentorship and leadership.

But nationality or ethnicity should not be a requirement for participation.

Indian-founded does not have to mean Indian-only.

Open by Default, Trusted by Design

This global openness must, however, coexist with serious security and compliance practices.

Not every project has the same risk.

A public compiler project and a secure automotive testing laboratory should not necessarily have identical access rules.

The consortium should therefore use a tiered participation model.

Open Community

Anyone can:

• read the code
• use the software
• report bugs
• submit patches
• write documentation
• participate in public projects

Technical Membership

Participating companies, universities and individuals can join working groups and contribute engineering resources under defined governance rules.

Strategic Membership

Trusted organisations can receive access to shared testing infrastructure, pre-production hardware, joint development programmes and industry working groups.

Restricted Projects

Projects involving particularly sensitive semiconductor designs, automotive systems, critical infrastructure, security technology or other controlled technologies can have additional access requirements.

The principle should be:

Open by default. Restricted where justified. Transparent about why.

Trust Should Be an Engineering Requirement

If India wants this consortium to become a major partner for Europe and other advanced technology ecosystems, trust cannot be an afterthought.

The consortium should establish a formal technology-trust framework covering areas such as:

• ownership transparency
• beneficial ownership
• conflict-of-interest rules
• export-control compliance
• research-security procedures
• secure development practices
• software provenance
• dependency tracking
• vulnerability disclosure
• access control
• protection of sensitive hardware
• auditable governance
• transparent funding

The objective should not be to create arbitrary political exclusions.

It should be to create a predictable, auditable system in which partners understand the rules before they participate.

That is particularly important for cooperation with European organisations.

The EU and India are already deepening cooperation in semiconductors, high-performance computing, AI, quantum technologies and 6G through the EU–India Trade and Technology Council. The July 2026 TTC meeting also launched an EU–India deep-tech startup partnership and agreed to strengthen strategic value chains. This creates a natural environment in which a well-governed open technology institution could eventually become a useful India–Europe engineering bridge.

Europe Should Be a Partner, Not Just a Customer

Europe has substantial strengths in automotive systems, industrial automation, robotics, embedded technology, semiconductor equipment, power electronics and industrial software.

India has enormous engineering capacity, a large technology market, a growing semiconductor ecosystem and a large pool of software developers.

An open consortium could sit between these ecosystems.

Indian engineers could contribute maintainers.

European companies could contribute industrial requirements.

Universities could contribute research.

Semiconductor companies could contribute hardware.

Startups could turn the resulting infrastructure into products.

The output would remain open wherever the project licences and governance permit.

A driver written in India could eventually support equipment made in Europe.

A European robotics requirement could lead to an open API maintained by engineers in India.

A RISC-V development tool improved in Bengaluru could be used by developers everywhere.

That is what a genuinely global FLOSS ecosystem looks like.

Become a Serious Upstream Participant

The consortium should also participate deeply in the organisations that already maintain the world's open technology infrastructure.

That could include appropriate membership and engineering participation in organisations and communities around:

• RISC-V
• Linux
• LLVM
• Apache
• Eclipse
• OpenSSF
• Mesa
• Zephyr
• other relevant FLOSS communities

But membership should not be about collecting logos.

Membership should mean contribution.

Money is useful.

Engineers are more useful.

Code is more useful.

Maintainers are more useful.

Testing infrastructure is more useful.

Upstream contributions are more useful.

RISC-V International's current development-partner model is an interesting example of this philosophy: participating organisations commit engineering resources and defined technical deliverables rather than merely being passive members.

India should adopt that mentality broadly.

Don't just join the global commons.

Become one of the people maintaining it.

Four Pillars

The consortium can therefore be organised around four major pillars.

1. Engineering & Maintenance

• Linux
• RISC-V
• firmware
• drivers
• compilers
• graphics
• AI runtimes
• security
• embedded systems
• testing

2. Open Technology Academy

• apprenticeships
• hardware labs
• mentorship
• upstream contribution
• maintainer development
• systems engineering

3. Industry & Ecosystem

• semiconductors
• automotive
• consumer electronics
• appliances
• robotics
• IoT
• industrial systems
• startups

4. Standards & Interoperability

• APIs
• reference architectures
• compatibility specifications
• certification
• hardware profiles
• security requirements
• interoperability testing

These four pillars reinforce one another.

Industry provides real problems.

The engineers solve them.

The Academy creates new engineers.

The standards teams turn repeated solutions into reusable interfaces.

The FLOSS community improves everything.

The Five-Year Flywheel

The initial roadmap could be remarkably simple.

Year 1 — Discover

Inventory existing RISC-V hardware and identify the most common gaps.

Year 2 — Enable

Fix drivers, firmware, toolchains, documentation, testing and hardware support.

Year 3 — Standardise

Turn recurring solutions into common APIs, SDKs and reference platforms.

Year 4 — Industrialise

Build automotive, appliance, robotics, consumer-electronics and IoT working groups.

Year 5 — Export

Turn the Indian engineering base into a global contributor to open technology infrastructure.

The important thing is that the work can begin immediately.

It does not require waiting for a future Indian processor.

And Then the Silicon Arrives

When new Indian semiconductor products eventually become available, they should not enter an empty ecosystem.

They should enter an ecosystem that already knows how to support them.

                  INDIAN SILICON
                       |
                 RISC-V / SoC
                       |
                 Common BSP
                       |
              Linux / RTOS
                       |
              Drivers / HAL
                       |
             GPU / NPU / VPU
                       |
                 Common APIs
                       |
                    SDK
                       |
             Testing / Certification
                       |
                   STARTUPS
                       |
                    PRODUCTS
                       |
                    USERS

This is the entire reason to begin now.

The semiconductor industry has long development cycles.

Software can move faster.

India can use that difference in timescale to its advantage.

Don't Wait for the Perfect Chip

There is a dangerous temptation to say:

"Once India has a world-class processor, then we will build the ecosystem around it."

That is backwards.

The ecosystem should already exist when the processor arrives.

Developers should already know the tools.

Drivers should already have a place to live upstream.

Testing infrastructure should already exist.

SDKs should already be available.

AI frameworks should already have integration pathways.

Companies should already understand how to build products on open hardware.

Universities should already be teaching the relevant skills.

European and other international partners should already know the organisation.

The first commercial Indian chips should therefore become another supported platform rather than an entirely new software emergency.

The Real Product of the Consortium

At first glance, it might seem that the consortium's product is software.

That is only partly true.

Its deeper product is capability.

The capability to take a new processor and make it useful.

The capability to take a new NPU and integrate it with AI frameworks.

The capability to take a new GPU and bring it into the graphics stack.

The capability to take a new sensor and make it available through standard interfaces.

The capability to take a development board and turn it into a product platform.

The capability to train engineers who understand the entire stack.

The capability to maintain software for decades.

The capability to participate in global standards rather than merely consuming them.

That is technological sovereignty in a much more useful sense.

India Does Not Need to Build Everything

There is an important philosophical point here.

Technology sovereignty does not require India to manufacture every component, write every piece of software or create an Indian copy of every global product.

It means developing enough capability that India can understand, integrate, maintain, modify and improve the technologies on which its economy depends.

Open technology is particularly powerful for this purpose.

India can contribute to the global commons while simultaneously developing domestic capability.

A Linux contribution is both global software infrastructure and Indian engineering experience.

A RISC-V toolchain improvement is both global infrastructure and Indian semiconductor enablement.

A new NPU runtime is both a FLOSS contribution and a potential foundation for Indian AI hardware.

A compatibility test suite can be used by Indian manufacturers and foreign manufacturers alike.

Everyone benefits.

The Bigger Vision

Perhaps the most important thing is what this consortium should not become.

It should not become another government IT project.

It should not become a collection of proprietary products.

It should not become an Indian fork of the entire open-source world.

It should not become a jobs programme whose success is measured by headcount.

It should not become a standards bureaucracy detached from real hardware.

It should not build products that compete with the companies it is supposed to enable.

Instead:

Find the talent.

Give them real hardware.

Fix the plumbing.

Upstream the improvements.

Turn repeated solutions into APIs.

Build the tools.

Train through contribution.

Create trusted governance.

Work with Europe and the wider world.

Let startups and manufacturers build the products.

Build the Plinth Before the Statue

India's semiconductor journey will eventually produce silicon.

But silicon alone does not create an ecosystem.

The ecosystem emerges when hardware, software, developers, standards, manufacturers and users can work together.

That requires infrastructure.

Much of that infrastructure can be open.

Much of it can be shared.

Much of it can be built before the final products exist.

And much of it can be built today.

India does not need to wait for the perfect chip.

It can start with the chips and boards already available.

It can start with the missing drivers.

It can start with the broken documentation.

It can start with the APIs nobody has standardised yet.

It can start with the engineers who already have the drive to maintain difficult software.

It can start small and let success attract talent, companies and international partners.

Eventually, Indian-origin engineers around the world can participate.

European companies can become partners.

Universities can become training grounds.

Startups can become users of the infrastructure.

Semiconductor companies can become hardware partners.

And the resulting software can remain part of the global FLOSS commons.

The philosophy can be reduced to five principles:

1. Build the tools, not every product.
2. Standardise the interfaces, not the innovation.
3. Train through contribution, not certificates.
4. Be open by default and trusted by design.
5. Build in India, contribute to the world.

The semiconductor fab may eventually produce the silicon.

But the software consortium can make sure that when that silicon arrives, someone already knows what to do with it.

That is the real opportunity.

Don't wait for the statue.

Build the plinth.

And make the plinth open enough that the world can build on it.

The Indian Computing Ecosystem: Own the Everyday, Rent the Extraordinary (Compressed)

Editor's Note: This is the compressed long-form edition of the original essay (https://thesovereignpulse.blogspot.com/2026/09/the-indian-computing-ecosystem-own.html) — shorter, but preserving the core argument and strategic framework behind India's emerging computing ecosystem.

India does not need to win the global transistor race to build computing sovereignty. It needs to own enough of the stack, enough of the market and enough of the learning curve.

The question is no longer whether India can build a computer

For decades, the obvious measure of computing progress has been the semiconductor process node.

7nm beats 14nm. 3nm beats 7nm. Eventually 2nm will beat 3nm, and some future process will beat that.

But national computing capability is not the same thing as transistor density.

A country can import the world's most advanced processors and still remain dependent on everyone else's architecture, software, intellectual property, manufacturing and supply chains.

Conversely, a country can build an ecosystem around mature silicon that is remarkably capable because the hardware, software and applications are designed together.

This is where India's semiconductor ambitions become much more interesting.

The Dholera semiconductor fab being developed by Tata Electronics, in partnership with PSMC, is planned as a 300mm foundry with technologies in the 28nm to 110nm range. Tata has also announced access to PSMC technologies including 28nm, 40nm, 55nm, 90nm and 110nm, while its 2026 partnership with ASML brings lithography expertise, equipment and ecosystem development into the picture. :contentReference[oaicite:1]{index=1}

That is not the end of India's computing journey.

It could be the beginning.

Stop confusing transistor size with user experience

The most important principle is simple:

A 22nm computer does not have to behave like a 22nm computer.

If the processor architecture is efficient, the operating system is optimised, the GPU and NPU handle the workloads they are designed for, memory is well matched to the system and applications are compiled specifically for the platform, a mature process can produce a very usable machine.

Users ultimately experience responsiveness, battery life, application performance and reliability.

They do not experience the transistor gate directly.

This creates a strategic opportunity.

India does not have to reproduce the entire global semiconductor hierarchy immediately. It can begin by owning the parts of computing that are economically and strategically important.

Generation One: build the computer before building the perfect computer

The first Indian processor does not need to be the fastest processor in the world.

It needs to exist.

A sensible first generation could be a modular laptop or desktop-class system built around a 40nm-class or similar mature process, with a RISC-V CPU, modest GPU or NPU acceleration, conventional memory and standard storage.

The objective would not be benchmark leadership.

The objective would be learning.

India needs engineers who understand the entire chain:

ISA → CPU → SoC → memory → accelerators → security → I/O → firmware → Linux → drivers → physical design → tapeout → packaging → product.

That knowledge cannot be acquired simply by importing finished chips.

The laptop should become a carrier for evolving silicon

This is where modular computing becomes particularly powerful.

Consider the philosophy behind systems such as MNT Reform: the motherboard, display, keyboard, storage and chassis can remain useful while the computing module evolves.

India could adopt the same principle.

+--------------------------------------------------+
|              Indian Modular Computer             |
+--------------------------------------------------+
| Display | Keyboard | Storage | Power | I/O       |
+--------------------------------------------------+
|              Standard Carrier Board              |
+--------------------------------------------------+
|       Replaceable Indian Compute Module          |
|     CPU + GPU/NPU + Memory + Security + I/O      |
+--------------------------------------------------+

The first compute module might be relatively modest.

The second could be faster.

The third could move to a smaller process.

The laptop does not have to become obsolete every time the processor improves.

That changes the economics of semiconductor development. Instead of treating every chip generation as a completely new ecosystem, India can build a platform on which successive generations of silicon are deployed.

The open-silicon advantage

India also does not have to start from an empty page.

The global open-hardware ecosystem already contains many of the building blocks.

RISC-V provides the open instruction-set architecture. Projects such as IIT Madras's SHAKTI demonstrate that India can build production-oriented RISC-V processors and SoCs. Other open projects cover CPUs, vector processors, GPUs, NPUs, image processing, storage controllers, security and SoC infrastructure.

Examples include SHAKTI, CVA6, BlackParrot, VexRiscv, Ara, Vortex, Coral NPU, NVDLA, Gemmini, Infinite-ISP, OpenTitan, LiteX and a growing collection of open ASIC design tools.

The significance is not that India should simply copy these projects.

The significance is that the starting point for Indian silicon can increasingly be a global design commons.

The missing piece is system integration.

Someone still has to turn all these components into a reliable product.

That is precisely where an Indian ecosystem can create enormous value.

Generation Two: optimisation becomes the weapon

Once the first generation exists, the objective changes.

The second generation does not need to reinvent everything. It can improve the CPU, memory subsystem, interconnect, accelerator blocks, power management and software stack.

A move toward 28nm-class silicon could provide substantially more room for integration.

Instead of building a generic processor and hoping the market finds a use for it, India could design processors around specific workloads:

• government productivity
• education
• office computing
• local AI inference
• industrial automation
• automotive systems
• communications
• edge computing
• storage and networking

The competitive advantage would increasingly become optimisation.

That is a much more realistic target than attempting to defeat the world's leading semiconductor companies at every workload simultaneously.

Generation Three: the 22nm possibility

Further down the road, a 22nm-class platform becomes particularly interesting.

Technologies such as GlobalFoundries' 22FDX demonstrate that 22nm FD-SOI can combine relatively mature manufacturing with low-voltage operation, body biasing and integration of digital, analogue and RF capabilities.

For India, however, 22nm FD-SOI should be viewed as a future possibility rather than an assumption about Dholera's current process roadmap.

Moving to FD-SOI would require the appropriate substrates, process technology, PDKs, standard-cell libraries, SRAM, analogue IP, design tools, manufacturing expertise and qualification.

But if that capability eventually becomes available, it could provide an interesting middle ground.

The objective would not be to make a fake 1.4nm processor.

The objective would be to make a very good 22nm computer.

Own the everyday. Rent the extraordinary.

This leads to the larger economic strategy.

India does not need every citizen to own the world's fastest computer.

It needs a domestic computing platform capable of handling the overwhelming majority of everyday workloads.

Think of the ecosystem as three layers:

Tier	Purpose	Silicon Strategy
Everyday	Government, education, business, home	Indian-designed and increasingly Indian-manufactured
Premium	Gaming, professional workloads, enthusiasts	Open to the best global hardware
Extreme	AI training, HPC, scientific computing	Accessed primarily through data centres and cloud infrastructure

This is not technological isolation.

It is sovereignty through optionality.

An Indian citizen should be able to buy an Indian computer because it is good enough, affordable and supported—not because every foreign alternative has been banned.

If someone wants a premium NVIDIA GPU, Apple processor or other leading-edge system, that market can remain open.

If a research institution needs enormous AI compute, it can rent it from a data centre using whatever advanced global silicon is economically appropriate.

The important thing is that the entire country does not need to depend on imported leading-edge silicon for ordinary computing.

The government can provide the anchor market

One of the biggest problems in semiconductor development is the chicken-and-egg problem.

Chip companies need customers before they can scale.

Customers hesitate to adopt immature domestic chips before the ecosystem is proven.

Government procurement can break that loop.

Imagine, as a policy scenario rather than a current mandate, that government departments and government-supported institutions committed to using a substantial proportion of domestically designed computing hardware.

A 20-million-device planning scenario would already be transformative.

At an illustrative ₹50,000 per machine, that represents ₹1 trillion, or ₹1 lakh crore, of hardware demand over a replacement cycle.

The real value, however, would be larger than the initial purchase.

Every government laptop becomes a test platform.

Every deployment creates software feedback.

Every failure teaches an engineer something.

Every successful deployment creates confidence for the private sector.

And the users take the technology home.

A government employee using an Indian computer at work is one user. A family exposed to that machine can represent several more potential users.

The government therefore does not have to manufacture everything.

It can create the initial market that allows domestic manufacturers and software developers to learn at scale.

Software is where the ecosystem compounds

Hardware sovereignty without software sovereignty would leave India only partially independent.

This is why the operating system matters.

Ubuntu and the wider Linux ecosystem already provide an enormous foundation for RISC-V computing. Over time, India could build a stronger national platform layer on top of Linux—possibly through a dedicated initiative or commercial ecosystem.

Call the hypothetical concept Canonical India.

The point would not be to create another Linux distribution merely for branding.

The point would be to coordinate the hardware and software stack:

• RISC-V support
• CPU-specific optimisation
• GPU and NPU drivers
• power management
• security
• developer tools
• package repositories
• enterprise support
• long-term updates

And the argument should not be that Android is simply a "virtualised" operating system. Android's ART runtime uses both ahead-of-time and just-in-time compilation, and Android supports native code through the NDK.

The stronger argument is that a native Linux/RISC-V platform gives India greater freedom to optimise the entire stack—from compiler to CPU to accelerator to application.

That is a much more powerful proposition.

The smartphone is the harder battlefield

Mobile computing would eventually become an obvious target.

A 22nm-class Indian mobile platform would not need to outperform the latest flagship processor.

It would need to deliver excellent everyday performance at a competitive cost.

Office applications, messaging, web browsing, media playback, education, payments and local AI inference do not necessarily require the world's smallest transistor.

The difficult part would be the ecosystem around the processor.

Cellular modems, RF, graphics, camera pipelines, display interfaces, power management and certification are all substantial engineering challenges.

Some of these technologies could remain globally sourced while the central compute platform becomes progressively more Indian.

Again, the principle is optionality rather than isolation.

Data centres complete the pyramid

The same ecosystem can support a completely different class of computing at the top.

                 EXTREME COMPUTE
             AI / HPC / SCIENCE
          Advanced Global Silicon
                    ▲
                    │
                 CLOUD
                    ▲
                    │
        INDIAN EVERYDAY COMPUTING
       Laptops / Desktops / Phones
            Domestic Platform

The ordinary device does not have to perform every computation locally.

A modest Indian laptop can run normal workloads while sending demanding AI, simulation or rendering tasks to a domestic data centre.

Those data centres can use whatever processors make economic sense—including advanced foreign silicon.

This is the key insight.

India does not need to own every transistor. It needs to own the ability to choose where computation happens.

Why ASML and the Netherlands matter

Semiconductor sovereignty cannot mean pretending the global semiconductor industry does not exist.

It means building strategic relationships with it.

The Tata Electronics-ASML partnership is significant in precisely this context. ASML is supporting the Dholera fab with lithography technology, training, supply-chain development and R&D infrastructure. :contentReference[oaicite:2]{index=2}

India can therefore learn from the world's semiconductor ecosystem while simultaneously building its own capabilities.

The long-term objective should be a design loop:

global technology → Indian engineering → Indian design → Indian manufacturing → Indian products → Indian users → engineering feedback → better Indian technology.

Over time, the proportion of that loop controlled domestically can increase.

The first generation creates the engineers who build the second

This may ultimately be the most important point.

The first Indian computer is not merely a product.

It is an engineering school.

The engineers who build the first RISC-V SoC learn things that cannot be learned from PowerPoint presentations.

They learn timing closure.

They learn memory controllers.

They learn power budgets.

They learn packaging.

They learn what breaks after tapeout.

They learn how Linux behaves on their silicon.

They learn what customers actually need.

Then they build the second generation.

And the third generation is built by engineers who grew up inside the second.

That is how ecosystems become self-reinforcing.

The ultimate roadmap

Stage	Objective
1	Open RISC-V development platforms
2	First Indian SoCs and learning silicon
3	Modular domestic computer platforms
4	Commercial 40nm-class systems
5	28nm-class higher-performance platforms
6	Integrated CPU, GPU and NPU ecosystems
7	Potential 22nm-class advanced domestic silicon
8	Thin-and-light mainstream computers
9	Indian mobile and edge-computing platforms
10	Advanced domestic data-centre accelerators

None of these stages needs to happen overnight.

The point is to make sure that every stage creates the capabilities required for the next.

Dholera should become more than a fab

The real opportunity is therefore much larger than manufacturing wafers.

Dholera could become the physical anchor of an Indian computing ecosystem—but only if the surrounding ecosystem grows with it.

That means semiconductor design.

It means RISC-V processors.

It means accelerators.

It means open-source hardware.

It means EDA and physical-design expertise.

It means packaging.

It means firmware and drivers.

It means Linux.

It means laptops, desktops, phones, servers and embedded systems.

And above all, it means users.

Conclusion: India does not have to win the transistor race

The conventional semiconductor race asks a simple question:

Who can manufacture the smallest transistor?

India should ask a different question:

How much of the computing experience can we control?

If India can build open processors, domestic SoCs, accelerators, operating systems, developer tools, computers and eventually mobile platforms, then a mature process node becomes much more powerful than its number suggests.

A 22nm machine optimised across the hardware and software stack can be an excellent everyday computer.

A premium user can still buy the world's fastest foreign machine.

A researcher can still rent extreme compute from a data centre.

And the domestic ecosystem can continue improving underneath all three.

That is the real meaning of “Own the Everyday, Rent the Extraordinary.”

India does not need to isolate itself from the global semiconductor industry.

It needs to become capable of participating in it from a position of strength.

The ultimate objective is not one Indian chip.

It is an Indian computing ecosystem.

Own the everyday. Rent the extraordinary. Keep the silicon evolving. And never start from zero again.