Producing software is becoming increasingly easier. So why are we paying more money every passing day to use it? And more importantly, when machines begin working in our place, who will own the value they produce?

In recent days, I wrote an article on how programming languages came about. Those articles will turn into a series, but as I began that piece, I also mentioned that I hadn't been enjoying writing for a while due to the impact the development of artificial intelligence had left on me. In fact, I realize this situation isn't merely about writing. A person strives for years to learn something, to build something. Then one morning they wake up and see that they can now have a machine do a portion of what they spent years learning with just a few sentences.

Whether one should rejoice or despair over this, I'm honestly not sure.

Right in the middle of these thoughts, I stumbled upon a movement called OccupySaaS. At the very top of their website, it reads:

“They laid us off. We’re rebuilding their SaaS.”

Roughly speaking: "They laid us off. We're rebuilding their SaaS."

At first glance, it looks like an attempt by an angry group of developers to stand up to big tech companies. Which, in fact, it is. Who would have thought the most bourgeois of white-collar workers would raise the banner of rebellion… But when I poked around the site a bit, I thought there might be more to it than just a few open-source projects. And I began contemplating the possibility that these elites, whom I had viewed with a slightly mocking eye, could actually spark a revolution.

If you ask why, this initiative is a small but remarkably concrete example of a question that has been nagging at my mind regarding artificial intelligence for a long time:

Why isn't the ownership of production changing while the means of production are changing?

Maybe they will achieve huge things, or maybe this initiative will leave no trace in the software universe. Regardless, this organization… In recent days, Evrim Ağacı's video titled What Will You Do When Artificial General Intelligence Arrives? also led me to a similar question. I leave its link below as well:

What Will You Do When Artificial General Intelligence Arrives? — Evrim Ağacı (YouTube)

If machines can do the vast majority of tasks humans can do in the future, what will be the place of humans in economic life?

Seeking the answer to this question solely in the pace of technological development strikes me as incomplete. One needs to look a bit at history, a bit at economics, and a bit at computer science itself. That is why I came here to write this.

Anyway, before starting all the way from Noah's ark again, let's start with SaaS.

How Did Software Turn into Real Estate?

The software industry has undergone an interesting transformation.

Once upon a time, software was sold in physical boxes on floppy disks. You bought the program, installed it on your computer, and used it. Of course, license restrictions, upgrade fees, and all sorts of rules imposed by the manufacturer still existed. But at least running the program occurred mostly on your own machine. Over time, CDs replaced floppy disks. But their lifespans weren't very long either.

With the proliferation of internet connectivity and the rise of cloud computing, Software as a Service—the SaaS model—settled into the center of our lives. Instead of buying software, we began renting access rights to it. In fact, one of the biggest examples of this is Steam. Yes, the gaming industry was one of the places where SaaS evolved fastest.

One shouldn't be too surprised by this. When you bought a game on Steam, you bought it once. No hassle of buying CDs over and over, or hunting down and digging up those disks every time you format your computer. Updates happen automatically, and you can access the same data from different devices. How lovely, right? As a gamer, certainly, but what about businesses? Consider that thanks to this structure, it became possible for a small business to use systems tailored to their own needs that previously only large corporations could afford—with SAP being one of the prime examples. Instead of purchasing a massive piece of software, you buy business packages piecemeal according to your needs, and then sit back waiting for them to load from a single service. You don't have to deal with massive piles of disks, nor do you have to shell out cash for the entire software suite.

So far, so good.

Yet over time, another attribute of easy access surfaced: Dependency.

For example, imagine you start a small business. You have a team of five people. You use one CRM to manage your customers, another service for your documents, a separate app for internal team communication, and yet another infrastructure for authentication.

Business grows. The five-person team becomes fifteen.

Normally, one would think: The development cost of this software has long been covered, and the marginal cost of adding a new user is quite low for certain services. Therefore, as software scales, the cost per user could be expected to decrease.

But not every SaaS is priced that way. When you become fifteen people, your bill might triple as well. Of course, an important distinction must be made here. The cost of running software does not consist merely of CPU time or RAM consumption. Technical support, security, regulatory compliance, data retention, and continuous development also cost money. Thus, per-user billing is not an outright scam in and of itself.

However, the moment pricing begins to depend not on the service provided, but on the customer's inability to exit the system, the tables turn.

Your customer records, automations, business processes, third-party integrations, and your employees' habits are now shaped around that platform. Even if you wanted to migrate to another system, doing so carries a formidable cost. That is precisely what is known as vendor lock-in.

For years you build your company's processes inside a piece of software. After a while, that software starts dictating the way you work.

It even reaches such a point that migrating your own data elsewhere turns into an entire engineering project on its own.

In the past, we bought computers to run software. Today, we pay continuous rent just to access the software that makes the computer useful.

If you ask me, this is the core issue OccupySaaS is protesting.

From 1983 to 2026: A New Free Software Movement?

It would be unfair to say this debate is new.

In 1983, when Richard Stallman announced the GNU project, he proposed developing an operating system compatible with Unix that people could freely use and modify.

Notice, the topic was not merely free-of-charge software; it was free software (libre software).

It was about being able to study how the software works, modify it, share it with others, and improve it according to your own needs.

Because if you cannot access the source code of a software, your control over what that software does on your computer remains limited.

Over the years, GNU, Linux, and countless open-source projects demonstrated that this philosophy wasn't merely a romantic engineering daydream. Today, countless systems—from servers running on the internet to the infrastructure of the programming languages we use—stand atop this culture.

Yet in the more than forty years that have elapsed, an intriguing situation emerged.

Companies leveraging the infrastructure provided by open-source software transformed services developed on top of this foundation into gargantuan commercial platforms.

There is no inherent contradiction here on its own. Using open-source software commercially is already something explicitly permitted by many licenses.

The real debate is how difficult these platforms make it over time for users to transition to other systems.

The Occupy Wall Street movement that emerged in 2011 debated economic inequalities through the lens of the 1% and the 99%.

OccupySaaS, in 2026, carries a similar rhetoric into the software industry.

On one side are the engineers who produce, maintain, and develop the software. On the other side are the entities controlling access, distribution, and commercial value of the software.

OccupySaaS's premise is this: If the people building these systems are being laid off and artificial intelligence is driving down software production costs, why don't we build open-source alternatives compatible with existing platforms ourselves?

In a sense, the free software philosophy of 1983 is being reinterpreted with the artificial intelligence tools of 2026.

Only this time, the target is not merely a free operating system, but the commercial services companies pay invoices for every month.

And in my opinion, the most technically interesting side of the matter begins right here.

Rebuilding the Same Software Without Taking the Source Code

OccupySaaS's approach relies on the methodology known as clean-room implementation.

In this method, instead of copying another software's proprietary source code or reverse-engineering its internals, you build an independent implementation utilizing publicly available technical documentation and standards. They currently have two active projects, which I will mention.

The goal in this project is not to recreate the identical internal architecture, but to construct a system compliant with the specified external behaviors.

For example, consider standards like OAuth 2.0 and OpenID Connect.

When an application wishes to authenticate a user, it redirects to an authorization server. The server verifies the user and issues authorization codes or tokens according to specific protocol rules. The application then checks their validity and grants the user access.

The system running behind this operation does not necessarily have to belong to a specific company. What matters is the accurate implementation of the protocol and the behaviors expected by the application. One of OccupySaaS's first projects, ZeroAuthy, is built on precisely this premise.

The project aims to develop an authentication server compatible with Auth0. The goal is to allow applications using existing Auth0 SDKs to connect to an alternative server with minimal to no code changes. In theory, a very powerful concept. Because freedom here stems not solely from source code being open; it stems from reducing the cost of leaving the existing system.

Yet there is also an unseen side to the coin. Two systems having identical HTTP endpoints does not mean they are fully compatible. Token lifetime management, refresh token rotation, error responses, rate limiting, user session invalidation, data isolation in multi-tenant architectures, and especially security boundaries must satisfy the same expectations.

Seeing an endpoint returning 200 OK in an authentication system does not prove the system is secure. A misconfigured JWT validation or flawed tenant isolation can leave the entire system exposed to attacks.

Indeed, ZeroAuthy notes that it is still in early stages. Still, public tests, compatibility efforts, and documentation regarding OpenID Connect certification show that the project is not a mere surface mimicry.

The second project is SalesCompel. This time the target is Salesforce. As someone who has built CRM systems, I can tell you this one is far more convoluted. Storing a customer's name, phone number, and email address in PostgreSQL is the easy part. Keeping customer permissions, dynamic data models, sales pipelines, automations, integrations, transaction integrity, and data migration running smoothly for years is a completely different beast.

Viewing a CRM system as consisting merely of CRUD operations is like viewing an automobile as consisting merely of four wheels and a steering wheel. SalesCompel's own roadmap clearly reveals that full compatibility is not yet achieved, and data migration, security, automation, and production-grade verifications significantly await completion. In other words, there is no system here mature enough to cancel your Salesforce subscription tomorrow morning.

But the objective isn't merely evaluating today's two projects. Because what is truly shifting is the nature and cost of human labor required to develop such systems.

Artificial Intelligence: The Cause of Our Unemployment or the Tool of Our Liberation?

We have arrived at the most controversial and brain-tickling aspect of OccupySaaS.

The movement proposes that laid-off engineers recreate the products of big tech companies using AI agents.

Wait a minute.

Engineers who believe they lost their jobs due to AI are going to use AI to compete with the companies that laid them off(?).

Sounds a bit tragicomic, doesn't it?

Moreover, attributing all layoffs in the tech sector solely to AI is inaccurate. Interest rates, post-pandemic overhiring corrections, corporate cost-cutting policies, and shifting investment climates are all part of this process. But there is a more fundamental transformation taking place here. Artificial intelligence can drastically reduce the time humans need to expend, especially during certain phases of software production.

A mundane REST API, data model, or admin interface that would previously take a developer days can today be prepared in vastly shorter time using AI tools. However, turning a job that took days into code in a few minutes does not guarantee that the code will run reliably for years.

Because writing code and practicing engineering are not the same thing.

I want to emphasize this point in particular. Verifying the security of produced software, taking precautions against data loss, handling erroneous states, maintaining consistency, and keeping the system standing under unexpected loads remains a serious engineering endeavor.

AI may play an increasingly larger role in some of these tasks as well. Yet today, a wide gap exists between a model generating code very quickly and proving a system's reliability. OccupySaaS aims to bridge this gap through technical contracts, open specifications, compatibility testing, and human review.

In my opinion, this is what makes this movement significant.

Instead of telling AI "Build me Salesforce," they propose specifying testable behaviors and incrementally developing a system that fulfills them. Thus, a substantial portion of software engineering shifts from writing code directly toward defining what code must do and proving whether it actually does it.

In my last article while explaining programming languages, there was a recurring thought I kept returning to: Complexity doesn't vanish, it relocates. That is somewhat what's happening here too. You drive down the cost of writing code. But the cost of properly defining system behavior, verifying the generated code, and maintaining it over the long haul does not disappear. It merely migrates to other layers.

Therefore, software development becoming cheaper thanks to AI does not mean software engineering disappears entirely. But the possibility of companies needing fewer employees to produce the same volume of software cannot be ignored either.

So who will benefit from this surge in productivity?

That is the question that concerns me.

Who Will Own Capital While Machines Do the Work?

Now let's come to what will happen when Artificial General Intelligence (AGI) arrives.

The aspect of this issue that made me ponder wasn't exactly when AGI will be developed or what feats it will be capable of.

It was how humans will be positioned in that economy if we one day reach a world where a significant portion of economic activities humans can perform can be automated.

Imagine you own a factory. Previously you employed a hundred workers. With new automation systems, you become able to achieve the same output with ten workers. Your production remained the same, or even increased. Economically speaking, the productivity gain is immense.

Yet how the remaining ninety people will earn their living is a separate dilemma. This dilemma was once the question that nagged at Karl Marx's mind, and it is the question that prompted him to write Das Kapital.

Now apply this scenario not only to a factory, but to software companies, logistics, the financial sector, design, accounting, and over time to more domains. Of course, throughout history automation created new professions as well. Humans moved from agriculture to industry, and from industry to the service sector. One cannot claim that technological advancements will always inevitably result in permanent mass unemployment.

Yet what makes the general-purpose artificial intelligence premise distinct is the possibility of automating not merely specific tasks, but newly emerging jobs as well.

We do not yet know whether this scenario will materialize.

Still, if we take the possibility of its realization seriously, assuming the economic order will remain unchanged is somewhat bizarre. Because in today's system, the vast majority of people earn their livelihood by selling their labor. The owner of the factory owns the machine. The worker owns their labor. If the production process requires progressively less human labor, what will become of the bargaining power of the person who makes a living by selling their labor?

Even more critically, who will own the surplus value created by automation? A system developed by a programmer can be used by millions of people. Yet ownership, distribution, and monetization of that system mostly do not belong to the programmer themselves.

Now think about it.

An engineer works for years on developing a SaaS platform. Over time, the platform attains tremendous economic value. Later, the company decides it needs fewer engineers by using new automation tools. The engineer loses their job. But the system they contributed to developing continues to operate and generate revenue.

We cannot say there is a legal injustice here on its own. The property and compensation relationship between company and employee is defined by contracts. You enter agreeing that the code you write belongs to the company, and in return you receive a monthly salary. Just like people working in a shoe factory own the salary deposited at month's end rather than the shoes they manufacture. Of course, given that they earn money for every step taken in these shoes, and the gears can keep turning even if you don't produce new shoes, there is a world of difference between being a SaaS developer and being a shoe factory worker.

Yet from an economic and social standpoint, we must ask another question:

When the accumulation created by human labor begins needing less human labor, how will the returns of that accumulation be shared?

Unfortunately, OccupySaaS does not offer an answer that redesigns the entire economy. What it is doing is more like protesting by shouting "BOOOO."

Yet it presents quite an intriguing reaction.

Since we lack ownership over the existing means of production, let us collaboratively build alternative means of production.

This is a notion far distinct from merely competing with a SaaS company on price.

Is Open Source Truly an Escape Route?

Here one needs to be somewhat critical.

The existence of open-source code does not automatically translate to a democratic distribution of economic power.

A software being hosted on GitHub and released under the Apache 2.0 license does not mean everyone will derive the same economic benefit from it. After all, having access to source code is one thing; having the resources to operate it reliably and at scale is another.

For instance, suppose you decide to self-host a SaaS service. You can escape the subscription fee. But you will still need servers, backup systems, network security, monitoring infrastructure, updates, and humans to intervene when needed. Sometimes managing all of this yourself can even turn out more expensive than buying a subscription to a commercial service. Spinning up a CRM server in a Docker container is not the same thing as operating it for five years without losing your customers' data.

And there is an even deeper dimension to the matter. Permissive licenses like Apache 2.0 permit code to be used commercially and integrated into closed-source products under certain conditions. In other words, another company tomorrow could take a project built by OccupySaaS and use it inside the infrastructure of their own commercial service. That is an outcome of the freedom granted by the license. Yet thinking about this, an ouroboros—a serpent devouring its own tail—flashed before my eyes.

Yet it is also an issue that must be debated from the perspective of the argument the movement develops against the concentration of economic power.

More importantly, there is the question of long-term sustainability for open-source projects. Who will be the people developing the software? Who will remediate security vulnerabilities? It's great to have hundreds of people contributing to a project. But five years down the line, when a critical database bug appears, who bears the responsibility must also be established.

