Just about a decade ago Microsoft faced similar charges for bundling IE with Windows OS. By the time the dust settled on all litigations, the competition was decimated or attenuated to stay in business.
I have to agree with him. I had to fix an app for a Huawei Honor 8x phone the other day. As the phone doesn't have Google Play Services and doesn't offer it in the app store - it's a huge pain using it. Enthusiasts can sometimes hack Google support on to an AOSP edition, but as app developers, we have to support what every day customers can do.
There are so many apps that won't work on it at all since Google has been steadily replacing AOSP services like location with Google Play proprietary versions. If you go to the open version of location services, you'll see there's a huge note at the top that you should really go use Google's version:
https://developer.android.com/guide/topics/location
And any app that requires that, isn't going to work on Android releases that don't have Google's blessing like Huawei.
The point regarding Play Services is valid, and if the parent comment had focused on that I would not have objected. But that doesn't mean AOSP is a "very small part" of Android or that it isn't open source.
The flip-side of your experience is that it highlights the existence of a large number of Android devices based on AOSP that don't run Google apps, particularly in the PRC. Aside from the Chinese market, you have a major company like Amazon selling millions of devices with their own AOSP fork on them. On an individual level, I can install Lineage OS on my unlocked devices and use apps from F-Droid as well as many others.
Play Services does have a significant foothold in many users' experiences, which bears discussion, but it doesn't invalidate AOSP. It is Android's open source nature that allows for forks and for apps to be shared across the Android ecosystem much more readily than programs developed for an actual proprietary operating system such as Windows.
And "Windows variants"? Comparing Windows backwards compatibility to the ability to run Android apps across different Android forks misses the point. All versions of Windows are proprietary operating systems owned by the same company: Microsoft. Amazon Fire OS, Lineage OS, and other Android forks are not.
Microsoft does license Windows to the same OEMs that are having fun with Android, which just like on Android are allowed to do a certain level of customisations.
Windows is not only what comes with a PC.
The only big difference is that AOSP costs zero dollars, euro, yen,.....
The difference is that it's free and open source. ROMs such as Lineage OS do not need to pay for a commercial license to fork the code, and an app such as F-Droid can run natively on any Android device.
We arrived at this after many years building multiple products. In all products we built we have just 3-4 plans. All features are included in all plans (including the trial plan). Only the usage amount differs from plan to plan. This makes it so easy to explain to end customers and leaves your engineering team with valuable time to deal with improving product. Further the number of billing related support requests decrease drastically. Your support staff also need less training.
The advantages are many to keep billing simple. This has been our experience. YMMV.
There are definitely a few moves you can make which avoid massive amounts of complexity if you're willing to accept a small downside. Another one is not allowing billing cycles to go past the 28th of the month thus making renewal logic simpler. Another thing would probably be just bill only in one currency (say USD).
Can you think of any other small things like that that help you massively reduce complexity? I think in the beginning it seriously makes sense to go with the simplest billing possible for as long as you can.
A valid business email is one where you should be able to receive and send mails. If you have a 'catch all' email id, the system does not accept that.
Having said that i must say our algorithm is deliberately a bit aggressive (so as to prevent spam).
Your email could very well be a false positive. Could you write to support@sess.email from the business email in question. I'll be happy to look into it and whitelist it.
What technical means do you use to detect a catch-all address? I know of no reliable method for that purpose, since receiving server cooperation would be required and could not be trusted.
This won't detect a catch-all address, but will almost always detect a catch-all domain: send email to [long random string]@domain. Does it bounce or is it accepted?
SESS is tightly wired to use SES (AWS). We do a bunch of algorithmic checks to validate email/domain validity plus assessing the risk-factor of uploaded email list. If you have a clean list deliverability is closer to 100%.
Edit: Thanks for the note. I will make a mention of the deliverability on the site.
We knew we could become a potential spam magnet. Like ive been mentioning in other comments here, we have an algorithm that does checks at multiple levels before a campaign is sent. If the algorithm deems the list as risky it triggers an automatic payment refund. The algorithm is also self learning. Over time its designed to assess the risk-function of an email list. (I'm from a data science background and SESS is a side project which uses learnings we get from elsewhere).
Like i mentioned in an earlier comment, we have a nifty little program that checks both the validity of the business email as well as the domain. Then a sampling of the list is done to weed out troublemakers. We do a little bit more. Unfortunately i can't get into specifics here :)
Hi, im one of the engineers that built SESS. I can't get into specifics but we have a nifty little algorithm that works at multiple levels right from checking whether you have a valid business email to email list scanning to match bounces from a master bounce list etc. etc. Finally if it deems the list is risky it triggers an automatic payment refund.
Let me rephrase your query. If you send 2 emails and 1 bounces, then your SBUR would be 50% and so will you be banned?
NO.
We predicted this would happen. The SBUR doesn't kick in for the first few thousand mails. Over time your list gets cleaner (because we keep track of bounces, unsubscribes and dont send them emails from next time on.)
Dirty spammer hack: include 50% of recipients as addresses you control, and that won't ever bounce, complain, or unsubscribe. That pushes SBUR down, likely below threshold.
These are often addresses created manually by 'click farmers' so they don't have obvious patterns which could enable an email service provider to identify them. (I'm still working on figuring out ways to detect this...)
Or, send spam to a new address via another service, then only use SESS to send to the ones who had opened or clicked on the other service. This is known as 'waterfalling'. Using this method, bounce rates can approach zero, and complaints/unsubscribes are likely to stay below 1% each - but make no mistake, ISPs can and will often still detect the email as spam.
You will need more complex ways to detect approaches like these, as well as other forms of spam/abuse. I would suggest starting with looking at thresholds for bounces, unsubscribes, and complaints independently - sometimes complaint rates of 0.1% can be a strong indicator of spam.
Related - don't limit your contractually-defined recourse to just SBUR rates. I would recommend including terms that allow you to ban or suspend users for any form of spam or abusive activity, "in the sole judgement of SESS.EMAIL" or similar. (I am not a lawyer and this is not legal advice.)
I mean, that's also an interesting question to ask, and a reasonable answer.
But it's not quite my original point - which is that if I don't know my SBUR rate, that would put me off ever starting to use this service. Though of course your competitors may have similar rates I'm just not aware of.
