2.1 Power

One of the first hurdles to deploying computing infrastructure in rural reaches of India comes from the fact that electricity is scarce commodity in most parts of India.

For example, the ubiquitous IBM PC clone consumes between 150 to 300 Watts of high-quality, 220 Volt AC power. Only a small portion (approximately 1%) of the Indian population has access to electric power of this quality 24 hours a day. A UPS (with its associated problems of reliability and running costs) is a necessity, not a luxury.

The power needs of a piece of computing equipment can affect its potential market by orders of magnitude. Table 1 maps the estimated market reach (in terms of a percentage of the Indian population) to the power needs of a device.

As Table 1 shows, the power requirements of a computing device has an inordinate influence on its social and market potential.

We clearly need to design our compute infrastructure in tune with the availability of power in our target society. Table 2 lists some available power sources, and their characteristics.

If every village in India were to get high quality electric power like India's cities, then this issue would cease to be relevant. However, the ecological costs of providing 1+ KW of high quality electric power to each of India's 1 billion plus citizens is disastrously high, even if such power distribution were to be feasible. Designing a computing infrastructure with a smaller power footprint is a much better alternative.

Currently, an affordable solar photovoltaic panel produces about 25 Watts of high quality electric power. Alternative sources of power (human, animal, biofuel or wind) are also feasible and economical in this power band. We thus need to develop computing devices that can work within 25 Watts or less of electric power.

2.2 Usability

The next big hurdle in building a pervasive computing infrastructure for India is that of making the compute infrastructure easy to use. In this section we will look at some very basic issues in human-computer interaction--the way in which a user would input data into a computing device and the way in which she would get back information.

As it turns out, these core issues have not received adequate design attention. For example, a few existing solutions have attempted to re-use input hardware designed for Western scripts. The end result practically requires a user to first learn English before they can be effective in communicating with their computers in an Indian language!

Section 2.2.1 examines the issues involved in entering data in Indian languages into a computing device. Section 2.2.2 covers the converse problem of presenting data to the user.

2.2.1 Input Methods

The predominant human-computer interface for western language input is a keyboard, modeled after the mechanical typewriters of the previous century. A typical computer keyboard is comprised of a number of keys (usually over a hundred) arranged according to ``well-known'' layout. These hundred or so keys correspond one-to-one with the characters of the western script. As Western scripts tend to be relatively simple, this approach works. Even here there are few quirks: a few of the characters used in Latin scripts can combine with diacritic marks; for example, the Latin character 'c' and the cedilla can combine to form the visual form 'ç'. Inputing these characters is usually done with the help of a special Compose key which indicates to the system that a special character combination is being requested.

Even for western languages there can be multiple keyboard layouts per language (for example, US English keyboards can be arranged according the the standard QWERTY layout (see Figure 1) or according to the alternative Dvorak layout).

Figure 1. A typical US English keyboard layout

Keyboard based input is however, infeasible for devices with small form factors, for example personal digital assistants and cell phones. For these devices, alternate input methods exist ranging from simple voice recognition and handwriting recognition to innovative use of the numeric keys to achieve text input.

2.2.1.1 Indian script input

Since the use of 100+ key keyboards is nearly ubiquitous in the western computing world, designers have attempted implementing Indian script input methods using this widely available form of hardware.

Using keyboards for inputing Indian scripts turns out to be awkward. Indian scripts typically use clusters (combinations) of consonants and vowels. A single visual unit of the script could represent a combination of 2 or more consonants and vowel. Since the number of possible combinations of consonants and vowels turns out to be very large, using a one to one mapping between keys on the keyboard and script units is not feasible.

What most Indian script keyboard input methods do is to assign keyboard keys only to the base consonants and vowels with the translation from a sequence of base consonants and vowels to the appropriate visual compound form being done elsewhere in the system. This approach suffers from many drawbacks, the primary two being a non-intuitive user experience and an increase is software complexity in many parts of the whole system. Figure 2 shows one of the many keyboard layouts for the Southern Indian language of Kannada.

