2005: Software Began to Live on the Web
· 57 min read · Views --

2005: Software Began to Live on the Web

Author: Alex Xiang

Essays

In the previous article about 2004, I wrote that “languages began to become toolboxes”. By 2005, that toolbox was pushed into a larger field.

Software began to live on the web.

That sentence sounds ordinary today. Office tools, maps, video, social networks, payments, documents, and code hosting are almost all online services now. But in 2005, it was not yet obvious. Much software was still understood as “download, install, open, upgrade to the next version”. Even websites were often understood as pages, channels, admin panels, and databases, not as systems that kept running, collecting feedback, and evolving continuously.

Around 2005, that understanding began to change.

YouTube appeared. Google Maps turned maps into interactive services. The word AJAX repackaged browser-side interaction into a development paradigm. Web 2.0 became a popular topic. Git was born under the pressure of Linux kernel development. People working on Linux and open source in China increasingly felt that software was no longer only about writing code, burning discs, and shipping releases. More and more, the real life of software was happening on the network.

I was still working on Linux in those years. The languages in my work remained mixed: Perl, PHP, Java, Shell, and Python all appeared in turn. But compared with 2004, my sense of “systems” became stronger. Whether a system could survive no longer depended only on code. It also depended on users, data, community, service, operations, business model, and continuous iteration.

Around 2005, I also began doing more Linux file-system-level development, including work related to SyncFS and SnapFS. The names sounded productized, but behind them were hard system problems: how files synchronize, how snapshots are made, how metadata is handled, how state recovers after abnormal interruption, and how all of this cooperates with the existing kernel, file systems, network protocols, and user-space tools.

This work was far from the excitement of Web 2.0, but it had an internal connection with “software living on the web”. No matter how beautiful an online service is, it still needs reliable storage, synchronization, backup, snapshots, and recovery underneath. The holes I stepped into in file systems during those years later made concepts in cloud storage, object storage, distributed file systems, and big-data platforms much easier to ground.

Web 2.0 Was Not Just a Buzzword Then

Looking back now, “Web 2.0” can easily feel like an outdated marketing term. And yes, many conferences, reports, and startup plans later spoke about it too vaguely: user participation, collective intelligence, the long tail, platforms, communities. After a while, it became tiring.

But in 2005, it did not become popular out of thin air.

The internet really was changing. Websites were no longer only media organizations putting content online for users to read. Users began uploading, commenting, collecting, sharing, subscribing, tagging, and collaborating. Products no longer waited a year to ship a major release. They changed continuously on the server side. Pages no longer refreshed the whole screen for every operation. More and more local updates and immediate feedback appeared.

Behind these changes was a change in software boundaries.

In older software, the boundary mostly sat on the user’s machine. You installed software on a computer, and that computer was its runtime environment. Later web services placed the boundary on the network: users, browsers, servers, databases, caches, logs, recommendation, search, ads, and monitoring all became part of the product. Software was no longer a package. It became a loop.

User behavior entered the system. The system produced data. Data changed the product. The product then affected user behavior. Once this loop started running, it could not easily return to the old rhythm of “ship one version and finish”.

In 2005, software became an online service loop

This is also why 2005 created new anxiety for many programmers. Writing code was still important, but writing code alone was no longer enough. You also had to understand browsers, networks, databases, logs, performance, availability, user growth, and even community and business.

Of course, we did not describe it so completely at the time. The work site was more plain: customer environments differed, deployment scripts had to be compatible, production issues required log inspection, internal systems needed fast changes, users wanted new features, backends had to hold up, and if data went wrong, someone had to write scripts to fix it.

Many grand technology trends eventually land in engineers’ hands as unattractive scripts and patches.

AJAX Gave the Browser Imagination Again

In 2005, Jesse James Garrett wrote an article introducing the term AJAX. Strictly speaking, the relevant technologies already existed. JavaScript, XMLHttpRequest, DOM, and CSS did not appear suddenly. The meaning of AJAX was that it reorganized a set of scattered technologies into a clear language for product experience.

Web pages no longer had to refresh the whole page after every operation. The browser could talk to the server in the background. Users could operate continuously on the page instead of waiting for one request after another to return. Gmail had already given a strong demonstration the year before. In 2005, the term AJAX let more teams know that this experience could be named, discussed, and copied.

This was interesting to me.

In 1997, I wrote a butterfly in JavaScript that could fly around the page. At that time, JavaScript felt like a small trick on a web page. Browser compatibility was terrible, and writing code often meant checking all kinds of strange differences. By 2005, JavaScript was being re-evaluated. It was no longer only an effect that floated around on a page. It could participate in real application logic.

Of course, this was still far from today’s frontend engineering. There was no React, no Vue, TypeScript was not mainstream, and npm’s massive dependency universe did not exist. But the direction had changed: the browser was moving from a “document reader” toward an “application runtime”.

