... what i think is wrong with plugins: There is a fairly high overhead and significant amount of work to write a plug-in API, and then document it fully....
[In addition]... most programs can't support a significant community of plug-in writers, or *ANY* plug-in writers.
-mouser
I agree 100%. However, in high-usage applications such as e-mail clients, browsers, clipboard enhancers, CAD tools; there is indeed interest in supporting extensions. AutoCAD is a good example. There's a big vertical market for AutoCAD add-ons. For example, there's one that lets you design a generic dress pattern, then the tool automatically generates different dress patterns to fit different sized women. There's another tool for optimizing factory layouts such that the assembly steps/distance traveled for producing each product is minimized. There are several traffic layout tools available in AutoCad.
AutoCAD simply provides a "generic" mechanical design environment, and it's totally customizable to specific mechanical design needs--and there are many.
Just looking at all the possible features and the number of clipboard enhancers out there tells us this is a high-use application and there are many possible features that can be included. There's certainly interest in adding a variety of features to this type of application, and there's a big enough audience to support the effort.
In addition, I would agree Opera is a better web browser out of the box than Firefox, but I use Firefox because with about ten extensions (plug-ins), I can customize Firefox to be a somewhat better browser than Opera to suite my particular needs.
The hard part about designing any plug-in API is making it
extensible so it enjoys a 20-year life expectancy. This requires some developer experience with that application and some vision. This is why the first web browser (remember Mosaic) didn't support plug-ins. Designing and documenting an API for the open-source world is not a trivial task.