Latest Thoughtworks Technology Radar

What is the Technology Radar?

The Radar is a document that sets out the changes that we think are currently interesting in software development — things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists and is based on our day-to-day work and experiences. While we think this is interesting, it shouldn’t be taken as a deep market analysis.

To find out more about the trends identified in the Technology Radar, read a summary of main themes below or join us at one of a number of events we are running in Manchester (26 April), Newcastle (28 April), London (11 May) and online (12 May) - sign up here. 

Themes from this volume

The Bizarre Bazaar: The Changing Economics of Open-Source Software

At Thoughtworks, we've long been fans of open-source software, popularized in part by Eric Raymond's famous essay "The Cathedral and the Bazaar." Open-source software improves developer mobility and crowdsources both bug fixes and innovation. However, attempts at commercialization demonstrate the enormous economic complexity of the current ecosystem. See, for example, AWS forking Elasticsearch to OpenSearch in September 2021 in response to Elastic changing their license to require cloud service providers who profit off their work to contribute back. This shows how difficult it can be for commercial open-source software to maintain a competitive moat. (The same concern applies with free closed-source software, as we witnessed some companies exploring Docker Desktop alternatives because of Docker's ongoing effort to find the right commercial model.) Sometimes the power dynamics work in reverse: because Facebook funded Presto as an open-source product, the maintainers were able to keep the IP and rebrand it as Trino after they left the company, in effect benefiting from Facebook's investment. The situation is further muddied by the amount of critical infrastructure that isn't corporate-sponsored, where companies usually only notice how reliant they are on unpaid labor when a critical security bug is discovered (as recently happened with Log4J). In some cases, funding hobbyist maintainers through GitHub or Patreon provides enough lift to make a difference; in others it simply creates an additional feeling of responsibility on top of their day job and contributes to burnout. We continue to be strong supporters of open-source software but recognize that the economics are becoming increasingly bizarre, and there are no easy solutions to finding the right balance.

Software Supply Chain Innovations

Public instances of severe problems — the Equifax data breach, SolarWinds attack, Log4J remote zero-day vulnerability and so on — were caused by poor governance of the software supply chain. Teams now realize that responsible engineering practices include validating and governing project dependencies, and this drives a number of blips in this edition of the Radar. Entries include checklists and standards such as Supply chain Levels for Software Artifacts (SLSA), a Google-backed consortium to provide guidance on standard threats to the supply chain, and CycloneDX, another set of standards driven by the OWASP community. We also feature concrete tools such as Syft, which generates a Software Bill of Materials (SBOM) from container images. Hackers are increasingly taking advantage of the asymmetrical nature of offense and defense in the security arena — they only need to find one vulnerability, whereas defenders must secure the entire attack surface — while employing increasingly sophisticated hacking techniques. Improved supply chain security is a critical piece of our response as we work to keep systems secure.

Why Do Developers Keep Implementing State Management in React?

Burgeoning categories of frameworks appear to be a common pattern in the Radar: a foundational framework becomes popular, followed by a raft of tools creating an ecosystem for common deficiencies and enhancements, ending with consolidation around a few popular tools. However, React state management seems resistant to this common tendency. Ever since Redux was released, we've seen a steady stream of tools and frameworks that manage state in slightly different ways, each with a different set of trade-offs. We don't know why; we can only speculate: Is this the natural churn the JavaScript ecosystem seems to promote? Is it an underlying deficiency in React, a fun and seemingly tractable problem that encourages developers to experiment? Or is it the permanent impedance mismatch between a document-reading format (web browsers) and the interactivity (and state) required to host application development atop documents? We don't know the reason, but we look forward to the next round of attempts at solving this seemingly perpetual problem.

The Neverending Quest for The Master Data Catalog

The desire to get more value out of corporate data assets drives much of the investment we're seeing right now in digital technology. At its core, this effort is often focused on better ways to find and access all the relevant data. For nearly as long as businesses have been collecting digital data, there have been efforts to rationalize and catalog it into a single, top-down corporate directory. But time after time, this intuitively appealing notion runs up against the hard realities of complexity, redundancy and ambiguity inherent in large organizations. Recently we've noticed a renewed interest in corporate data catalogs and a surge of Radar blip proposals for clever new tools such as Collibra and DataHub. These tools can provide consistent, discoverable access to lineage and metadata across silos, but their expanding feature sets also extend to governance, quality management, publishing and more.

In contrast to this trend, there also seems to be a growing movement away from centralized, top-down data management and toward federated governance and discovery based on a data mesh architecture. This approach addresses the inherent complexity of corporate data by setting expectations and standards centrally but segregating data custodianship along business domain lines. Domain-oriented data product teams control and share their own metadata including discoverability, quality and other information. In this scenario, the catalog is just a way to surface information for searching and browsing. The resulting data catalogs are simpler and easier to maintain, reducing the need for richly featured cataloging and governance platforms.