2002: Linux Learned How to Do Business
· 50 min read · Views --

2002: Linux Learned How to Do Business

Author: Alex Xiang

Essays

In 2002, the character of Linux was changing.

It still belonged to technical enthusiasts. Magazine discs, forum posts, installation notes, desktop customization, kernel compilation: all of that was still there. Many people installed Linux for the first time with a sense of challenge: what did this non-Windows world look like?

But if you look at 2002 only from the enthusiast angle, you miss the most important shift.

That year, the enterprise market began to take Linux seriously.

Red Hat launched Advanced Server. SuSE, Turbolinux, Conectiva, and SCO tried to form UnitedLinux. OpenOffice.org 1.0, Mozilla 1.0, GNOME 2.0, and KDE 3.0 kept the dream of desktop Linux alive. At the same time, Chinese domestic Linux companies, technical communities, training markets, and government-enterprise customers were becoming lively.

Linux was no longer only a question of “can it be installed?”

It had to face another question: could it become a product, enter enterprises, receive long-term support, and build a business model?

I joined a Linux company that year. Personal experience is only the entrance. The more important line is the era itself: Linux moved from ideals, discs, and forums toward distribution companies, enterprise support, and domestic infrastructure software.

From Disc Enthusiasm to Enterprise Distributions

The 2001 essay was about the golden age of Linux discs. The keywords then were freshness, curiosity, and idealism.

In 2002, the keywords became stability, support, certification, release cycles, and customer responsibility.

Installing Linux for yourself is personal. If installation fails, you can try again. If a driver is poor, you can change hardware. If Chinese input is inconvenient, you can tolerate it. If the desktop crashes, you can go back to Windows. Enthusiasts have high patience and enough freedom.

Enterprise Linux is different.

Customers will not be moved because you solved a dependency conflict. They will not feel safe only because the upstream community is active. They care whether the system can be installed, whether services can start, whether upgrades will break business, and who is responsible when something fails.

That was Linux’s 2002 turning point: it started moving from usable to deliverable.

Usable depends on technical passion.

Deliverable depends on engineering discipline, version control, compatibility, documentation, service, contracts, and long-term maintenance.

This step was hard and important. Later cloud computing, containers, and AI training environments were built heavily on Linux. But if Linux had not first passed through enterprise adoption, it would have been hard to become today’s infrastructure.

The Second Stage of Domestic Linux

From the outside, domestic Linux can look like “making Linux Chinese.”

In reality, it was far more than that.

A distribution needs to solve several layers.

At the bottom are kernel and hardware. Server NICs, storage controllers, graphics cards, printers, and strange peripherals can all become problems. One unstable driver does not make the system “imperfect”; it makes it undeliverable.

The middle layer is the package system. Which packages enter the distribution, how versions are chosen, how dependencies are handled, how security updates are delivered, and how installation-disc space is allocated: these decisions are tedious but affect system stability.

Above that are desktop and Chinese environment. Fonts, input methods, browsers, office suites, printing, encoding, and document formats sound ordinary today, but at the time they could seriously damage the usability of a desktop system.

Finally there are customers and markets. Government and enterprise customers want stability, support cycles, documentation, training, and on-site service. Sales wants the system to look complete. Engineers know that every “complete” feature hides long-term maintenance cost.

That was the true difficulty for domestic Linux companies.

It was not about whether an installation disc could be made. It was about whether that disc could become a product with long-term support.

Around 1999, names such as TurboLinux, Red Flag, BluePoint, and Xteam had already brought Linux into Chinese technical media and communities. TurboLinux deserves special mention: it originally targeted Asian markets, valued Japanese and Chinese localization, and had deep connections with the Chinese market around 1999. Richard Stallman was invited to China by TurboLinux that year, which also shows that free software, the GNU/Linux naming debate, and China’s Linux boom had intersected early. TurboLinux later became the predecessor of the company I joined, which gives that history a more concrete distance for me.

By 2002, domestic Linux had moved from “let people know China can also make Linux” to “who exactly do we serve, and how do we survive?”

The desktop market was attractive but hardest. Ordinary users needed office software, input methods, browsers, games, peripherals, document compatibility, and familiar habits. One weak link could send users back to Windows.

The government-enterprise market was more realistic but heavier. Customers needed security and controllability, local support, training, on-site troubleshooting, and long-term maintenance. It was not as directly visible to ordinary users as the personal desktop, but it was more likely to bring revenue to distribution companies.

