5 ms·

Not sure in which reality you're living, but FirefoxOS was developed at Mozilla from 2011 to 2016, before any cut back. Mozilla Corp actually grew a lot during

Not sure in which reality you're living, but FirefoxOS was developed at Mozilla from 2011 to 2016, before any cut back. Mozilla Corp actually grew a lot during that time. About FxOS being mismanaged, well... you have to understand that if you follow a model where you rely on others for distribution (carriers and open market OEMs), you are bound to their constraints. In that case, it was a chicken and egg situation where selling devices without a WhatsApp app was very difficult, but WA didn't want to develop an app for a new OS until it grew to tens of millions of users. Then Moz top management lost some key proponents of the project, and the FirefoxOS haters got their wish. I still don't understand why Mitchel Baker didn't agree to support a community based project (like Thunderbird) or try a strong privacy based spin.

cxr 3y ago
> Moz top management lost some key proponents of the project, and the FirefoxOS haters got their wish That's an interesting way to say that the people who foresaw its imminent failure were correct—but (conveniently) does so in a way that not only downplays[1] the correctness of their prediction, but also maligns them by ever-so-subtly suggesting the reader consider whether blame for the resulting failure shouldn't perhaps be shifted onto those who made the prediction [1 again, unfortunately]... 1. <https://web.archive.org/web/20201022224913/https://www.colbyrussell.com/2018/10/11/mozilla-and-feedback-loops.html https://web.archive.org/web/20201022224913/https://www.colby...>
toast0 3y ago
> In that case, it was a chicken and egg situation where selling devices without a WhatsApp app was very difficult, but WA didn't want to develop an app for a new OS until it grew to tens of millions of users. Disclosure: I worked at WA during the FirefoxOS time period as well as when the KaiOS client was developed and launched. I honestly don't remember the internal sentiment on FirefoxOS, and I don't know if Mozilla ever approached WA to ask for a client. But the public interfaces for apps were insufficient for a WhatsApp client, so that's a bigger issue. The KaiOS client (which afaik, Jio approached FB/WA to ask for) was difficult to build in part because the OS was missing important features for apps, and that takes time and collaboration to get added to the OS and then pushed out to users. From memory, the major missing interfaces were around access to TCP sockets and ability to run code that accesses the network in response to a (silent) push message that optionally submits a notification for the user. If FirefoxOS didn't have push messaging (I can't remember), then ability to keep a socket open always and post notifications at will would suffice. Arbitrary tcp sockets are needed because the chat protocol is not http based; running code on pushes is required for e2e, so sender names can be populated from the device's address book, and to avoid notification horrors. Horrors include getting a notification about a message you can't read because the client hasn't fetched it yet and getting a notification about messages you've already read; WhatsApps model is the client is the source of truth, and so there's no reason to accept notification horrors that are common with server source of truth systems. e2e was under development for quite some time, so even if the public timelines don't match up, it would be a requirement for supporting new OSes. For calling, access to UDP sockets would also be needed as well as ability to run native code as the voice codec and data marshalling is in C; although Firefox OS came out before WhatsApp calling. Calling didn't make it to all platforms, and would have been an acceptable thing to defer, IMHO.
- fabrice_d 3y ago
  Hi! Yes Mozilla approached WA (talks were held with Brian Acton if I remember correctly). We tried various workarounds: - 3rd party clients. That worked initially, but WA was quite aggressive in breaking them, and once e2ee was added they stopped working. - we wrote a j2me VM in Javascript (https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet) to run the S40 version :) Perf was not good enough when dealing with java threads. - we collaborated with a company (OpenMobile) to run the Android app in a container, rendering in a DOM element. That was a pain in term of OS integration, and OpenMobile finally didn't get the distribution agreement from WA. I implemented the KaiOS additional APIs, basically exposing a subset of libsignal. You're right that there are missing pieces in the web stack for these apps - it's very frustrating that you can't rely on WebCrypto for all the e2ee. Let's hope WebAssembly will fix that!
  - toast0 3y ago
    > - 3rd party clients. That worked initially, but WA was quite aggressive in breaking them, and once e2ee was added they stopped working. Yeah, that happened. :/ I was mostly in favor of a light touch, but e2ee would have been a hard cutoff anyway, and we didn't have the desire to make a compliance program for 3rd party clients, so they just got the boot whenever they caused inconvenience. There would usually be a flurry of activity around individual changes, but afaik, third parties saw the writing on the wall when e2ee started showing up. > - we wrote a j2me VM in Javascript (https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet) to run the S40 version :) Perf was not good enough when dealing with java threads. Wow, that's impressive! (and kind of terrible!) Were you able to leverage this for other things, I hope? > - we collaborated with a company (OpenMobile) to run the Android app in a container, rendering in a DOM element. That was a pain in term of OS integration, and OpenMobile finally didn't get the distribution agreement from WA. I was unaware of this. That's interesting to hear about. I think you're right from your earlier post, that user count would have pushed WA the other way, and that lack of WA support made it harder to get user count. Samsung (Tizen) and Jio (KaiOS) got WA to make clients by subsidizing handsets and leveraging user counts / other business relations; s40 got a client because Nokia was clearly going to sell at least a few million of them (s40 predates WA, of course, but the earlier ones never ran WA); same with WP7, although no client until 7.5, because the platform was missing pieces. WebOS didn't get a client because the platform was missing pieces and didn't survive long enough to add them (lack of WA support wasn't really an issue, given the timing). MeeGo didn't get a client because Nokia cancelled the N9 before they launched it, and limited the release.