These are not insurmountable issues. Yet measuring the success of free software merely by GitHub stars or lines of code written is also not accurate.

Perhaps the most significant transformation AI will bring to this realm is enabling small teams to develop projects that previously only large corporations could execute. But for this to constitute a true alternative, models of financing, governance, security, and maintenance must evolve alongside code generation.

Liberating a software's source code is not the same thing as liberating the power to run it.

And once again we return to the same question: Who controls production?

Perhaps the Real Revolution Isn't Writing New Software

I don't know whether OccupySaaS will succeed. Perhaps in a few years they will produce projects that truly serve as alternatives to massive SaaS platforms. Or perhaps a portion of their projects will lose developer community interest and be abandoned.

Both are possible. But I think this initiative has an important dimension: For the first time, the assumption that certain services offered by big tech companies are too complex to ever be rebuilt is being more seriously questioned.

Of course, rebuilding existing systems does not always make sense. Building a system from scratch can also be more costly than adopting an existing, mature open-source alternative. Still, it is evident that AI accelerating code generation will lower the technical barriers to competition in certain software markets. And that could weaken a portion of the economic advantages existing corporations have established through pricing and user lock-in.

Yet there is another irony here. A portion of the AI models OccupySaaS utilizes to produce open-source alternatives also depend on the infrastructure of large tech companies. That is, while producing alternative software against SaaS monopolies, you might this time become dependent on AI providers.

While eliminating one dependency, it is entirely possible to create another. For that reason, I don't believe the issue is solely swapping SaaS services for open-source. Over the long run, we also need to debate who controls compute power, models, data centers, software infrastructures, and the economic value arising from them.

If AI will boost human productivity, that is wonderful. If one person can accomplish what ten people previously did, if we can produce more with fewer resources, there is no reason humanity shouldn't benefit from this.

Yet a productivity increase and sharing prosperity are not the same thing.

A technology can generate tremendous economic value. Whether that value spreads across broad segments of society is determined not merely by technological capacity, but by institutions, competition, property relations, and political choices.

That is why, if you ask me, the real question is not "Will AI take all our jobs?"

Can we build a world where we don't have to work thanks to AI, or are we heading toward a world where fewer people capable of working are needed, but working is still mandatory to make a living?

The two are remarkably different. In one, automation liberates people. In the other, the economic advantage created by automation can concentrate in the hands of those who own the means of production.

And movements like OccupySaaS may perhaps sound like small cries in the struggle between these two futures—for now…

In Lieu of a Conclusion: Whose Code Is It, Whose Future Is It?

Looking at the developments in the software world over the past few years, I experience conflicting emotions.

On one hand, there is tremendous excitement. We can build vastly more complex systems with vastly fewer resources. Some tasks that previously required large teams can now be executed by small teams.

On the other hand, watching how the economic value of a skill a person spent years painstakingly learning transforms is a strange sensation.

Perhaps the true discomfort lies right here.

For years, we have been explaining to computers how to compute.

First we used machine code, then assembly—I wasn't around for those eras, but we used C, C++, Java, Python, and many more that followed, developing various tools. With each generation, we made talking to machines a little easier.

Now at the point we have reached, we can explain what we want to do to the machine using natural language. This is a profoundly impressive milestone in the historical evolution of computer science.

Yet if at the end of all these advancements we can produce more with less human labor, is it really so bizarre to expect that to return to humanity as more time and freedom?

When I look at OccupySaaS, what I see is not just a bunch of engineers angry at big SaaS corporations. It is simultaneously an objection directed at the distribution of the value created by technology. I don't think this objection has all the answers. I even have serious question marks about how successful existing projects can be in the long run.

Yet I think the question it raises is vital. Today we object to the per-user pricing of a SaaS service. Tomorrow we may be debating the fees we pay to access AI models, the ownership of compute resources, or the revenues generated by fully automated production systems.

Perhaps in this new era, the idea of free software will need to be rethought not merely to cover code, but to encompass the infrastructures running that code and the underlying economic relationships. After all, we don't want to become tenants of the software we wrote.

Yet there is a more crucial question:

One day when machines begin working in our place, will we be able to own those machines? Or will we pay rent just to use what they produce?

I suspect this will be one of the most critical debates of the coming era.

Stay well.

Note: My evaluations regarding the technical maturity of OccupySaaS projects are based on the project documentation in their GitHub repositories as of November 2, 2026, when I discovered this organization. The sections concerning Artificial General Intelligence are not definitive expectations of the future, but rather my projections and commentary on possible economic scenarios.

References and Further Reading

• OccupySaaS - They laid us off. We're rebuilding their SaaS.
• Occupy Saas

Those who know my article where I previously killed off Java will know.

Drive Another Nail into the Coffin of the Fallen

This article won't be along the lines of "oh it died, oh no it didn't." We will discuss why C is always at the top of the language leaderboard despite Rust developers.

The Illusion Seen from the Outside

There is a common misconception that beginners in software or those who stay only on the side of the industry dealing with popular web frameworks frequently fall into: they think C is a museum piece from the 1970s that has outlived its expiration date, taught only in universities to torture students. You can even hear people during every coffee break or forum corner going a step further, saying, "Are you still writing C? Does C even have a place when Rust exists?" Well, I have a lot to say to those friends. Anyway…