Figure 2. Kannada Keyboard Layout (Inscript)

Unshifted	Shifted

2.2.1.1.1 Voice recognition and pen-based input methods

Two major alternatives to using keyboard based input methods are pen-based handwriting recognition (gesture recognition) and voice recognition. Of these, voice recognition technology for Indian languages is still being researched and is not in deployable shape today. Pen-based methods however, are already in production use in a few popular personal digital assistants in the West.

Most Indian citizens learn to read and write their native scripts using a pencil and paper (or chalk and slate). Using a pen-like input device would provide the most intuitive user interface for the common man.

In a pen-based input method, the user would directly write onto a touch pad or touch screen and the system would perform handwriting recognition to translate the users strokes into characters. A pen-based input method would also be suitable for handheld computing devices like cell phones and personal digital assistants.

Unfortunately, while pen-based input methods look attractive, practical implementations of such input methods for Indian scripts are not widely available.

2.2.1.1.2 Other alternatives

Some efforts have attempted to map Indian scripts onto a numeric keypad available on say a cell phone. While these efforts are innovative, they fall short in overall usability.

Indian language input methods are discussed in greater depth in the Indic-Computing Handbook.

2.3 Interoperability

As the phenomenal growth of the public Internet in the last decade has shown, data is truly valuable when it can be seamlessly shared.

We would like our Indian computing infrastructure to be able to designed in such a way that every participating device is able interpret Indian language information flowing around in our infrastructure without errors and distortions, whether the device is a humble handheld device or a central data repository. This interoperability is essential to the success of the computing infrastructure.

Such interoperability can only be achieved over the foundation of standards. At the most basic level, computers are devices which manipulate digital patterns of ones and zeros. The ``meanings'' of these digital patterns are implemented in the higher levels of the system; these meanings have to be defined somewhere (i.e. in the appropriate standards) and software has to be written very precisely, adhering to these definitions, before the digital patterns would mean the same thing on two different devices.

We have two broads kinds of standards that underly interoperability:

In the Indian language context, there are other standards that are either missing or faulty; for example, we do not have widely accepted standards for Indian language font encodings. This lack of standardization makes the task of rendering Indian language data to visual form unnecessarily complicated (and sometimes, makes the accurate display of script elements impractical).

The lack of adherence to standards is one of the reasons why Indian language data is not widely available on the Internet--for example, it is not possible today for a web-crawler like Google to search and index web pages with Indian language content.

2.4 Locality of Information

``Local information'' has great value. By local information we mean information that is relevant to the social context for which we are designing our information infrastructure.

Today, much of the content on the Internet comes from a few centralized sources. Much of this information is of limited value out of the context of the society that produced it. For example, it is a straightforward matter to get U.S. financial data on the Internet. However, a farmer in rural India would be interested in the rates for agricultural produce in his neighboring town. This farmer is unlikely to find data about say, oil futures in New York to be of immediate relevance.

Information systems in India today are structurally oriented towards disseminating information generated by a small number of sources of information. Information flow is mostly one-way: from the information sources like news agencies, corporations and government agencies to the consumer (for example, this is the way television and the print media work). Distributed systems that enable every citizen to be a potential information source do not exist.

Yet, there is a lot of local information that has value in-context. Tapping this information would open up entirely new markets.

2.4.1 Designing around local information

The basic characteristic of local information is that it is, local both in content and value-- the rainfall pattern in East Bihar would be of little relevance to a farmer in Maharashtra.

Consequently, a centralized information collection and distribution system is unlikely to be effective. We need lightweight, affordable systems that are managed by the local communities themselves.

For example, we could have information collection centers at the major (and perhaps the not-so-major) towns and agricultural centers, which record and publish prices and sales volumes of agricultural produce. This information would help value to the farmers of the neighboring villages to time their entry into the market and to determine their next crop (see Figure 3).

Figure 3. Hierarchy of Information Sources

