It is always difficult to decide between an Add-on and a built in feature, this become worse when an add-on in previous version become inbuilt feature for the main software in next version.
To better understand this lets take an example of web browsers, I remember that initially tabbed browsing was not available for any of the web browser and then an add-on came for Internet explorer which made tabbed browsing possible. Now, after many years of that add-on the tabbed browsing is an inherent feature of web browsers and is comes as inbuilt feature. This is a classic case where an add-on became a feature.
When a software is being analyzed one must differentiate between an add-on and a feature i.e. if an add-on become a feature then work should be done on it as a feature and not as an add-on. This work would be primarily focused on risk analysis and QA. Some of the time it might require the developers to verify the interfaces as well the reason for this is simple, earlier when the feature was supported as an add-on it might had used some open API's from the main software but while it became part of main software then it directly communicate with the software and its failure could cause failure of the whole software. Hence, it become crucial to work on affected areas once an add-on is adopted as a feature.
Vice-versa is also possible for the add-on v/s features. With adding lots of feature application becomes bulky and software architects often opt for an add-on way to taper off the not so important features to make the application light. The practical example of this conversion is the app Dolphin browser for Android which uses provides its users a fast working basic web browser by providing additional features as add-on.
So, there is always a trade off between a feature and an add-on based on the convenience and the size of application. This remains the choice of software architect to choose one.
To better understand this lets take an example of web browsers, I remember that initially tabbed browsing was not available for any of the web browser and then an add-on came for Internet explorer which made tabbed browsing possible. Now, after many years of that add-on the tabbed browsing is an inherent feature of web browsers and is comes as inbuilt feature. This is a classic case where an add-on became a feature.
When a software is being analyzed one must differentiate between an add-on and a feature i.e. if an add-on become a feature then work should be done on it as a feature and not as an add-on. This work would be primarily focused on risk analysis and QA. Some of the time it might require the developers to verify the interfaces as well the reason for this is simple, earlier when the feature was supported as an add-on it might had used some open API's from the main software but while it became part of main software then it directly communicate with the software and its failure could cause failure of the whole software. Hence, it become crucial to work on affected areas once an add-on is adopted as a feature.
Vice-versa is also possible for the add-on v/s features. With adding lots of feature application becomes bulky and software architects often opt for an add-on way to taper off the not so important features to make the application light. The practical example of this conversion is the app Dolphin browser for Android which uses provides its users a fast working basic web browser by providing additional features as add-on.
So, there is always a trade off between a feature and an add-on based on the convenience and the size of application. This remains the choice of software architect to choose one.