toyg 3y ago
> FirefoxOS was developed at Mozilla from 2011 to 2016, before any cut back It absorbed resources and focus, which resulted in the browser stalling development, which resulted in shrinking marketshare, which resulted in less money from the search deals, which resulted in the ongoing job losses. > you have to understand that [hard realities of the mobile market that everyone knows already] I don't disagree, but: none of that was new or unexpected when going in. That's why a lot of people thought FFOS was hopeless: because breaking the mobile duopoly is so hard, by then it had already claimed a giant (Nokia) and seriously humbled another (Microsoft). The play for the "developing market" and low-end devices was hopeless and misguided. We had just seen Nokia dying while trying to hang on that same market... There was a lot of wishful thinking in all the strategic moves, and unsurprisingly they didn't pan out.
- fabrice_d 3y ago
  > It absorbed resources and focus, which resulted in the browser stalling development, which resulted in shrinking marketshare, which resulted in less money from the search deals, which resulted in the ongoing job losses. That's history revision. The browser development didn't stall because of FirefoxOS, it was slow for other reasons (look at the leadership team changes when the Quantum started). Please remember that FxOS started in 2011. At the time WindowsPhone was quite new (first release in 2010), Samsung was pushing Tizen and Android was not nearly as dominant. Context matter. Mozilla already knew that Firefox would not be the default browser on Android (Google waited for Chrome to be ready to replace the crappy default one that was subpar compared to Firefox) so owning a platform was a logical step. It would still be better these days.
