This is the last post in the series developing against third party software. You have successfully shipped around the obstacles of using third party software in your project and are ready to ship your product. Congratulations! But wait, you have to tell your users what to expect. More precisely, what you expect from them! System requirements are an important part in your rollout procedure to test. More important than testing is, however the design time decision how much you would like to integrate the third party software into your project. More integrated, the third party product becomes your own and you have to serve first level support for your clients if any problems arise. The benefit, on the other hand, is because of this tight integration, you have more control over the environment in which your product operates. With just loose integration (or none at all, just depending on the existence of the third party software at run-time) you don’t have to worry about much since this has shifted the responsibility for maintenance to the user. This comes at a price: you have to support every version of the third party software. And no, you can’t limit yourself to special versions, your clients won’t read the system requirements or come crying and demanding you to support their versions in use. While deciding which level of integration to choose, you have to consider that license agreements could prohibit you from distributing the third party software as part of your product. But things may not as bad as they seem, maybe the design decision has already been made by the author of the third party software. For example, source libraries have to be compiled in while some software tools for the operation system should stay with the vendor and just be invoked like any system call. Finally, you have to be extra careful to document the system requirements and communicate them to your user base. Without this, you’re in for trouble!