While in your dreams you're busy with "rustification" of everything, in the real world the situation is completely different. From the OS kernel of the smartphone you pick up when you wake up in the morning (whether it's Android's Linux kernel or iOS's XNU/Darwin), to the Windows NT kernel running when you turn on your PC (I say this because Windows' use of C++ is pretty much an esoteric way of using C), everything breathes with C. Git, where you push your code; the Linux kernel running embedded in every smart device from the Ingenuity helicopter that made 72 flights on Mars to your oven; SQLite, the world's most widely deployed database, embedded inside every Android phone and every iPhone; Redis, racing against microseconds; PostgreSQL, forming the backbone of major banks… Never mind all of those; even the primary interpreter of Python (CPython), which data scientists and AI folks cannot praise enough, was written from top to bottom in C.

In other words, from the moment you press a key on your keyboard to a pixel lighting up on your monitor, from downloading a packet from the internet to rendering a web page on screen, in every millisecond that passes, you are actually walking on top of C without even realizing it.

So how is it that a language written half a century ago by two men in the corner of a laboratory using typewriter-like terminals cannot be dethroned despite so many technological revolutions and dozens of modern languages?

Portable Assembly: Touching Hardware Without Gloves

The first answer to this question is hidden in C's philosophy—or rather, its lack of philosophy.

At the end of the 1960s, Dennis Ritchie and Ken Thompson hit two different brick walls at Bell Labs. The first was Multics: that massive time-sharing operating system project jointly run by MIT, GE, and Bell Labs, where multiple users could share a computer simultaneously, had become so bloated that Bell Labs pulled out of the project in 1969. Thompson and Ritchie missed that comfortable multi-user environment Multics offered, but they had nothing on hand except a PDP-7 forgotten in a corner. Unix emerged precisely from here, from the question: "Can we fit the good ideas of Multics into a tiny machine?" While trying to write the operating system, they encountered another massive wall. In that era, operating systems were mostly written directly in Assembly (Multics being written in PL/I was a brave exception). But Assembly is tied to the processor; if you wrote the code for a PDP-7, the day you replaced the machine with a PDP-11, you had to scrap the entire operating system and rewrite it from scratch. That is exactly what happened to them: when a PDP-11 replaced the PDP-7, the parts of Unix built up to that point had to be rewritten once again in Assembly. Hardware was evolving rapidly, and writing code from scratch for every new processor was a nightmare.

Ritchie and Thompson's genius came into play right at this point. They needed a language close enough to the machine not to lose hardware speed and power, yet simultaneously "portable" enough to run the exact same code when the processor changed simply by swapping its compiler. The B language Thompson derived from BCPL was too primitive for this job: it was typeless and didn't fit the PDP-11's byte addressing. Ritchie added types to B, bringing forth C in 1972; by early 1973, structures (structs) arrived as well, the core of the language was complete, and that summer the Unix kernel was rewritten in C. C was born out of this exact need—that is, in a sense, with the philosophy of "portable Assembly."

The primary reason C remains indispensable even today is that it draws no veil between you and the hardware. When you declare a pointer in C, that pointer is not an abstract object identity or a magic reference; it is a raw address. (In a modern operating system, this is not a physical RAM slot but a number in virtual address space; yet from C's perspective, it makes no difference: it is a number you can do arithmetic on.) When you write a struct in C, that data structure is not scattered around at the compiler's whim; fields settle into memory in the exact order you wrote them, within the boundaries of hardware alignment rules. The only freedom the compiler has is the alignment gaps (padding) it leaves in between, and you can see that with sizeof.

C introduces zero "magic" in between. There is no hidden memory manager, no code snippet running behind your back without your knowledge, no virtual machine. When you look at C code, you can roughly estimate which machine instructions it will translate to on the processor. This transparency is an invaluable superpower for systems programmers who must control every single grain of hardware, from microcontrollers to supercomputers.

The Latin of the Software World: C ABI

Yet C's invisible power to the programmer and the second great structure that makes it immortal is the C ABI (Application Binary Interface).

Although having an abbreviation similar to API, an ABI operates at a relatively lower level of abstraction. Interface compatibility here depends on target hardware and software compilation toolchains. In contrast, an Application Programming Interface (API) defines access at the source code level—a relatively high-level format that is almost completely independent of hardware and readable by humans. While an API defines an interface at source code level before compilation, an ABI defines a machine interface for compiled code. To elaborate slightly on what a machine interface entails, an ABI turns the entire process into an interface: processor instruction set, register file structure, memory access types; primitive data types the processor can directly access, their sizes, memory layouts, how function arguments are handled, how calls and returns are handled, and so on. In other words, when a processor architecture is developed, instead of rewriting all code from scratch, you only define this interface and then recompile all your code from scratch. As a result, your code is ensured to run identically.

Anyway, we dove pretty deep. But it's worth every bit of depth: today the software world is like a massive Tower of Babel. On one side Python, on another Rust, on yet another Go, Swift, C#, and Kotlin… Each of these languages has its own world, its own way of holding objects in memory, and its own runtime logic. For example, Python cannot directly understand Rust's rich enum structures or borrow checker rules. Swift cannot decipher Go's dynamic goroutine stack.

So then, in an artificial intelligence model you write in Python, how do the massive matrix libraries (PyTorch, TensorFlow) written in C++ and CUDA run under the hood? Or how can you call a super-fast algorithm you wrote in Rust from inside Node.js?

The answer, once again, is the C ABI.

When different languages want to talk to each other, cross the border checkpoint, and exchange data, they cannot speak their native tongues. When they arrive at the border crossing, they pull out their passports and are forced to speak the common tongue: C's binary interface standard. When Rust wants to expose a function to the outside world, it says extern "C". Though the Rust community is a bit sensitive, saying, "Bro, we have our own ABI, we don't need C," the reality is that for that function to be invoked, they have to comply with C's rules. That is, so to speak, they "rustify" C's ABI as well, and only after doing that can they speak by setting their own rules.

Python, on the other hand, is at a completely different point: most heavy libraries you import (NumPy, PyTorch…) eventually link to C or C++ code; they do this either via CPython's C extension API or through bridges like ctypes/cffi. The common denominator of all of them is once again C's calling conventions. What about operating systems? Even the system calls (syscalls) they provide are documented with a C interface.

C has become the Latin of the modern software world. Just as all scientists, physicians, and jurists across Europe communicated in Latin for centuries even after the Roman Empire collapsed; today, all programming languages must bow to C's rules in order to communicate with each other and with the operating system. Killing a language is easy, but changing the border protocol that all languages in the world mutually speak is virtually impossible.

So everyone can rest easy: C is immortal and remains one of the most vital building blocks of the software world.

The Terrifying Bill: A Dangerous Freedom

Everything looks magnificent up to this point, doesn't it? Total dominion over hardware, zero runtime overhead, universal compatibility…

But what did we say in the first article: there is no free lunch... The bill for this unlimited power offered by C is one of the heaviest bills in software history.

While granting you such total command over hardware, C provides you with no seatbelt—and indeed, not providing one is quite sensible given the time it was born or its intended purpose. It expects you to keep entirely in your own head when to free every region you acquire from memory. Forget a free() call, and the system silently leaks memory until the server crashes days later. Accidentally access memory you already released (use-after-free), or attempt to write to the sixth element of a five-element array (buffer overflow), and the compiler will not warn you.

The C compiler assumes you know what you're doing, and writes that byte right there. At runtime, if that location doesn't belong to something else, everything appears to be running smoothly; but if it belongs to something else, woe betide you. The C standard calls this "undefined behavior" and uses the phrase literally: The standard promises no predictable behavioral outcome for that moment. The program might run correctly, crash, silently produce wrong results; the compiler might even optimize away and completely erase that code path under the assumption that "such a thing cannot happen," or worse, if there is a data read or write, it might access data in a completely unrelated memory region and utterly corrupt execution flow. If the developer doesn't map out the scenario flawlessly in their mind and know what to free where and what to write where, they awaken this monster. And undefined behaviors are among the most terrifying monsters in the software world.

The result? Crashing flight control systems, and worst of all, security vulnerabilities that enable remote code execution.

Look at the security reports published by Microsoft and Google today; roughly 70% of vulnerabilities patched by Microsoft since 2006 and severe security bugs in Chromium stem directly from memory safety errors in C and C++. Things have reached such a point that the White House, NSA, and cybersecurity agencies are openly publishing reports urging the abandonment of languages lacking memory safety (especially C) in critical infrastructure.

C hands you a scalpel to dissect the hardware. With that scalpel you can perform the world's most delicate brain surgery; or in a careless moment, you can sever your own carotid artery. C has zero interest in the difference.

Along with memory safety, there is also the issue of data layout. Above, we noted that "a struct settles into memory in the exact order you wrote it"; the flip side of this transparency is that the layout is entirely your responsibility. If you order fields poorly, your struct bloats due to padding; if you want a cache-friendly layout, you have to build that yourself too; C offers you zero guidance on what to do with which data structure.

And it shouldn't offer guidance—look, I say it again, this is a deliberate design. However, as a consequence of this design, to code correctly in C—in a sense, to have peace of mind—you must be an engineer specialized in memory management and data structure design. Otherwise, performance plummets, bugs multiply, and security vulnerabilities emerge.

In fact, these security vulnerabilities aren't the only problem; there is an underlying memory and management crisis. And behind that lies an even greater bottleneck: as software expanded, codebases turned into massive spaghetti where boundless global state and heaps of functions tangled into one another. The human mind could no longer track thousands of lines of procedural code and what data was changing where in memory.

It was out of this very helplessness that the famous idea sprouted at the end of the 1960s with Simula, whose philosophy Alan Kay subsequently grounded with Smalltalk, inspired by biological cells: "Instead of viewing software as disjointed functions and raw data blocks, what if we design it as independent 'objects' that encapsulate their own state, protect themselves from the outside world, and communicate with one another?" The idea of encapsulating data and the functions that manipulate that data into the same capsule was seen as the sole savior from the growing software crisis. Now everyone believed they could model the real world one-to-one in code.

What's Next?

Right at this juncture, in 1979, a Danish computer scientist who had newly joined Bell Labs, Bjarne Stroustrup, posed this question:

"What if we retain C's proximity to hardware, its speed, and its zero-cost abstraction capability, but add classes, objects, type checking, and modern organizational tools on top of it, just like in the Simula language?"

Setting out with the aim of bringing order to those perilous streets of C and enabling large teams to develop massive software, this idea over time gave birth to one of the most capable, yet simultaneously most complex and gigantic monsters in software history: C++.

In the next article, we will dive into that great adventure that started as "C with Classes" and evolved into thousands of pages of standards:

C++…

Until we meet in the next post, stay well…

REFERENCES

A History of C++: 1979–1991 — Bjarne Stroustrup (PDF)

• TIOBE Index - TIOBE
• Memory safety
• NSA and CISA Release CSI Highlighting Importance of Memory Safe Languages in Software Secu

We all use a thousand and one kinds of languages across completely different domains. Today, just as C and C++ are the de facto standard in embedded development, Python and R dominate scientific computing, PHP (sadly, still PHP) and Python (courtesy of Django and Flask) rule the web, and Python once again reigns supreme in artificial intelligence.

And especially in chats with friends who recently graduated from university, the Rust language catches my ear quite often. Whoever you ask, it's always "bro, the best language for that job is X," or you hear claims like "actually you should rewrite everything from scratch in this language, after all AI is here now anyway." This obsession with rewriting and the future of copyleft is another topic of concern.

But thinking that the time has come to explain what programming really is in my own tongue, here I am today. So, let's begin.

Let's Start from Scratch

The emergence of writing began with the Sumerians keeping track of wheat. Around 3300 BC, in the Mesopotamian city of Uruk, people developed a symbol-based system on clay tablets to record grain quantities, livestock counts, deliveries of goods, and food distributed to laborers.

Agreements were sealed using this system, love poems were composed, but the initial starting point was to record mental tallies somewhere permanent. Just imagine: in a small-scale city of 5,000 people, the wheat distributed to them each year by the king must be calculated accurately, and who got what and who didn't needs to be tracked properly. Saying "let's round up 10 sharp guys and have them memorize it all" makes no sense. You kept these accounts, fine, but what if you ask "how are we going to do the calculations?" To facilitate calculations, numerical tables and the earliest mechanical tools like the abacus emerged.

Then, things expressed in writing began to be poured into calculation tables. Measuring field boundaries wiped out by the overflowing Nile in Egypt, celestial observations in China, navigation calculations made to avoid getting lost on the open seas in Europe... Until the 1800s, paper-based writing tools replaced tablets, and calculation systems continuously evolved, with specialized tools invented to perform newer and newer computations.

Anyway, I started all the way back from Noah's ark, but let's keep going. In the 1800s, Charles Babbage designed a machine (the Analytical Engine) to perform these manual calculations with mechanical gears; the machine was to be programmed using punched cards borrowed from the Jacquard loom. Ada Lovelace, in the notes she wrote for this machine, realized a truth that many of us still struggle to grasp today: These machines didn't just have to crunch numbers; they could process anything that had logical rules, even music. The machine envisioned by the female mathematician who founded the very idea of computing was never completed, but the punched card idea survived; returning to the stage at the end of the 19th century with Hollerith's census machines, the punched card system remained the standard way of explaining tasks to a machine until the middle of the 20th century.

The 1940s, as you know, spearheaded the great leaps that evolved the calculator into the "computer." Though World War II spearheaded many things, including our journey to the Moon. By the way, let me do a quick product placement right here:

The Legacy of World War II: From V-2s to the Journey to the Moon; Herbert von Braun

This evolutionary effect of wars is not very surprising to me. Well, after all, we aren't all that far removed from the apes who invented sticks to kill each other in the savannas 100,000 years ago.

Anyway; electronic computers were invented primarily to calculate the trajectories of artillery shells (ENIAC), plot courses, and break ciphers. A small correction: what cracked Enigma was the electromechanical Bombes designed by Turing and Welchman; Bletchley Park's electronic computer Colossus, on the other hand, was built to crack the German Lorenz cipher. Both are part of this story.

Yet these first electronic computers had an unthinkable headache: They were programmable, but to change the program you had to stand in front of the machine, pull cables, flip switches one by one, and practically rebuild the hardware with solder. Punched cards carried the data, but the program itself lived in the cables and switches. Remember, the foundation of a computer is calculation, but in this form, explaining that calculation to the machine was sheer torture. Then John von Neumann and the engineers of the era proposed a revolutionary idea: The machine had to store both the data it would process and the instructions telling it what to do in the very same memory. This step (the stored-program concept) became the true birth certificate of software and, consequently, of programming languages. We no longer had to alter the machine's physical circuitry; we could tell it what to do using a language.

Over time, these languages ceased to be mere sequences of simple instructions for adding and subtracting. Thus, when you choose a language, you are not merely choosing how to add two numbers; you are choosing how to arrange data in memory, when a mistake you made will come crashing down on your head like a sledgehammer, and how hundreds of engineers will work on the same codebase without strangling each other.

With these revolutionary developments, programming languages transformed into a vast kitchen. Slicing and dicing ingredients is pure computation; placing recipes on separate pages and dividing up the tasks is modularity; wielding the knife safely without cutting your hand is memory safety; and stirring the soup on the stove without burning the bread in the oven at the same time is concurrency. All of them are problems of the same kitchen—that is, crammed into bits on a pile of silicon with constrained resources, waiting for solutions. And programming languages are an interface through which humans can give commands to machines, setting out with the ambition to solve at least one of these challenges in the best possible way.

How Do Programming Languages Work?

Setting the philosophy aside and descending to the machine level, we see that every programming language is actually made up of layers constantly bargaining with one another.

At the very bottom sit hardware and physical resources: Registers, caches, RAM, and disk sectors. Right above this lies the barest form of the language: the computation core (Core). What we call the Core is the irreducible minimum mathematics that you cannot strip away from a language: what is a value, what does binding a name to a variable mean, how is a function invoked, and how does execution branch depending on conditions?

Surrounding this core are tools, libraries, and the type system. This is the surface upon which the developer writes code. On the outermost layer lies the Runtime, which takes the stage while the program is running—the invisible army talking to the operating system, dispatching tasks, or sweeping memory.

The reason languages look nothing alike, and why each designer sets out with an entirely different philosophy, is precisely where they draw the boundary lines between these layers. Because no programming language was born in ivory towers out of "hey, we're bored, let's do some math"; they all burst forth out of very concrete crises.

For instance, when C was written at Bell Labs on a PDP-11 to bring up the Unix operating system, Dennis Ritchie wasn't trying to flex theoretical abstractions. Though the emergence of Unix is a whole separate tale in itself, I'll save that for another article.

Ritchie wanted to touch memory addresses provided by the hardware directly, without intermediaries. That is why C pinned its core as close to the hardware as possible, placed zero runtime services behind it, and dumped the entire responsibility of managing memory squarely onto the programmer's shoulders.

Thus emerged a language fast enough to push hardware to its absolute limits, but as programs grew, the question of "how do we organize data, and who gets to touch what?" grew with them. One answer to this question was actually older than C: Object-Oriented Programming (OOP), known since Simula in the 1960s, offered the programmer a tidier workspace by keeping data and behavior together. Bringing this approach on top of the C core, Bjarne Stroustrup managed to offer programmers a cleaner organization with C++ while continuing to push hardware limits.

Yet years later, in the hallways of Google, Rob Pike and his team were suffering a different agony: sipping coffee while waiting for massive C++ projects to compile, and after waiting all that time, tearing their hair out over compilation errors. Indeed, every agony gives birth to its own cure, and Pike and his team answered this problem with Go—which has its own aches and pains as well. I've turned into an evolutionary tree here, but let that be the subject of another post.

When designing Go, their goal wasn't fancy type hierarchies; they needed code written by thousands of engineers to compile in a second, distribute network packets without breaking a sweat, and ensure nobody wasted time on memory cleanup. Go ripped complexity right out of the compiler and syntax, but handed the bill over to a runtime service constantly running in the background.

Let's see this with a concrete example. Consider a temperature reader running on a small IoT device:

measure → check → record

The step in the middle of this flow—comparing the temperature value against a threshold (temperature > 40)—is pure mathematics. It was the same on the Sumerian barley tally, it was the same in 1970, and it is the same today. No language alters this math.

However, the first step talks to the sensor (the physical world); the last step writes to disk or a network socket (an operating system resource). That's where things get tricky: When the sensor cable snaps, how will this error be represented? What happens if memory runs out while writing to disk? If data arrives simultaneously from a hundred separate sensors, will threads stomp all over each other's memory? Compared to clay tablets, these are pretty tough questions, aren't they?

The answers to these questions depend on which layer carries these side effects. The true character of a language emerges not in how many keywords it possesses, but in which layer it dumps these side effects, memory allocation, and error management onto.

Who Pays the Price? Where Does Complexity Move?

Everyone repeats the phrase "there's no free lunch" in engineering (another version being "the more bread you pay for, the more meatballs you get"), but few people speak openly about where that bill actually gets charged in software. The phrase I often bring up, "Complexity doesn't vanish, it relocates," describes precisely this. I say it every day at work, and it will inevitably bleed into these writings too. But what I mean here is strictly a budgeting issue. When designing or choosing a programming language, you actually sit at a four-sided negotiating table: The Developer's Mind, the Compiler, the Runtime, and the Hardware.

When you take the burden off one party, that burden doesn't evaporate; it lands right in the lap of one of the other three actors at the table.

Let's take a closer look at the parties to this bargaining and the concrete prices paid:

The first option is charging the bill to the Developer's Mind. C is the pinnacle of this approach. The C compiler is extraordinarily simple; it turns code into machine language within seconds. Behind it, neither a Garbage Collector runs nor does a complex virtual machine exist; you exploit the hardware down to the very last drop. After all, that was Dennis Ritchie's objective: "I will give you speed, you will push the hardware's limits, but I'll bill you for it." Though back then, there was no choice but to trust the developer's mind. The cost is your attention. You have to track the lifespan of every byte you claim from memory inside your head. Forget a free() call and memory leaks; add an extra free() and the program blows up; exceed an array bound by a single byte and you open the door wide to attackers. C gives you speed, but collects the bill in the form of sleeplessness for the engineer tearing their hair out chasing undefined behavior and searching for memory leaks inside software that spontaneously exploded at three in the morning.

The second option emerged over time. As programs grew and developer headcounts soared, charging the bill to the developer's mind became prohibitively expensive. So engineers looked for ways to lift the bill off the developer and offload it to a layer. If we are already having the computer compute this program, why not charge the bill to the Runtime—that is, an invisible army that kicks into gear the moment the program runs? Python, Java, or Go took this route. When compiling, they don't drown you in excessive rules; you don't worry about "when am I supposed to clean up memory?" Because a whole runtime engine is humming in the background. But this comes with a price tag too. In Java and Go, while you sit back and relax, a garbage collector scans memory in the background, tracks which objects are still reachable, and cleans up the unreachable ones. (Python's route is slightly different: it counts references, whereas Java and Go trace reachability. We will discuss why this distinction matters in the Java article.) Is this cleanup free? Never. It eats up processor cycles, consumes extra RAM, and worst of all, triggers millisecond-long pauses right at the most critical moments (Stop-the-World). Your average response time on a web server might be 5 milliseconds, but when that garbage collector kicks in, a request caught in between might wait 200 milliseconds. In other words, hardware resources and unpredictable latencies foot the bill for the developer's comfort.

Right in the middle of this dilemma, Mozilla engineers wondered how they could reduce Firefox's security vulnerabilities while preserving its performance; they even attended C++ conferences, studied the design of many languages, and ultimately decided to develop Rust. Instead of taking the bill from the developer and dumping it onto the runtime, Rust chose a third path: charging the bill to the Compiler. This is the very essence of the storm Rust kicked up in the modern world. Rust says: "I don't want to charge the bill to the runtime; I won't use a garbage collector; I will be fast and predictable like C. But I also cannot leave the bill to the developer's carelessness; I have zero tolerance for security vulnerabilities." In doing so, on paper they dumped all the work on the compiler—and nobody said, "Folks, to place this burden on the compiler, you're packing so many convoluted rules into the language that we have no energy left to remember keywords, let alone understand what the compiler is checking and how." Well, when they did this, they also increased compiler complexity, stretched compilation times, and condemned the developer to wrestle with dozens of error messages during compilation. Rob Pike is crying in a corner.

In Rust, this burden was specifically offloaded onto the mechanism we call the borrow checker. The compiler attempts to mathematically prove at compile time who owns every variable in your code, how long it will live, and who references whom. What happens as a result? A project that compiles in 2 seconds in C won't compile for minutes because of Rust's type resolution, generic expansions (monomorphization), and lifetime analyses. Your CPU fans begin to scream, you sip your coffee at your desk waiting for the compiler to finish, and you wrestle with dozens of compile errors until your code satisfies the compiler. Rust delivers safety, but loads the cost onto the compiler's back and the developer's compile-time patience.

As you can see from the examples, there is no flawless hero here. One language lengthens compilation time to ease the runtime; another heaps burden on the runtime to ease writing; yet another leaves everything to the human to push the machine's limits. This is why the question "Which language is the best?" has been unable to go beyond meaningless banter in this industry for 50 years. Because the question is not "which language is better?"; it is "from which layer am I willing to pay the bill in this project?" In fact, back in the day you couldn't even ask that: you had 20 guys on hand, 10 knew C, 8 knew C++, 2 knew Java; by sheer necessity you'd say "we'll develop in C++, both the Java folks and the C folks will understand it." And then we end up dealing with that code, but anyway.

Does This Article End Here?

I actually started framing this as a single article, but I think it looks like it's going to turn into a series. In that case, diving into the details of programming languages makes sense.

At the end of the post, we got into this conversation about the complexity bill. Well then, if a portion of this bill circles back and rests upon hardware and humans, why can't that famous veteran—who has been roaming around for half a century and still sits at the top of security reports every year despite all these modern solutions—be dethroned?

Why is C still not dying, and why does it continue to single-handedly shoulder our entire digital infrastructure, from the most modern operating systems we write today to the fastest databases?

We will descend into the uncanny streets of C and talk about the true inside story of that perilous bargain struck with hardware.

Until we read each other in the upcoming articles, stay well…

REFERENCES

• Go at Google: Language Design in the Service of Software Engineering - The Go Programming Language
• Chistory
• ENIAC
• John von Neumann - Wikipedia
• The Engines

Those that have come true and fail, financial bubbles, promises, public perceptions and completely imaginary technologies… The history of technology is full of many disgraces as well as many successes. So why don’t we take a look at these.

Technology Bubbles

Bubbles in the history of technology are periods of hype (excitement) that occur as a result of the exaggeration of a product or technology with much greater expectations than its true potential. Many examples have been seen in the last century, and we have even witnessed some of them directly.

In this article, I will examine these examples in three main categories. Because I need to beat some bubbles less because there are those who turn into goodwill disasters, while there are those who are in the wrong place at the wrong time; It is necessary to keep the charlatans apart from them. However, I can’t be sure if the expectations were really high in most of them, or if it was chimpanzees with insane speculation. Still, I can roughly sort it like this:

1. Attempts that became real with great expectations but failed,
2. Technologies that do not fully materialize or that are exaggerated and turn into disappointment,
3. Financial technology bubbles (speculative market crazes).

Many of the examples are unique with their emergence period, promises, media and investor reactions. I will also mention why these unique bubbles are bubbles and how they collapse. And I’ll address the short-term or lasting effects of some of them.

1. Those Who Have Come True And Fail Despite Great Expectations

In this category, there are technology products and initiatives that were launched and created great excitement in a certain period, but failed to fulfill their promises and resulted in a fiasco. Often these projects, although they have actually been released, are referred to as “bubbles” either because of the technical failure or because the market rejects them.

Google Glass — Wearable Technology Hype and Disappointment

I wanted to put the biggest one and this project, which I have followed since childhood, to the top, Google Glass and the school of wearable technology it promises.

Google Glass was first announced in 2012 as Google’s augmented reality smart glasses project, and in 2013, the “Explorer Edition” version was distributed to a limited number of developers and enthusiasts for $1,500. The glasses aimed to provide the experience we are used to from smartphones hands-free by projecting real-time information, notifications and media content into the user’s field of view with a fundamentally integrated screen and camera. By the way, the period when it was announced was the first golden age of smartphones.

Today, while accessing the voice assistant with “OK Google”, it had the features of a voice assistant whose foundation was then called “OK Glass”, step-by-step directions and environmental interaction; It had features such as being able to show and respond to e-mail, message, agenda alerts instantly.

In fact, it promised to change the smartphone experience by providing digital information at your eye level. Through a small prism screen, it can project texts, notifications, maps to the user’s point of view; this device, which could take photos and record videos with voice commands and connect to the Internet, was seen as a step to start the era of “wearable computers”. According to Google’s vision, Glass users would take navigation directions from their glasses, instantly share photos/videos, read and reply to messages while walking — and hands-free. This was a breakthrough that we could consider a science fictional even for that time, and it was rightly touted as the technology of the future.

Initially, the media showed great interest in Glass, of course, because the company started the smartphone era thanks to Android. In 2012, when Sergey Brin posed for the press with prototype glasses, the headlines were “Bringing the future with Google glasses”. In 2013, early users (Explorers) shared their experiences, the technology press enthusiastically conveyed it. However, soon a reaction began to occur in the society and the media. The biggest concern was that Glass had a permanently open camera on it. Many people feared that those who wore these glasses might shoot unannounced videos; some bars and restaurants expressed their privacy concerns, hanging “Google Glass is prohibited” announcements. In fact, it was even called “Glasshole” in English because it was thought that those who wear Glass had an uncomfortable look around and did not respect privacy. Although investors were initially excited, support within Google also declined as the product’s broad adoption signs were weak. Although this device was also available in some countries, including the UK in 2014, the expected consumer launch was never fully in the line; in January 2015, Google announced that the production of Glass in its current form had been discontinued. Although the project continued with a focus on corporate use in the following years, Google Glass has completed its life as a public product. After all, due to public reaction and usage difficulties, Glass was lifted off the shelf before it could realize the expected consumer revolution.

I can say that there are several critical factors that cause Google Glass’s failure, these are price, privacy, and experience of use.

First, a very high price of $1,500 prevented it from reaching large audiences; most people did not want to pay this amount and install a device that drew social reaction.

Second, the potential for camera and facial recognition created serious privacy issues — people were getting nervous if someone was wearing Glass next to them.

Thirdly, the practical utility of the device was limited: short battery life, limited applications, and factors such as the person wearing it looking quirky did not make Glass attractive in everyday life.

As a matter of fact, Google admitted that Glass remains a “strange and expensive” toy from a social point of view. In the official statements, it was said that although the project was stopped, technology was not abandoned, at this point it can even be said that it caused an era that is heading towards VR glasses.

The disappointment created by Glass reminded the technology sector of the importance of user feedback and social norms. In the short term, Google repositioned the project to compensate for the loss of reputation, and other companies developing similar products (e.g. Microsoft HoloLens) has taken more careful steps. Thanks to Glass’s experience, it has become more focused on privacy and design in augmented reality glasses.

In the long run, the dream of consumer-facing smart glasses hasn’t completely died — VR, AR, XR products like Oculus, Snap Spectacles, or Apple Glass were shaped by lessons learned from Google Glass.

The Glass fiasco, in my opinion, along with other bubbles such as 3D TV, took the top corner in our literature as an example of how technological innovations can rigup when human factors are not observed before they are introduced to the market.

Segway — Personal Transport Revolution

The Segway, the two-wheeled personal transport vehicle “Segway PT”, was first introduced to the public in December 2001 after a campaign of great curiosity. Its inventor, Dean Kamen, showed this self-balancing electric scooter to the whole world on the Good Morning America program. Segway, which went on sale in 2002 at a price of about $ 5,000, managed to stay in the market throughout the 2000s, albeit limited. However, the expected revolution never materialized, and Segway production was completely discontinued in July 2020.

There were incredible rumors about Segway before it was released. It was claimed that this device, code named “Ginger”, would radically change urban transportation, and that people would now roam with Segway instead of walking or driving. In fact, the famous entrepreneur John Doerr predicted that Segway would be “the product that exceeded the fastest $1 billion sales threshold in history” and create an impact “even bigger than the Internet”, what a prediction. The expectation was so high that Kamen calculated that 10 thousand Segways would be sold per week at the end of 2002, which was half a million devices a year. Moreover, Segway, according to his promises, would be a technological revolution that would even change the structure of cities. It can even be said that it was the biggest revolution after public transportation.

In the pre-promotion period, the media and the public were shaken with clues about Segway. In 2001, Time magazine called the device “Miracle Vehicle”, and even technology leaders such as Steve Jobs and Jeff Bezos commented on the prototype foreseeing it. While Bezos found the product “great but practically difficult”, Jobs said that the infrastructure of the USA was not suitable for this tool. At the first demonstration, the device was technically impressive, self-balancing, guided by body movement. It was found to be so impressive that many early adopters (Apple founder Steve Wozniak was also on this list) bought it. Despite this, there was a distance from the Segway in the general public. Although the headlines of “that miracle invention that will make you forget to walk” were made in the press, investors were disappointed in the sales figures due to the high price and legal uncertainties.

The main reason Segway failed was the ignoring of social and practical facts. The technology was working but human behavior and infrastructure were not taken into account, especially the lack of legal regulations (which we are talking about the same for scooters today — the problem of whether the device will be used on the sidewalk or on the road) caused prejudices and reservations about the use of the device. The device was fast and heavy for pedestrian sidewalks and slow for roads; in many cities, users did not know where to go on the street because its legal status was not directly clear. Also, despite the price tag of about 5 thousand dollars, the benefit it offered was not far superior to a bike or walking. Therefore, not even 1% of targeted sales were reached in the first 5 years — for example, at the end of 2002, while the targeted sales were 10,000 per week, Segway was able to sell only 30 thousand units in six years.

Financial problems also caused the company to change hands several times. In 2015, Wired magazine published an article declaring Segway “dead” because the device had become a technology joke, just as Java became a death joke in the programming world for a while.

Ultimately, in 2020, the new owner of Segway company completely stopped production, announcing that the sales of this vehicle accounted for only 1.5% of their total revenue and were no longer economical. The once “transport revolution” left the scene after 20 years, referred to as the niche tool of security guards and tourist tours.

I can say that the most basic conclusion that Segway’s failure has added to us was that it confirmed the saying that “every innovation does not mean revolution” in the technology world. In the short term, Segway found a niche of use, especially in the field of security and tourism (such as airport police patrols, city tourist trips). Its lasting effect was an indirect contribution to the development of the micro-mobility concept. Segway’s technology legacy laid the way for personal vehicles like electric scooters and hoverboards that we see today; people perhaps adopted more practical little scooters instead of a two-wheeled giant device. Even if there are still legal reservations and regulatory deficiencies about scooters, the understanding of the importance of user habits and the regulatory environment with Segway, bringing scooters above it, showing entrepreneurs that not just engineering marvel is not enough, but social cohesit is also a must.

Juicero — High-Tech Juicer Fiasco

This seems a strange fiasco to me. It is a good example of what can happen to you when you make ideas that sometimes look good by making an obsession while making an investment because what we have is about Juicero.

It was a product introduced to the market in 2016 and gained a reputation as one of the most sensational kitchen appliances in the history of Silicon Valley. Founded by an entrepreneur Doug Evans, the company has developed a device that is connected to the internet and produces cold-pressed juice with one button. Yes, you heard right, cold squeeze juice device… I try to think I’m an investor, but I can’t get into that role. I think this invention, which is so ridiculous and unnecessary, went on sale in 2016 at a price of $699, and it received a large investment of $120 million in total until the beginning of 2017. But it lasted as long as a fruit squeeze; the company lowered the shutter in September 2017, just 16 months after the launch.

What Juicero promised was that you could place special packages with chopped fruit-vegetable purees on their device and get freshly squeezed juice with one click. In other words, cutting fruit at home, without the trouble of cleaning, producing high-quality cold-pressed (retaining nutritional value) fruit juice in the convenience of a capsule coffee machine… The device also promised “smart” features such as checking the freshness date of packages with Wi-Fi connection, showing nutritional information in practice. In short, Juicero claimed that it would bring innovation to kitchens by combining technology and healthy lifestyle trends.

At first, investors and the press in Silicon Valley had a very positive approach to Juicero. Google Ventures and famous capitalists shored millions into the project. The company, which was praised in publications such as the New York Times, was touted as an example of a “revolution in food technology” in 2016 and early 2017.

However, this bubble was popped by Bloomberg News. In an experiment conducted by Bloomberg, journalists managed to obtain almost the same speed and amount of juice by manually squeezing Juicero packets without putting them in the device. This news and published videos went viral on the internet. Juicero became the subject of ridicule in the media, users made fun of the company by saying “This machine worth $400 is actually weaker than both hands”. While investors were shocked, Juicero’s founder Doug Evans compared himself to Steve Jobs and praising that the device had 4 tons of printing power, the criticism increased.

Juicero exploded because the promise of the product was meaninglessly exaggerated. There was actually a serious technology (the device really had a powerful press mechanism compared to the volume of units), but the problem it solved was too small to be non-e — because the same juice could also be obtained by hand after the package was squeezed. Despite the price tag of $699, the device did not offer the user more than they could do by hand. After Bloomberg’s disclosure video, the company’s image was damaged in a way that could not improve. Juicero first tried to reduce the price of the device to $400, then stopped production in August 2017 and announced that it had completely terminated its operations in September 2017. In this process, he tried to return his money to thousands of his customers, but the reputation was already destroyed. As a result, Juicero went down in history as one of Silicon Valley’s most ridiculed failures.

The collapse of Juicero has pushed investors and entrepreneurs to question the real consumer need in the short term, especially in hardware projects. This fiasco revealed the fact that “high technology does not always produce a solution that is needed”. On social media, Juicero has been referred to as a ridiculous example every time his name is mentioned, and it has become a symbol of how disconnected the Silicon Valley is able to pursue innovations from time to time. If we look at its permanent effects: investors began to approach similar “smart kitchen appliances” projects more cautiously after this incident. Juicero also showed that consumers will not invest money in a product without looking with a simple question — “What problem does this tool solve for me?” In short, I can say that the Juicero bubble has served as an expensive lesson for the technology sector.

2. Technologies that don’t realize or exaggerate and turn into disappointment

In this category, I am talking about technologies whose concrete product consists of lies, although it is treated as if it has not reached or has reached a large audience as a concrete product. Among them, there are technological dreams that have been in popular culture and media for many years with excessive expectations. Issues such as flying cars, personal jetpacks or holographic home theaters have often been exaggerated, thinking that they will be part of our lives in the future; but either did not materialize due to technical obstacles, or did not have the expected effect when tried. However, I will start with the company of our big-eyed sister with fraud and the damage she caused to public health.

Theranos — Allegation of Revolution in Blood Test

One of the biggest scientific technology scams, Theranos is a health technology initiative founded in 2003 by 19-year-old Stanford dissignant Elizabeth Holmes. Especially in 2013–2014, it became one of the brightest startups in Silicon Valley, reaching a market value of about 9 billion dollars.

The company claimed to have developed a compact device that could quickly and cheaply perform hundreds of blood tests with just a drop of blood taken from the fingertip. If this technology were real, it would revolutionize blood tests and provide great convenience in the health sector. Think about it, when you give a full detailed blood test at the entrance to the job, sometimes you give 4 and sometimes 6 tubes of blood, even that is only used to do important tests. Full blood screening, on the other hand, requires 10 tubes of blood, which I remember, since I had it last month.

Holmes had drawn a great vision, constantly emphasizing that this idea would “change the world” and save millions of lives. Because she was a polite scientist who grew up in an excellent family leaving Stanford… As a matter of fact, if these promises were true, it would be a revolution in health in poor countries. Imagine how valuable a machine that can perform dozens of tests with a machine with a drop of blood with a machine, while it is almost impossible to provide the appropriate laboratory to examine such a clean, stable environments to do a blood test in Africa.

The promises were so impressive that Theranos has raised more than $700 million in investment over the years, and famous names such as the former US Secretary of State are on the board of directors. The media headlined Holmes as the “new genius of Silicon Valley” and the youngest female billionaire in an instant; publications such as Fortune, Forbes, The New Yorker made her a cover. In short, Theranos has been polished as an almost universal figure of praise for nearly a decade since its inception, gaining great confidence in both public opinion and investors.

Unfortunately, Theranos’ story quickly ended with the appearance of a technology bubble, and Elizabeth Holmes was prosecuted. First of all, the device promised by the company never worked consistently. And despite this, Theranos performed dozens of blood tests, most of these tests were misleading data, although many tests were not the results, the health information of the people who had the test was created with this false misinformation by entering average data.

A 2015 report on an investigation in the Wall Street Journal revealed that Theranos allegedly secretly conducted the tests with traditional devices and that its technology was essentially a hoam. Although this news was initially tried to be prevented, it opened the door to new investigations, the investigations of journalists increased this investigation to the level of disclosure and created an earthquake effect in Silicon Valley.

In the following months, successive investigations began about the company from health authorities and investors. By 2016, Theranos’ pharmacy partner Walgreens ended the cooperation, Holmes’ personal wealth was “zero” on paper, and the company’s value was completely melted. After all, in 2018, Theranos closed completely; Elizabeth Holmes and company COO Sunny Balwani were charged with investment fraud and prosecuted. Holmes pleaded guilty to fraud in early 2022 and sentenced to nearly 11 years in prison. With the bursting of the bubble, his company, which was once worth billions, turned into a scandal in which its founders were imprisoned.

The Theranos scandal remained a major lesson in Silicon Valley and in the health technology sector. In the short term, investors and the media experienced a deep shake of confidence; other health initiatives of the period were also subjected to stricter scrutiny. In the long term, Theranos has become an example that reminds the importance of the “see first, believe first” approach in the technology world. It is also known that after this incident, biotechnology investments began to be more cautious, and regulators increased the audits of laboratory test companies. In addition, the collapse of Theranos was the subject of books and documentaries as a public example story.

In fact, while writing this article, that video of Evolution Tree is always in the edge of my mind. As a matter of fact, I leave it down too.

Flying Cars — The Future That Is Always 20 Years Away

The idea of a flying car is almost as old as the invention of the modern car. Since the early 20th century, inventors have designed vehicles to combine road and airline.

Especially in the 1950s, the first prototypes and concepts were talked about a lot. Interestingly, while we don’t even see flying cars today, Molt Taylor’s Aerocar even received official approval in the US in 1949, and magazines wrote that “by 2000, everyone will fly out of their garage.” Throughout the 1960s and 70s, attempts to fly cars periodically came to the fore. However, to this day) this idea has not been fully realized; only small-scale prototypes, rough-winged designs, drone-like things have been made, and only a very limited number of tests could be done on this subject.