The server market was where Linux was most suitable. It did not need to please every ordinary user, but it needed stability, networking capability, scripting, remote management, and cost advantages. History later proved that Linux won most thoroughly on servers and infrastructure.

Four paths inside a Linux company

Behind an installation disc were community, build systems, servers, and customer support. The image is a period-inspired illustration.

Open-Source Ideals and Commercialization Were Different Things

The Linux world in 2002 carried strong idealism.

Many people believed open source would change the software industry. Source code would be open, communities would collaborate, users could learn and modify, and companies would no longer be completely locked in by closed vendors. These ideas are common today, but they still had fresh power then.

The problem was that companies had to survive.

Open source could explain the technical route, but it did not automatically explain revenue. How does a distribution company make money? Sell discs? Sell licenses? Sell services? Sell training? Do integration? Take government or industry projects? Every path was tried, and none was easy.

Red Hat later proved that enterprise subscriptions and long-term support can become a business. But that path requires strong productization, engineering, brand, ecosystem, and customer-service capability. It does not appear automatically by packaging software into an ISO.

Domestic companies faced more complicated pressure.

The personal desktop market was firmly occupied by Windows. Enterprise customers were willing to talk about domestic alternatives, but during procurement they would ask about stability, compatibility, service capability, and responsibility boundaries. Government projects could bring opportunities, but could also let projects drag product direction. Open-source communities could bring visibility, but not necessarily cash flow.

That was the contradiction many Linux companies faced: ideals were real, technical enthusiasm was real, and the market window was real, but the commercial loop was extremely hard.

Later I increasingly felt that the hardest part of infrastructure software is not writing code.

The hardest part is long-termism.

You need to maintain something for many years, keep compatibility with old versions, fix edge cases nobody wants to touch, answer repeated questions, and give customers a trustworthy upgrade path. Infrastructure software has few overnight success stories. It is more like paving a road inch by inch.

The Ambition of UnitedLinux

If you look only at China, 2002 was a lively year for domestic Linux companies.

If you zoom out globally, Linux itself was entering a new stage.

That year, SuSE, Turbolinux, Conectiva, and SCO launched UnitedLinux, hoping to jointly build an enterprise Linux foundation. The alliance now looks like a short episode, but at the time it explained the problem well: everyone saw enterprise Linux as an opportunity, but single companies found it hard to resist Red Hat’s momentum alone.

The logic of UnitedLinux was understandable.

Enterprise customers did not want each distribution to be completely different. Hardware vendors, software vendors, and integrators also wanted a more unified certification foundation. Several distribution vendors joining together to maintain an enterprise base, then separately building brands and services, sounded reasonable.

The problem was that an alliance is harder to maintain than a product.

Companies have interests, versions differ, the market has competition, and customers may not change choices because of an alliance. More dramatically, SCO later sued IBM in 2003, becoming one of Linux history’s famous legal events, and making its position inside the Linux camp awkward.

Looking back, UnitedLinux did not become the final answer.

But it proved the industry mood in 2002: Linux was no longer a marginal hobbyist system. It was a market enterprise software companies had to bet on seriously.

The Last Bright Moment of Desktop Linux

Beyond servers, desktop Linux in 2002 still had great imagination.

OpenOffice.org 1.0 was released, Mozilla 1.0 was released, and GNOME 2.0 and KDE 3.0 matured around that year.

Together, these events looked like a bright moment for desktop Linux.

The browser had a more reliable open-source route, the office suite had a visible alternative, and desktop environments looked increasingly like operating systems ordinary users could understand. For many people then, replacing Windows with Linux seemed no longer only a slogan.

But desktop systems are cruel because they must face human habits.

A programmer can tolerate ugly fonts, occasional input-method problems, document-format mismatch, and printer-configuration trouble. Ordinary users will not. Enterprise users even less so.

So desktop Linux in 2002 was exciting and also contained later disappointment. It showed possibility, but had not truly solved the ecosystem problem.

Linux was no longer only a black-screen server system and hobbyist toy. It was seriously entering enterprise markets and seriously facing desktop experience.

But enterprise adoption meant another kind of constraint.

Versions could not change casually, interfaces could not break casually, documentation could not be absent, security updates could not rely on enthusiasm, and customer sites could not be handled by saying “read the source yourself.” The rhythm of the open-source community and the rhythm of enterprise customers were not naturally aligned. Distribution companies, service companies, and engineering teams had to buffer between them.

