(no title)
grigory | 3 years ago
I think a more nuanced perspective here is that roughly 80% of the work was done, and the remaining 20% require significant effort and organizational energy.
Not all of the WebExtension API surface is currently supported; there's a long tail of infrequently used extensions that require non-trivial engineering effort and often cross-team coordination to implement. However, the actual usage of these APIs in Fennec was very, very low, so the actual bet and the organization sales pitch for this work must be on building a platform, and evidently that's not happening. You can argue that this type of platform work and extensibility is why people use Firefox for Android. You can also look back at the actual usage telemetry (current whitelist is basically what vast majority of people used) and wonder if that additional investment will move the needle.
There's also front-end/back-end engineering required to fully expand existing UIs into a proper "store" experience.
Personally, I think as a matter of principle Firefox for Android should be fully open in terms of what extensions it allows installing.
I believe that will eventually happen - it's where the prevailing winds are blowing inside the org, too! but it may take time for the stars to align, people to have energy to fight through the internal malaise, to pitch work that may not immediately help with any OKRs and is mostly about building community goodwill and sending a message, etc.
As always, it basically comes down to lack of strong leadership.
iggldiggl|3 years ago
While API support in GeckoView/Fenix might be incomplete as compared with Fennec, then again the API support in Fennec was equally incomplete when compared to Desktop, and yet with Fennec there were no restrictions in installing addons.
> There's also front-end/back-end engineering required to fully expand existing UIs into a proper "store" experience.
I suppose you could always try polishing thins up even more, but given that addons.mozilla.org already had (actually still has) a mobile view/responsive layout that seemed perfectly adequate, this still seems somewhat strange.
dblohm7|3 years ago
grigory|3 years ago
I think what's generally missing in these discussions is that the whole project to bring extensions into Fenix was extremely user-driven - whatever people actually use in any significant volume on Fennec, Fenix supports. And the actual UX of installing extensions is just so much more streamlined and nicer in Fenix.
If you purely look at it from the "most value for most users" perspective, Fenix extensions are a great success. And, it's also a success in purely engineering terms - code that's not bringing a lot of value but yet creates an overall maintenance drag is omitted.
What may have been missing from it is the ideological bit - for a platform to be truly open - and to be a viable platform!, it can't have a restricted "whitelist". And I agree with this. But it's not clear that "mobile-browser-as-a-developer-platform" is a sustainable long-term pitch for an organization as small and as resource constrained as Mozilla.
So, there's a tension between these two perspectives. In purely "rational" terms, what's there is good, and there are a ton of other much more pressing issues to work on for the small teams - bugs, performance, missing functionality that can actually "move a needle", etc.
You can make an argument that in this case, the rational, data-driven engineers won. Which is the opposite of what HN seems to think of Mozilla! What's probably needed for full webextension support is a strong, perhaps not purely rational leader that will rally folks and actually push the teams to do the work that may be useless, or useful to a tiny percentage of the user base, in a belief that it'll produce a better future. Which may or may not pan out!
athrowaway3z|3 years ago