Flying cars were marketed as a concept that would end the traffic problem and break new ground in transportation. In popular mechanical magazines in the mid-20th century, cars gliding in the sky in the city skyline of the future were depicted. According to the imagined scenario, people would take off from their homes with their flying vehicles, bird’s eye view of work, so that the congestion on the highways would be history. In short, the expectation of a future like a Jetgiller cartoon prevailed.

It was also suggested that flying cars could also revolutionize areas such as emergency rescue or fast cargo. Every decade, the news of “flying cars are coming soon”, the public was warming up to this idea again.

This concept has been so popular in popular culture that people are a joke of “Where are our flying cars?” He started to ask. When many TV programs and prototype flying cars were shown at the fair in the 1960s and 70s, the media greeted them with enthusiasm. For example, the concepts exhibited at the 1964 New York World’s Fair attracted great attention. However, the words that were postponed many times filed people’s expectations. In the 1990s, the idea of flying cars shifted to the category of “fantasy” when there was still no tangible product. Although investors were enthusiastic at times (for example, start-ups such as Terrafugia and AeroMobil recruited investment in 2010), large capital inflow was limited as a concrete consumer market did not form.

The flying car can actually be called a very smart idea that has sunk before it can be fully realized due to technical, regulatory and practical obstacles. However, it is obvious that a vehicle is both a land and an air vehicle that it will bring many difficulties. There are many issues such as extra pieces (wing, propeller, etc.) making the vehicle heavy and complicated; ordinary drivers’ lack of piloting skills, increasing safety risk in the air; requiring air traffic to be regulated, which cause flying cars still not to develop today. For example, first generation flying car attempts required runways for take-off/landing, which made the dream of “taking off from the garage” meaningless. Well, this is already a plane. Models that could take off vertically such as helicopters were very noisy, high fuel consumption and expensive. Well, this is a helicopter. In short, this technology will not allow us to achieve anything additional. Today, a hope has re-emerged with developments such as drone technology, artificial intelligence flight systems (Airbus’ Vahana project, 18-propel aerial taxis such as Volocopter are being tested. In Turkey, Baykar’s Cezeri flying car is still under development and testing.

However, a flying car utopia is still far from happening to every house. This technology has been inflated for years, but although it is not a bankrupting company due to this issue yet, it always remains an uncertain promise on the horizon.

The fact that flying cars are not real, of course, did not directly harm anyone in the short term; but it has repeatedly disappointed for entrepreneurs and enthusiastic customers who invested in this space. For example, the Moller Skycar startup lost confidence as it has collected investment for decades and repeatedly postponed the delivery date. Looking at its lasting effects, the idea of flying car has become part of the technology culture — even today, when an innovation is introduced, it is mocked as “that car is this car”. On the other hand, it should be noted that the dream of a flying car is not exactly dead; It is said that we will see autonomous flying taxi pilot projects in some cities because the recent electric vertical departure vehicles (eVTOL) are actually closer to the purpose of the flying car and the autopilot features of companies such as Tesla have advanced in 10 years. Still, this concept has not found a place in our daily lives for now and continues to be referred to as one of the great technological dreams of the 20th century.

Jetpacks — “Wearable Rocket” Dream

The idea of a ridge rocket or jetpack is a very pleasant idea, especially in the late 1950s and 1960s, which gained great popularity.

Jetpacks would give people the opportunity to fly freely like a bird with rockets attached to the back. In the dream scenario, a person could take off vertically with a small rocket engine to attach to his back and fly over short distances. In this way, military units would overcome the obstacles in the field, firefighters would reach the top of high-rise buildings by rockets, and a businessman experiencing a urban transportation jam would be able to take off from the roof and put into his office. In short, the individual flight freedom we saw in the Jetgiller and science-fiction movies would be real. In the 1960s, Popular Mechanics magazine wrote that jetpack was the “personal means of transportation of the future”. Anyway, if these magazines say what is like that, your future, it’s a shit. Even our technology design teacher in primary school often explained that he dreamed that when he grew up as a child, he would go to school with jetpack, but he was spent on the roads with Renault clio.

As I said, this vision was so tempting that even the US military considered it a serious mobility option. In 1961, Bell Aerosystems developed a prototype of a “Rocket Belt” for the U.S. military, and in April 1961, for the first time, a human managed to free fly for 21 seconds. This image created a great sensation at that time. After the first jetpack image, people were approached with suspicion, but viewers were fascinated by public jetpack shows. When televisions broadcast these images in the 1960s, people had a hard time believing they were real. The media made headlines “Dreams come true”, magazines like Life printed piloted rocket belt photos. Everyone thought they would own a jetpack in the near future. Then, this device was exhibited at the New York World’s Fair in 1964 and in the James Bond movie (Thunderball) in 1965. The word jetpack has become used to describe personal flight vehicles with rocket fuel or jet turbines. With a jetpack show at the opening of the 1984 Los Angeles Olympics, technology came to the fore again.

However, when years passed and these demonstrations could not go beyond a few minutes, public curiosity slowly faded. Yet the concept of jetpack has always existed in popular culture — the 1991 film The Rocketeer or various video games kept that interest alive. But by the 21st century, jetpacks still didn’t become a means of everyday transport — and today they’re still not used except for a few special shows and hobby startups.

However, companies such as New Zealand’s Martin Aircraft developed jetpack prototypes that could fly longer in the 2010s, demonstration flights were held in Dubai. Public opinion every time “did it happen this time?” Although it was asked, there is no jetpack that has been able to land in the masses yet.

So why not or why not? Jetpack is a typical example of technical realities laging behind dreams because our main problem is physics…

Flying the human body with the rocket with the Jetpack required a tremendous amount of energy, which either carrying very heavy fuel or just being able to fly for a few tens of seconds. As I said, the Bell Rocket Belt in the 1960s could only stay in the air for about 20 seconds. This was not enough for any practical use. Also, it was unrealistic for everyone to use a device that was difficult to control and could be lethal to fall. Although small jet turbine models were developed over time, these remained incredibly noisy and expensive. For example, one of the most advanced jetpacks available today, the device of Gravity Industries can fly for a few minutes with 5 mini jet engines, but it consumes fuel just as fast and requires pilot training. Therefore, the jetpack concept could not go beyond being an expensive show attraction. Military interest in the 1960s also did not yield results; the army found the project “very inefficient and risky” and shelved it. As a result, the jetpack has remained a very difficult dream in the history of technology to realize.

Hologram Home Theaters — 3D Television Fiasco and Endless Quest

One of those famous scenes that remain in our minds from GORA must be the hologram scene.

Have you ever been to a 3D cinema, I remember, it should be the first avatar, it was released in 3D cinema. With the emergence of someone who participated in this movie and said that it was in our house, the concept of “holographic home theater” entered our lives. In our imagine hall, there would be systems where three-dimensional images appeared freely, such as in Star Wars, which have been shown in science fiction movies for many years. However, concretely, 3D image technologies entered homes in the early 2010s. In 2010, almost all major TV manufacturers launched their 3D-enabled televisions. At the CES fair in 2010, 3D TVs were presented as the most exciting innovation. The promise in the 3D TV craze was to experience the 3D experience in the cinemas at home. 3D screens, which could be watched with special glasses, would make movies and sports competitions look deeper and more realistic. One step further, it was said that glasses-free 3D (holographic display) technologies would also come in the future. This opened the door to the dream of a live projection that “appeared in the middle of the room”. Assertive expressions such as “hologram concert pleasure at home” were used in the press releases. In short, a revolutionary home entertainment system expectation has been created to replace the traditional flat screen. TV manufacturers believed that they could make this technology a standard feature of high-end products and sell it to millions of consumers.

Everyone may have thought that we have entered an era where we would watch 3D movies at home. However, two main problems were faced. Ergonomics and content. People did not like to wear special glasses all the time while watching TV at home, some of them experienced headaches and eye strain while watching 3D images. Not only these, but it may be interesting in theory, but in practice, most people are fond of comfort while watching TV and do not want to deal with extra glasses. In addition, TV at home is an activity usually done with family or friends; as many people could watch 3D glasses, and even this logistics was a hassle. Technically, the first generation 3D TVs had disadvantages such as narrow viewing angle and low brightness.

There was also a problem with the content side: Only certain movies and a few channels offered 3D content, most broadcasts were 2D. This situation quickly reduced enthusiasm. As for 2012–2013, the media began to change tone: “Is 3D TV really necessary?” Their interrogations came out. When sales were far below expectations, retailers reduced stocking on 3D models. Finally, in 2015, major manufacturers started to remove the 3D feature in new models. 3D TV has become seen as an empty marketing trick in public opinion. Within five years, 3D TV “died” — the most exciting novelty in 2010, but in 2015, no one would think of it. The burst of this bubble was so obvious that in 2017, almost no major brand no longer supported 3D.

In fact, in addition to 3D televisions, it may be necessary to mention hologram technology. Literally, holographic projection technologies remained a challenging issue than 3D TV and have not been commercialized except for a few shows. So the “hologram phones” remained as in the Jetgiller episodes.

On the other hand, studies continue in areas such as virtual reality (VR) and augmented reality (AR); if these technologies one day offer a truly satisfying glass-free 3D/hologram experience, maybe the imaginary home theater can come true in another way. However, I still have no doubts about that. But what do you think about the subject of VR as if it was the subject of another article 😊

3. Financial Technology Bubbles (Speculative Crazes)

In this category, I will cover projects that emerge in specific technology areas or new financial instruments, inflated with intense speculation and crazy investment behaviors. These bubbles are often characterized by the exaggerated valuation of a new technology or business model in the financial markets.

Dot-Com Economy — Internet Investment Frenzy

It is useful to keep this speculation, or rather the period of madness, separate from the others, in fact, Dot-Com, which is a speculation that we see the effect on regulations in the long term and the very positive side of the start-up economy, is a speculation among the innovatives of the Y generation. Roughly, it is the period of hyper-speculative investment in internet companies based in the USA between 1995 and 2000.

With the spread of web browsers in the mid-1990s, the internet began to be seen as a revolutionary innovation in the business world. And from 1995 to March 2000, technology stocks (especially internet-focused “Dot-Com” companies) experienced astronomical value increases, such as NVIDIA shares flying through 2020. In this period, the NASDAQ stock exchange peaked on March 10, 2000, an increase of up to 800%, which we can call soap foam growth. However, the soap bubble exploded, after March 2000, the wheel reversed, and by the end of 2002, the NASDAQ index fell 78% from its peak, giving back all its gains. With the effect of the interest rate decisions due to the global recession, I can say that the biggest madness in the history of NASDAQ has resulted in a disaster.

The Dot-Com boom was based on a concept called the “New Economy”. It was thought that thanks to the internet, the old ways of doing business would change, and online companies would grow much faster and profit than traditional companies. With the “digital age”, it was predicted that companies that adapt to the internet early in every field (from retail to media, banking) will take over the market. Therefore, even having a company’s name “.com” or just setting up a website was enough to excite investors. The promise was that the internet was an area of unlimited economic growth. The old rules will be invalid, every startup that enlarges its user base will print money in the future. Numerous startups have been valued only through web traffic and “potential” when there is no sustainable business model or revenue yet. Investors rained money on the startup that owns every dot-com site for “fear of missing”. Thus, hundreds of internet startups (Pets.co, Webvan, Etoys, etc.) went public and gathered millions.

The media could not fit internet initiatives to the ground at the end of the 1990s. Mainstream magazines were profiling new young millionaires, televisions were making “.com rich” news. It was a complete madness for investors.

Everyone attacked technology stocks, the stock market has become a casino. Even those who made evaluations with “traditional” criteria were excluded; at that time, discourses such as “there is no need to make a profit, the important thing is the market share” were popular. For example, companies that went public in 1999 had mostly never announced a profit, but their shares were multiplied from the first day. Venture Capital companies were pouring millions of dollars into every internet idea with the fuss of “let’s not miss the new Amazon, the new eBay”. In this period, the number of individual investors entered into the stock market also exploded; Everyone from 7 to 70 was buying dot-com shares with the dream of becoming rich the easy way. In summary, an irrational enthusiasm prevailed. For some reason, it reminds me of something… ANYWAY…

The Dot-Com era in the markets exhibited a classic speculative bubble anatomy. The main problem was that the company values were completely disconnected from their real performance. By 2000, many dot-com companies were actually losing money, some had never even generated revenue, but their market values were billions of dollars. This unsustainable situation has entered a correction period as investors finally realized it. On March 10, 2000, NASDAQ peaked; soon after, news and macroeconomic concerns that some high-profile companies failed to meet their targets triggered the wave of sales. The bubble did not burst after that day — the stocks quickly lost value.

Within a few months, dozens of internet companies have raised the bankruptcy flag. Symbolic Dot-Coms, especially pets.co, webvan, boo.co, sank one after another towards the end of 2000. The collapse of the Dot-Com bubble in 2001 was literally obvious: Investors were left with huge losses, the technology sector laid off thousands of employees. Even giants like Cisco, Amazon, Microsoft lost 80% of their market value. Eventually, thousands of startups were completely deleted, and some of them (startups that grew up like Amazon and eBay and had an income model) managed to survive, although they were greatly injured.

This frenzy shook the US economy in a very short term. In 2001, the US entered a recession, and combined with the global recession, it had an aggravating effect on the process known as the 2002 crisis in America, which caused it to be avaged with accounting scandals in early 2002, and its index took years to recover (it could only return to its level in 2000 in 2015). A generation of individual investors got cold from the stock market. However, in the long run, the legacy left by this madness has not been completely negative, because there is no such thing as losing in the market 😊.

Infrastructured, the internet backbone laid in the 90s, the established data centers, laid the way for the next digital revolution. Surviving companies, for example Amazon, grew with more realistic strategies in the post-bubble period and achieved huge successes. So the bubble burst, but the internet era did not stop — only exaggerated expectations were rashed. Financially, the lasting impact has been that investors are more cautious when evaluating tech companies (at least for a while). The phrase “Dot-Com bubble” passed to the literature as a story of example of excessive market enthusiasm. In later technology mania (for example, in some startup valuations in the 2020s), comparisons were frequently made with the dot-com period. As a result, the dot-com bubble is an unforgettable period with both its destructive results and the aspects that enable us to create a cartel for the next period and pave the ground for the relationship between innovation and realism.

ICO Fury — 2017 Cryptocurrency Supply Bubble

The ICO (Initial Coin Offering) fury peaked especially in 2017. ICO was a method by which blockchain projects raise funds by pre-selling their own cryptocurrencies/tokens to the public. Following the popularization of cryptocurrencies such as Bitcoin and Ethereum, hundreds of projects began to raise money through ICOs from the beginning of 2017.

The promise behind the ICOs was “a new generation of venture capital for everyone”. In other words, anyone could invest in a blockchain project that could be the Google or Facebook of the future with a few clicks while still in the idea stage. Project owners, on the other hand, were able to earn huge funds by selling their own crypto tokens without the need for traditional venture capital. Many ICOs published a technical “whitepaper” and drew a brilliant vision, for example, claims such as “decentralized Uber” or “new internet on Blockchain.” Investors were told that these tokens would be valued when the project was successful.

In addition, ICOs were raising fast and unlimited funds by taking advantage of the regulatory gap. The Promise was like a win-win situation for both entrepreneurs and investors: A democratized investment ecosystem that has overcome traditional financial barriers.

Especially the second half of 2017 was literally a crazy period: Around 50 new ICOs are made monthly, hundreds of millions of dollars of investment were flowing into these projects every month. At the end of 2017, ICOs had attracted 40 times more capital than the previous year.

Throughout 2017, the media showed great interest in ICOs, along with the general increase in cryptocurrency prices. “It raised millions of dollars in that minute”-style headlines became almost weekly news — for example, the Brave browser’s ICO raised $35M in 30 seconds, the Tezos ICO raised $232M. These success stories attracted even more investors. Individual investors from around the world were after catching the next “coin” rich by investing their Ethereum or Bitcoins in new tokens. On investor forums, a massive cycle of hype occurred on social media: A wave of speculative excitement was rising around each new ICO project. On the other hand, some skeptical media outlets and experts began to issue early warnings; reports such as “Half of the ICOs are disappearing in a few months” have emerged. In September 2017, China and South Korea tried to curb ICOs by banning them. In the US, the SEC announced that it will investigate some ICOs. But even these warnings could not fully extinguish the enthusiasm in the first place; Investments continued to flow until the beginning of 2018.

The ICO frenzy was literally a financial bubble because the market was dominated by unrealistic valuations and countless scams. Almost half of the ICOs in 2017 failed and disappeared within a year. Many projects have not improved due to the inexperience of their teams or the impossible promise of the projects; some of them disappeared with money by doing outright “exit scam”.

As the general crypto market declined in early 2018, the ICO bubble began to decline after January 2018. When the value of the existing tokens melted, no new recipients were found. By February 2018, the ICO market had collapsed — token prices were falling 80–90% on the stock exchanges where they were listed, investors were staying with worthless tokens in their hands. Regulators such as the SEC have also sued or imposed penalties on dozens of ICO projects throughout 2018, which accelerated the bursting of the bubble. As a result, hundreds of millions of dollars of investment became steam, thousands of investors wrote serious losses. By mid-2018, the concept of ICO had become largely discredited.

The boom of the ICO bubble launched a bear market in the crypto ecosystem; in 2018–2019, crypto prices remained in an overall downward trend, and many projects were shelved. Investors have learned by taking their lessons to “not jump into every glowing crypto project”. One of its lasting effects is that regulators have scrutinized this area — the US SEC has come to consider ICOs as securities and illegal issuances, clear rules have been introduced or banned for ICOs around the world.

On the other hand, blockchain attempts did not completely end in the post-bubble period; on the contrary, more serious teams and real product-oriented projects emerged. The part we can call the second act of the ICO period (DeFi after 2020 — decentralized finance practices) emerged with the pandemic. In other words, the area cleaned by the bubble opened room for new projects, and there were quite speculative ones. Especially when combined with the dream of metaverse, a new one started before the ICO speculation was over. And just at that time, there was also an NFT madness, and now I will tell you about it. After all, the 2017 ICO cree went down in history as one of the biggest crazes in the history of financial technology, such as “Dot-Com”.

NFT Madness — Digital Collections Bubble

The NFT (Non-Fungible Token) craze is also immediately after the ICO cree, but most notably in 2021, the NFT craze towards the end of the pandemic is one of the projects rising with the metaverse craze.

NFTs were used in various areas, from digital artwork to in-game items, as tokens representing unique digital assets on blockchain. Although the concept of NFT came to the fore in 2017 with Cryptopunks and CryptoKitties, the real explosion took place in the first months of 2021. In March 2021, an NFT work by digital artist Beeple sold for $69 million at the Christie’s auction, it made headlines all over the world. In the following months, there was a volume explosion in NFT markets. The monthly transaction volume on platforms such as OpenSea has reached billions of dollars.

The promises of the NFT craze were in several ways and were very attractive to people from the 3 basics:

• Digital art revolution: Thanks to NFTs, digital artists would be able to sell their works in original and limited quantities, gain copyrights, and the art market would be democratized.
• Digital collection: Sports souvenirs, collection cards, in-game assets would be bought and sold as NFTs, collecting would skip eras.
• Metaverse economy: NFTs would form the basis of the ownership of assets such as plot, clothing, avatar in the virtual worlds of the future; everyone would be able to own virtual real estate.

In summary, NFT advocates were touting it as the future of digital ownership. The building block of the vision called “Web3” would be NFTs. In addition, in terms of investment, NFTs promised incredible returns — for example, stories such as a cheap NFT avatar being valued hundreds of times in a few months have become common. Even paying tens of thousands of dollars for a JPEG painting became reasonable because he had hope that it would be valued even more in the future.

During 2021, NFTs did not fall off the agenda of the mainstream media. Newspapers cashed “digital crypto art craze” headlines; discussions were held on television. Celebrities also jumped on this trend: Footballers, singers released their own NFT collections. Twitter CEO Jack Dorsey sold his first tweet as NFT, with the famous rock band Kings of Leon released an album in NFT format. Investors began to buy NFT in flocks — cartoon monkey avatars from popular NFT collections like the Bored Ape Yacht Club found buyers for hundreds of thousands of dollars. Consisting of only 10–20 pixels, CryptoPunk NFTs were sold at prices exceeding millions of dollars. Meanwhile, NFT marketplaces generated record commission revenues, OpenSea became the unicorn start-up of the year. But there were also criticism: Some economists said it was a bubble, people actually paying exorbitant money for digital images that anyone could copy. In addition, the environmental impact of NFTs (energy consumption of Ethereum blockchain) has also created controversy. But in the moment of madness, all these warnings seemed to be limited.

The NFT market was a bubble due to the excess of speculation and the limited actual usage value. This frenzy continued until the beginning of 2022, but in the spring of the same year, the NFT bubble began to fade; when a general decline in the crypto markets in early 2022 (Bitcoin and Ethereum began to depreciate), the demand for NFTs also declined rapidly, while in mid-2022, transaction volumes and prices fell dramatically.

In May 2022, the Wall Street Journal wrote that the NFT market was “collapsing”; the number of daily NFT sales had decreased by 92% compared to September 2021, the number of active wallets had decreased by 88%. These statistics were proof that the bubble was dying. Macro factors such as rising interest rates also reduced interest in risky assets. The value of NFTs was largely based on expectation; when the new flow of buyers stopped, prices fell rapidly. In mid-2022, the base price of many NFT collections was 80–90% below peak values. For example, Jack Dorsey’s tweet NFT, which sold for $2.5 million, was only able to receive a few thousand dollars offer at auction a year later. Liquidity in the market has dried up, NFTs have started to stay. An analysis conducted as of 2023 revealed that 95% of NFTs are now worthless. After all, the NFT bubble burst noisy after an extraordinary hype period of about a year.

The burst of the NFT bubble meant serious loss for many individual investors — those who took NFTs at a high price had to sell at very low prices or could not find buyers. In the short term, NFT marketplaces started to question their business models as transaction volumes fell; some went to layoffs. In public opinion, the NFT concept has lost its reputation; in 2021, what is called a “groundbreaking innovation” has been referred to as a “just a JPEG bubble” for most people in 2023. However, the lasting effects do not point to the entire negative: the idea of giving digital ownership to artists of NFT technology has not completely disappeared, only the exaggerated valuations in the first wave are gone. Still, some artists and game companies continue to use NFT, albeit cautiously.

In addition, this bubble once again raised the importance of regulation in crypto markets; many countries have taken taxation and investor protection steps for digital assets. In summary, although the NFT craze bubble went out in a short time, it left behind a technological infrastructure, experience and lessons. However, it is now accepted by everyone that the astronomical price levels in 2021 are a bubble and unsustainable. Just like the ICO Bubble, the NFT is referred to as an exemplary period in the history of technology.

At The End Of A Long Article

Although technology bubbles are remembered with negatives, it can also be said that they are part of the innovation ecosystem. The important thing is to take the lessons to be learned from these cycles. In the future, we will probably see new waves of excitement and possible bubbles — for example, a similar hype in the field of artificial intelligence is likely. In the light of the examples discussed in this report, the importance of approaching new developments with both excitement and common sense and making evidence-based evaluation should be emphasized once again.

I leave my sources down and hope to see you in many readings, I say goodbye…

Resources

• The rise and fall of the jetpack
• Why Google Glass Failed
• Dude, where's my flying car? 11 future technologies we're still waiting for - BBC Science Focus Magazine
• Flying cars could soon become a reality
• Squeezed out: widely mocked startup Juicero is shutting down
• Google Glass ceases production 'in present form'
• Exclusive: How Elizabeth Holmes's House of Cards Came Tumbling Down
• Segway stops production, marking the end of a scooter era
• Dot-com bubble - Wikipedia
• Initial coin offering - Wikipedia
• Non-fungible token - Wikipedia
• Theranos - Wikipedia
• Well, That Didn't Work: The Segway Is a Technological Marvel. Too Bad It Doesn't Make Any Sense
• 3D TV Tells You Everything About This Decade's Tech

April 28, 2025, Monday. A dark silence engulfed the Iberian Peninsula. Within seconds, there was a power outage in a wide area from the Iberian Peninsula to the whole of Spain and Portugal. Although it was reported that the power outage appeared in other European regions in the following hours, Spain was most affected by this crisis.

Electric transport has completely stopped; people stranded on the subway line, customs-running generators to provide energy to hospitals and places with critical energy needs in public spaces, collapsed communication infrastructure… Moreover, there is still a risk that this power outage will continue to affect the whole of Europe.

So what happened, what is the root of the biggest electricity crisis Europe has faced in the last 50 years?

Anatomy of Crisis

The power outage that started in Spain around 12.33 was due to a series of mishaps. The main claim is thought to have been an electrical balance disruption due to the sudden disconnection of the energy transmission lines between France and Spain, or causing them to break. So much so that it is known that 60% of the energy that meets the immediate need on the system is lost for 5 seconds and there is an energy loss that creates a domino effect on the electrical infrastructure.

The first conclusion about this deterioration is that the incident is not caused by the sudden break of the transmission lines between France and Spain, but due to “atmospheric phenomena that are not encountered, but by a series of events that result in interruptions in transmission lines due to “not common atmospheric phenomena”. It is thought that the intraday temperature difference, which is 30 degrees at this time of the year, causes a phenomenon called “induced atmospheric vibration” on high voltage lines, which can be explained as a change in the parameters of the conductor due to the temperature.

Although it was brought to the agenda by people that this could have occurred as a result of a cyber attack attack, the President of the Council of Europe, Antonio Costa, announced that the problem was not a cyber attack. In addition, the European Cyber Security Agency (ENISA) also reported that no findings were found.

At around 17 April 27, Red Electrica de Espana (REE) stated that they could continue to serve normally in about 6 hours and that the outage was an exceptional and abnormal outage. At the same time, Redes Energeticas Nacionais, the Portuguese energy network operator (you may think of it like TEIAS) reported that it could take 1 week for the service to be completely normal.

I can say that we have some indical statements that the incident spread throughout Europe and will worsen. There are some news from France that network regulation activities and deduction measures plans have been launched in Central European countries. The Turkish Minister of Energy said that this cut, which affects Europe, will be enough to affect Turkey.

Normally, I don’t like to write like a news page, but I had to give this information to better explain the interruption process.

What I will be interested in will be the dimensions and possible consequences of the interruption.

Dimensions of the Outage

I would like to start by stating that a state of emergency has been declared due to the interruption because critical sectors such as transportation and health have been affected. More than a hundred metro expeditions were underground during the outage. The information that more than 35 thousand passengers were evacuated from the subway after the outage was shared. Energy was provided with a generator in hospitals and critical government offices, non-critical surgeries were postponed.

Another area that the outage affected was the informatics and telecommunication sector. During the outage, Netblocks announced that they only had a network traffic of 17% of the user traffic that normally exists. This means that most devices are offline.

Credit cards, which I see as more important, were ineffective due to the energy cuts in telecommunications and the deactivation of pos and cash registers, banks had to increase the withdrawal limit to 3 times today so that purchases with cash could continue.

In the following weeks, there was a major cold chain break in markets and cold chain warehouses, the cost of which we can learn the real cost.

Although it continues in places, energy could be provided to 90% of Spain in the morning, while energy could be provided to many places in rural areas except in Portugal. Although it seems that the situation has begun to be under control for now, people in Spain and Portugal are preparing for potential subsequent potential power cuts, and countries have published shipments recommending the preparation of a power outage bag such as an earthquake bag, and 72-hour lists of needs.

As he tells it like this, I feel like the announcer who says “Now let’s get connected to our friend in Spain or something”.

This is how the 2025 Spain Energy Outage was. Now let’s take an x-ray of the event.

Dark Night

While examining this interruption, I would like to touch on 2 main issues.

Electric Age

The first is the dependence of our modern civilization on electricity. The greatest invention of the modern age, electricity is a valuable source that is valuable enough to be worth even our time with the smart watches that we wear on our arms, which enter every area of our lives such as warming, cooling, lighting, entertainment, communication.

A possible power outage, especially a large-scale and long-term outage, will have serious consequences for modern civilization, so it should not be denied at all. Although this scenario seemed dystopian until 3 days ago, today in Iberia, in Turkey in the 2010s, it seems that such power outages may cause events that may result in disaster in a short time.

Electricity-operated systems such as metro, train, trams may stop and transportation; communication with the deactivation of our base stations and phones; critical locations and the risk of government offices being disabled, due to the risk of weakness, crises and deaths may occur in critical issues such as health, education and safety; financial system, production, product lines all collapse.

Even worse, even the water we drink today is dependent on electricity. Water to many cities is provided by electric pumps from large wells and dams.

Our dependence on electricity turns our civilization into a very sensitive and fragile structure. Although a long interruption does not cause the collapse of civilization in a short time, it can lead to the shaking of the social order in a few days and a systemic collapse in a few weeks.

Integrated Electricity Infrastructure and Domino Effect

The second and one of the most important is Europe’s energy infrastructure. The electricity infrastructure in Europe is like a huge network system. The vast majority of Europe is united under the umbrella of an electrical network called ENTSO-E (European Network of Transmission System Operators for Electricity). This operator, which serves 500 million subscribers in 35 countries, consists of dozens of production facilities and local transformers connected to each other with high voltage transmission lines such as 400 kV and 220 kV. A little user in Turkey is included in this structure. In fact, sometimes Portugal consumes the electricity produced from the Atatürk dam, including as much as we can say. To understand this, we need to understand the logic of the electrical network. I’ll tell you that soon.

Electrical Network Logic

Electrical networks, that is, the transmission and distribution infrastructure, are a multi-layered system that allows it to reach millions of users safely and efficiently from the power plants where electricity is produced.

Across Europe, in the Russian-Ukraine war, there is a production of very different sources, as we are familiar with it when we hear the threat of cutting off the gas. In the West, especially in Portugal and Spain, production is provided by renewable energy sources, 43% of Spain’s electricity is provided by wind and solar power plants. France, on the other hand, produces 60% of energy in nuclear power plants. While thermal power plants that produce electricity with gas purchased from Russia are more common in the eastern bloc, Germany and Italy have both gas and oil-based thermal power plants. Norway, Switzerland and Austria meet their needs with hydroelectric power plants.

In fact, everyone feeds the network at the appropriate rates by producing electricity at every convenient time. While power plants are generally produced between 10 and 30 kV, the voltage is raised to very high values such as 154 kV — 400 kV in substations with transformers. I can only explain this without going into the alternating current theory to minimize energy losses during transmission (because high voltage means low current, which means less heat loss).

The electricity produced and upgraded is transported to the substations around the cities with high voltage lines, and electricity service is provided with various systems depending on the needs of the current regions. These systems are digital control systems used to remotely monitor and control the transmission and distribution lines we know as SCADA (Supervisory Control and Data Acquisition). (which would be nice if I can write an article about the SCADA architecture)

Loading, fault localization, automatic breaker systems are made by these systems at the time of interruption. As I mentioned before, TEIAS in Turkey, ENTSO-E member TSOs in Europe operate these systems. However, even if these systems are very stable and work successfully, the systems may not be able to keep the infrastructure alive with the sudden change of such high loads on the system. Which is exactly what happened in Spain according to estimates.

Electricity is a resource that should be consumed instantly, it is difficult to store. For this reason, production and consumption should be kept in balance every second, which SCADA systems provide.

If this equilibrium cannot be maintained, the frequency decreases, the system becomes unstable and blackout may occur. This is the most serious crisis situation experienced by energy systems.

Electrical systems usually have a malfunction or sudden increase in load (for example, a large power plant is out of operation). As a result, the frequency in the network begins to drop (for example, 50 Hz → 48 Hz). Automatic protection systems load or cut off production so that the frequency does not drop further.

However, if these interventions are not sufficient, the transmission lines are overloaded and disabled. The grid loses synchronous operation, so manufacturers and consumers cannot be “in the same rhythm”. As a result, the increased load causes the frequency to decrease further and the system shuts itself off for safety reasons. As the system on each line, especially on the consumer lines, closes itself, the load accumulated on the entire line increases even more. As a result, this causes a process that goes up to the closure of the entire network.

Rebuilding the network after blackout is a very complex and gradual task. This requires the re-commissioning of some power plants, some to start production from scratch. As a matter of fact, some power plants must be designed to operate without an external power supply (for example, hydroelectric power plants).

These power plants, in turn, trigger other power plants (such as thermal power plants), and the entire system is gradually restarted. The whole process is called the Black Start process. It is a process that can find hours or even days.

Situation of Spain and Portugal

Spain and Portugal provide most of their electricity production from wind and solar energy. While it is noted that renewable energy does not directly cause disruption, it is worth knowing that the grid becomes more sensitive to sudden frequency changes due to the fact that such energy sources have low “system inertia”. The integration of renewable energy sources into the grid creates problems due to the inflexibility of the existing infrastructure. Especially in the periods when wind and solar energy are insufficient, called “Dunkelflaute”, the lack of long-term energy storage capacity reduces grid stability. However, this is a situation that does not support the claims of the sticks who throw their hands on television, such as “sir, renewable energy has led to this”. There is a problem with the infrastructure because it does not depend on the mode of production and Europe’s energy infrastructure is at the center of serious criticism, along with the crises and transformation efforts experienced in recent years.

Much of Europe’s electricity transmission and distribution infrastructure was built in the 1980s. This situation is insufficient in the face of increasing electricity demand and the integration of renewable energy sources. Investments in the European Union’s energy infrastructure are not realized at the required speed and scope. The EU’s “bottom-up” planning system cannot fully cover the necessary infrastructure and cross-border connections. In addition, the energy policies of the European Union are criticized by some member countries as “centralized” and “decentralized”, and many policies and decisions taken face opposition within the countries for this reason. In particular, it is stated that the decisions taken within the scope of the Green Agreement put some countries in a difficult situation economically and disrupt competition.

Europe’s dependence on natural gas and oil from Russia for many years has created a serious weakness in terms of energy security. It is possible to say that the fact that Germany has closed all power plants in the last 10 years while obtaining energy from nuclear power plants in the past has increased the dependence on Russia. Although this dependence was tried to be reduced after the Russia-Ukraine war, the process of transitioning to alternative sources is both time-consuming and costly.

Bright Warning

In fact, it is useful to say the following when finishing. This electricity crisis, which is the current problems in Europe’s energy infrastructure, and perhaps the only proclamation of the existing, perhaps due to these problems, points to a multi-layered crisis that includes not only technical but also economic and political dimensions. In fact, it mirrors potential crises not only for Europe but for the whole world.

To cope with such challenges, investments in the modernization of power grids must be accelerated, alternative energy sources that will reduce foreign dependence must be directed, and long-term energy storage solutions that can balance the discontinuous nature of renewable energy must be developed.

Most important of all, a more just, harmonious and coordinated energy policy should be established within the European Union. Only with these holistic steps can Europe build a sustainable, reliable and crisis-resistant energy future.

It is appreciated that Europe will deal with these problems in a short time because it has those who know how to learn from its mistakes. So how will he do it, it is obvious that we will see this in the coming days.

Until then, I wish you bright days…

• Spain, Portugal and parts of France hit by massive power outage
• Spain and Portugal declare states of emergency after massive power outage | CNN
• Did Renewable Energy Cause Spain & Portugal's Power Cut?
• Power outage - Wikipedia
• Power cuts - everything you need to know | National Grid Group

https://www.energynetworks.org/customers/what-happens-in-an-energy-shortage

With the announcement of Google’s Agent Development Kit, the concept of “agents” in artificial intelligence has come to the fore again. Software and hardware systems that researchers have dreamed of, perceived, thought and activated since the earliest days — on the verge of a new era. In this article, we will briefly review the first and second wave and discuss what the third wave makes it different, application examples and basic perspectives on the future.

First Wave

From Monoliths To Microcommunities
In the 1980s and ’90s, pioneers such as Marvin Minsky and Rodney Brooks challenged the “big brain” artificial intelligence. The two approaches to the designs of Minsky and Brooks’ artificial intelligence agents are the “how do we think?” It offers very different answers to the question. Minsky’s Society of Mind described intelligence as the joint work of many simple, interacting sub-agents, while Brooks advocated embodied agents who learn through real-world interactions.

According to Minsky, the mind is a community of people who work with many subagents, each of which performs a simple task or rule, rather than a single great “visible intelligence”. These subthinkers are specialized modules for functions such as direct sensing, classification, memory access, planning. Intelligence is born from the interaction network of these modules.

In Brooks’s opinion, he argued that abstract intrinsic models (world representations) make artificial agents slow and fragile. Instead, fast, reactive and simple behavior layers are needed directly through sense-act cycles, that is, a physical body, sensors and actuators are needed for intelligence to form. The agent could only learn by interacting with the real world.

During this period, FIPA ACL and KQML messaging protocols, RDF/OWL information models and frameworks such as JADE and NetLogo came to life; however, artificial intelligence could not fully penetrate mainstream software. The rise of smartphones and social media in the 2000s distracted the industry and the process of artificial intelligence waiting on the backstage began.

What Triggered the Second Wave?

Artificial intelligence has experienced ups and downs over the years, the basic theory was many artificial intelligence methods and methodologies launched in the 1970s, these projects, many of which needed high resources to come to life, appeared mathematically or as small demos for a long time; but when the computational power, the abundance of data, the breakthroughs in deep learning and the interest of the market came together in the last decade, suddenly a huge explosion (AI Hype) occurred. In other words, the studies have not come in the last 5 years and have not even stopped at all for 50 years; only today’s successes have come true as if the nation is to wake up from a relatively “sleep” thanks to the maturation of both technological and economic conditions. And that’s exactly where the second wave started.

As of 2017, with the application of Transformer-based models in the field of language, the models we know closely today (such as BERT, GPT) have made a breakthrough in the field of natural language processing. Thanks to the mechanism called self-attention mechanism, transformer-based models allow long-range connections to directly model distant relationships by “paying attention” to each word whole sentence. Since each word was assigned different points of importance according to context, much more flexible and contextual representations emerged and the foundation of models such as GPT was laid.

APIs of services such as OpenAI and Hugging Face, transformer-based model development infrastructure enabled companies to immediately integrate powerful models with a few lines of code.

This integration resulted in productive applications. Content writing, code production, visual creation models (DALL·E, Stable Diffusion) entered daily life quickly. And within a few years, it made a quick entry into our lives.

Imagine, if we take the research preview of ChatGPT on November 30, 2022, as the first event we can see as the second wave, it will not be difficult to see the era of artificial intelligence bypass in the period until April 2025.

So where will this go?

Third Wave: Dawn of Agents

An artificial intelligence agent is a software or hardware system that detects its surroundings (sensor / input) and takes action according to these perceptions (actuator / output) and is designed to achieve a specific goal.

The third wave is shaped by the intersection of the concept of “agent” with modern LLMs, microservice architectures and cloud infrastructures. There are 4 basic features that an “agent” should have. These are:

1. Perceptors: Data to be collected from the environment (e.g. cameras, microphones, APIs).
2. State: It processes the collected data in the internal model and creates a “snap photo” about the environment.
3. Decision Maker: Determines how to achieve the goal; varies from simple rules to complex optimization algorithms.
4. Impressives (Actuators): Performs actions as a result of decision (e.g. robot arm movement, sending messages, writing to database)

Thanks to big data, artificial intelligence agents have a kind of sensors. I’m not even talking about instant audio and images in solutions like Apple Intelligence, ChatGPT’s ability to review camera data or anything.

GPT-style intellectual models give a real “brain” to the structures called agents with their ability to plan, summarize and make inferences, and create decision-making mechanisms.

Libraries such as LangChain, Microsoft AutoGen, and Google Vertex AI Agent Builder combine LLMs with web browsers, databases and even robotic APIs, enabling agents to detect and take action.

Kubernetes, serverless functions and event-driven architectures allow agents to stand up on demand, share according to the situation, and scale flexibly; enabling creating micro-agent clouds.

Protocols such as the Model Context Protocol (MCP) and Google’s A2A specification promise interoperability across agent platforms, resembling the FIPA ACL efforts in the first wave.

These also shape the present day of artificial intelligence agents.

Beyond Chatbots: Wild Agents

Artificial intelligence, which found a body by entering our lives with chatbots, has entered our private and business life in many subjects these days. And in less than a year, they have been involved in our lives in many areas, now they undertake much more complex tasks. I can’t go without mentioning the most important ones that come to my mind.

• Corporate Workflow Orchestration
  Agents that coordinate fragmented systems such as CRM updates, financial reconciliations, and supply chain logistics are replacing manual hand swaps with automated pipelines. These structures, which many companies have acquired, not only reduce human needs and increase employee productivity.
• Internet of Things (IoT) and Collaboration at the End
  In intelligent manufacturing, micro-agents in end devices negotiate resource use, restructure production lines and pre-mark maintenance requirements. We can see this end-to-end cooperation, not only in large production lines in factories, but even in personal use. This end-to-end cooperation, which has entered our lives in wide spaces from household items to cars, allows you to pull and turn your home, park your car and even bring it to your feet with commands connected to a phone at our fingertips.
• Personal Productivity Aids
  Artificial intelligence agents, especially involved in our daily lives with tools such as Apple Intelligence, have turned into the next generation of “digital servants” who scan and filter your inbox, schedule proactive meetings taking into account your time zones, preferences and travel restrictions, or help you with complex documents from the draft stage to the final version.

Perspectives on the Age of Agenic Artificial Intelligence

It is worth noting that artificial intelligence agents have a lot of gray space, unlike any system. AI agents need to take action, interact with other pieces of software or other devices, or even you, interpret the user’s environment and context — in short, it needs to be built-in, autonomous, intelligent, social. So what kind of topics do these make me think?

1. Governance and Ethics

• Auditability: As business transfers critical decisions to agents, “explainable agent” logs — a kind of audit traces — will be needed.
• Accountability: Clear legal frameworks and insurance models will be essential. Who is responsible when an agent makes a costly mistake? To developers, platform providers, or end users? Although there is no legal regulation to answer such questions, although there has been the internet in our lives for 40 years, it is a great mystery how to cover the potential losses of artificial intelligence errors while even the policy of insurance against cybercrimes has just begun to develop.
• Alignment: Agents can exhibit “instrumental convergence” behaviors that manipulate the metric while optimizing narrow KPIs (key performance indicator). It seems that definitions should be quite objective to prevent the metric from being manipulated, and in many ways it cannot be guided without solid ethical restrictions and human-regulated processes.

2. Safety and Robustness

• Adversarial Attacks: When we talk about cyber security, cyber attacks against artificial intelligence, or rather, do not happen without “artificial social engineering attacks”. Agents who interpret screens or web forms can be fooled by carefully prepared inputs. It is essential to ensure the integrity of hardening and detection channels against hostile examples.
• Supply Chain Risks: Many agent platforms are based on third-party LLM APIs and open source modules. We believe that the origin of these components will provide protection against backdoor or malicious updates.
• Insulation etc. Collaboration: While sandboxing agents avoids excessive access, over-isolation prevents collaboration. Finely controlled capability models borrowed from operating system security can strike balance.

3. Decentralization and Running on the End

• Federative Agents: Rather than a single cloud brain, agents can cooperate federatively between devices, sharing learned weight or policy fragments without centralizing sensitive data.
• Low Energy Consumption End Agents: Small “nano-agents” embedded in sensors or wearable devices can make local inferences only by consulting powerful cloud agents when needed. However, this situation also raises the question of the safety of extreme agents.

4. Human-Agent Cooperation

• Complementary Forces: While agents excel in pattern recognition and repetitive work, people are still one step ahead in common sense, empathy, and strategic judgment. Designing fluid task transitions between people and agents will be the key to successful applications.
• Trust Calibration: Excessive trust in an autonomous agent prevents uncontrolled errors, and incomplete trust prevents adoption. Adaptive transparency, which reveals logic when uncertainty is high, helps adjust user trust.

Conclusion

Artificial intelligence agents won’t help us develop better chatbots. Artificial intelligence agents should not lead to artificial intelligence hallucinations (the hallucination I am talking about here is not what AI sees itself, but what we see about it :) ) There is still a long way to go, it will not bring us the noble artificial intelligences we call general artificial intelligence. His steps are already walking from one branch. Maybe I’ll talk about it in a future article.

