As a software vendor responding to requests for proposals (RFPs), Tyk is often asked which integrations we support for specific tasks. Of course, we answer politely and honestly that we have a range of popular tools and plugins, but we’d much prefer to integrate via open standards wherever possible.
It’s not feasible to start with an open standard, though. Moving from bespoke approaches to agreed norms is a gradual evolution. Separate organisations realise they’re working towards the same goal, and a fledgeling standard emerges (or several).
Original image – https://xkcd.com/927/
Over time, assuming it is well-liked, the standard will become prevalent, then predominant.
I’ve detailed how to accelerate uptake later in the article, but first…
What’s so great about open standards anyway?
Tyk loves open standards. We’ll always support them and adopt them whenever the time is right. Here are three reasons software buyers should love them, too.
Flexibility for you, forever
Tight integrations force an ecosystem on you. If your favoured product relies on a connection to a specific observability vendor, you’re bound to make that purchase, even if it isn’t quite right for you. But if the products you buy support open standards, then the options for third-party products are far greater.
This matters beyond the point of purchase, too. What happens when a tech giant buys your current third-party tool and makes it ten times as expensive? If you’ve purchased software that uses open standards, you can simply jump ship overnight to another vendor that supports the same standard.
The weight of numbers
Open standards are developed open source. That has a huge advantage – and by ‘huge’, we’re talking about the number of people able to contribute to the project. For instance, the OpenTelemetry standard has around 1,500 contributors.
Think about that for a moment – that’s 1,500 developers and testers making the project better, sharing all their combined knowledge and experience, distilled and battle-hardened, and constantly updated.
Future fit by default
Once widely adopted, open standards tend to stick around for a good, long time. You’re using several right now to read this, right down to the basic architecture of the World Wide Web. A well-adopted open standard benefits from continuous adaptation to global technology trends while staying conveniently stable at its core.
On the other hand, updates to tightly coupled integrations between systems rely on suppliers’ willingness to pay for the change. What’s more, you’re at the mercy of their release cycles. Even the best-intentioned organisations will struggle to keep up with the pace at which an open standard can respond to change.
Giving something back
OK, I know I said three things, and this is the fourth, but hear me out. This is the most important reason to support open standards and, indeed, the entire open source movement.
The approaches taken, the learning, the problem solving and the code are all available to everyone for free. Open sourcing a development project makes it accessible to all developers regardless of socio-economic background. It’s a small – but significant – way of levelling up. You don’t have to be from a rich nation to use open standards; you just need access to an internet-connected computer and sufficient curiosity.
How do we move past custom integrations?
As I said earlier, we can’t throw away all those custom plugins overnight; it would lead to the collapse of large parts of the software landscape. But we can continue to push for the adoption of open standards and support their ongoing development so that the overwhelming majority of system-to-system integrations eventually use them.
Push vendors for adoption
If you’re purchasing software, you have the power to influence what’s available in the marketplace. If, like us, you fundamentally believe in the value of open standards, then ask vendors which they support. Make it clear that you consider that support to be an important element in your decision-making process.
Get involved in the open standard community
This is our favourite way to give something back. Tyk is actively involved in two of the key open standards for API management – the Open API Specification (OAS) and OpenTelemetry (OTel). With OAS in particular, we’re pushing hard for global adoption and have put our money where our mouth is by baking powerful OAS support into our products.
OpenTelemetry is also receiving strong support from Tyk through early adoption within our product set and collaboration with the community to enhance OTel for API observability use cases, such as better GraphQL semantic conventions.
We’re working to share our journey with the API community on using the OTel tool. Whether you’re wondering how to improve API observability, curious about using OTel to observe GraphQL errors or keen to take the plunge and migrate from OpenTracing to OTel, we’ve got you covered.
If you don’t know where to start or just want to know more about the communities building the open web, head over to the Cloud Native Computing Foundation website to read about the important open projects they’re supporting and which power the web you’re using.
Give WebAssembly some love
Even if you can’t entirely adopt an open standard, the next best thing is to build custom integrations on top of one. WebAssembly, or WASM, is a web-based method for running code regardless of the underlying infrastructure. As such, it forms the perfect foundation for integrations between different systems. It’s still relatively early days for WASM, but it has been adopted as the fourth official language of the internet, so expect it to be a big part of the future.
Onwards to the future!
Hopefully, this article has convinced you of the significance of open standards. Not just their value to you but their intrinsic importance to the future of the connected world. Tyk, as an organisation and individual Tyklings on a personal level, will continue to push for their wider adoption.
We hope we can count on your support!
The author would like to thank Sonja Chevre for her invaluable contributions to this article.
