I think we should base our decisions for such things on evidence, so I profiled memory usage with 35 additional omniauth providers: additional_providers.rb · GitHub - I chose all the names I’d heard of that actually worked. A few seemed broken.
This is on ruby 1.9.3p327, running on my OSX machine (64-bit) in production mode. I ran apachebench for 5 minutes on each to make sure they were fully cycled.
- With our current 5 strategies, OSX Real mem: 230MB
- With 40 omntauth strategies: OSX Real mem: 240MB
So we are really talking about a 4% difference in memory usage, assuming we’d include all 35 strategies I chose, which I doubt we ever would.
I discussed this recently with @codinghorror. Our original idea was to include a top 4 or so that would represent the most popular providers. Then there would be a “More…” link that would spill out all the additional ones. Note I am not suggesting we add all 35 here, probably an additional 10 would suffice to cross off those even remotely useful to users.
Having said that I do think it would be useful to figure out a clean way to nicely conditionally include gems in our app. Some are only required when a site setting is present for example. We also have the problem that right now installing a plugin means changing your Gemfile, which is locked to our tested versions of stuff.
I wonder if there’s a good solution to having our core Gemfile for discourse as a base, and a secondary one users can edit or something like that to configure the plugins they’d like? It would be even more useful if they could add/remove from it via our admin UI.