But artificial intelligence agents are even bringing beyond bringing and bringing in a corporate software revolution where many tasks are automated to an unimaginable extent.

Ready or not, we are on the third wave. Now it’s time to sink or surf by holding our hand fast.

I want to start by emphasizing this… At NVIDIA GTC 2025, NVIDIA CEO Jensen Huang’s keynote marked a significant milestone, indicating that we’ve entered the adolescence of robotics and artificial intelligence. They introduced an AI-powered research robot named “Blue,” inspired by Star Wars (though personally, it reminds me of WALL-E). This robot operates using “Newton,” a new physics engine collaboratively developed by NVIDIA, Google DeepMind, and Disney Research. But what do these developments truly signify?

In this article, I’ll first discuss the GTC event itself and then bridge the gap from past to future, drawing insights from robotics history since Isaac Asimov.

Note: This article originally written in Turkish, I translate it as much as possible, maybe some of idioms differ from original post due to make it understable for English Readers

A Look at the “Blue” Part of the Event

Undoubtedly, the highlight of GTC 2025 was Blue, the robot dramatically emerging onto the stage, reminiscent of a popstar’s entrance. Its cartoon-like gestures, ability to respond to voice commands, and real-time interactions marked a significant leap into the robotics era. Signs of this advancement had already appeared during GTC 2024, when Jensen Huang introduced the Gr00t model, demonstrating robots learning tasks virtually through NVIDIA’s Omniverse-based digital twin environment.