Figure 3 represents schematically how local information could be aggregated and processed. Some information could be aggregated at the village level, and some would make sense only at higher levels of aggregation. The figure attempts to show the information flow between villages, clusters of villages, districts and higher levels of aggregation.

For an infrastructure like this to become widespread in the Indian context, the Power, Usability and Interoperability issues have to be solved first. A hard to use, non-interoperable or power hungry infrastructure will not be functional.

Summary. We need to design our computing infrastructure so that it is conducive to the collecting and disseminating of local information. Every Indian citizen would then be a potential publisher of information.

2.5 Value Addition

This is a fairly obvious point--our compute infrastructure should offer to its users significant value when compared to its cost.

This notion of ``value'' tends to be dependent on the surrounding context--for example, in the Indian context, it would not be good idea to implement expensive computer infrastructure aimed at replacing a cheap paper ledger and a human accountant. In the West, human labour is costly and so the speed and efficiency of computers when performing routine tasks provides value. However, labour costs in the Indian subcontinent are low, so the value addition offered by a computer will need to come from elsewhere.

There have been some efforts in reducing the cost of computing hardware for the Indian context: for example, Emergic Solutions has attempted to produce a stripped down PC costing about INR 5000 (about one-sixth the current entry level price for a full featured PC). The Simputer design attempts to spread the cost of the device across multiple users, by allowing per-user data to be stored on a cheap smart card.

However, just lowering the cost of the computing device is not enough. In the end, the adoption of a computing device in the market is determined by the value provided by it to the end-user, and not just by the devices cost.

Since computing devices process information, some of the ways they can provide value are:

• By using the sheer speed of the computer to automate processing of information. The value here is the speed and reliability of processing that a computing device offers over manual methods.

• By collecting and processing information in ways that are not feasible using manual methods.

Of the two, information collection and processing definitely offers a bigger value-add; for example, giving the rural user the ability to track market prices in neighboring towns. Being able to provide value in this manner requires a the complete system to be workable in the Indian context--for example, we would need low-power computing, networks for the dissemination of local information in place and easy to use computing devices.

2.6 Social Structure

For a computing infrastructure to be successful it needs to work harmoniously inside the overall structure of the society that it serves.

As a case in point, consider the problem of designing computing infrastructure for a society that places a strong emphasis on individual achievement and individual possession of artifacts. In such a society, computing devices would be personal: a user would own her cell phone and her personal digital assistant. These devices would be extensions of her personal psychological space so sharing of these devices would be limited to a few trusted people. Even when accessing a shared resource like a data network, a user in this society would expect the system to provide her an illusion of privacy.

In such a society, a manufacturer would profit by making information access devices personalizable; for example, many cell phones today allow their user interface to be somewhat personalized. It would not make economic sense in this market for a manufacturer to spend money adding multi-user capabilities to its device range.

Other societies may be more open to sharing material possessions. In these societies, a design that lowers per-user cost of information access by allowing multiple users to share a computing device may be feasible.

2.6.1 Indian Society

One major characteristic of Indian society that has a major impact on potential market size but that seems to be often ignored by policy makers and designers is the stratification induced by the caste system.

Indian society is highly segregated, with the kind of resources a person has access to being largely determined by his or her birth caste. The caste system functions predominantly an economic tool supplying the upper castes in the social hierarchy with cheap, and well indoctrinated labour.