- toast0 3y ago
  > The play for the "developing market" and low-end devices was hopeless and misguided. I don't think that's right. The developing and low-end devices are probably the only plausible route into the phone market. Especially during the time period that FirefoxOS was active, there was a tremendous opportunity for a phone that cost very little and was widely available. I don't know that FirefoxOS could have really addressed that market, given their software stack, but the market was there. Wikipedia claims 23 million KaiOS devices were produced in Q1 2018; given that KaiOS is a fork of FirefoxOS, I think that's a demonstration that the targeting was fine. 23 million devices is a small chunk of the mobile market, but it's still a lot of devices. Microsoft was making significant gains in market share with WP7 and WP8 by having devices that were low cost and worked much better than similar cost Androids. In the US, you could go out and get a $60 wp7 device or a $100 wp8 device when they were new and have a much more usable phone than a $150 Android. and an iPhone was like $400-$500 at the time. Microsoft had some high end wp7 and wp8 devices too, but not many people bought them, because high end iPhones and Androids worked well, and at that price point you're looking for different things. WM10 had promise and interesting features (Continuum might have been pretty cool, especially if Intel hadn't dropped development of x86 phones days before the Continuum public demo), but WM10 didn't run well on low end phones, so there were no low end WM10 phones, and user growth evaporated. (It doesn't help that WM10 included at least the 3rd new framework for windows phones in 3 generations, and called this one 'universal', which meant it only ran on the OS which had the least number of phones for its whole lifetime....)
toastal 3y ago
Capyloon is an alternative trying to carry the FxOS torch, but its focus on IPFS & things other than telephony make it hard to recommend if you can’t use a phone as a phone.
- fabrice_d 3y ago
  Thanks for the mention! Capyloon (https://capyloon.org https://capyloon.org) had a grant from Protocol Labs (the IPFS stewards) in 2022 so we focused quite a bit on that indeed. We learned a lot - especially about the maturity and usability of the IPFS stack. I'm still very bullish on the dWeb pieces: content based addressing, UCANs (https://ucan.xyz/ https://ucan.xyz/) for distributed auth, new web app models (https://hackmd.io/@robin-berjon/tiles https://hackmd.io/@robin-berjon/tiles) to create an ecosystem that is not locked by centralized app stores. There's a lot to do, all contributions are welcome (frontend, device ports, platform apis...). We have a Matrix channel (https://matrix.to/#/#capyloon:matrix.org https://matrix.to/#/#capyloon:matrix.org) and you can try desktop builds easily following the steps at https://github.com/capyloon/nutria#quick-start https://github.com/capyloon/nutria#quick-start

cxr 3y ago

> Moz top management lost some key proponents of the project, and the FirefoxOS haters got their wish That's an interesting way to say that the people who foresaw its imminent failure were correct—but (conveniently) does so in a way that not only downplays[1] the correctness of their prediction, but also maligns them by ever-so-subtly suggesting the reader consider whether blame for the resulting failure shouldn't perhaps be shifted onto those who made the prediction [1 again, unfortunately]... 1. <https://web.archive.org/web/20201022224913/https://www.colbyrussell.com/2018/10/11/mozilla-and-feedback-loops.html https://web.archive.org/web/20201022224913/https://www.colby...>

toast0 3y ago

> In that case, it was a chicken and egg situation where selling devices without a WhatsApp app was very difficult, but WA didn't want to develop an app for a new OS until it grew to tens of millions of users. Disclosure: I worked at WA during the FirefoxOS time period as well as when the KaiOS client was developed and launched. I honestly don't remember the internal sentiment on FirefoxOS, and I don't know if Mozilla ever approached WA to ask for a client. But the public interfaces for apps were insufficient for a WhatsApp client, so that's a bigger issue. The KaiOS client (which afaik, Jio approached FB/WA to ask for) was difficult to build in part because the OS was missing important features for apps, and that takes time and collaboration to get added to the OS and then pushed out to users. From memory, the major missing interfaces were around access to TCP sockets and ability to run code that accesses the network in response to a (silent) push message that optionally submits a notification for the user. If FirefoxOS didn't have push messaging (I can't remember), then ability to keep a socket open always and post notifications at will would suffice. Arbitrary tcp sockets are needed because the chat protocol is not http based; running code on pushes is required for e2e, so sender names can be populated from the device's address book, and to avoid notification horrors. Horrors include getting a notification about a message you can't read because the client hasn't fetched it yet and getting a notification about messages you've already read; WhatsApps model is the client is the source of truth, and so there's no reason to accept notification horrors that are common with server source of truth systems. e2e was under development for quite some time, so even if the public timelines don't match up, it would be a requirement for supporting new OSes. For calling, access to UDP sockets would also be needed as well as ability to run native code as the voice codec and data marshalling is in C; although Firefox OS came out before WhatsApp calling. Calling didn't make it to all platforms, and would have been an acceptable thing to defer, IMHO.

fabrice_d 3y ago
Hi! Yes Mozilla approached WA (talks were held with Brian Acton if I remember correctly). We tried various workarounds: - 3rd party clients. That worked initially, but WA was quite aggressive in breaking them, and once e2ee was added they stopped working. - we wrote a j2me VM in Javascript (https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet) to run the S40 version :) Perf was not good enough when dealing with java threads. - we collaborated with a company (OpenMobile) to run the Android app in a container, rendering in a DOM element. That was a pain in term of OS integration, and OpenMobile finally didn't get the distribution agreement from WA. I implemented the KaiOS additional APIs, basically exposing a subset of libsignal. You're right that there are missing pieces in the web stack for these apps - it's very frustrating that you can't rely on WebCrypto for all the e2ee. Let's hope WebAssembly will fix that!
- toast0 3y ago
  > - 3rd party clients. That worked initially, but WA was quite aggressive in breaking them, and once e2ee was added they stopped working. Yeah, that happened. :/ I was mostly in favor of a light touch, but e2ee would have been a hard cutoff anyway, and we didn't have the desire to make a compliance program for 3rd party clients, so they just got the boot whenever they caused inconvenience. There would usually be a flurry of activity around individual changes, but afaik, third parties saw the writing on the wall when e2ee started showing up. > - we wrote a j2me VM in Javascript (https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet) to run the S40 version :) Perf was not good enough when dealing with java threads. Wow, that's impressive! (and kind of terrible!) Were you able to leverage this for other things, I hope? > - we collaborated with a company (OpenMobile) to run the Android app in a container, rendering in a DOM element. That was a pain in term of OS integration, and OpenMobile finally didn't get the distribution agreement from WA. I was unaware of this. That's interesting to hear about. I think you're right from your earlier post, that user count would have pushed WA the other way, and that lack of WA support made it harder to get user count. Samsung (Tizen) and Jio (KaiOS) got WA to make clients by subsidizing handsets and leveraging user counts / other business relations; s40 got a client because Nokia was clearly going to sell at least a few million of them (s40 predates WA, of course, but the earlier ones never ran WA); same with WP7, although no client until 7.5, because the platform was missing pieces. WebOS didn't get a client because the platform was missing pieces and didn't survive long enough to add them (lack of WA support wasn't really an issue, given the timing). MeeGo didn't get a client because Nokia cancelled the N9 before they launched it, and limited the release.

