Can googlefonts profile be a plugin just like all other vendor-specific profiles?

[felipesanches]

README.md lists these crates under "Components" section:

It caught my attention that from all vendor-specific profiles, only the googlefonts one is built-in, while others are loaded as plugins.

This raises the following questions:

• Is there any measurable performance difference between these two ways of loading profiles (built-in versus plugin)?
• Could we make googlefonts profile a plugin as well, so that there's no special treatment for one specific vendor?

These questions come from my insights as FontBakery maintainer, where there were intentional project decisions made aiming at ensuring it is clear to all users that the project is inclusive, and not biased by a single player.

I believe that ideally only Universal and OpenType profiles should be kept built-in and all the rest should be plug-ins.

[simoncozens]

Is there any measurable performance difference between these two ways of loading profiles (built-in versus plugin)?

There's no performance difference. There is a distribution/maintainability difference. Plugins need to be compiled/downloaded and installed separately, located somewhere loadable on the filesystem, etc. Built-in profiles are just right there in the binary.

Could we make googlefonts profile a plugin as well, so that there's no special treatment for one specific vendor?

I'd rather go the other way and add more profiles into core (just like fontbakery did). The reason I wrote the other profiles as plugins rather than in core is to demonstrate that adding custom Rust profiles is possible.