Social structures in a typical Indian village In 1995, the author had an occasion to stay in a small village in the Chittoor district of the southern Indian state of Andhra Pradesh and had occasion to make the following first-hand observations. Figure 4. Layout of a village in Chittoor district, Andhra Pradesh Like most villages in India, the residential part of this village too was segregated along lines of caste. A schematic layout of the village is shown in Figure 4. The prime part of the village was occupied by the landowner caste, which in this village belonged to the Naidu community. The next area, comprised residences of washer-folk and other castes involved in the service of the upper castes. The regions where the people lower down in the caste hierarchy resided were further down the village road. In this village these were the snake catcher tribes (Irulas) and other tribal folk. On the economic front, the landowners controlled the economy of the village. Agriculture was the main occupation and as land ownership was confined to the upper castes, the lower castes eked their living by selling their labour. Payment given to the lower castes was rarely in cash, and was instead given in the form of foodstuffs, paid once a year. There was a separate area for the ``untouchables'', separated from the main village by about half a kilometer. This was the cleanest and best maintained part of the village even though the people here lived in conditions of great economic hardship. The untouchables were a source of cheap labour to the Naidu landowners. They worked in the fields for far less than the government prescribed minimum wage. Further, this payment was mostly in kind (foodstuff, handed over once a year) and not in cash. Consequently, most of these people were deeply in debt, at the mercy of the local moneylenders. In one family, one of the youngsters had managed to get recruited into the Indian army as a jawan (foot soldier) and would periodically send home some money. The whole untouchable community was very proud of this young lad. There were numerous social restrictions on the lower castes: lower caste people were not permitted to enter the upper caste areas freely, on the pain of physical punishment. Lower caste menfolk were permitted to wear footwear while walking on roads; however they were still required to step off the road if an upper caste person were to come along. Less than a generation back, protocol required the lower caste person to get off the road, squat and look down at the ground till the upper caste person had passed. Lower caste children were allowed into the nearby school (not shown in the figure), but had to sit on the floor at the sides of the class room and not on benches with the rest of the upper-caste kids. Girl children who reached puberty were not permitted to continue schooling, irrespective of their community of birth. There was one bore well in the village, supplying drinking water, which the lower castes were forbidden to use. The untouchables had their own (open) well. The Naidu landowners were the most caste and status conscious group in the village. When the village milk cooperative was setup, land had to be allocated from the middle part of the village as a compromise; the milk cooperative refused to have separate collection points for milk from upper and lower caste cows, and the upper caste landowners did not want the lower castes coming into their area to deliver milk. Right at the entrance to the village, close to the upper caste region but on the other side of the village road, the local member of the state legislative assembly had constructed a veritable palace; a two-storied house that looked as if it had been translocated from one of the posh suburbs of Hyderabad city (the state capital). This seemed to be the most visible effect of ``democracy'' in this village.

The basic social conditions described in the sidebar Social structures in a typical Indian village: the segregation of society along caste lines, separation of living areas, economic exploitation, and the division of resources and determination of a human being's potential on the basis of her birth caste are very common in mainstream India.

As computing infrastructure makes inroads into Indian society, information will become a commodity that the power centers in the society would like to control. A technology that allows itself to be controlled at a few ``choke-points'' will very likely not be able to reach the vast majority of India's citizens.

It is not in the scope of this article to comment on the morality of the Indian caste system. Instead, we would like to examine the implications of caste-based social hierarchy on the potential size of the Indian language computing market. Ideally, we would like every one of India's 1 billion plus citizens to be players in this market. The inefficiencies brought in by the Indian caste system could result in a reduction of the potential market size by orders of magnitude.

The choice of technologies used when doing system design needs to be done carefully, as the following examples will illustrate.

2.6.1.1 Example: Digital Identity

In order to participate in the new digital information age, people will need ``digital identities'', so that the system can verify that a person initiating a transaction is really who he or she claims to be.

There are two popular schemes available for people to identify themselves digitally:

• an hierarchical network of ``certifying authorities'' (CAs) who issue, for a fee, digital certificates of identity to their users,

• a looser peer-to-peer certification system used by tools like OpenPGP and Gnu Privacy Guard.

Both systems have their basis in the science of cryptography, but differ in their administrative structure.

Implicit in the design of the CA based authentication scheme is the assumption that every human being has a right to a digital identity. In the context of Indian society, this is a dangerous assumption to make. Caste based prejudices have survived for tens of centuries and we have the real possibility that digital identities being made available only to a few upper castes, rendering the lower castes identity-less in the new digital world.