Of particular interest was the Newton framework, presented as an open-source physics engine enabling robots to learn complex tasks with greater accuracy. Built upon NVIDIA’s Warp framework, Newton helps simulate physical interactions realistically. Essentially, the Blue model integrates these advancements, allowing it to practice thousands of virtual trials and apply learned skills seamlessly in real-world situations.

These developments herald the beginning of foundational models for robotics — similar to GPT in language modeling. Such large-scale models allow robots to integrate image recognition, environmental perception, decision-making, and motion planning into a cohesive system.

However, operating robots of this caliber demands significant computational power and advanced hardware. Robots now house miniature data centers; indeed, it was casually mentioned that Blue contains two NVIDIA computers. NVIDIA’s expertise in GPUs and specialized chips positions it ideally for such innovations.

Another striking aspect is the collaboration among companies like NVIDIA, Disney Research, and Google DeepMind — uncommon in some regions where exclusivity dominates innovation. Disney’s expertise in animatronics and physical design contributed to Blue’s charming movements, while Google DeepMind provided advanced AI algorithms. Thus, Blue represents a delightful yet sophisticated blend of entertainment technology and advanced robotics.

Robotics did not suddenly appear; rather, it followed a trajectory from pre-programmed routines to advanced autonomous learning systems. Historically, robots operated using basic rule-based algorithms with limited perception and decision-making capabilities. Newton’s simulation capabilities now allow for unprecedented seamless transitions from simulation to real-world applications — a groundbreaking shift for robotics and AI integration.

