Application dependencies: Ensuring that third party plugins are upto date with the latest software version

Software development involves working with and resolving a lot of dependencies. I have been writing about the dependencies related to vendors (Article 1, Tools, Process sharing)  and those relating to the use of components (Article 1, Article 2). But this is not the only dependencies that happen in a software project. When you look at big software such as Photoshop or Microsoft Office, these software and other large software deliver a lot of functionality. However, there is always the effort by all such software companies to get a lot of experts and users to extend these software in terms of adding functionality through the use of software. If you take these software, there are actually a number of companies that provide third party components, some of them free and others that users can buy. If you consider a software such as Photoshop, there are a large number of components available that provide extended functionality, such as being able to do a better job of photo manipulation, additional effects for the software, and so on.
Having such components also adds a lot of benefit to the software, since this is ensuring that there is a eco-system that grows around the software, and with these components adding functionality to the software, there is a larger set of users who grow attracted to the software. But, with all these functionality, there is an additional amount of dependency and risk. Any software goes through changes during the product development of a new version, and many of these changes can impact the integration of these components with the product. For example, during the development of a software version, we made changes to the database in which product information was being stored, and this database change meant that a number of such services through which components linked to the database would no longer work, and even if they would work, there could be changes in the way they worked. Such a change is a big thing, since the component makers go through the same challenges as the makers of the software, and there is a lot of synchronization that needs to happen with relation to the component makers. What are some of the processes that need to be gone through for such a change:
- As and when there are changes that could impact a component, there needs to be a discussion with the maker of the component. Detecting such a change is possible for the software team, but it can be difficult. It is far easier to add the component maker to the beta program of the software component maker, and they can check the ongoing version of the software in the beta program with the component and evaluate for any change.
- At the same time, there needs to be a testing effort to ensure that the product team (if through automation, then makes it easier) is also periodically checking the components with the software and informing the component maker if there is any problem
- The product team also needs to have the latest version of all the components to test all of these on a periodic basis. They cannot just depend on the component maker for the same, since if there is a major problem, then there is an impact on the credibility of the product team (for example, in an extreme case, it would be a real problem if the product was crashing on the installation of a component)
- There should be a mailing list which has all the component makers on it, and where the team can send out important updates on any changes in the product that could impact the components

However, there needs to be some limit on the amount of changes that are made in the product in every version. When people buy a component along with a software, they have the expectation that the same component could work in multiple versions of the software, and having to purchase a new version of the component is not likely to win the software company a lot of friends.