toyg 3y ago

> FirefoxOS was developed at Mozilla from 2011 to 2016, before any cut back It absorbed resources and focus, which resulted in the browser stalling development, which resulted in shrinking marketshare, which resulted in less money from the search deals, which resulted in the ongoing job losses. > you have to understand that [hard realities of the mobile market that everyone knows already] I don't disagree, but: none of that was new or unexpected when going in. That's why a lot of people thought FFOS was hopeless: because breaking the mobile duopoly is so hard, by then it had already claimed a giant (Nokia) and seriously humbled another (Microsoft). The play for the "developing market" and low-end devices was hopeless and misguided. We had just seen Nokia dying while trying to hang on that same market... There was a lot of wishful thinking in all the strategic moves, and unsurprisingly they didn't pan out.

fabrice_d 3y ago
> It absorbed resources and focus, which resulted in the browser stalling development, which resulted in shrinking marketshare, which resulted in less money from the search deals, which resulted in the ongoing job losses. That's history revision. The browser development didn't stall because of FirefoxOS, it was slow for other reasons (look at the leadership team changes when the Quantum started). Please remember that FxOS started in 2011. At the time WindowsPhone was quite new (first release in 2010), Samsung was pushing Tizen and Android was not nearly as dominant. Context matter. Mozilla already knew that Firefox would not be the default browser on Android (Google waited for Chrome to be ready to replace the crappy default one that was subpar compared to Firefox) so owning a platform was a logical step. It would still be better these days.
toast0 3y ago
> The play for the "developing market" and low-end devices was hopeless and misguided. I don't think that's right. The developing and low-end devices are probably the only plausible route into the phone market. Especially during the time period that FirefoxOS was active, there was a tremendous opportunity for a phone that cost very little and was widely available. I don't know that FirefoxOS could have really addressed that market, given their software stack, but the market was there. Wikipedia claims 23 million KaiOS devices were produced in Q1 2018; given that KaiOS is a fork of FirefoxOS, I think that's a demonstration that the targeting was fine. 23 million devices is a small chunk of the mobile market, but it's still a lot of devices. Microsoft was making significant gains in market share with WP7 and WP8 by having devices that were low cost and worked much better than similar cost Androids. In the US, you could go out and get a $60 wp7 device or a $100 wp8 device when they were new and have a much more usable phone than a $150 Android. and an iPhone was like $400-$500 at the time. Microsoft had some high end wp7 and wp8 devices too, but not many people bought them, because high end iPhones and Androids worked well, and at that price point you're looking for different things. WM10 had promise and interesting features (Continuum might have been pretty cool, especially if Intel hadn't dropped development of x86 phones days before the Continuum public demo), but WM10 didn't run well on low end phones, so there were no low end WM10 phones, and user growth evaporated. (It doesn't help that WM10 included at least the 3rd new framework for windows phones in 3 generations, and called this one 'universal', which meant it only ran on the OS which had the least number of phones for its whole lifetime....)

toastal 3y ago

Capyloon is an alternative trying to carry the FxOS torch, but its focus on IPFS & things other than telephony make it hard to recommend if you can’t use a phone as a phone.

fabrice_d 3y ago
Thanks for the mention! Capyloon (https://capyloon.org https://capyloon.org) had a grant from Protocol Labs (the IPFS stewards) in 2022 so we focused quite a bit on that indeed. We learned a lot - especially about the maturity and usability of the IPFS stack. I'm still very bullish on the dWeb pieces: content based addressing, UCANs (https://ucan.xyz/ https://ucan.xyz/) for distributed auth, new web app models (https://hackmd.io/@robin-berjon/tiles https://hackmd.io/@robin-berjon/tiles) to create an ecosystem that is not locked by centralized app stores. There's a lot to do, all contributions are welcome (frontend, device ports, platform apis...). We have a Matrix channel (https://matrix.to/#/#capyloon:matrix.org https://matrix.to/#/#capyloon:matrix.org) and you can try desktop builds easily following the steps at https://github.com/capyloon/nutria#quick-start https://github.com/capyloon/nutria#quick-start