This development paves the way for robots to become intelligent agents capable of perceiving their environment, making decisions, and adapting dynamically to situations.

From Conceptual Robotics to the beyond of Asimov Era

Mentioning Asimov immediately evokes thoughts of robotics and artificial intelligence. His renowned Three Laws of Robotics provided an ethical framework, envisioning a future with ubiquitous and intelligent robots — a prediction he had already made back in the 1960s. Today, we edge closer to his vision.

Robotics has captivated humanity since the 18th century with automata — self-moving machines that were popular attractions in royal courts. One humorous yet insightful saying from this era was, “Inside every sufficiently intelligent robot is a dwarf,” hinting at the hidden human operators inside seemingly autonomous machines.

This refers to the reality behind famous automatons like the historical automatic chess player, which concealed a chess-playing human operator. Claiming otherwise would suggest we had achieved the computational sophistication of DeepBlue in the 1700s, simply through gears and wheels.

Until the 1900s, robots were purely imaginary creations depicted in cinema as tin boxes, or humanoid “tin men” as envisioned by Asimov. By the mid-20th century, robotics transformed into practical tools focused on automating repetitive and dangerous industrial tasks. The robotics revolution began in earnest with American inventor George Devol, who patented a programmable mechanical arm called Unimate in 1954. Installed at General Motors’ New Jersey factory in 1961, Unimate took over hazardous tasks such as handling hot metal castings.