This line would go much further later: Web 2.0, mobile web, SPA, frontend-backend separation, Node.js, TypeScript, Electron, PWA, and today’s AI applications inside browsers. Many of these can be traced back to early outlines visible in 2005.

YouTube and Maps Changed the Weight of Websites

YouTube was founded in February 2005. When people talk about online video today, they usually think of recommendation algorithms, the creator economy, short video, livestreaming, and copyright. But in 2005, the most basic questions were already hard enough: how to upload video, transcode it, store it, play it, distribute it, and make ordinary users willing to use it.

Video made websites heavy. A site was no longer only HTML, images, and database records. It became bandwidth, storage, encoding, player technology, content moderation, community interaction, growth, and operations. Behind one “upload video” button was a full infrastructure system.

Google Maps was a similar example. On paper, a map is static information. On the web, it became an interactive service that could be dragged, zoomed, searched, and continuously updated. To users, it simply became easier to use. To engineers, it meant the combination of frontend interaction, geographic data, backend services, cache, tile rendering, user queries, and external ecosystems.

This change mattered. It showed that websites were no longer only “information publishing systems”. They were starting to carry complex objects from the real world: videos, maps, relationships, locations, behaviors, transactions, documents, and code.

System complexity grew from behind the page.

In the past, if a website was slow, maybe a database query was slow, or a page was too large. Later, if an online service was slow, the cause might be cache breakdown, queue backlog, slow image processing, video transcoding delays, abnormal map tile loading, a third-party service fluctuation, or bad network conditions in a user’s region. Problems looked less and less like “code bugs” and more and more like “system illness”.

Programmers in 2005 did not yet have as many mature tools as today. There were not such standardized cloud services, containers were not widely adopted, and observability systems were far from complete. Many things depended on experience, logs, scripts, and manual investigation. But precisely because of that, engineers of that generation often developed a sensitive feel for system boundaries.

Git Was Born From Collaboration Pressure

Another event in 2005 was extremely important for programmers: Git was born.

Today Git is so ordinary that many newcomers assume version control naturally looks this way. But before that, CVS, Subversion, BitKeeper, and other tools each had their place. A large-scale, distributed, global collaborative project like the Linux kernel placed very high demands on version control. If the tool was unsuitable, collaboration itself became the bottleneck.

Git appeared largely because the real pressure of Linux kernel development forced it into existence.

The lesson this gave me was bigger than the tool itself: excellent tools often do not begin from abstract design. They grow out of unbearable work pain. Branches, merges, patches, history, offline commits, distributed collaboration: these concepts were not for elegance. They were needed so a group of people scattered around the world could keep pushing a complex system forward.

I was not yet using Git every day the way I would later. CVS and SVN were still common in Chinese companies, and many teams were still using more primitive collaboration methods. But Git’s direction was already clear: software engineering would depend more and more on toolchains, not only on individual heroism.

This is even clearer today. CI, code review, automated testing, artifact management, release pipelines, dependency scanning, code search, and AI coding assistants are all on the same line. Code is not finished when it is written. It must be understood, modified, tracked, rolled back, and continuously delivered by teams.

In Mountain View, I Saw Another Kind of Distance

During those years, I had the chance to spend a month at the company’s office in Mountain View. Looking back now, that experience may not sound earth-shattering, but for me at the time, it was still striking.

When doing Linux in China, there was often a strange sense of distance. On one side, we discussed global open-source projects, kernels, distributions, free software, and community protocols. On the other side, our daily work faced domestic customers, Chinese environments, driver compatibility, sales pressure, project delivery, and company survival. The technical world seemed close, yet the real center also seemed far away.

In Mountain View, that distance became concrete. Offices, streets, engineers, community events, and relationships between companies were not as mysterious as imagined. It was not a temple. It also had ordinary desks, meeting rooms, emails, arguments, and deadlines. But many key people, key projects, and key companies really were close together. Communication cost was low, and opportunity density was high.

My boss in the United States was friends with Linus. I did not meet Linus, but I did receive a baby-bottle sterilizer that was said to have been used by Linus’s child. The detail was so domestic and ordinary that I remembered it ever since.

It made me realize that the open-source world did not exist only in mailing lists, patches, and release announcements. It also existed in real human networks: who had worked with whom, who trusted whom, who was willing to introduce an opportunity, and who could push a project at a critical moment. These things are hard to write into technical documentation, but they deeply influence the direction of technical ecosystems.

The problem for Chinese open-source companies then was not only technical. Technology could be chased, versions could be followed, patches could be merged. But ecosystem position, commercial trust, community influence, talent density, and global collaboration networks were not things that could be filled in quickly.

The Problem of Open-Source Commercialization