A peer-to-peer identity authentication scheme like that used by GNU Privacy Guard would be immune to this kind of a ``choke-point''.

2.6.1.2 Example: Restrictions on Physical Access

In the typical Indian village, your lower caste customer faces restrictions on his physical mobility; some areas of his village are denied to him as the upper castes have deemed that his presence there ``pollutes'' the area.

Consider now, a shared rural information kiosk being setup in a village as an information dissemination point. Such a kiosk could disseminate a lot of useful information to the village folk; information that could result in substantially higher profits and efficiency of operation.

In the typical Indian village, the location of this kiosk would largely determine which communities would get access to the information being made available. If the kiosk were to placed in an upper caste area, the lower castes would effectively be cut off from the benefits the kiosk would bring. Voting booths, another disruptive influence for the upper castes, already tend to be placed in upper caste areas in Indian villages, as a means of ensuring that the lower castes face difficulties when voting; it is likely that our information kiosk will suffer the same fate.

Clearly, a technology that allows access to information without physical restraints (perhaps a solution that utilizes wireless networking as its basis, and which could work with alternate power sources) would reach more customers than one that would allow itself to be ``choked'' due to the need to physically access a computing facility.

Summary. We would like to have every single person in the Indian subcontinent as a user of our computing infrastructure. Consequently, our infrastructure needs to be as ubiquitous and easy to use as a pencil and paper (or chalk and slate) To be able achieve its full potential, our infrastructure needs to be immune to control by the discriminatory and restrictive social structures in place today.

2.7 Developer Ecosystem

So far we have looked at Indian language computing through the eyes of a user. There is another important group of people who are as essential to the success of our effort in building Indian language computing infrastructure--the Indian language software developer community, the people who would be implementing solutions that the end user would use.

Indian language software development efforts, like other software development efforts would need the following to be viable:

• An accepted vocabulary to describe the technical aspects of requirements and implementations. This would facilitate communication between customers and implementors, and even inside a development team.

• Knowledge (including ``folklore'') about implementation issues faced by developers writing Indian language software. Ideally, this knowledge should be widely available and should cover every Indian language of interest in a way understandable even by non-native speakers.

• Forums where developers and managers can gather to discuss issues about standards or implementation techniques related to Indian language computing.

The situation today is not encouraging. We lack a developer community around Indian language computing. Knowledge about the technical aspects of Indian language computing is difficult to obtain. We do not have a uniformly accepted vocabulary with which to describe issues, and we lack effective forums where technical issues can be discussed.

A commercial developer community around a technology develops according to market demand for products using the technology (for example, the high-profile marketing effort by Sun Microsystems pushing the Java language has resulted today in a large pool of Java developers worldwide). Since the Indian computing market is practically non-existent today, it may be a while before we see a commercial developer community centered around Indian language computing.

The open-source software community is less dependent on commercial pressures. However, the Indian open-source community is fairly thin today. Those developers willing to contribute volunteer time and effort to developing Indian language software are handicapped by the fact that there is a dearth of widely available know-how about Indian language computing. This, and the fact that most open-source ``developers'' tend to be students has ensured that the majority of open-source efforts on the Indian language front have been restricted to providing translations and the like. The harder and more pressing problems have had few takers.

The Indian academia could be a potential source of Indian language developers. However, interest in teaching Indian language computing has been hitherto limited among Indian academic institutes. Thus few new entrants to the Indian industry are even aware of the issues in Indian language computing. There are reasons for this lack of interest: today, most computer training institutes face a problem in attracting teachers qualified to teach basic computer science, leave alone the more specialized topics. The limited job prospects in the Indic field reduces the attractiveness of such training to students, and finally, even if the institute and students are willing, there is a scarcity of training material available for use in teaching Indian language computing.

A vibrant software developer community (including the necessary software management aspects) is a must for Indian language computing to become a reality. Section 4 describes the steps that the Indic-Computing project is taking in this regard.