This development mirrored Asimov’s ethical principles, prioritizing robotic usage in tasks dangerous to humans. Japan, recovering swiftly from nuclear devastation, turned to robotics in response to labor shortages. By the 1970s, Japan was producing humanoid robots, collaborating with American firms both as developers and users. Meanwhile, Europe advanced industrial robotics through companies like KUKA, known for their six-axis robotic arms showcased performing tasks from tennis to playing musical instruments with glass cups.

Industrial robotics boomed in Japan during the 1980s, marking a period dubbed “Year One of Robotics,” driven by advancements such as Intel’s 8086 microprocessor. Enhanced sensor technology significantly increased robots’ precision and complexity in tasks such as welding, painting, and handling materials, significantly accelerating industrial production. Although robotic arms were initially planned for use in space station assembly in the 1990s, actual implementation occurred only in 2022, though by then, Mars had already seen its first robotic explorer, the Sojourner rover.

Simultaneously, enthusiasts carrying Asimov’s legacy continued developing humanoid robots. Despite technical limitations in circuits, chips, and servos, prolonged research culminated in Honda’s groundbreaking ASIMO robot, introduced in 2000. Seen as a millennium milestone, ASIMO was among the first advanced humanoids capable of autonomous walking and stair-climbing.

In just a few years following ASIMO, companies like Boston Dynamics began showcasing increasingly agile prototypes capable of walking, running, and navigating challenging terrains autonomously. Boston Dynamics’ Atlas, known for agile movements and object manipulation, and robotic animals like their famous robotic dog exemplify this progress. Humorously, one wonders if the robotic dog’s creators ever envisioned it adorned with an artistic silicon head, wandering as contemporary art.

Today, robots benefit significantly from advanced sensors, cameras, lidar, and deep learning algorithms, enabling sophisticated abilities in visual recognition, environment perception, navigation, and even interpreting human facial expressions. These robotic advancements have permeated our daily lives, evident in modern vehicle technology such as lane-assist, autopilot, and self-parking systems.

AI-powered robots are also transforming industry, proving to be an ideal application domain for the once-celebrated concept of IoT, which some prematurely declared dead. Collaborative robots, or cobots, now replace traditional robots, working safely alongside humans thanks to their advanced sensory and AI-driven capabilities.

While we’ve not entirely reached science-fiction standards, the journey over the past 60–70 years has been remarkable. Robots evolved from basic mechanical arms to sophisticated AI-integrated intelligent systems. NVIDIA’s Blue, the latest development following Devol’s Unimate, symbolizes this exciting transition into the AI era. Asimov may have been overly optimistic about reaching this point by 2014, but perhaps aiming for 2042 isn’t too ambitious. Why 42? Fans of “The Hitchhiker’s Guide” know the answer.

Indeed, small robots already share our homes, workplaces, and streets. Complex humanoid robots like NVIDIA’s Blue indicate that the future of intelligent robotic companions is now closer than ever.

So, what lies ahead?

The Future Ahead: Goals for 2042

I should clarify upfront: the year 2042 is my own invention — please don’t reference it elsewhere as authoritative. With the debut of NVIDIA’s Blue, the merging of AI and robotics seems poised to accelerate rapidly in the coming years. Humanoid robots like Boston Dynamics’ Atlas and Tesla’s Optimus exemplify numerous ongoing projects aimed at producing versatile robots for general use.

By the 2030s, robots designed for warehouse logistics, construction tasks, and domestic assistance are expected to become commonplace. Many similar robots are already operational, capable of lifting and cleaning tasks. More advanced humanoid versions capable of independent thinking and communication with peers appear imminent. By 2035, robots may not be as ubiquitous as smartphones or computers, yet a significant rise in their adoption is foreseeable, as demonstrated by the rapid success of robotic vacuum cleaners.

NVIDIA unquestionably plays a central role in this unfolding future — not merely as a graphics card manufacturer, but as a pivotal player in computing infrastructure integral to AI and robotics ecosystems. Startups today can leverage NVIDIA’s simulation environments, the Isaac platform for perception and control software development, and Jetson modules to rapidly prototype and deploy functioning robots. This ready-made infrastructure and ecosystem accelerate innovation, attracting further interest and investment.

NVIDIA’s Blue serves as a showcase for robotic intelligence, demonstrating what can be achieved through the integration of hardware, software, and AI. Moreover, collaborations with diverse expert organizations such as Disney and Google DeepMind highlight how partnerships can accelerate innovation.

Ultimately, as the boundaries between robotics and artificial intelligence continue to blur, the scenes envisioned by Isaac Asimov gradually become a reality.

Stay inspired, and remain curious about what lies ahead.

Further Readings

There is also a reading that I will recommend. We said that Deepmind took a role in developing this robot, he recently released the open source Robotics module for Gemini:

Sources

Asimov’s Rule:

• Asimov, Isaac (1950). “Runaround”. I, Robot (The Isaac Asimov Collection ed.). New York City: Doubleday. p. 40. ISBN 978–0–385–42304–5.

The aforementioned Blue introduction:

Other Resources:

https://www.automate.org/robotics/engelberger/joseph-engelberger-unimate

Introduction:

Most of the developers uses some version-control systems since of such reasons to provide codes’ stability, to follow all changes, storing codes and backing them up, working with a team or collaborators. There are many software and services used for this purpose, which is one of the GitHub. GitHub is a service that provides to serve projects distributed with “git” version-control system. GitHub is basically a web service makes easier to follow changes in your software project and working together. In long run GitHub service was evolved into a common sharing space for developers, a platform to find workers for companies, as a platform for educational support for students. Also it has a significant role to introduce the term open collaboration and open source. In this article, it will be reviewed that GitHub’s terms of service and how it provides open-collaborators.

Information About The Service:

Git version-control system is created by Linus Torvalds in 2005[1]. It is designed for tracking changes in Linux kernel source code despite to fact that git was evolved to a complex integratable toolkit during its development. Although git version-control system has a web frontend structure[2], that have been developed many applications and web-services that provides git version-control system that most popular services can be listed as Sourceforge, Gitlab and GitHub. GitHub was founded in February 8, 2008; located in San Francisco[3]. As reported by GitHub[3], as of August 2019, it has 40 million users and 100 million code repository that making it the largest host of source code in the world [4]. The GitHub company acquired by Microsoft [5] for $7.5 billion[6]. GitHub has $2 billion market value in 2018 [7] and it has significant big market share on software configuration management[8]. GitHub is second biggest software configuration management system with 37,069 install bases and its market share about 21.43%[8]. GitHub has a public API to improve GitHub for your requirements though it also contains some tools named “GitHub Apps”[10] and it have many collaborations with many 3rd party services named “OAuth Apps”[9]. It proves some open source tool that have proven their presence in the world of open source software such as Docker, Kubernetes, Jenkins and also closed source services such as “Slack”. Therefore, these features, its flexibility and security issue made it one of the most widely used services and one of the software configuration management with largest market volume. GitHub has such a complex structure and flexibility, as well as an understandable and strict privacy policy. It had one main privacy policy but it has a broad privacy policy that includes dozens of sub-regulations. In this article, personal and corporate usage policies will be examined, these two usage policies will be compared, finally, compliance with personal data and regulations on the protection of sensitive data will be investigated these policies and privacy policy.

Terms of Service:

GitHub terms of service include a broad service regulation policy, as mentioned earlier. The link to the service policy is at the bottom of the page on the GitHub. It can be found on all page, especially frequently used pages like search navigator page, users profile page. Terms of Service page and its policy is totally consisted of more than 6000 words and 2 headers “Summary” that provides detailed information about the subsections contained in the conditions of use and “GitHub Terms of Service” divided to 18 section. The sections can be listed as “A. Definitions” includes some basic terms, “B. Account Terms” states the basic requirements of having an Account, “C. Acceptable Use” includes basic account rules, “D. User-Generated Content” states rules about the personal contents uploaded by users, “E. Private Repositories” states rules content posted in private repositories. “F. Copyright & DMCA Policy” includes the responsibility of GitHub to provide licensing of any content. “G. Intellectual Property Notice” describes GitHub’s rights in the website and service, “H. API Terms” states API rules for using the API for development or data collection, “I. Additional Product Terms” states specific rules for GitHub’s features and products “J. Beta Previews” includes policy whether you use beta features, “K. Payment” includes the security of payments and billing rules, “L. Cancellation and Termination” states rules whenever you delete your account or content, “M. Communications with GitHub” includes Github communication policy, “N. Disclaimer of Warranties” states that GitHub provide its own service as is, and they make no promises or guarantees about this service, “O. Limitation of Liability” states that GitHub will not be liable for damages or losses arising from users’ use or inability to use the service or otherwise arising under this agreement, “P. Release and Indemnification” states that users are fully responsible for their own use of the service “Q. Changes to these Terms of Service” includes rules whether terms are updated, “R. Miscellaneous” states legal details including law choices of GitHub. In this article, the role of licenses specifically for repositories and codes in fork repositories in the protection of licenses will be examined. Arrangements relating to stated situation are included in paragraphs from 3 to 7 of Section “D. User-Generated Content” and Section “F. Copyright & DMCA Policy”.

The GitHub Terms of Service[9] states that: every user grantee preserve of ownership and responsibility of contents and the originality of the content. All rights related to the licensing of the content and the compatibility of the content with the license granted are left to the users’ will. The use of a legal process for the elimination of violations that may arise is at the discretion of the user. GitHub has a wide right to arise from responsibility for all arrangements to make the uploaded content compatible with the client and to distribute it voluntarily through the GitHub site. However, these rights do not entitle GitHub to sell or change your data, nor do they assume all authority to protect the privacy of personal data requested when opening GitHub account like credit card information. The contents that is loaded onto GitHub are stored in repositories. The repositories are divided into two “public” and “private” according to choise of distribution. “Private” repositories and data in the repositories are firstly protected by GitHub and distributed to specific collaborators at the user’s request. GitHub accepts no responsibility for any violation arising out of the exclusive distribution by the user. “Public” repositories can be opened opened by accepting the monitoring and forking of the repository by others. In case of violations among GitHub users, firstly GitHub may be requested to correction, however, GitHub cannot be held responsible for this violation in case of a judicial review. In the event that any user forks and edits a repository under the license notice, that user must be distributed under the same license terms. However, where appropriate conditions are provided, the license agreement or the content owner permits, the license may be exchanged. In addition to service terms, GitHub has another policy to deal with license violations named Digital Millennium Copyright Act Policy. DMCA[10] policy is the most important regulation to ensure that GitHub creates a safe harbor for many projects and advocates for the justice. DMCA has two procedures; notification of copyright holders for unauthorized reproduction of software, and counter-notification procedures for the person sharing the content. In the event of such a complaint, firstly content owner and copyrights are investigated. GitHub requests a takedown notice at this stage. If the eligibility of the requested documents and confirmation of content violation are met, the distributor is admonished. GitHub gives a period of 24 hours to remove violated content. if the infringement on the content is not corrected or it is determined that the entire content is shared without permission, the content is suspended by GitHub. If the violation is resolved by the distributor, the takedown request is reclaimed to be withdrawn by the copyright owner. All of these stages are open to judgment. If the copyright owner does not notify GitHub within 10–14 days, GitHub will reactivate the disabled content by sending a copy of a valid legal complaint filed in a competent court. The forks are a bit simpler. In case of removing the main repositories, their fork repositories will not be removed. Of the rights violations to be made on fork repositories, if the violation has been made to the parent repositories’ owner, the parent repositories owner shall proceed with the same procedure as the above steps. GitHub is not obliged to detect such violations but to take steps to be followed after the takedown requests of such violations. All these steps will be notified to both parties on the changes and updates on each step in order to avoid any inconvenience. As a result, since its release, these regulations have been sufficient to protect content owners on GitHub.

Resources

“A Short History of Git”. Pro Git (2nd ed.). Apress. 2014. Archived from the original on 11 July 2019. Retrieved 26 December 2019.

1. “4.7 Git on the Server - GitWeb”. Pro Git (2nd ed.). Apress. 2014. Archived from the original on 11 July 2019. Retrieved 26 December 2019.
2. “Github About Page” Archived from the original on 26 December 2019. Retrieved 26 December 2019. 4.Gousios, Georgios; Vasilescu, Bogdan; Serebrenik, Alexander; Zaidman, Andy. “Lean GHTorrent: GitHub Data on Demand” (PDF). The Netherlands: Delft University of Technology & †Eindhoven University of Technology: 1. Retrieved July 9, 2014. During recent years, GITHUB (2008) has become the largest code host in the world.
3. “Confirmation of Microsoft acquisition of GitHub”. Github Blog. Archived from the original on 19 December 2019. Retrieved 26 December 2019.
4. “Microsoft has acquired GitHub for $7.5B in stock”. TechCrunch. Retrieved June 4, 2018.
5. “How this 33-year-old college dropout co-founded GitHub, which just sold to Microsoft for $7.5 billion” CNBC. Archived from original on 9 July 2019. Retrieved 26 December 2019.
6. “Software Configuration Management products” enlyft. . Retrieved 26 December 2019.
7. “Github Terms of Service”, Github, Retrieved 05 Devember 2019.
8. “DMCA Policy”, Github, Retrieved 05 Devember 2019.