It's Not a Race

Intro

Tech progress, as I feel it, was somewhat shadowed by dramatic political events and AI-buzz. If you dig deeper, it feels so inspiring how many good technologies evolved and matured lately – my favorite being Go, of course. :) Coming from a B2B world, which is very conservative about the tech stacks being used, I often notice a misconception: that you should always use "the latest and the greatest." That's not necessarily true, especially if you take into account the term "production-ready," which implies reality-testing and stability, as well as documentation and a community (with a known number of bugs and workarounds). My point is that on a country level, it's good enough to adopt decent technology rather than consider it a race with a winner and losers.

The COBOL case

If you look at job ads, you can notice that from time to time banks are looking for COBOL programmers because they still need to support COBOL apps, which can be core systems, by the way. Of course, Revolut will take over these banks with its modern tech stack, product-based approach, and the principle of "attracting the best talent" (probably being the most important). But the old COBOL code surprisingly works and does the job. It's not like with the introduction of a new tech stack the old apps stop working, but it almost seems like it.

The PHP case

There's also the "When will the investments pay back" principle – rewriting a core banking system can take a long time to pay back and comes with instability risks (which mean losing customers). Management in Germany frequently uses PHP-based apps because of investments made into learning this stack (I mean by suppliers, who can in turn offer lower prices). The thing is, it's too outdated and... it doesn't work. For example, some parts of websites have broken scrolling in Chrome because of a WordPress plugin; I'd also not trust business data to a PHP app, as they can be insecure. This PHP era has to end; it's five steps back, at least:

  1. First, there was PHP (and Perl)
  2. Then, we had Ruby and Ruby on Rails, Python and Django, probably C# and ASP.NET, and Java
  3. Then we had server-side JavaScript and Node.js
  4. After that, we had server-side TypeScript and server-side React (OMG) :)
  5. Now we have Go, and many companies are rewriting their Java, JavaScript, and Python with Go

Go is mature; it has all the features, the community, and the libraries. It has much better packaging compared to npm (hell), and its design is holistic. And it delivers great performance. It's a matter of computer literacy to learn what PHP is, when it was relevant, and why it's relevant no more. Most people know that you should probably operate your mouse with your hand, not with your foot – for me, that's not even an exaggerated analogy. The more dramatic analogy is shooting yourself in the foot because it's cheaper, and that's what happens when someone orders a PHP app in 2026.

The Opensource case

When new tech evolves, it's just there, and as lots of engineers like open source, it often arises as an open-source project. It might not be pretty and is probably not well-documented, but if enough companies adopt this technology and contribute to it by fixing bugs and documenting, it can become great. The issue is that people in general – be they managers or bureaucrats – do not want to wait and/or to contribute. And that's the issue! We are all kids wanting something shiny right now, and as kids, we don't want to take responsibility for contributing or being real about the fact that shiny doesn't mean good. And that's when the tech gets commercialized and you see pitiful ads and promises:

It's not a bad thing to believe that people will cut corners where they are allowed to, so managers maximizing profits in the short term will do it.

The way out

I've written that the EU was not radical enough regarding regulations, but what would these regulations to implement open source look like? And, more importantly, what process is required? Just "in my humble opinion":

  1. We need to identify areas where open-source solutions exist and implement requirements that, in these areas, solutions should be Opensource-based (maybe I'm not radical enough here).
  2. I believe that the only way to find out if a solution is good enough is to start using it – the wider, the better. Finding bugs or new requirements is the process here.
  3. We need to pay for adding features and fixing bugs, but these contributions should be sent as pull requests to the main branch, just because it's cheaper to maintain one main branch and one company shouldn't have to pay for that alone.

If, say, you're in Germany and you invest in some software and write pull requests – will some company in the US benefit from that? Yes, sure, as well as North Korea and other bad actors. "But that's not a bug, it's a feature":

  1. Civilization is essentially one noosphere;
  2. You maintain your digital sovereignty in any case, because no one can take the Opensource product from you;
  3. It's not that everyone can just "install and use it"; you need competence and a community, which bad actors don't have, so we're safe.

Conclusion

It's funny that when discussing tech or politics, we end up discussing being an adult and taking responsibility. I have a friend who migrated from Moscow to London, and he said that this attitude of being an adult is what makes the difference between countries. Being too conservative, on the other hand, is not compatible with tech; the challenge is to embrace the new Generation-Z-JS-frameworks and still feel comfortable and aware of what's going on. Do we have a term like "Über-adult" who can do that?