Around 2005, many people were no longer simply asking whether open source was usable. Of course it could run on servers. Of course it could be used for development tools. More and more infrastructure also depended on open source. The real difficulty was: how does an open-source company make money?

Sell distributions? Sell support services? Sell training? Sell certification? Sell custom development? Sell industry solutions? People tried all these paths, and none was easy.

Because open-source software itself could be obtained freely, commercial companies had to provide value elsewhere. But many Chinese customers’ understanding of “service value” was unstable then. On one side, they wanted lower prices. On the other, they wanted someone to take responsibility when problems happened. On one side, they talked about supporting domestic software and open source. On the other, they worried about risks in critical business. In the end, this often became low-price projects, heavy delivery, and difficulty scaling for the company.

This later contrasted strongly with cloud computing, SaaS, and open-source commercial companies. Once software truly lived in the cloud, users were not only buying code. They were buying continuously running services, stability, upgrades, data security, ecosystem integration, and technical support. Only then did the business model gradually gain a clearer carrier.

So when I look back at that golden age of domestic Linux, I feel it was both lively and difficult. People really did a lot of work and trained many engineers. But it was still some distance from a mature commercial loop. Not every gap can be closed by effort. Some gaps come from the era itself.

Software Began to Become an Operational Craft

After 2005, more and more products would prove one thing: software is not finished when it is written. Software is operated into shape.

This sentence can easily be used by product managers to talk about growth, or understood by technical teams as operations. But it is broader than both.

After software goes online, users tell you what they really need. Logs tell you where the system is slow. Data tells you whether features are being used. The community tells you where documentation is unclear. Failures tell you where the architecture is fragile. Competitors tell you whether your rhythm is fast enough.

So engineers’ work changed too.

Earlier, it was more like building a machine and delivering it when it was done. Later, it became more like taking care of a system that changed every day. Code was only one part of it. Configuration, data, dependencies, scripts, monitoring, release, rollback, and user feedback all became parts of the system.

This is why I see 2005 as a dividing line. It is not that everything changed suddenly that year. Rather, many trends surfaced at the same time: Web 2.0, online video, online maps, AJAX, Git, open-source commercialization, user participation, and continuous services. Together, they pointed in the same direction: software looked less and less like a “product box” and more and more like an “online living system”.

This direction would later take me into larger internet companies, and it would take many programmers into new career cycles. When I joined Baidu in 2010, search, advertising, infrastructure, and data platforms were already at another scale. When I went to Weibo in 2012, the mobile internet and social networks would push system complexity up another layer.

But all that still lay ahead.

In 2005, I was still in a Linux company, writing code, writing scripts, building systems, and watching the open-source world change. But I already vaguely understood that the next things to truly change the industry might no longer be a standalone software product, an installation disc, or a distribution. They would be systems that stayed online, continuously absorbed user behavior, and continuously evolved themselves.

IT Events of 2005

  • Web 2.0 became a frequent term. In 2005, user participation, platformization, data-driven products, and continuous services represented by Web 2.0 gradually became industry consensus. Software was no longer only a release package. It became an online system that was continuously operated, updated, and fed by user behavior.
  • YouTube was founded. YouTube was founded in February 2005. Online video placed bandwidth, storage, transcoding, playback, copyright, community interaction, and recommendation distribution into one product. It later became a key form of internet content consumption.
  • Google Maps launched. Google Maps launched in February 2005. Maps moved from static information to interactive, continuously updated online services that could be embedded in applications. It also paved the way for local services, mobility, and location-based services.
  • AJAX was named and spread. Jesse James Garrett’s 2005 article on AJAX made asynchronous browser-side interaction an easier development paradigm to discuss. Web pages began to look more like applications and less like documents.
  • Git was born. Linus Torvalds created Git for Linux kernel collaboration. It later became the de facto standard for software engineering and changed distributed collaboration, code review, branch management, and open-source project workflows.
  • Reddit was founded. Reddit pushed community voting, link sharing, and user-generated content into a product form. It showed that the core of Web 2.0 was not fancier pages, but user behavior shaping content order.
  • Douban went online. Douban connected books, movies, music, ratings, reviews, groups, and city life, forming a distinctive community example in the Chinese internet. It represented another possibility for interest communities and long-tail culture outside portals.
  • Qunar launched. Online travel search began placing air tickets, hotels, and price-comparison capabilities in front of users. Later online travel competition would become an important branch of Chinese internet local services and transaction platforms.
  • Apple announced the move to Intel. Apple announced that Macs would migrate from PowerPC to Intel processors. This decision changed the Mac ecosystem and had long-term effects on macOS, development toolchains, and cross-platform experience.
  • Open-source commercialization continued to be tested. By 2005, the usability of open-source software was increasingly clear. The real difficulty was commercialization, ecosystem position, and continuous service capability. Later cloud computing and SaaS would provide new answers to this problem.

References

More in this column

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