Why is the SDL OpenExchange called the OpenExchange?
If you weren’t familiar with SDL and the OpenExchange initiative then perhaps the name suggests it could be a platform of some kind that supports an open exchange of information or tools to help manage the open exchange of data or processes that are not supported out of the box in the core products. Maybe you might also think that the word Open could refer to some kind of opensource facility?
Well, it would be incorrect to state that this is open source because it’s not a “free license“, but if this is what you thought then you were on the right lines.
If you thought any of the following then you’d be wrong!
- The SDL OpenExchange is not available to anyone in competition to SDL… like Atril, or MemSource for example.
- The SDL OpenExchange is not free and SDL will charge a fortune to make this available to you.
Why do people sometimes think this facility is restricted in these ways? This is a good question, and I can only hazard a guess. But I think it’s probably for two reasons. First it’s simply because some people like to perpetuate the idea that SDL are closed and not open to everyone… particularly when the reality is that I think SDL are the only commercial provider in this space that provide as extensive a facility as this for free! It’s very likely that if you choose any other commercial technology as your primary platform you are locked in and will either have to pay for access to a less extensive API or ask the vendor to add features before you can get them. I’ll repeat this because contrary to the reputation we sometimes see perpetuated, the Studio Technology Platform is a lot more than a tool for translating files and managing your Translation and terminology databases. It’s a platform that does provide this capability of course, but it also provides a SDK (Software Development Kit) and an API (Application Programming Interface) that is freely available to anyone with a full license of the Freelance or Professional versions of SDL Trados Studio and what you can do with this is what’s referred to as the SDL OpenExchange. It is exactly the opposite of being locked in!
The second reason would be because in the olden days of TTX and ITD, TMW and MDB, formats created by Trados and SDL, it was sometimes voiced that these proprietary formats locked you in and forced you to stick with Trados or SDL technology. If you were locked in I think it was the result of circumstance rather than any deliberate attempt on the part of Trados or SDL. When these tools were first developed there were probably less viable alternatives, and certainly other tools were less commonly used as we know. Today things are different and the modern tools developed by SDL are XML based making it easier for interoperability of files and for developers wanting to integrate or customise to suit themselves. Things have moved on and the user is in control!
If you want to read a little more about what can be done with this platform then perhaps these articles will be interesting for you:
- The SDL OpenExchange
- The PowerShell what?
- Pimp my Studio 2014…
- SDL OpenExchange Application Security
- X-CAT… the next generation?
These articles are fairly generic around the capability of the SDL OpenExchange so you can get a good idea of what this is all about, but you can also use this link to get a range of articles about how tools have been created for all users:
Tools like these are made available through the SDL OpenExchange “App Store” which you can see here : SDL OpenExchange “App Store”. But this is really the tip of the iceberg because many companies, and individual users, take advantage of the SDK and API to develop tools, and to integrate systems for their own benefit. All of this with no additional charge from SDL!
So, why might we see a competitor complaining that the SDL OpenExchange is closed to them even though they have a license for SDL Trados Studio? Well, we might be very “Open” but you still need a key! In this case, the key is simply a valid usecase for us providing access in the first place. What’s a valid usecase? Quite simply, the facilities we provide free of charge are there to enable users of SDL technology to benefit by enhancing the value they get from the SDL technology stack. Developing the SDK and the API is no small task and it costs SDL a lot of money to create and maintain it. These kind of things would be a valid usecase:
- Create a filetype to allow a Studio user to be able to open and translate proprietary files from an application not currently supported.
- Create a plugin that allowed a Studio user to connect directly to a Translation Memory system of a different translation environment.
- Integrate a quality assurance tool not developed by SDL into the Studio interface so that Studio translations could be interactively QA’d.
- Add new views into Studio so that additional processes such as analysing files, connecting to remote content, searching internet based dictionary tools.
- Add a plugin to Studio for any Machine Translation engine
- etc.
The basic theme here is that development using the SDK and API should benefit the users of SDL Trados technology. The SDL OpenExchange has not been provided for competitors to SDL Trados technology to use in support of development and features for their own products and users. On a personal level I don’t see anything wrong with this approach, and I don’t see anyone else providing this much, never mind giving it away to their competition! Certainly today we have applications on the OpenExchange that have been created by competing vendors, and we also have applications not on the OpenExchange that were developed specifically by competing vendors because they wanted to be able to introduce their technology to SDL users; especially where the end user already uses a variety of solutions and wants to see them working in a more interoperable fashion. The capability SDL provides does make the SDL Technology stack a sensible choice for anyone who wants, or needs, the ability to integrate disparate systems or simply add their own tools and features.
We also have some vendors who have not been given the key… well one at least! But when you consider we have over 800 approved developers with access to the SDL OpenExchange and only four we didn’t provide a key then I think this puts a little more perspective on it. Most of the competitors to SDL who applied have done so with the intention of creating a plugin that would benefit a Studio user. I mentioned Atril and MemSource as examples of competitors to SDL… here’s an example of what one of them has done which will benefit both Studio users and their own just in case you thought I was kidding!
In fact you may well have seen examples of plugins in other articles on this blog that have been created by competitors to SDL.
I think calling it the SDL OpenExchange is correct… and everyone gets a key if they have the right intentions!