That was why Linux companies existed.

And why they were hard.

Programmers Were Standing Inside the Wave

I joined a Linux company in 2002, which felt more like stepping into a wave.

There were many smart people in the company. Many colleagues came from Tsinghua, Peking University, and other top schools, and some were well known in China’s Linux circle. People discussed kernels, desktop environments, drivers, compiler toolchains, free software, and commercial licensing. The density of that environment still feels special today.

But this essay should not be only about personal experience.

What personal experience explains is this: after a programmer truly enters a Linux company, history stops being a headline. It becomes the installation disc next to your desk, the machine at a customer site, packaging scripts, version plans, sales promises, and failure calls at midnight.

Before that, when writing programs, I focused more on whether functions were implemented. After entering a Linux company, I was forced to care about a whole system: kernel versions, filesystems, boot flow, service scripts, network configuration, package dependencies, installers, upgrade paths, log locations, and remote troubleshooting methods.

This was not training in one programming language. It was training in system engineering.

The development languages during that period were also mixed: Perl, PHP, Java, Shell, Makefiles, and configuration files were all used, and I later started using Python. Inside a Linux company, languages felt like a toolbox: text processing, system automation, backend administration, websites, and enterprise applications each had their own tools.

That mixture had a long-term effect.

It made me less superstitious about any one language and more focused on the problem itself.

What 2002 Really Left Behind

Looking at the outcome, many early domestic Linux distributions did not become mainstream consumer desktops.

But from the perspective of people, those years left many things behind.

They trained a group of people who understood systems: Linux, networks, servers, builds, open-source collaboration, and the complexity of customer sites.

They exposed domestic programmers earlier to open source. Many people seriously read large-project code for the first time and understood patches, versions, dependencies, and community collaboration.

They also taught some people that infrastructure software is not a slogan. Slogans can be loud, but when landing in reality, every driver, document, upgrade, and customer site is cost.

For IT history, the biggest change in 2002 was that the enterprise path of Linux became clearer.

The desktop ideal remained, but servers and enterprise markets were more realistic.

Community mattered, but commercial support mattered too.

A distribution was not only installation media. It was a software supply chain, version responsibility, and service system.

For me, the biggest change that year was that the technology world expanded from “what program can I write?” to “how is a system produced, delivered, and maintained?”

This step mattered.

In later years, whether building backend services at Baidu, data platforms and recommendation systems at Weibo, or graph databases and AI engineering later, I could still faintly see the shadow of that period.

In 2002, Linux still had strong upward momentum.

In 2003, another reality arrived: SCO sued IBM, RHEL and Fedora separated, enterprise Linux’s commercial path became clearer, and the legal boundaries of open source drew more serious attention.

Richard Stallman’s visit to China belongs to the 1999 prehistory: he was invited by TurboLinux, which was the predecessor of the company I later joined. The free software movement did connect early with China’s Linux boom, but it was not my personal experience in 2002 or 2003.

The next essay is about 2003: the ideas of free software, Linux’s legal shadow, and open-source compliance after enterprise adoption.

2002 IT Timeline

  • Red Hat Linux Advanced Server 2.1 was released. This was an important milestone for Red Hat’s enterprise Linux route. The later RHEL subscription model became one of the most successful examples of open-source commercialization.
  • UnitedLinux was formed. SuSE, Turbolinux, Conectiva, and SCO tried to build an enterprise Linux foundation together, reflecting the rapid formation of the enterprise Linux market.
  • OpenOffice.org 1.0 was released. The open-source office suite reached an important milestone, adding a key piece to the dream of Linux desktop replacing Windows.
  • Mozilla 1.0 was released. After the browser wars, Mozilla continued in open-source form and laid the foundation for Firefox.
  • GNOME 2.0 and KDE 3.0 were released. Linux desktop environments entered a more mature stage, and the imagination around desktop Linux remained strong.
  • Domestic Linux companies and communities stayed active. Names such as Red Flag, BluePoint, Xteam, Co-Create, Xinhua, and CS2C appeared in technical media, communities, training, and government-enterprise markets, continuing early exploration of domestic operating systems.
  • TurboLinux’s China line still influenced the domestic Linux ecosystem. TurboLinux had deeply participated in the Chinese market around 1999 and invited Richard Stallman to China. By 2002, this Asian Linux distribution route remained important background for understanding domestic Linux commercialization.

References

More in this column

View all posts in "Thirty Years in IT and Me"